Transform Help Request

owen_sparks

Hi folks.

Another newbie FS request.  Please can I have some help with a transform?  I'll admit I'm finding the "help" hard to deal with.  It's a bit like Microsoft's help in that you need to be proficient in the subject to understand the help in which case you wouldn't be reading it in the first place...  Actually that's a bit unkind, if you think of it as a technical reference for looking up parameters then it fits that use case well but if you're a newbie it's a whole different story.  I've got this far mostly with help from OS staff and helpful forum users. (Thanks for that BTW.)

Background:-

Feature is a part of my company specific standard content widget.

Desired functionality is to select a sketch point or mate connector and the feature will derive in a desired part and optionally create the appropriate void for it to fit into.  In this example we're using a type of bolt often used in furniture making. 

We have a configurable PS to build the bolt for us, and a solid model of the void we require for that series of parts. 

The void is modeled in a separate PS around the origin.

By controlling where this "void part" is placed we can allow the bolt to be positioned on the surface of the target part or to have it recessed such that it is flush with the surface.

https://cad.onshape.com/documents/309774b0db75c727fcc46027/v/55155edf378d217f4fe46822/e/4047d3a40cec759f8029bbd6 Chopped down example file here.

It's this additional "flush" transform I'm stuck on, the rest is working as intended.  I have an initial transform to take the part from the source studio and move it to the target sketch point or MC. 

 try silent //Build Transform as if target is Mate Connector
                            {
                                transform  = toWorld(evMateConnector(context, {
                                    "mateConnector" : TargetPoints[i]       
                                    }));
                               
                                if (definition.isFlipped)
                                            {
                                               
                                            }
                                   
                                debug(context, "LoopCounter:- " ~ i);
                                debug(context, "is a Mate Connector");
                            }              
                           
                            try silent //Build Transform as if target is Sketch Point
                            {
                                var skPlane = evOwnerSketchPlane(context, {
                                        "entity" : TargetPoints[i]
                                    });
                               
                                skPlane.origin = evVertexPoint(context, {
                                            "vertex" : TargetPoints[i]
                                        });
                               
                                if (definition.isFlipped)
                                            {
                                                skPlane.normal *= -1;
                                                skPlane.x *= -1;
                                            }
                               
                                transform  = toWorld(coordSystem(skPlane));
                               
                                debug(context, "LoopCounter:- " ~ i);
                                debug(context, "is a Sketch Vertex");
                            }

Later:-

//Add void if selected<br>                        if (definition.AddConnectorBoltVoid)<br>                        {<br>                            const instantiatorVoid = newInstantiator(id + i + "instantiateVoid");<br>                            addInstance(instantiatorVoid, ConnectorBoltVoid2::build, {  "transform" : transform} );<br>                <br>                            instantiate(context, instantiatorVoid);<br>                    <br>                                //Boolean remove Void from TargetPart<br>                    <br>                                opBoolean(context, id + i + "booleanVoid", {<br>                                "tools" : qCreatedBy(id + i + "instantiateVoid", EntityType.BODY),<br>                                "targets" : definition.TargetPart,<br>                                "operationType" : BooleanOperationType.SUBTRACTION<br>                                });  <br>                        }<br>                        

So my question is how do I apply an additional transform to my part before the boolean?  I have a variable defined but I'm at a loss as to what to do with it. 

var FlushTransformDistance is ValueWithUnits = 2.25*millimeter;

I understand we can perform multiple transforms by multiplying them together, and we can build one with a vector but that's about it.  How to build this?  How do we have it apply to local space?   

Have tried for a while and am at tearing hair out stage so am asking here before I break something expensive...

Thanks all,

Owen S.

konstantin_shiriazdanov

the general idea is if you need some additional transform (the moovement of the tool body) you can make it before the main transform and the resulting transform would be a composition of 2, in OS it wil be a product of 2 transforms:

if (definition.AddConnectorBoltVoid)
{
transform =  transform * transform(vector(0,0,-0.005)*meter)
...
}

note that it is not a good idea to name a variable as a builtin function so i would name your transform variable as tr

ilya_baran

To be clear, variables shadowing functions is correct behavior -- in most c-like programming languages, variables declared in inner scopes shadow symbols in outer scopes.  It's also desirable because it lets a library writer add new functions to the library without worrying about breaking a function in code that uses that library that happens to use a local variable name that matches the new function name.  I'm not sure warning about shadowed symbols will provide more noise or signal; would need to think about that.

konstantin_shiriazdanov

the general idea is if you need some additional transform (the moovement of the tool body) you can make it before the main transform and the resulting transform would be a composition of 2, in OS it wil be a product of 2 transforms:

if (definition.AddConnectorBoltVoid)
{
transform =  transform * transform(vector(0,0,-0.005)*meter)
...
}

note that it is not a good idea to name a variable as a builtin function so i would name your transform variable as tr

owen_sparks

Hi @konstantin_shiriazdanov and thanks for your help, it's appreciated.

I swear I tried exactly that right at the beginning, and all seemed well.  The featurestudio accepted the code, but it fell over as soon as it was run.  Your "note" on "builtins" is of course the culprit, as soon as the code was changed to

Mytransform =  Mytransform * transform(vector(0,0,-2.25)*millimeter);

it all worked as expected.

@kevin_o_toole_1

 Can we beat up Onshape on this point?

https://cad.onshape.com/FsDoc/imports.html 

It would be nice if the IDE rejected variable names that are reserved!

Cheers all,

Owen S.

Jake_Rosenfeld

@owen_sparks

Good find.  Our standard practice is to say 'const xform = toWorld(...)'

I'll write up a bug.

owen_sparks

Jake_Rosenfeld said:

@owen_sparks

Good find.  Our standard practice is to say 'const xform = toWorld(...)'

I'll write up a bug.

Thanks Jake, Onshape's commitment to address even small niggles like this is impressive.

Owen S.

mortezaPourmohamadi

@Jake_Rosenfeld

How is the bug fix going? 

I just wasted a whole morning struggling to define a simple translate transform with no luck.

Then I found this post by @owen_sparks and realised that the bug is still in there. 

Jake_Rosenfeld

@mortezaPourmohamadi

Fell through the cracks, thanks for the reminder.  I've reprioritized and added you to the ticket.

Jake_Rosenfeld

FYI it will be a lot easier to fix the documentation to not make this error than to fix the root issue that variables are allowed to shadow function names etc.  We cannot get rid of that behavior because it would break numerous feature studios.  We could warn for shadowed variables, but it is a lot of work, and we would need to find time for it.  I will write up an improvement for that too.

ilya_baran

To be clear, variables shadowing functions is correct behavior -- in most c-like programming languages, variables declared in inner scopes shadow symbols in outer scopes.  It's also desirable because it lets a library writer add new functions to the library without worrying about breaking a function in code that uses that library that happens to use a local variable name that matches the new function name.  I'm not sure warning about shadowed symbols will provide more noise or signal; would need to think about that.