I’d like to start a scope capture (manually), but stop it when a value exceeds a particular threshold value.
Is this possible?
What makes this harder for me is that I want to do it with a value that is probably represented in (firmware) memory as an 8-byte double, but the trigger conditions only let me specify a 32-bit mask.
Is the firmware little-endian (like my CPU)? I was wondering if I could just look at the 11-bit exponent (if I knew where it was relative to the address of the value in question) and look for some of the higher-order bits turned on (indicating the magnitude of the value has exceeded some number). Is this even remotely possible?
Technically it is possible to start a scope manually and stop with a threshold-exceeded trigger. (RMP firmware supports this.) However the RapidCode API doesn’t support this level of customization, nor does MotionScope.
Yes, the firmware has the same endianness as your CPU. I don’t think you’ll have much success with the current MotionScope interface to do what you’re trying to do.
We could add the additional capability in RapidCode for 64-bit double triggers. Also we’ve so far only exposed a specific recorder trigger setup – mainly for starting and stopping a recording based on motion start and motion done. RecorderConfigureToTriggerOnMotion()
I think it’s an interesting and doable request. Would it be of any help if this was available in RapidCode or do you only need it in the Scope GUI?
I was using the scope because I didn’t have better options.
What I really want to do is react (in the RMP firmware) if motor acceleration exceeds some predefined (sane) threshold. I want to be able to test things and have RMP trigger some action (disabling the machine, in my case) if I do something that results in a motor jumping (measured as excessive acceleration).
Since RMP doesn’t really measure commanded acceleration (when I’m sending waypoints through MovePT), I’d have to calculate it from commanded velocity. It doesn’t look to me like I can do such a thing with a user limit. (The outputs allow me to set, and, and or, but not add or subtract.)
In this case, I was going to hack something together so that the scope would stop if the commanded acceleration was too high, just as an indication that something bad happened.
Do any of your other customers have a need/desire to add or subtract a value to a memory address in a user limit? This would probably do all that I needed.
I’m thinking more of doing things like making a counter that increments or decrements when the user limit condition is met. For me, I’d rather subtract two memory addresses (as doubles), kind of like *addr_a = *addr_a - *addr_b.
IDK how much value this would add to RMP for your other customers, but it would be really cool for me.
Yes, we have gotten the request to have RMP firmware perform basic math operations… and have worked up a new firmware object for this purpose. MathBlocks are designed to perform add/subtract/multiply/divide on two inputs and writing the result to an output register. (There’s also sqrt() and a sqrt(sum of squares of input[0] and input[1].) You could then setup a UserLimit to trigger on the output of a MathBlock.
We have the firmware implementation but haven’t yet completed the RapidCode API required to get you access. It’s on our backlog. Thanks for letting us know you have interest. Would that suffice for your use case?
At the moment, I would need to be able subtract the current command velocity from the previous command velocity, and compare that to a fixed value (presumably stored in a user buffer) as > or >=. That comparison would be the trigger for a user limit. Then, store the current command velocity (as the previous command velocity, presumably in a user buffer),
(This is basically calculating effective command acceleration and comparing it to a threshold value to detect bad commanded motion.)
The MathBlock feature will be included in 10.5.1 and will use the same license bit as UserLimits (real-time triggers). Here’s a sample app that works for your requirements. It uses two MathBlocks. The first to do the math, and the second to copy the Axis’ CommandVelocity to the UserBuffer so we can use it in the first MathBlock.
