How would you solve this control problem?

[aikona]

My solution would be to stop scanning the SFC's ( frozen state )
and to disable or set to zero any outputs till reset of light curtain.

 

[Ken M]

Good old IEC - by defining 4 languages plus SFC (you did know they don't consider SFC a 'language' as such didn't you?) they've really managed to put the blinkers on people. It's entirely possible there will be control problems out there where the best solution can only be conceived and expressed using some other means. This may well be one of them.

I've always felt the 'S' in SFC is the most important part. It's a sequence. In other words you can predict what is required at every step and define the control accordingly. But what if life isn't like that? Instead of Step 1 always leading to Step 2 what if sometimes it needs to go to Step 3, or Step 4 or Step 99? An SFC could be constructed with this in mind but it would be a horrible mess of spaghetti and cover about 3 hectares. Atifplus shows an example of this for only 5 steps in post #5, and even then the return paths are strictly sequenced. The net result of all this is that IEC SFCs as we know them are not really 'state machines'.

The only time I've seen PLC software which seemed to tackle this issue is Siemens. I once visited a automotive plant where an OEM had supplied a machine programmed with something called Siemens Higraph. I was just an observer but it seemed to be an add-on to STEP7 like the other languages, and was a attempt to produce state machine design which compiled down to FCs and FBs. It looked suspiciously like Atifplus' diagram, with circles representing 'states'. You could connect any state to any other state or states. Where a state had multiple exits to other states you had to define each exit condition uniquely - I don't know how/if the software checked this. A circle could represent not just a single state with a set of commands, but a whole linked chart with other circles/states within it.

You could define a sequence of operations if you wanted: State 1 led to State 2 led to State 3 etc, or have it responding in a controlled manner to live conditions e.g. 1-2-1-2-3-1-... But if these were all part of a 'higher level' state I think an event at the upper level could interrupt the lower level. I'm not sure on the details but it looks as though Siemens still have it on their tech support web-site and it's still available. Clearly it's not a IEC standard so someone has to be brave enough to step away from that.

IEC61131-3 is just a toolbox. And Peter needs to perform a task. If the IEC toolbox only contains Torx bits and he needs to tighten an Allen bolt he either has to bodge it or go and get a new set of tools. From his posts I suspect I know what kind of engineer Peter is.

Regards

Ken

 

[CharlesM]

f the motion controller allows has a feedrate override feature, you might be able to use that.

Depends on the application and the safety part of the machine. However I like the feedrate override idea. When I was making CNC type grinders with the Delta Tau we did this very thing. The first idea was to use a pot like a lot of CNC machines did to provide variable inputs. We then went to a BCD switch that provided 12 positions and 12 speeds. The control did not care because it was just looking at an address. The operators like the different bumps in the switch because if felt like they had more control. Pots are real easy just to spin to max speed. The other thing we did was a feed hold. It was just a push button setup with a toggle (push on/push off) that would set the speed ref to zero and override the speed input. I liked this on a grinder because I could run the first part slow and then turn up the speed when I saw that everything was going to be ok. If I had a problem I could push the feedhold button for a fast (ramp down) stop.

I could use this type of feature now on our presses. On the mechanical presses we have a fly wheel and air clutch. One of the modes of the press is inch. When the operator hits the palm buttons the press will run till they let go. So they can jog the press through the cycle. With the feed hold type system I could have another mode that would set the speed when the palm buttons are pressed then zero when the operator lets off. I don't do this now because I make them start the cycle over when it is stopped. The first part of my step program moves the axis to a safe start position before the cycle starts.

I would love to see what you come up with.

 

[Peter Nachtwey]

CharlesM, the feed rate idea will happen. You have brought up another reason why I need it which is the inching. The variable feedrate or time base seems to solve a couple problems. We can do this with virtual axes or real feed chains but we never considered the need when just moving point to point. The inching function would make jogging obsolete.

Ken M, I agree that the SFC could get to be very large and messy. I can see where there would be a need for nested blocks so the pause feature could be contained with the large block that execute the code for that step.

Thanks guys. I will solve this problem in the motion algorithms because this feature has many benefits as have been pointed out.

I will still work on the SFC approach though because that can happen sooner.

 

[panic mode]

i am working on control systems of different complexity all the time
(most are complex and use sequence and motion, often using multiple devices
such as both robots and PLC controlled servos etc.).

all ladder 99% of the time... i was posting some small sample projects
but note with motion (have signed agreement with company). they all look
very much the same anyway.

i allways allow for choice of resuming current sequence from any point or
returning start position (reset and home) which means one has to have proper
interlocks or one would risk colisions (depends on machine design and motion paths).
basic thing is to stop incrementing sequencer on certain conditions
(stop pressed, changed mode, safety ckt trip, alarm states etc.).

when faults are cleared and start cmd is issued, outputs are active again
(including motion commands) while sequencer is still in the same state as before
light curtain trip.

this means that any motion would be completed before next step is initiated.
one must be careful about tolerances as someone may have moved things out of
acceptable range (move clamps, servos etc. in manual mode and forgot to bring
back to where they ware or safe positons).

i agree about having limit on speed for testing or until interrupted cycle is
complete (or part of it...).