Please Help-Another Turret controlled by PLC

[drbitboy]

During my testing last night when I would press the e stop the plc would fault out of course. DS1 would still not be = to DS2. So as soon as the fault was reset the CW motion would try to start. With the c10 in place it wouldn't let it. So that would give me a chance to move the machine to a safe position, fix what I programmed wrong, then restart the T.C. sequence.

It's not necessary to eliminate the separate C10 start signal, but it does make the system less complex.

TL;DR

N.B. I am not saying remove the rising edge instruction, of C10 in Rung 12, that starts CW motion and the rest of the sequence.

I am saying replace C10 with C2 in that rising edge instruction.

So it's easy to test by changing "C10" to "C2" on Rung 12; you don't even have to remove the Modbus Receive instruction that writes to C10 to run the test.

Because I am all but certain that

• when the target tool (DS1) is updated via the Modbus transfer successfully,
  • C2 will always have a rising edge as the indicator of that success.
  • And, the way the lua code is written, that C2 rising edge will be just before C10 gets its rising edge from the second Receive.

If the Modbus write to DS1 fails, then

• C2 will not have a rising edge,
• and the lua code will also not send a 1 to C10.

Since C10 will always follow C2, C10 is redundant.

On recovery from an e-stop fault, the lua code will not automatically send any Modbus messages, so neither C2 nor C10 will have a rising edge. So even if DS1 (target tool) was not equal to DS2 (current tool) when the e-stop fault reset occurred, that reset would not cause CW motion and the tool search to start.

 

[Aaron_]

I am following you. I was having problems with the c2 instruction on rung 12. That was before we added a little more logic to the modbus instruction though. I didn't test it after that. I'm currently away for work this week. I will return on Thursday evening so I will test it then and report back.

 

[drbitboy]

I am following you. I was having problems with the c2 instruction on rung 12. That was before we added a little more logic to the modbus instruction though. I didn't test it after that. I'm currently away for work this week. I will return on Thursday evening so I will test it then and report back.

Yeah, I think it will be better, but not by much, and given that there were problems before, I would not be surprised if I am missing something.

Have a good trip. I'll be flying for 20h starting Thursday (boy, will my arms be tired ).

Btw, when I use bold italic font it is for emphasis; I'm not shouting.

Btw II, there is another way to approach this, which is to use a state machine to model the sequence. It is sometimes easier to read and debug. There is a state variable, usually an integer, that has a unique value for each step of the process e.g.

• 0 - locked
  • waiting for new target tool
  • When new target tool received, change state to 10
• 10 - start CW motion, start fault timer
  • wait for strobe@target-1 (@one tool before target tool
  • when strobe@target-1 detected, change state to 20
• 20 - engage indexing solenoid
  • wait for IndexSignal@target
  • when signal received, change state to 20
• 30 - Etc.
• 999 - Change directly to this state on stall fault or e-stop event
  • Do some cleanup maybe (e.g. timer, let system settle),
  • Or wait for manual intervention
  • Eventually change to state 0

You put 10 or 100 between initial states so you can add intermediate states.

The nice thing about this approach is that it separates the input/event checks, from the sequence logic, and both of those separate from controlling the outputs. This makes the code more readable: the state is all that needs to be checked to know where the process is in the sequence, not "is CW motion active and we have not seen the index@target signal yes? okay then we are still looking for index@target" or "Is brake released?" Also, as noted above, the outputs section can be isolated from the step logic, e.g.

• If state is in range [10:29], then run motor CW
• If state is in range [20:99], then engage solenoid
• If state is in range [10:89], then release brake
• Etc.

So you are making simple checks of the state against known ranges, e.g. instead of checking several several disparate e.g. CW motion, CCW motion, Post-CW delay, etc., to know if the brake should be released.

This makes problems, like CCW motion occurring when it is not expected, far less likely, because that can only happen from states X to Z, and the only way to get to state Z is from state Y, and the only way to get to state Y is from state X, and the only way to get to state X is from state W, and CCW cannot run in state W, or any other non-X/Y/Z state.