Stop trajectory before entering workspace

    Hello,


    I am working with a KR120R3200PA and a KRC4 KSS 8.6.6.

    I hace defined several workspaces to avoid existing obstacles while palletizing but the robot only stops once it enters them, while when the destination point of a motion is outside the range it stops before starting said motion.

    I would like the robot to stop before executing the motion that goes through the workspace as it does when it tries to go outside it's reach. Is this possible?

    The problem I have with the workspaces is that it takes a moment to react and stop when it violates one so they have to be very big to not hit anything when moving at speed.

    Thank you

    of course it is possible but that is what makes life interesting. if your motions are using spine, there is a stop condition. it is the best and simplest way to achieve what you want.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Hi panic mode,

    Are you referring to the STOP WHEN PATH instruction? But how would I program this stop condition? The robot controller raises a flag when the workspace is already violated, unless there is another way to know before the spline motion begins that I'm not familiar with

    all right... i will have to take that back... i have re-read your posts and this is not necessarily what i assumed (sorry).


    actually to be honest i am not even sure what spaces you are referring to. perhaps you can try to elaborate exact setup, types of used spaces and how they are configured and why the spaces are needed at all.


    in general both safety and standard spaces can be configured to monitor only or to stop robot.


    if the space is configured to stop the robot ... and robot enters... then stop will be triggered.

    if the space is configured to monitor only ... and robot enters ... it will not stop robot but will tell you if the robot is inside the space or not.


    if you want robot to stop sooner, you need to increase the size of the space... or perhaps use additional space.


    if the robot need to move fast, stopping distance will be longer. there is no way around that. and palletizers tend to be wicked fast. but that is why they need clearances so they have the room to move.


    and now to what i was had in mind.. palletizers tend to move using same trajectories. so if you have an interlock of some sort and space is activated by condition. that condition could be used to stop (or slow down) robot. if there is no need to stop, robot will fly through without stopping. it is a cycle time saver. but i am not sure how your motions are programmed and what the real situation or goal there is.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Ok, that was very clear. My question was more general, not specifically about palletizers. I've done other projects where smaller robots are guided by cameras and in those cases the trajectories were much more uncertain, and my question applies much more to that rather than to the palletizing application.

    In any case, I'll just make sure all workspaces have sufficient margin to stop at high speed.

    Thank you panic mode

    The root issue here is that the robot does not do a "simulation" of a move before it executes. When a PTP command is executed, the path planner basically calculates the end of the motion, issues each axis a command to move in that direction at that speed, and doesn't look at it again until the PTP is finished. The path planner is not "aware" of any of the motion along the way, except as a set of accel/decel/time profiles.


    The workspace checker, OTOH, is a "realtime" task, that is only monitoring the actual position of the TCP and/or axes and checking them against the workspaces every IPO cycle. It's not "aware" of where the robot is going, only where it is at any given moment.


    LIN motions are basically a string of very small PTP motions run in sequence, and the path planner is only really "aware" of the next 2-3mm of motion.


    I have seen applications where someone tried to create a "path awareness" check, but it got very complex very fast. A planned motion would be divided into "chunks" of a certain distance, and the program would run each "chunk" destination through INVERSE and FORWARD and check the results against the WorkSpaces, then only execute the LIN or PTP if all the "chunk checks" passed. The KRC processor is usually fast enough to do some of these checks in advance without breaking the ARP, if your program is well structured, but you quickly run into an issue of resolution -- checking every 1000mm makes it easy to miss that you might clip the corner of a workspace, but checking 1mm will probably bog down the processor and break the ARP. Then, of course, every in/out check has to be hand-coded, as well.

    I'm inclined to partially disagree. This is apparently not well documented and I could be wrong but e.g. $DIST_NEXT does not work with PTP motions. But from what i've tested it does work with SPTP, which in turn suggest the updated motion planner is atleast more aware than I was expecting.


    $DIST_NEXT could be implemented in a submit where you could abuse $OV_PRO for the purposes discussed above with well situated points for the task. Not an elegant solution but in principle functional.


    I will doublecheck my claims tommorrow but I'm fairly confident.

    Quote from Hes

    $DIST_NEXT could be implemented in a submit where you could abuse $OV_PRO for the purposes discussed above with well situated points for the task. Not an elegant solution but in principle functional.

    $DIST_NEXT is a scalar value, however. It won't tell you anything about whether the next move passes through a workspace or not.

Advertising from our partners