When multiple coils are connected in series....

[zhaolinger]

Let say coil A and coil B are connected in series, can I say that coil B will be active when coil A is active.

So, for a normal coil/relay, they are no different from coil A and coil B connected in parallel to whatever conditional combinations connected to coil A, isn't it?

But for the case of Timer coils (or sub-routines or counters), if Timer A and Timer B connected in series, does it mean that Timer B only start counting after Timer A is active,

in short, means the output of Timer A is connected as a NO contact to input of Timer B, am I right to say that?

And so for the case of sub-routines, the procedures of the different sub-routines that connected in series will be executed sequentially as compare to the arrangement of nets numbers which will still have all the nets be executed concurrently. Were my assumptions correct?

Please, can any expert here enlighten me on these doubts? Thanks in advance.

[Joe Tauser]

Unitronics is funny that they let you connect coils in series, whereas other brands force a parallel connection. You are correct in surmising that A and B will both be on at the same time.

In the case of timers, you are dealing with the activating coils, not the output contacts. If you connect two timer coils in series, they will both be active. The way to reference whether a timer is done is to tie its address to a contact.

Subroutines will be solved in the order of connection from left to right. If you have sub A in series with sub B, the program will jump to A, solve its logic, and then jump to B and so on.

I often stack coils in series but usually only call one subroutine per network. It's easier to read and troubleshoot that way.

Joe T.

[zhaolinger]

Thanks for clarifying my doubt, when I first see a Unitronics PLC sources written with multiple coils connected in series, my thought is “What? I remember I read it on book that this is not allowed.”

While VisiLogic don’t allow software mode simulation, there is no way I can see how such connections will behave. Without understand this part, it’s hard for me to understand the original intention of the program. You clarification in this really save me my day.

So from what you are saying, if 2 Timers connected in series, they both will be activated (start its countdown) at the same time when the contacts conditions hold true, right?

Another doubt I like to clarify, for Timer unit in Unitronics PLCs, they are positive clock edge activated or contact activated (the input must stay charged until the timer finished counting).?

Thanks you for your help.

[Joe Tauser]

Yes, both timers will be activated at the same time.

The default timer type (TD - On Delay) is contact activated - if you remove power they reset. The contact associated with them comes on when they time out and stays on until power is removed from the timer coil.

If you want to further muddle your brain read the Help on the other timers - TA (accumulated) and TE (pulse).

Joe T.

[Damian]

The biggest pitfall many folks have when trying to understand ladder is viewing it as a circuit diagram or a relay logic simulator. Using this form of understanding will always lead to wrong conclusions.

Ladder is simply a method of graphiically laying out instructions. It is meant to be intuitive for those not familiar with text based programming codes. There are instruction that "test", "operate", and some function blocks that may do a little of both. It used to be common that instructions that performed "operations" always had to be at the end of a rung, but many have adopted series execution over the years. Like everything else it all boils down to knowing the rules of the game the compiler follows.

As Joe points out, Visilogic "scans" the ladder with priority (left to right) and (top to bottom). What you see as contacts and coils are very different from physical devices.

Right click on a network you are curious about and select "STL quick view". This is how the PLC interprets your ladder. If you ever have any doubts about how things will execute in a network, reviewing the STL translation will show you exactly how it will process.

Unfortunately the compiler for Visilogic breaks from all other PLC ladder interpreters in one very crucial way. All other PLC software will only execute each instruction in a network once and only once everytime that network is processed. Visilogic instead will go back an re-execute your "test" operations for the branches and it does not always do this in a consistent fashion. This little detail has in the past caused me many hours of head scratching and grief until I finally studied the STL and realized what was going on. Strictly speaking the compiler should be "stacking" these conditions and buffering the evaluations as opposed to re-testing them but at this stage it is what it is. The best way to deal with this is to keep your networks as short and to the point as possible and to avoid networks that both "test" and "operate" on the same memory value.

One thing you will also notice with instructions such as "Energise Coils" and "TD Timer Coils" is they ALWAYS execute if that network is scanned regardless of the ladder conditions directly preceding them. This makes them special in this sense since virtually all other instructions will not not execute at all unless the rung conditions preceding them evaluate to true. This is the key to understanding the difference between a regular "Energize" coil as opposed to "Set" and "Reset" coils. The former always executes regardless of rung condtions wheareas the latter ONLY exectues if ALL preceding condition evaluate in a true fashion.

As an exercise regarding your Timer question, create two separate rungs. In one rung use one normally open contact to source two separate times in series. In the next rung, using all the same values, put the two timers in parallel as opposed to series. Look at the STL for both compilations. Do you see any difference?

[zhaolinger]

To Damian,

Thanks you so much for your kind inputs on my questions, your post actually highlighted the situation I am facing right now. Actually I am quite new to the world of PLCs, it is considered my very first project on PLCs with no experience before, I got quite a bit of experiences in VHDL, but PLCs seem to play a different rules.

From what you saying, Visilogic will always execute a normal coil at each scans even the preceding ladder conditions hold false (energize it if true, and de-energize it if false), while a Latched Coil will only be executed with ladder conditions hold true.

From what you said that Visilogic will go back an re-execute your "test" operations for the branches, does it means that a badly timed (staged) stages machine model will go hype-wire if Visilogic re-execute a branch (net) when another branch reference to the same MB, and hence the result may evaluate differently if the ladder conditions of that branch had changed. Thanks for the warning, I will be-careful on this part.

And the part regarding the STL view you mentioned, any references on what those symbols mean? Let me make some guesses, correct me if I'm wrong.

1. ! is NOT

2. = is Coil Output

3. & is Logical AND

4. &N is AND NOT

5. / is Logical OR

And what about LB0, I never declared it in my ladder program, yet the STL show it on the Net STL view, so can you tell me what is it? What purpose it serve? What behaviour it have?

Sorry if these questions sound like newbie, I was a newbie in this field and I really appreciate yours kinds inputs on these questions.

[Damian]

"From what you saying, Visilogic will always execute a normal coil at each scans even the preceding ladder conditions hold false (energize it if true, and de-energize it if false), while a Latched Coil will only be executed with ladder conditions hold true."

That is correct.

And to finish it out, both LATCH and UNLATCH (SET and RESET) coils only execute when all the preceding logic evaluates to true.

Regarding the STL view I don't believe there is any official documentation on it, but this is how I have interpretted them.

! Load the following condition into the accumulator/stack

= Assign the logic evaluation of the accumulator/stack to this memory location

& AND the value in the accumulator/stack with the state of this memory location and place in the accumulator/stack

&N AND the value in the accumulaotr/stack with the INVERSE state of this memory location and place in the accumulator/stack.

/ OR the value in the accumulator/stack with the state of this memory location and place in the accumulator/stack

the LB disignators are branch buffers that retain the value of the evaluations. My guess is that it stands for "Logic Buffer". With large networks you will generate a lot of these. Essentiually one for every paralllel branch you create. As I mentioned above, it is "remembering" the state of these evaluations so that it does not have to go back and re-test. The tricky part is that the translator does not always remember these evaluations and will in some instances go back an retest the logic. Later this evening I will grab an example I have in another post to help explain that better.

Yes, your undertstanding is correct regarding the re-execution. If you have series logic where you had to satify condition NOT X and A and B to set X and then you have another condition C after that to evaluate Y then it may go back and re-evaluate NOT X & A & B which will now evaluate to FALSE and C will not energize even though it should have under strict left ot right rules. It tends not to have logical significance unless your logic is writing to the same memory that you are testing in that same network (which is a pretty normal thing to want to do - i.e. "a self sealing coil").

Since this is your first PLC application I would highly recommend reading through a section in the Visilogic help where it explains the order of the scan, when things like I/O and HMI memory are updated and refreshed, when the system memory is serviced, an the rules that are used to govern the ladder execution. Whenever I am learning new PLC software this is usually where I start to try and understand better what the controller is doing under the hood.

With your background in VHDL your going to find this stuff a breeze. Your asking all the right kind of questions and ultimately you will end up with a much deeper understanding of what your doing than average user.

[zhaolinger]

Damian,

Thanks for these pointers you have given me, it really helps me a lot, I was able to somehow understand the background concepts of these Unitronics PLCs in the shortest time possible because of yours and Joe’s kind pointers given to me these few days.

The STL View tips is really useful, it actually convert and display the net in Boolean algebra format once you understand how to read those symbols, and that is where our fundamental of digital logic shine. We can actually spot a logical error using STL view (logical errors are always a headache to any programmers).

From these information you provide above, it seem that Unitronics PLCs inherent much of the properties of a microcontroller.

The evaluating of normal coils is just bit operation of the Boolean equations displayed by the STL view each time a net is scanned. Hence, it wasn't the ladder condition that is evaluated, instead it is the Boolean equation of that net got evaluated (as a result, one may need to set some operation critical memory bit to initial reset state to ensure it don't got initialized with a on state at power-up).

For a latched coil, because the value must be practically latched (actually all memory bits are latched until you power off), so the set and reset coil shall only be executed when the conditions hold true, hence a Boolean equation cannot be used, instead, the ladder condition is evaluated to a register memory and then a compare and jump conditions is checked to determine whether to set/reset the target memory bit or just do nothing and go to the next net.

For Timer coils (pulse), most likely it is making use of the timer interrupts of microcontroller to do the countdown, and for TD timer, a check condition is done at every scan and reset the timer call if its ladder conditions no longer hold true. (Hence I presume the timer output is also latched by default unless it is designed to reset it on the next scan).

The sub-routine call also behave the same way as that of a microcontroller, call in with no data feed allowed (unlike the case of any software language/VHDL), do operations and change data in memory address and return to the calling address without returning any value directly;the sub-routine in VisiLogic just behave the same way, any coil changed by the sub-routine will have its value latched (thanks Joe answering me this part in my other post) until another ladder access and change it.

Since PLCs is not actually a hardware connections of real contacts and coils in series/parallel, the net that got executed latter will always supersede the one that got executed before it, so if the conditions ladder that change the same memory bit are not mutually exclusive, one might get logical error in his program and it will be very hard to seek out the root of problem. A good way to avoid this is to put all conditions that change the same coil into a single net so that the Boolean equation is evaluated as a single equation.

With this, the use of sub-routine in PLCs seem kind of redundant now to me. In the case of microcontroller, a sub-routine is to call and reuse a commonly repetitive task so as to shorten the code to be more manageable and easier to read, But for a PLCs, the whole main module is already nested in a huge never ending while loop, so the use of sub-routine no longer so meaningful in a PLCs program, because the whole of main module already repetitive in nature. But by executing a sub-routine only through conditions in a PLC program, it does shorten the time needed to scan through 1 single cycle (saving the CPU cycles wasted on executing a sub-routine that is not needed), if the PLC program is getting real huge and lots of timer interrupts are used, this advantage might become a critical requirement.

Hence I also presume most other functional blocks would pretty much behave the same way a microcontroller would, but I haven't explore into these functional block yet.

And again, thanks for helping me understand how a PLC works.

[Joe Tauser]

My two bits on subroutines in PLC's - you are correct in your conclusion that a PLC program is a big never-ending loop, but that loop can get huge. Subroutines in a PLC serve a couple of purposes-

1. They allow functional organization of code. A classic PLC newbie puts all of his code in the Main routine and you wind up with a couple of hundred networks that turn into a troubleshooting nightmare, especially if said newbie or just plain crappy programmer doesn't document his code.

2. They do allow you to turn some of your code off if not needed. The biggest Unitronics program I ever saw (I did not write it) had 49 subroutines with a lot of CPU-gobbling math. If the PLC were to solve all that code, the scan time would very likely approach the watchdog timer limit and the PLC would fault out.

Glad to hear you're figuring things out.

Joe T.

[Damian]

Sorry for taking so long to respond to this.

Your take on how you perceive what is going on in the background of the PLC is for the most part inline with how I would interpret it.. Ultimately it is just a microcontroller and the ladder software is just window dressing to make things easier to program.

Your view of subroutines though is not quite right for the reasons Joe pointed out. They allow you to organize your code in the same fashion that a book may have chapters. I just had to modify a Mitsubishi program a few weeks ago where the whole program 500+ rungs of code were all in one big subroutine. I spent 90% of my time using the scroll bar to search up and down for the relevant logic I was looking for. Arghh! I still have that headache.

In my programs you will find there are some very common subroutines that always pop up. Such as

HMI

Alarms

Auto

Manual

Inputs

Outputs

Virtually every program I write has at least these. Now if I want to diagnoise alarms I can go right to the code where they are at etc.

My Main subroutine is generally just a place where I put all these subroutine calls in the order I wish them to be executed.

The modules are also handy for organizing your code. For example, I may have 3 axis of servo and each one of those has a few common subroutines.

Axis 1 Manual

Axis 1 Auto

Axis 1 Reset

etc.

Axis 2 Manual

Axis 2 Auto

and on and on.

I will give each axis its own modules to help create and organizational tree for them. Just keeps things neat and tidy.

The type of subroutines you are used to are what in PLC ladder land are usually called UDFB (User defined function blocks). These allow you to pass parameters to and from a certain chunk of code that perform a function on them. Visilogic unfortunately does not support this capability and has often been a request here on the forum. With the use of data tables, it is possible to mimic the functionality of a UDFB. It is cumbersome enough to where you really need to have a good reason to bother doing it that way.

The biggest reason for having UDFBs is for making portable code. This way you can import that UDFB into another project later on without having to worry if that code was written using operands that were already in use by other code.

Some day, hopefully in the near future, I believe you will see Unitronics software with this ability. But probably never in Visilogic.

Next ............. that execution sample I promised you.

[Damian]

This is an example of normal translation

Every thing flows left to right as expected.

Now lets add a contact in series with the INC block.

As you can see the left to right execution has been broken.

It actually went back and executed the comparator twice!

It interpretted the ladder as if it were actually written as so.

So you have to be careful how you structure your rung.

Now watch what happens when I add another test/operate condition in series.

In reality, the translator actually broke the network up into three separate rungs.

Each time it redundantly re-tests all of the preceding conditionals.

Only problem is it is only redundant if the conditionals don't change during the rung execution.

The moral of the story is, be careful when writing rungs that both test and operate on the same operands.

The results may not always be as expected. When in doubt, double check the STL just to make sure it jives with what you wanted.

[Flex727]

Outstanding explanation, Damian! I have been tripped up by that before and never really thoroughly understood what was happening. Very helpful post.

[tmoulder]

Wow! That's deep... good job Damian!

[zhaolinger]

Thanks Damian, you are great!

You even get to the length of situation on how a test condition may get superseded and overwritten with a unexpected result even when a condition in with a single nets.

This is a great example, I bets many others beside me will too benefited from yours above explanation, when they facing similar situations.

Regarding using sub-routine as bookmark, yes, I agree with you on that too, while it doesn't simplify my code, it does help me to find code of different group of purpose more easily.

Thanks, you and Joe are really, yours information helps me alot in getting my first PLC project moving in the right direction in the shortest time.

[Bruce]

I cannot view the jpg pictures which are essential to the explanation, can these be restored in Damians's Sept. 14 post?

[Flex727]

I don't know if @Damianis still around after all this time, but maybe tagging him will provide an alert that he is needed.