Hi my friends,
Can the "LIN" instruction stop on the path to record the pos_act then execute the another instruction?
My meaning is the LIN instruction can stop on the way to the end point?
Best,
Hi my friends,
Can the "LIN" instruction stop on the path to record the pos_act then execute the another instruction?
My meaning is the LIN instruction can stop on the way to the end point?
Best,
any motion can be stopped then another code executed. but if you only wish to record position, why bother stopping? you can record on fly. either way, this is what interrupts are for.
What Panic said^^
Also, when recording position with interrupt, use $pos_int instead of $pos_act.
Hi panic,
I need to detect the position of a work piece and then run on it.
robot moves forward, input a signal after hitting the work piece, stops,records the position of the work piece, and then execute other instruction.
How to do robot can stop before end point?
Many thanks,
The robot is to search for a part on a path. The part is detected by means of a
sensor at input 15. Once the part has be en found, the robot is not to continue
to the end point of the path , but to return to the in terrupt position and pick up
the part. The main program is then to be resumed.
DEF PROG()
INI
...
INTERRUPT DECL 21 WHEN $IN[15] DO FOUND()
PTP HOME
...
SEARCH()
...
END
DEF SEARCH()
INTERRUPT ON 21
SPLINE
SPL START_SEARCH
SPL IN_BETWEEN
SPL END_SEARCH
ENDSPLINE
WAIT FOR TRUE
...
END
DEF FOUND()
INTERRUPT OFF 21
BRAKE
LIN $POS_INT
... ;The robot grips the found part.
RESUME
END
Almost, like what you wrote, but needs some changes:
DEF PROG()
INI
...
INTERRUPT DECL 21 WHEN $IN[15] DO FOUND()
PTP HOME
...
INTERRUPT ON 21
PartFound = False
$advance = 0
SEARCH()
$advance = 3
if PartFound then
... ;The robot grips the found part.
...
END
DEF SEARCH()
SPLINE
SPL START_SEARCH
SPL IN_BETWEEN
SPL END_SEARCH
ENDSPLINE
END
DEF FOUND()
INTERRUPT OFF 21
BRAKE
FoundPartAt=$pos_int ;// declared as a global pos/frame variable
PartFound=True ;// global bool variable
RESUME
END
Display More
better but still not right...
risk of collision since interrupt is never turned off if search completes without finding part and $IN[15] turns on for some reason AFTER the search.
solution is to ALWAYS turn off no longer needed interrupt - regardless if something was found or not.
this is what result could be:
this is what result could be:
After reading the title, I expected an explosion. Feeling a little let down, but that's my own fault.
While we are at it, don't run untested code at speeds higher than you can react, folks.
that is the thing... just like with advance run, program could run many cycles without observable issue so one would get false impression that program is tested....
I agree, turning interrupts off is as needed as turning them on at appropriate time. I should have known better than that when providing an example to someone, who is just starting to use them.
My comment about untested code, was more of a general idea Also, by "testing" I meant, more of running the code under different conditions to determine if it's fit for use not only in normal or perfect conditions. IMO in automation, 1 in 10000 is a "when", not "if".
You are all responsible, thanks
You need to be a member in order to leave a comment