Hello,
I am trying to limit axis angular velocity to 30 deg/s for an RSI application. I have been told that RSI is not capable of this. However, is it possible to limit maximum axis velocity in KRL code?
Thanks!
bwait
Hello,
I am trying to limit axis angular velocity to 30 deg/s for an RSI application. I have been told that RSI is not capable of this. However, is it possible to limit maximum axis velocity in KRL code?
Thanks!
bwait
I also tried modifying $VEL_AXIS_MA to a lower value (originally was 6000) but when I downloaded the code, it reverted back to the original velocity of 6000.
bwait
Controller model? KSS version? RSI version?
"Downloaded" what code? Did you download an old WV project without uploading the updated version first?
At any rate, it shouldn't be too hard to limit the motion rate of an AXISCORR object in RSI. As RSI updates every 12ms (or 4ms in IPO-FAST mode), and and RSI treats the input to the AXISCORR object as a position to execute within one update cycle, simply using a "Roof" object of about (30deg/s * 0.012sec = 0.36) on the inputs to the AXISCORR should put a hard limit on how fast the axis will be commanded to move.
Hi SkyeFire,
KRC4 compact controller, Work Visual 4.0 V 4.0.26_Build0312, RSI Visual 1.1.0.0.
I did not upload the code from the robot. However, I used the last version of the WV project downloaded to the robot and made a change to it. Should I be doing this differently?
I need to limit axial speed in both AXISCORR motion and POSCORR motion. Thanks for the info on AXISCORR motion. Any ideas on POSCORR motion?
Thanks!
bwait
Something's not right here -- you don't edit RSI programs through WorkVisual. RSI has a separate editing program.
The only way to guarantee that you are working on the latest Project is to connect to the robot, upload the active project, then make your edits and re-download (under a new project name, if you're experimenting).
I don't know why anyone would need to limit axis velocity while controlling Cartesian motion, but... well, there's no simple way to do it, but RSI is extremely powerful and flexible. One method that would probably work would be to build an axis-velocity monitor into your RSI object (checking $AXIS_ACT every cycle and subtracting the current value from the previous), and use the output to drive a PD object that would influence the inputs to your POSCORR. Tuning that PD will take some work, but it should be doable. You'll need to ensure you scale all 6 inputs to the POSCORR equally, though, to ensure your path remains accurate.
Hi SkyeFire,
Thank you for your response! Let me clarify...
I modified the variable $VEL_AXIS_MA in WorkVisual which subsequently reverted back to the previous value when I uploaded it to the robot. I will try downloading the code first, modifying the variable, and then uploading. When modifying RSI code, I use RSIVisual.
The reason we need to limit angular velocity to 30deg/s is because this is a requirement of SafeOp which will be installed on our finished product. This is a requirement in both poscorr motion and axiscorr motion.
Thanks again for all of your great responses. You & others on the forums have been very helpful! Hopefully, this clears up some of the confusion from previous posts.
Thanks,
bwait
Hi SkyeFire,
I tried downloading the code from the robot, changing the $VEL_AXIS_MA variable value, and then uploading but it still reverted back to the original value...
Thanks,
bwait
Hm. Not sure I've ever tried changing $VEL_AXIS_MA for the arm axes. I know you can control it for any External axes, but it's possible that the OS forces the values for the arm back to the factory defaults. There are a few system variables I know work that way.
I have to question a flat 30deg/sec limit for SafeOp, however -- 30deg/sec on Axes 4-6 can make for very small velocities in real space, while 30deg/sec on, say, Axis 1 can make moderate real-space velocities if the robot is tucked in close, and much larger velocities if the arm is at full extension. SafeOp usually is set up to work using Cartesian velocities for this very reason.
Either way, though, the only way to ensure RSI doesn't fatally trip any of these limits ($VEL_AXIS_MA or SafeOp) is to put limits into the RSI program itself, and to handle it smoothly usually requires some sort of PID implementation.