Hi all, I’m trying to get a Dynamic Component set up so I can “free move” it or have its location defined by attributes. I want the user to have the option for Auto/Manual, and that would determine if you can “free move” the component or if it has a defined placement.
So far I’ve set up an option for auto/manual that the user can select, resulting in 0 or 1. Then I used an IF statement to define placement on each axis using the following. =IF(userselction=0, PlacementX, 0) The problem is once userselection is set to 1 the component is placed at the origin. I can’t figure out what I need to put in place of the 0 so that when userselection is 1 I can move the component normally with my cursor.
I’ve attached a test file to help show what I’m trying to do, does anybody have any ideas or a different approach I can try?
So I’ve been playing around with this today and it works with linear movement, but I can’t get it to work with rotation attributes.
I tried the following =IF(userselction=0, rotation ,current(“RotZ”)) with “rotation” being the user definable rotation angle. Using this IF statement doesn’t work as it wont return a value for RotZ.
My next step was to set a test attribute that is defined as =current(“RotZ”). This attribute will remain at zero even when the component is rotated. The only time that this value changes is if I manually set RotZ to a value using the DC UI.
Next I manually rotated the component -45 deg and checked the _inst_rotz value using the ruby console. It reads 0 even though the component has been rotated (screen snip below). At this point it looks like Sketchup doesn’t insert a value for RotZ until you manaully set one with DC UI.
I’m confused why this works on position but not rotation, any thoughts?
Yes, we use Sketchup to make sure our conveyors and processing equipment will fit on site. My goal is each component(DC) has a defined input and output point that can be linked using a ruby plugin (Still learning Ruby for that part).
This would be hugely beneficial to link our equipment together so if you change the placement of one piece the others follow, and I’m hopeful we can get to that point.
However, there will be times we want to move a component into place manually and this is what I’m trying to figure out at the moment. We have too many components in our library to have 2 separate components for each part.
I guess we could go into component options and delete the RotZ formula every time but I would really like to minimize the amount of editing required inside the component so its less confusing.
So you want a component placer, that is to select a file, have it placed at a point and link it to another. Do any of these existing components scale?
I think a set of proxy DCs (symbolic) that cover the type and range of the existing components, would make the connections easier. Then they can be swapped for the detailed ones after or swapped back again. These proxy DCs can have properties beyond that of the existing.
Yes this is the goal. None of the components will be scaled, it will all be move/rotate.
I hadn’t thought of this but I’m hoping that our existing models are small enough file size to make this work. We already omit textures and we delete all internal details that aren’t important. Our largest file size for a full site location without DCs is about 10MB. I have noticed that DCs add considerably to file size.
I’ll draw up a more detailed example to show what we’re aiming for.
Yes, this worked, but only if RotZ is undefined. I tried typing =IF(userselction=0,rotation,test) into RotZ and then this doesn’t allow the =current(“Rotz”) to update. Once an equation is entered into Rotz the display changes from 0 deg to 0.0 deg, I believe I saw a post about this recently that was a similar bug.
The next step may be to leave rotation undefined so the user can rotate the component normally and then the user will have to add the rotation equation later.
Forgot to upload the component as it is now. Whatever the value of RotZ is when you type an equation into it is where it will revert to after a redraw.
Generally, we may not want to do this. Put custom formulae in custom attributes that reference the standard attributes like “X”, “LenX” and “RotX”, etc.
I just coded up a test fix (Ruby extension) for this bug and it works for me when I create a custom attribute named "Rotation" set to =current("rotz"), and then let “RotZ” be set by the user or by the RotateTool. (Ie, you need to change the access for “RotZ” so that “Users can edit as a Textbox”.)
OK, I follow what you’re saying and I also got this to work also. Problem I’m still having is:
I can’t figure out how to get this part to work without an IF statement in RotZ or have RotZ set equal to another attribute that has an IF statement in it. But any time a formula is entered into RotZ it will not allow the component to be rotated manually.
Right, because the formula is restricting the attribute.
You may be over thinking this. From the end user POV, they will just want to go ahead and use the tool if they wish. The others that need to and prefer to enter some precise angle and need to enter decimal numbers will want to just do that.
The problem with the dialogs not updating can be overcome with a Ruby extension using observers to do the reselect (which causes the DC extension to redraw the component and update the dialogs.)