Is it possible to pull a variable back into a previous Event?
My very first Post had a lot of hard coded outputs.
I now want to change the behaviour in the Program Start Sequence Events based on variables that do not appear until the Operation "Object" Start Events in NX.
So, if a variable created from a UDE in the Operation Start Events in NX exists I want to branch some logic based on this.
However, if I post out at the moment I am getting an alarm to say the variable does not exist - obviously because it does not appear until the Next Event (Operation Start Sequence).
Thanks in advance.
It is a challenge to go back and put something in. Once a line is output by code in a previous event - it is done. There are some lookahead variables - but they may not be what you need - and may not be available. For these look for "next" or "nxt" in the variables browser. What someone would typically do is mark a line (I use "<- B_ouput_next_sop" for example) and store the value when you get where you know - then open the file after posting - look for the markers - and replace the line with the value.
Note the "look ahead" (basically) only works AT and/or AFTER the initial / first move events. If you need something earlier, you are out of luck.
To enable, add this somewhere in "start of path"
global mom_kin_read_ahead_next_motion set mom_kin_read_ahead_next_motion 1 MOM_reload_kinematics
Note attributes ARE available earlier (part attributes are available in "start of program") so if you can use attributes to do what you need, try them. Look for variables like "mom_attr_"
Production: NX10.0.3.5 MP16/TC11.2
I'd rather be e-steamed than e-diseaseled
Your idea of substitution on reprocess doesn't always work. It may be done for simple output of some values. However UDE variables often control the subsequent logic of postprocessing, and it is not a situation of single substitution...
The File/Properties attributes were my "get out clause"!
I just thought I'd ask if anyone knew how to pull back UDE variables. I didnt think it could be done; well not simply anyway.
I will just add an attribute and TCL "if info exists" as a safeguard measure against making all my previously posted programs redundant.
TCL is very flexible. I often load command strings into lists. Even your substitution string could be "hard coded" in the list of commands. The point is there is no look as far forward as you want and go back ability - but you can decide that you need to do something and do it later when you know everything you need to know - or after posting.
I say about another thing. For example, you have UDE Set Polar. Then program of WHOLE tool path looks different than it is without this UDE.
What are you going to substitute? Every string? So substitution is an useless method when UDE is used for switching some modes of output.
The correct decision is not to go forward/back but process UDE "AT and/or AFTER the initial / first move events" as Ken_A said above. The substitution like yours may be used but only sometimes.
Agreed. If you don't even know kinematic when dumping out points (waiting for later to find out) things will get more complicated than substitution (put out point vectors - expand kin - output code later.)