SafeOp Workspaces, velocity reductions, and testing

    I have more than a little experience with SafeOp (3.2 or so, currently), but lately I've been feeling that I'm not doing as well with it as I should. One reason for this is a series of cells with very oddly shaped fence perimeters, requiring me to "stack" multiple zones like Lego bricks when the actual Cell Perimeter couldn't handle all the concave shapes. These cells also included too many instances of working positions that required the end effector to come very close to the physical fence line, resulting in a large number of safety speed reductions.

    My usual approach is to plot out the fence lines and corners on paper or CAD, relative to $WORLD, and create my Cell Perimeter and/or Workspaces from that. Then, test in T1 by attempting to run into the fence or breach a WorkSpace, and making adjustments if the zone boundaries are too tight or too lenient. That part's not too hard.

    But where I keep having trouble is the velocity reductions. I often have setups that work fine in T1, with what seems like plenty of margin, but will show unexpected slowdowns near the boundaries that only show up in Auto. And the entire process of making a change, waiting for the robot to reboot, then testing in Auto again gets cumbersome.

    The main thing I'm interested in is this: is the a better way to predict the "slow zones" in advance? The SafeOp documentation talks about this, but only in the most general terms. To avoid the slowest parts of the trial-and error way of testing? Heck, if I could just get a warning when the robot is in T1, it would make adjusting the boundaries much faster. Has anyone figured out a more clever testing method, or even a better "rule of thumb" for this?

    Also, whenever I bring this up with the cell designers, I keep getting asked for a "hard number" for how much airspace has to be left between the fence and the nearest sphere of the safety tool, in order to avoid the "slow zone" velocity-reduction issue (the RIA spec for fence distance being a separate can of worms). Most of the time, I can only say "it depends," or I make a guess based on experience. I'm interested in what figures of merit have worked for other SafeOp users in the past, when they have to scrape the edges of the safety boundaries.

    Quote from SkyeFire


    My usual approach is to plot out the fence lines and corners on paper or CAD, relative to $WORLD, and create my Cell Perimeter and/or Workspaces from that. Then, test in T1 by attempting to run into the fence or breach a WorkSpace, and making adjustments if the zone boundaries are too tight or too lenient. That part's not too hard.


    I also use this classical approach, but sometimes the safety/working zones in some cells are complex, so much time is need to everything setup. In such case I will recommend defining these zones with Process Simulate software if you are familiar with and have access to it. You can visualize and test everything in simulation (apart from velocity and acceleration). It is very easy to export the parameters into robot controller after. With this method you dont have to adjust the zones each time.

    Quote from SkyeFire


    But where I keep having trouble is the velocity reductions. I often have setups that work fine in T1, with what seems like plenty of margin, but will show unexpected slowdowns near the boundaries that only show up in Auto. And the entire process of making a change, waiting for the robot to reboot, then testing in Auto again gets cumbersome.


    With the velocity, testing the zones in Auto/Ext modes and T1 are not completely the same, especially if you have more PTP motions close to the boundaries.Variables to consider in the custom.dat are $SR_VEL_RED=TRUE and $SR_WORKSPACE_RED. The variables can be used to activate/deactivate the unexpected-slowdowns when approaching the zones.

    Quote from SkyeFire


    The main thing I'm interested in is this: is the a better way to predict the "slow zones" in advance? The SafeOp documentation talks about this, but only in the most general terms. To avoid the slowest parts of the trial-and error way of testing? Heck, if I could just get a warning when the robot is in T1, it would make adjusting the boundaries much faster. Has anyone figured out a more clever testing method, or even a better "rule of thumb" for this?


    One way is to configure some $WORKSPACE[ ] monitoring in custom.dat to monitor where the robot is in order to predict in advance when robot in approaching the "slow zones". You will need to define those boxes close to where you want to predict. The combination of those box-zone monitoring and program-override variable $OV_PRO has done the job for me in the past.

Advertising from our partners