ladder logic help for studio 5000

Hi, I am new to PLC with computer science background in scripting. I am very lost in the ladder logic here.

I took a 5 seconds video clip since I can not upload here.
https://drive.google.com/open?id=14tHLuyQXKtGYpJpjEsPjXMOTcQQq6aYI


here I have a very simple ladder diagram :
rung 0 : left side: XIC , right side : MOV: test1 to result1
rung 1 : right side: CPT result1 = 1000
rung 2 : left side: GRT result1 > 90, right side : testlight
rung 3 : right side: CPT result1 = 2000

for the variable above, test1=0 is real , result1 is real and testlight is bool

observation:

1. the result1 value remained at 2000 most of time and changed to 1000 periodically (shown in the video )
2. the testlight in rung 2 is on all the time
3. if I changed rung 2 to GRT result1 > 1500, the testlight in rung 2 is off all the time. ( though the result1 value was shows as 2000)



Question:
what are the values shown on the ladder diagram ? for example, result1 in rung 0 should be 0, result 2 in rung 1 should be 1000, and rung 2 should be 2000. Why results in all rungs show the same value as 2000?


thank you

It's continuously scanning in cycles and the display isn't fast enough. You have three rungs all trying to put different values into result1 during each scan.

Rung 0 moves 0 into result1.
Rung 1 moves 1000 into result 1 (you have no formula, just a number)
Rung 3 moves 2000 into result 1 (you have no formula, just a number)
Rung 0 moves 0 into result1.
Rung 1 moves 1000 into result 1 (you have no formula, just a number)
Rung 3 moves 2000 into result 1 (you have no formula, just a number)

and so on....

For help on an instruction, click on it then press F1. It'll bring up a help window with a description of how that instruction works and an example or two.

let us say, I have a 8 channel AI module in slot 1.

in rung 0, MOV I:1.1 to variable1
some other rungs here
in rung 90, MOV I:1.1 to variable2

assuming the value in register I:1.1 has changed during the timeframe between rung 0 and rung 90.

my question:
1. in the PLC tutorial I watched, values will be first read to the IO register during the PLC scan, then run the ladder diagram (https://youtu.be/AF3sRde0qhs) . my question is the MOV instruction in rung 0 will assign variable1= I:1.1 at that instant of time when running rung 0 or fetch the value already saved in the register I:1.1 during the early scan ?

2. will variable1 be equal to variable2?

question 1 and 2 basically is the same question.

Hi pittlei,


I mostly work with DCS controllers not PLCs but I assume they work much the same:


My view would be this:


Scan Cycle:
1: Update Data Tables From IO
2: Execute POUs


So I would assume that the MOV instruction at both rung 0 and rung 90 will have the same source value because the value from the IO wont be updated until the scan cycle is run again.

pittlei said:

let us say, I have a 8 channel AI module in slot 1.

in rung 0, MOV I:1.1 to variable1
some other rungs here
in rung 90, MOV I:1.1 to variable2

assuming the value in register I:1.1 has changed during the timeframe between rung 0 and rung 90.

my question:

2. will variable1 be equal to variable2?

question 1 and 2 basically is the same question.

Click to expand...

I'm going to take a stab at this, but for full disclosure, I'm not that smart, and have often been proven wrong. On the plus side, if I'm wrong, the resident sharks will smell the blood in the water and pounce on the opportunity to correct a lowly Bubba.


The short answer to your question is maybe.

You are going to have a few of things coming into play that will determine if the two values are the same or not.

The first is the brand and flavor of your PLC. In the Allen Bradley ControlLogix platform, the scan and update times are asynchronous so the processor does not follow the scan/update/housekeeping/repeat formula that the older SLC processors did. In fact, the possibility that your your data will update mid scan is something that you have to account for when programming. I can't speak at all about any other brand of PLC because they are like the metric system to me. I have heard of them, and seen examples. But that's as deep as my knowledge of them goes.

Another factor will be the scheduled update time for the card. (RPI?)Generally, the update time will be faster than the scan time, but that isn't always the case. so that would be another thing that has to be considered when programming.

As a general rule, if you need something to happen in very reliable and predictable intervals in ControlLogix processor, then you would put that in a periodic task. A periodic task will interrupt the the "main" program and execute no matter where the main task is in its cycle. So if you wanted variable1 and variable2 to always have the same data, then you would update them in the same periodic task, perhaps even on the same rung. If you wanted to be able to track the rate of change between them, then variable1 could be updated in periodic task that runs every 500ms, and variable2 would be in a second periodic task that runs every 600ms, or whatever you want the time difference to be. This would not be the easiest way to accomplish things, but it would work.

Hopefully this helps. Now we just have to wait and see just how wrong my answer is.


Bubba.

One thing you have to remember is the communications i.e. monitoring.
For example regardless of the type of I/O table update i.e. start of scan, end of scan etc. the monitoring of the program is much slower than the scan in most cases so it could be that when the data is read to RSL for monitoring the value in a register will be the value at the time the data is transferred. so for example if you had a variable that was being written to by many rungs then the value displayed could vary depending when it was read. Again it probably depends on platform and how the communications work i.e. at any time or only at end of scan cycle.
The only reason to write different values to a variable within the scan (well normally and assuming update at end of scan) would be for example used as a temporary holding variable.
i.e.
mov 1000 MyVar
do something with it
mov 1002 MyVar
Do something with it.
personally, I prefer update at beginning or end of scan, that way I know what value would be sent to say I/O it would be the last value set in the program scan.
Most platforms that use this principal have functions to refresh or enable/disable and timed update.

Get stupid; it's the only way

pittlei said:

Hi, I am new to PLC with computer science background in scripting. I am very lost in the ladder logic here.


[...]


Question:
what are the values shown on the ladder diagram ? for example, result1 in rung 0 should be 0, result 2 in rung 1 should be 1000, and rung 2 should be 2000. Why results in all rungs show the same value as 2000?

Click to expand...

What are the values:

The values shown on your PC are the values of the variables from a snapshot of the entire state of the PLC variables at the time the PC did a query of the PLC.


The PC does not query for e.g. [variable result1 after rung 1], [variable result1 after rung 2], etc.



Why results in all rung show the same value:


Because when the PC displays a values for a PLC variable, the PC uses that PLC variable's single snapshot queried value for all locations in the ladder diagram where that variable shows up.



The PC query process is not a debugger.

TL;DR

The prerequisite to any CPU/computer/digital debugging task it that we have to get stupid, as stupid as the hardware we are using.

There are several activities going on here:

1) The PLC is repeatedly

• reading inputs
• running the program
• writing outputs
• responding to queries from the PC
• it may be doing those things asynchronously

2) The PC is repeatedly

• querying the PLC for its state
• updating the display with the result of each query
• it is almost certainly doing this asynchronously with the PLC

The key thing to understand here is that the update of the PC display happens asynchronously with respect to the execution of each rung.

The PC almost certainly does not query the PLC after each rung executes, it may not even query the PLC at the same point during each PLC scan.

However, when the PC does execute a query, the PC only queries the state of the variables, not the program; the PC already "knows" the program that the PLC is running; the PC has, and displays, that program in ladder form. That ladder diagram on the PC is a static template on which the PC hangs the dynamic PLC variable values.

So any set queried data is an instantaneous snapshot of the state of only the variables from the PLC.

When the PC displays PLC variable values in the ladder diagram, it uses those snapshots; so even if a PLC variable is used in more than one place, and has more than one value, throughout the PLC ladder program, the PC has only one queried snapshot value for that PLC variable, and the PC displays that single snapshot value for every rung and instruction that uses the PLC variable.


Extra credit

You could put a couple of tests after each assignment to result1.


For example, immediately after the CPT instruction rung, which assigns 1000 to result1:

• Add a rung that latches a bit (to True) if result1 is equal to 1000
• Add a second rung that latches another bit (to True) if result1 is not equal to 1000.

Ensure those two bits to be latched are not assigned anywhere else in the program.


The second added rung is actually more interesting: it will never give a True result (although of course you will only see a snapshot anyway, which is why these diagnostic rungs use latching.



The first added rung could be made more interesting if it were to unlatch its bit (to False) if result1 is equal to 100, and there was a [First Pass]-dependent rung that set its destination bit True.


According to The Google, [First Pass] is S:1/15 on SLC and MicroLogix; [First Pass] is S:FS on ControlLogix and CompactLogix.