Hello community,
is there any representation of current motion identification number e.g, MovementID or MoveID in the SRCI environment?
Thank you.
MovementID
Re: MovementID
Unfortunately, I have no experience with SRCI motion commands so far,
but as I understand it currently, it is different than it works for example with Stäubli UniVal PLC or Kuka MxAutomation.
Here you do not pass one point after another asynchronously
and get a MovementID back, which tells you which point was processed last.
In my understanding, it is rather the case that each point has its own Motion-FB instance
and then you get reported back via the DONE flag of the Motion-FB, that this point has been processed.
But that does not mean, that you need 100 FB instances, if you want to execute a list of 100 points.
Here you could program a serialization with 2-3 FB instances in the PLC and if necessary create a MovementID yourself.
The important thing is that you get the points transferred to the robot faster
than the robot can process the points - but that can be solved with more FB instances...
But maybe there is an alternative approach...?
Best regards
Thorsten
Thorsten
Re: MovementID
When a command is processed, it is handled by the active command registry (ACR). According to its position in the ACR a corresponding cmdID (sometimes also called acrID) is assigned.
This behavior applies to all commands (not only movement commands). You can identify movement commands by their command type.
Movement commands also feature an output parameter called "FollowID", which is related to the so-called trigger mechanism. Internally, the cmdID/acrID is mapped to this output parameter.
One FB instance is enough to execute a list of points. You can either wait for the CommandBuffered output before sending the next movement or send it right away without waiting for any of the FB's outputs. The ACR will make sure that the processing order is identical to the execution order.Thorbot wrote: ↑08 Jan 2025, 08:20 In my understanding, it is rather the case that each point has its own Motion-FB instance
and then you get reported back via the DONE flag of the Motion-FB, that this point has been processed.
But that does not mean, that you need 100 FB instances, if you want to execute a list of 100 points.
Re: MovementID
That seems like a useful representation of MoveID functionality.MarkusL wrote: ↑08 Jan 2025, 17:47When a command is processed, it is handled by the active command registry (ACR). According to its position in the ACR a corresponding cmdID (sometimes also called acrID) is assigned.
This behavior applies to all commands (not only movement commands). You can identify movement commands by their command type.
Movement commands also feature an output parameter called "FollowID", which is related to the so-called trigger mechanism. Internally, the cmdID/acrID is mapped to this output parameter.
One FB instance is enough to execute a list of points. You can either wait for the CommandBuffered output before sending the next movement or send it right away without waiting for any of the FB's outputs. The ACR will make sure that the processing order is identical to the execution order.Thorbot wrote: ↑08 Jan 2025, 08:20 In my understanding, it is rather the case that each point has its own Motion-FB instance
and then you get reported back via the DONE flag of the Motion-FB, that this point has been processed.
But that does not mean, that you need 100 FB instances, if you want to execute a list of 100 points.
Is it possible to set specific ID for the FollowID?
Thank you for the explanation!