BlackBamba
Member
Hi all.
It's been a while since I last posted here
Looking for an advice on handling command/feedback mismatch during transitions.
I have a PLC controlling a Motion Controller (MC). Comms are done via Modbus/TCP.
The main commands from the PLC to the MC are:
1. RUN
2. STOP
3. FREEZE
The feedback reflects the commands but includes an additional option:
1. RUNNING
2. STOPPED
3. FROZEN
4. ERROR STOPPED
The differences between the "not running" states are not important for this discussion I think - but do note that a FREEZE could be initiated internally by the MC in case a collision is suspected.
Basically, the PLC expects the feedback to match the command.
Obviously when command/feedback don't match it usually means there's a problem.
What I'm not sure about is handling the transitions.
Let's consider the case of [out: RUN, in: FROZEN].
Even when using a state-machine (which I do), there's no easy way of telling if
- FROZEN is the "old input", and system in transition to running state
- FROZEN is the result of current run command (due to collision)
- the RUN has not been processed due to some comm issue or another problem in the MC program.
I thought about using counters instead of status bits for feedback; this way it's possible to say if that FROZEN feedback is "fresh".
Also considered adding a "command ack" to make sure the MC is aware of the current command.
But I was wondering if there are other better established approaches to that?
Would apperciate any thoughts on that matter.
It's been a while since I last posted here
Looking for an advice on handling command/feedback mismatch during transitions.
I have a PLC controlling a Motion Controller (MC). Comms are done via Modbus/TCP.
The main commands from the PLC to the MC are:
1. RUN
2. STOP
3. FREEZE
The feedback reflects the commands but includes an additional option:
1. RUNNING
2. STOPPED
3. FROZEN
4. ERROR STOPPED
The differences between the "not running" states are not important for this discussion I think - but do note that a FREEZE could be initiated internally by the MC in case a collision is suspected.
Basically, the PLC expects the feedback to match the command.
Obviously when command/feedback don't match it usually means there's a problem.
What I'm not sure about is handling the transitions.
Let's consider the case of [out: RUN, in: FROZEN].
Even when using a state-machine (which I do), there's no easy way of telling if
- FROZEN is the "old input", and system in transition to running state
- FROZEN is the result of current run command (due to collision)
- the RUN has not been processed due to some comm issue or another problem in the MC program.
I thought about using counters instead of status bits for feedback; this way it's possible to say if that FROZEN feedback is "fresh".
Also considered adding a "command ack" to make sure the MC is aware of the current command.
But I was wondering if there are other better established approaches to that?
Would apperciate any thoughts on that matter.
