Hypothetically (read: in my real-world circumstance), what would/should happen if I stopped streaming motion to a multi axis while the multi-axis was e-stopping over a long period of time?
I have configured a user limit with an RSIActionE_STOP action. I set the corresponding stop time to something fairly large (but not unreasonable, IMHO), like 0.160 sec. When the user limit fires, RMP starts commanding a stop. When my application notices this, it stops sending motion and prepares to clean up the scenario. (I’m probing.)
I had assumed that RMP would generate its own motion points to keep the axes in the multi axis on the same linear trajectory and that I no longer needed to send it more motion. My observation is that this assumption is incorrect. What I see is that as soon as the motion buffer is exhausted, the commanded velocity immediately halts and the axes report RSISourceOUT_OF_FRAMES.
Just because I already have one, here’s a plot of velocity for one axis.
The dashed black vertical line is when the input triggers the user limit. The red vertical line is when the velocity abruptly halts (when I get an OUT_OF_FRAMES interrupt for the axis). The green area is the time period when I cease sending motion (via MovePT(...)).
Can you help me understand why this makes sense? Initially, this seems like bad behavior. I’m probably not considering it from all angles, though.
First, is RMP “honoring” the motion I send it in its commanded decel? Is it continuing to use the motion I give it in its calculation of waypoints?
I had assumed that from the moment RMP took action, it didn’t need any motion data from me to complete the e-stop, since it was going to do all the calculations from there and leave the axis in an error state.
What am I expected to do in order to allow RMP to finish? Keep sending something/anything for motion?
Also, it looks like my attempts to send motion early on (after the dashed line but before the green region) fail because the multi axis is in an error state.
Is it possible to have a stop time that exceeds the size of the motion buffer?
The RMP is not generating its own motion points for Stop or EStop events. It is adjusting the execution of the existing motion profile via Feedrate. Since we are presumably starting at a feedrate of 1.0. You average 0.5 feedrate over the configured time. Thus you will execute about 1/2 configured time buffer.
If you are streaming motion points, its important that buffer isn’t starved. There is a lot of variation in how you might be loading points. What you need to consider is your lowest buffer. If for example you have an interrupt when your buffer hits 30ms before you feed in 70ms worth of points, you should consider 30ms of execution low point. Here I would no longer configured stopping time than 60ms (2 x lowest expected).
Unfortunately you can’t add more buffer as once you are in an event, you will get a state error when issuing new motion commands. You’ll need to tighten your configured (e)stop time or increase the buffer so you can safely come to rest.
As an academic question, how is this not essentially “creating” motion points? It seems to me that in order to accomplish this, you’d have to interpolate between two motion points (from the buffer) or at least not consume the motion points from the buffer at the previous rate (1 point per time slice).
What does “adjusting the execution … via Feedrate” do? (I’m trying to understand RMP better so that I don’t make foolish decisions based on behavior that does not exist.)
It lowers feedrate from its current value (normally 1) to 0 over the configured (e)stop time. Suppose you had a configured time of 10 samples. The feedrate change each sample from 1.0 → 0.9 → 0.8 → -> → 0.0.
Feedrate being how fast we executing something.
1.0 → 1 second of motion executed per second.
0.5 → 0.5 seconds of motion executed per second.
So, doesn’t that mean that all the motion (in the buffer) will take longer to execute, and thus you would have “more” motion available (or, motion available for a longer time) during a stop/estop?
In a sense yes. Although I would rather say that you need less than the full (e)stop time motion of buffer. Assuming a starting feedrate of 1, you end up averaging 0.5 over that period. Thus you only need 1/2 (e)stop time’s worth of buffer to execute to avoid hitting Out of Frames.
