_LE, _INTRASCAN, _DUPECOIL, _PERSITANCE Sub Scan behaviour

L

Thread Starter

LouisKriek

I read that some people were developing the LinuxPLC with Opto hardware while others wrote about having a lot of Allen-Bradley hardware. One day a Allen-Bradley 1746-HSCE High Speed Counter module would/could be part of the hardware.
Allen-Bradley has kindly put the user manual on-line (file name 174665.pdf)
.

PLC_DUPECOIL:
Duplicate use of coils is a thing that is frowned upon. Commercial Ladder programming software often does not check for coil duplication until the user makes a menu choice to active a test of the Ladder for this error. However a good Ladder may not be able to avoid this frowned upon practice.

While Omron has a Keep Relay with both a Set and with a Reset input controlling a single output coil shown as a single rectangle, in contrast
Allen-Bradley has them split into two parts. Splitting them into two parts for the same coil give great flexibility in placing the Set(U) part or placing the Reset(L) part without the discomfort of crossing "wires" , but it does free someone up to program (perhaps unknowingly) multiples of say the Reset(L) part. Here the only distinction is wether to energise or de-energise the one coil. I know/agree this is slightly/a-lot different from(depending on your point of view) duplication of ordinary coils.

Look at the example in the above user manual, on page 6-5, rung 2:5, and rung 2:6.

PLC_INTRASCAN:
case 1
Look at the example in the above user manual, on page 6-5, rung 2:1, and rung 2:2.
Add to this the explanation for coil M0:1.1/12 written on page 4-26.
"...do not set to 1 until all of your configured parameters are transferred"...(this is the task in rung 2:1)
"Module operation will be altered upon 0 to 1 transition..." (this is the task in rung 2:2)
To get the coil M0:1.1/12 to be the pre-requite 0 is the task of an rung (call it rung 2:1-1) not in the example, but is identical to rung 2:2 with
an L action instead of a U action. All three rungs are alive only for the same single scan, here in the example it is S:1/15 the "1'st Pass" contact.

This works in practice, and highlights the INTRA_SCAN changes to the I/O scanner's outputs. I am saying that the effect is progressive and
instantaneous all the way to the hardware, progressive down the ladder. ie There may not always be a respectful waiting for an EndOfScan/BeginOfScan I/O update action.

With 700MHz processors, the speed that each rung is solved/actioned is perhaps far, far faster than the poor 1746-HSCE could cope with. Without
the slowing down effect of a long scan cycle, the speed of solving adjacent outputs may be no more than "white noise containing Nil
information content" as far as hardware module is concerned.

(Here is my point)...
This has implications for the LinuxPLC scan and intrascan design, and for the LogicEngine timing and design.


case2:
A math calculation will be written as a series of
functions/data-manipulations consecutively down the right hand side of the Ladder page. The intermediate results are immediately useable by the next lower function/data-manipulation. There only needs to be a single contact to "power" the whole group of functions, and that contact needs to be on for only a single scan.

case3:
If there is a _DUPECOIL error in the Ladder, the state of the last evaluated instance will be the state to go to the output hardware.
It is often not explained, that the state of that coil will go through all the high/low values that the relevant Ladder rungs cause. If that output coil is "listened to" by some hardware module or whatever, than that module will have been told a hole sequence of High/Low states, even though more likely if this output is an ordinary output "coil" then none of the mid-scan sequence will be visible outside the PLC.
ie The Ladder Programming software do not prevent DUPECOIL Ladders being downloaded to the existing PLCs. The existing PLCs don't care about
multiple instances, or do not care about dupecoils, because they seem to just solve the Ladder rung by rung mindlessly. It is in the existing Ladder Programming software where the concern for DUPECOIL is located, not the LogicEngine)

(This is probably why the standard theory where inputs are all en-mass sampled and held at the beginning of a scan, followed by a solving of the
Ladder networks to create a "file" of future outputs, followed by an action at the end of the scan where these are applied to the output hardware, is very clearly spelt out by each manufacturer, but an explanation of what happens mid-scan is not quite so definitely
explained.)

(Here is my point)...
Intrascan functions have immediate effect at the mid-position of the scan. Further LogicEngine solving Ladder networks either using bits Or using
words, are based on the results saved/stored/backed-up data words manipulated mid-scan. The theory of only passing the solved output bits on towards the output hardware at the end of the scan, is not applicable to all bits.
This will give a different result to the situation where the PERSISTANCE aspect for the LinuxPLC is applied at the end of a scan.
So really persistence might need to be in active operation on a time scale much smaller than the time scale of a scan.

If Persistence is going to provided by a hard-drive, then the worst-case timing for write latency needs to be smaller than the shortest time between individual events where the solved value needs to be saved. (ie in the
worst-case, the time between individual "rungs"/maths_functions on the one scan.) The newest hard-drives are advertised with quoted times on-average of sub 10 milliseconds.
Probably something clever would be needed to use a hard-drive, and yet never loose a single important bit of information, and never have to the
hard-drive say that it is not quite ready yet for a power supply loss. The other concern is that if all the drive's attention is fixed on saving
Persistent data, we would need to have a _different hard-drive_ for the operating system to use for its tasks, so that our writing head will never be busy doing someone else's writing/reading task at the very moment that
some Persistent data is urgently needed to be saved. The idea of a simple SRAM card with built in battery is looking very nice, plus it give a place to put a WatchDog Timer too. I have not seen a WatchDogTimer discussed yet, even though it is a traditional/knee-jerk requirement for projects like this.

Persistence as Practiced by Existing PLCs:
By the way, in most PLCs that I have looked under the covers, I have seen a single SRAM chip, and the whole of the SRAM chip - not selected portions of the chip is battery(or capacitor) backed. Even when PLCs were young, and
SRAM was expensive and came in smaller chips, they did not selectively choose portions to be battery backed. The point is that the design choice taken was to simply give Everything
persistence, and additionally at the time of PowerUpAgain there is a housekeeping routine that selectively zeros the bits that have no right to
have Persistence. If I remember correctly, Omron C200H has a bit that will configure that
PowerUpAgain housekeeping routine to give Persistence or No Persistence to selected type of bits. The LinuxPLC might take a similar design decision to save everything at each picosecond of the day, and delay the awfull moment of deciding what can be seen to have persistence and what may never appear to havePersistence until the moment of a single scan when the PLC Powers up Again,
ie instead of running the processor ragged doing timestamps and CRCs and rotating overlapping logs and making sure that we don't figuratively "wear
out a spot in the carpet" on the hard-drive etc, let the processor do nothing most of the time and let it do a little task just once for the very
first scan.



(Soapbox
Do you remember the relay circuit with physical relays. Do you remember the occasional circuit that only worked because one relay was marginally faster than another sort, or in another position of the circuit diagram. Do you remember the adjective you were tempted to use. In PLC Ladder land we have circuitry that depends on where it is located in the ladder. Just as a base 10 number system has the concept that position has a bearing on value, so for ladders etc- position has a bearing on just how the circuit will actually work. Shift things around and most likely it wont matter, but it might, so see/think/check if it matters in this particular
edit move. Files may have progresses from .COM to .EXE and use the idea of "relocatable code" , but in Ladder land--because of the downward scan-- the
code is not carelessly "relocatable.
End of Soapbox)


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top