Intuitively, I might expect that all those actions will happen in the order I called the API, with the last one being the “winner,” but that’s just a guess.
It is two operations rather than a overwrite. It is going to add a frame for each call of StreamingOutputAdd. It should execute them in the order they were added.
If you’ve masked off something in the first frame, it will affect the output if decide not to mask it off in the second.
Suppose I set the value in two successive point indices? That’s totally legit, too, right?
We’re trying to implement laser rastering, where the output power of the laser is set (potentially) every (tiny) move. So, I might need to set a different sync output for every waypoint I send via MovePT(...).
Are there limitations with synchronous outputs that might affect this behavior?
I’m observing that even though I pass in different point indices for the same motion ID, sometimes, it looks like the first value I make the API call with is the one that gets sent over the network.
Do you have some suggestions for how I could troubleshoot this? I’ve wrapped every API call to StreamingOutputAdd with a log record. I’ve also done a scope capture where I get the firmware address of the analog output controlling the laser power. In the firmware, I can see where the power set is not what the last value given to StreamingOutputAdd(...).
Is there a firmware address for the Motion ID and Motion Element ID for a MultiAxis? I see RSIAxisAddressTypeMOTION_ID and RSIAxisAddressTypeMOTION_ELEMENT_ID, but those are in RSIAxisAddressType. The only things in the MultiAxis are motion status, target feedrate, and current feedrate.
Do some/all of the axis addresses also apply to a MultiAxis? Probably not, I’d suppose, because the integer value of those enumeration constants doesn’t like up between multi axis and axis address types. Should I just get the first axis in the multiaxis and get its motion ID and motion element ID?
Curiously, both RapidCodeMotion::MotionIdExecutingGet() and RapidCodeMotion::MotionElementIdExecutingGet() exist and are callable for a MultiAxis object.
Is there a firmware address for this data, though?
Yep, you found them. If you use Axis::AddressGet with either:
RSIAxisAddressType::RSIAxisAddressTypeMOTION_ID
RSIAxisAddressType::RSIAxisAddressTypeMOTION_ELEMENT_ID
In practice, the MultiAxis version just gets this value for the first axis associated with it and calls that function.