scan-to-scan vs automatic cycle

[GeoffC]

I almost always use an integer value as the control for all my sequences, and have found this to be really flexible, easy to fault find, and easy to read and understand. (sorry can't post an example at the moment)
Basically each rung consists of a sequence permit bit followed by a comparison to the state value then the transistion condition and then the next state value, with trigger bits for the required actions.

This way I just pass the state value to the HMI and know where the program is at, so I display State number, description & condition all from that value.

Normally I use a function block (or subroutine in AB land) as the control for the sequence, ie at the end of the sequence routine, call this subroutine to set the next state value. This lets me take care of all the diagnostics in the background (time in state, state when fail, etc)

Anyway just my thoughts, if interested I can post an example tomorrow

 

[PeterW]

I almost always use an integer value as the control for all my sequences, and have found this to be really flexible, easy to fault find, and easy to read and understand.

Same here really, I don't know about AB but there's a neat instruction in Step 7 which you can set up to process only the step active in the sequence. Better than numerous comparisons.

Example

	 L	 #Step_Number
	 JL	Err					// Step_Number > 6
	 JU	Wait				   // Step_Number = 0
	 JU	Stp1				   // Step_Number = 1
	 JU	Stp2				   // Step_Number = 2
	 JU	Stp3				   // Step_Number = 3
	 JU	Stp4				   // Step_Number = 4
	 JU	Stp5				   // Step_Number = 5
	 JU	Stp6				   // Step_Number = 6
 
Err: SET						  // Set Error as Step too big
	 =	 #Error
	 BEU
 
Wait: AN	#start				// wait for Start Button
	 BEC 
	 L	 1
	 T	 #Step_Number
	 BEU 
 
Stp1:SET					   // Step 1 - Do whatever

You could do the same in Step 5 via the indirect DO instruction.

 

[Binaural]

First of all...

Binaural again supports and repeats my loooong standing positions!

Binaural... it appears that as long as you argue with me, you are arguing with yourself!

I have no idea what you are trying to say there. If you have long standing positions on this issue, then you have not expressed them in this thread, so I will make no attempt to address them.

The idea of "Programming for Failure" is NOT the same as "Programming against Failure".

Programmi be! And, as such, must be modifiable by anyone that can come ing FOR Failure means writing a program that ASSUMES that the program is much less than it shouldn to SAVE YOUR A$$!

This is a meaningless distinction in the context of discussing robust code. Not everyone has the time to write perfect code, and many cannot even with plenty of time and money to do so. Code imperfect in some respect is therefore a given for new systems. This dictates that well written code should also be well organized and as easy to read, modify and check as possible because it may have faults that were not apparent during the design phase, or perhaps because the goalposts were shifted by a client once the machine was delivered, or one of a thousand other reasons.

There are also other reasons for code to be written in this fashion other than planning for failure. Say for instance that you have a machine that is frequently customized to a client's requsts, or another than is produced infrequently and updated whenever another is built. Would you say that optimizing your code to easily incorporate some modifications for these is "programming for failure?"

Whereas, Programming AGAINST Failure means... totally recognizing that $HIT HAPPENS! It means covering ALL potential possibilities!

I have ALWAYS been a proponent of Programming AGAINST Failure! That is, to be cognizant that $hit happens!

Do you understand the difference? Do you know where I'm coming from? It's a really BIG difference!

Sorry, this is just playing with words. Your concepts of "programming against failure" and "programming for failure" are really the same thing - programming for robustness. Both kinds of code should be tolerant of both internal and external faults. The only difference that I can guess unless you elaborate your long-standing views further is that code written "for failure" monitors itself for internal logical errors, which is inarguably a good thing. So why should this be looked down upon as a programming methodology? And why should these two types of code be mutually exclusive?

Systems fail, so do humans (only at a higher rate). If code is unnecessarily difficult to read, debug or check then it is not robust code since it means failures will be costly to fix, and changes difficult to make when necessary. Plus, code written without order and structure is generally indicative of poor design and planning.

 

[Peter Nachtwey]

I too am a fan of the S7 JL instruction.

The S7 JL instruction allows one to execute only the code that is required for the execution of that state. Normal PLCs must scan the whole program unless jumps are used. Several state machines, or JL tables, may be necessary in one program. For instance, one can have a state machine for a loader, unloader and the press it self.

The JL instruction is something that the other PLCs should copy because it helps organize code and is very efficient. Those that have ST or SCL can use a switch or case ( I forget exactly what it is called right now ) statement to get the same result.

About safety. I usually have one place where I check for general permissives. If something is wrong then I change the states to enter the fault handling states. This way I don't need permissive coils in every state. It keeps the program a little cleaner. One can do the same thing in normal ladder using bits but one must be sure that all the normal state bits are cleared.

Now we are back on topic. I couldn't let Terry's comments go unanswered.

 

[GeoffC]

Heres an example of how I do sequencing.
Notice by using the old basic idea of stepping by 10 allows for easy additions to the sequence
I haven't shown it but at the end of the routine I have a user defined function block that moves the Seq_ReqState to the Seq_State, this ensures that a state is true for at least 1 full scan, it also does all the diagnostics.

 

[ToolGuyFred]

Here's what my normal automatic sequences look like:

This is sort of generic but in general if you loose the "auto" bit the whole sequence stops. You can drop "auto" with any fault or whatever your application requires for safety. Step 2 is delayed 2 seconds in this example.

The output rungs then look something like this:

With the auto part having an N.O. Contact for the step that turns it on and a N.C. contact for the step that turns it off. If an outputs goes on and off more than once in a sequence you just add another branch with on and off steps.

No offence, but this is the method I used to use. I switched to the method outlined above (sequence step counter, incremented in 10s) because I found it more flexible, quicker to debug and less error prone. I use steps of ten to allow me to insert steps, and move rather than add instructions so I can jump out of normal sequence if required.

The most memorable error I had using the above latch method was on a pick and place robot loading/unloading a cell of CNC centre lathes. The gripper (6 foot long) took a dive through the lathe guard after trying to resume from a sequence pause. The reason? I had F25.4 where I should have had F24.5 (a Step5 system). It took me two hours of head scratching and beard tugging to find the bug, too! I have never had a similar experience using a counter (and I've used that for a much longer time).

 

[Big John T]

ToolGuyFred, can you post a short example of your counter method?

Thanks
John

 

[ndzied1]

No offence, but this is the method I used to use.

None taken. If one sequence fit everyone's thinking or every applicaiton then there would be no PLC programmers and only one brand and model of PLC.

Glad you found something that worked.