Setting E6POS variable to null value?

[bert]

When the controller is first booted, looking at an uninitialised E6POS variable in "Variable Overview" you see the value given as {E6POS:}

After you initialise the variable it is shown as {E6POS: X 150, Y 100 ... etc.

Does anybody know if there is there any way to "uninitialise" the variable again so that it has the original null value?

[SkyeFire]

You want it uninitialized, or just set to all 0s?  Setting it to 0 is easy, although it takes a few lines of code:  just work your way from E6POS.X through to E6POS.E6, setting each subvariable to 0 as you go.
Or, as an easy out, you could just do Pos_Variable=$NULLFRAME.  That will zero out the XYZABC elements, and "remove" the S,T, and E1-6 elements.

The system considers any variable that has no value (for example, a variable that has been declared but not assigned yet) to have an "invalid value," so it won't really let you set a variable to nothing.  You can set it to zero, but not back to the invalid state it had had immediately after being declared.  You can try this by declaring two variables (x and y), modify one (x), then try x=y.  The system won't let you do it.

[mookie]

as an added note, If you write to that variable as a whole using the plugin, remember to add the E6POS or else youll go fatal

Position = {x 0,y 0,z 0,a 0,b 0,c 0} ; wont work

Position = {E6POS: x 0,y 0,z 0,a 0,b 0,c 0} ; will

[bert]

Thanks for the replies.

I really would like to uninitialise the variable so that the robot will not even attempt to move to the point if it is asked to.

Imagine the scenario (shouldn't be too difficult ;)) in which I am feeding the value of the E6POS into the robot controller from an external program (or plugin). Under certain conditions it is possible that the external system fails to update the variable correctly. At this time the robot may then attempt to move to the last position that was written into said variable with possibly undesired consequences.

My other solution is just to write some numbers into the variable that will put the robot way outside of it's envelope, but thought that just nulling it out would be a neater solution if it was possible.

[mookie]

Can you explain the scenario a little more, I know your intentions but what is it your actually trying to do?

if you want to stop the robot, you can just write the variable to

Code:

p1 = {e6pos:}

this is going to stop the robot but is that the result that your actually looking for to achieve a clean automated solution?

[mookie]

know what im saying?

if you dont want the robot to go to the position, then what do you want to happen? Im going to go forward and assume that the next krl command will be a lin move, you may need to conditionalize the statement to have it skip the move and either recheck the operation or move on to the next task.

[bert]

I tried setting the value of the variable as you suggested-

Code:

p1={e6pos:}

from within the robot program. I know that's not exactly what you said, but that's actually what I wanted to do when I thought about it a bit more. Anyway, I get an error "Component name expected" on the teach pendant.
What I'm trying to do is to make the program "safe" so that after the robot has moved to a position that is set by the measurement system, the variable is cleared so that it will not try to move to the same corrected position again. The variable *should* be updated by the measurement system again before the robot attempts to move again. However, we came across an unusual situation (when the measurement system had basicaly crashed) where the robot went to an unexpected position since the corrected position had not been updated correctly by the measurement system. Obviously, in such a condition it is preferable if the robot does not move at all.
I have put in an extra boolean variable and pre-move check so that the robot won't move anyway, but thought that for extra security the robot should overwrite the previous variable contents just to make extra sure.

Hope that makes my intentions a bit clearer...

[SkyeFire]

I did a little bit of experimenting, but didn't find a way to uninitialize the variable.  The only approach I can think of would be to put your point and motion into a separate subroutine, with the point DECL'd at the top, but only assigned a value if/when the measurement system completes a new measurement (something interrupt-based, say).  Depending on how your program needs to be structured, it might be possible to *keep* your E6POS variable in a declared-but-never-assigned state unless and until your measurement system cycles. 

The other idea that comes to mind would be a "safe" position, if there is such a pos in your workspace, that you could always set the E6POS variable to after you've moved to it, so that in any situation like you describe the robot would at least move to a known, harmless position.  Or, always set the E6POS to some ridiculous number, like X=100000, which is absolutely guaranteed that the robot won't even *try* to reach b/c it's so incredibly far out of the robot's motion envelope.  That would generate a motion envelope error

Or... depending on how much the robot needs to move after a measurement, you *could* try doing something with the workspace monitoring, setting it on the fly to $POS_ACT (+/-) a range.  But that only works if a "bad" measurement will cause the robot to definitely move further than a "good" one. 

[bert]

You've got a couple of interesting ideas there...

Setting the numbers in the E6POS to something huge was my backup option, but thought that it would just be *nicer* to nullify the variable. Either way, I don't intend the situation to ever arise again where it would cause a problem, but you can never forsee every posible scenario.

I actually asked the original question with another couple of little things in mind. I can think of one or two more situations where I would like to nullify variables, but it has evaded my efforts so far.

I'm going to have a little think now about your other suggestions. I can't work out all of the consequences of them without a little more thought and coffee...