Resetting a totaliser yearly

[Ron Beaufort]

well then, I think that a friendly wager would be in order ... personally, I'm betting that the Help file that you posted for the 1400 is wrong ...

I KNOW that the same description would be wrong for the 1100 - because I just ran the test shown above ...

and I'm pretty sure that I remember running the same test several years ago on a 1500 - and the book was wrong about that model ... (I can confirm the 1500's operation later today) ...

I don't have a 1400 available right now - but I'll bet more than pocket change (but less than the rent) that the Help file is wrong on that one too ...

going further ... the Instruction Set Reference for the 1400 basically says that the ONS instruction gives the "same functionality" as the OSR for the SLC 500 and the MicroLogix 1000 platforms ... the "inline" OSR instruction does NOT get its status bit set during Pre-Scan ...

suggestion:

if anyone out there has a 1400 available to run the test I've shown above, that would be a very simple way to settle this friendly little conversation ...

.

 

[JonAW]

As the Op of the thread I would run a trial but the control system is no longer in the manufacturing workshop. Sorry about that.

 

[daba]

I only have a 1500 that I could test it on, that wouldn't give a conclusive result, so I'll leave it until another day. (EDIT: just noticed Ron is going to test it on a 1500)

A-B (or RA) have clearly made a big hole in their foot (with a shotgun) in the way they have jiggled about with one-shots over the years.

I started my PLC career working mainly on PLC5's (circa 1987), and that platform had a conditional ONS instruction that could be placed anywhere on a rung. Pre-scan of that was as I described. Big jobs were handled by PLC3's and 3/10's, and to be honest I can't remember what one-shot instructions they had.

Along came the PLC5/250 and I was lucky (!) to do a project with the first release of the firmware that had no math or compare instructions, only CPT and CMP - deep joy that was !! And there was no ONS, it had been replaced with output instructions OSR and OSF, causing you to use more memory, and slow the scan down...

I skipped the SLC era, moving up to ControlLogix as soon as it was released. Back came the conditional ONS, together with the output OSR and OSF instructions. We were blessed with all three !!

It is only recently (years, not days, lol) I learn that SLC has an OSR conditional that looks and feels like the ONS I am familiar with. I suspect someone with total disregard for the consequences decided the instruction should be called OSR, not ONS, because it only "reacts" when the rung conditions change from false to true (rising). IMO that was a "misplaced" decision.

So now we have ONS OSR and OSF that mean different things in different platforms, which to me is not a good idea, but hey-ho, it's all explained in the online "help"... but Ron is now telling us that the beloved "Help" system is flawed.

Given that RA train people to rely on the Help, (written in the course material), you'd have thought they would have got it right. People have to program these PLCs, not spend time discovering how instructions actually work !!

Eagerly awaiting a definitive answer... the test is simple, put a CTU instruction on a rung with just a ONS in front of it. The counter should not count on mode change (program to run), nor should it count up on power-up.

 

[Ron Beaufort]

I tried the same test shown in Post #13 on a MicroLogix 1500 today ... the results were exactly what I expected – the Pre-Scan operation does NOT set the status bit of the ONS instruction ...

the only conclusion that I can reach is that the Help file being referenced is wrong ...

the test is simple, put a CTU instruction on a rung with just a ONS in front of it. The counter should not count on mode change (program to run), nor should it count up on power-up.

I'm afraid that particular test won't be conclusive ... the counter won't count at all either with or without the ONS instruction ...

the reason:

the counter's CU (Count Up) bit will be set (to ONE) by the Pre-Scan operation – which means that the CTU wouldn't increment on Go-To-Run even if located on a completely unconditional rung ... using an ADD instruction would make a much more reliable test – simply because the ADD won't be influenced by the Pre-Scan operation ...

the test shown below was done on a MicroLogix 1100 ... notice that the ADD instruction incremented once at Go-To-Run ... neither of the CTU instructions counted at all ...

if the status bit of the ONS had indeed been set (to ONE) by the Pre-Scan, then the ADD would not have incremented when the processor was switched into the Run mode ...

.

 

[daba]

I'm afraid that particular test won't be conclusive ... the counter won't count at all either with or without the ONS instruction ...

Yes, you are correct, I should have taken into account that the .CU will be set by pre-scan....

Perhaps to ensure that a ONS operation works as intended across all platforms, it could be followed by XIO "First Scan".

The reasoning is that the first scan will pre-condition the ONS (if it wasn't already pre-conditioned by the pre-scan).

I tested this on ControlLogix as below, notice that I had to "roll-my-own" one-shot, to simulate an ONS that isn't set by the pre-scan.

 

[Geospark]

We are going way O.T. here, but it is very educational.

Ron,

For arguments sake, I have tested your rung from Post #13 on a 1400 and yes, the 1400 does exactly the same as your rung comments describe for your 1100 test, and subsequent 1500 test, and so it should in my opinion.

What the RSLogix help is suggesting is that the pre-scan always sets the storage bit for ONS instructions to prevent false triggers on the first scan, no matter what. Our little test has proved otherwise.

The ONS instruction is a retentive input instruction that triggers an event to occur one time. After the false-to-true rung transition, the ONS instruction remains true for one program scan. The output then turns OFF and remains until the logic preceding the ONS instruction is false (this re-activates the ONS instruction). The ONS Storage Bit is the bit address that remembers the rung state from the previous scan. This bit is used to remember the false-to-true rung transition.

It has always been my understanding that the ONS instruction is retentive, so the storage bit retains its last state during power cycles or switching between Run and Program Mode. If this is the case, the pre-scan should not need to set the storage bit to prevent false triggers.

A false trigger is where the rung-condition-in to the ONS instruction is true when the controller goes out of Run Mode, and is still true when returning to Run Mode. If the ONS was non-retentive, and the pre-scan does not set it, then the pre-scan would reset the storage bit. Then, on the first scan, the rung-condition-in to the ONS would be true, the storage bit would then be set, and the ONS rung-condition-out would be true, executing the rung. This, in effect, has executed the rung twice for the one transition from false-to-true of the rung-condition-in to the ONS instruction. Once before leaving Run Mode, and once when returning to Run Mode.

To prevent this, the ONS storage bit is retentive.

Scenario 1: Prevent false trigger

When the controller goes out of Run Mode, with the rung-condition-in to the ONS true, and the storage bit set, the storage bit retains its last state. When returning to Run Mode, the pre-scan does not set the storage bit. It is still set retentively. The rung-condition-in to the ONS is still true. The first scan reads the rung-condition-in as true, and the storage bit as set. So the rung-condition-out of the ONS is false and the rung does not execute. The rung-condition-in to the ONS must now go false-to-true again to execute the rung once more.

Scenario 2: Normal false-to-false thru a Run Mode cycle

If the rung-condition-in to the ONS is false, and the storage bit is reset when going out of Run Mode, the storage bit retains its reset state. When returning to Run Mode, the pre-scan does not set the storage bit. The first scan reads the rung-condition-in to the ONS as false, and the storage bit as reset. The rung-condition-out of the ONS is false and the rung does not execute.

Scenario 3: Ron's little test

Again, if the rung-condition-in to the ONS is false, and the storage bit is reset when going out of Run Mode, the storage bit retains its reset state. But now let's say the rung-condition-in becomes true, while out of Run Mode. When returning to Run Mode, the pre-scan does not set the storage bit. The first scan reads the rung-condition-in to the ONS as true, and the storage bit as reset. So the storage bit is then set, and the rung-condition-out of the ONS is now true. The rung executes on the first scan.

Is it correct that this should happen?

I would say yes. The fact that the rung-condition-in to the ONS is false when going out of Run Mode means that the execution of the rung after returning to Run Mode is valid. The transition of the rung-condition-in to true for the ONS during say Program Mode, or a power cycle, is another transition after the last valid one, and may allow execution of the rung.

Of course, it may not be ones intention for this to happen in certain applications. If you must execute the rung only on the transition to rung-condition-in true to the Oneshot, use an OSR - One Shot Rising. The OSR will ignore the fact that the rung-condition-in is already true on the first scan, and subsequent scans, and will wait for the next transition from false-to-true.

As I said, that is my understanding of how it works. It makes the most sense to me looking at it, but I am open to other suggestions.

I'm not sure if the pre-scan is actually involved in writing retentive values, but if the pre-scan does actually write to ONS storage bits, it must write its last state before it left Run Mode. In other words, the pre-scan performs the retentive write to prime the storage bit before the first scan. That's the furthest I can stretch the Help files explanation into making some kind of sense?

Just to add some more mystery to the plot...

39155 - Why is the ONS Instruction (One Shot) rung-condition-out false when a Logix controller goes into RUN mode?
Access Level: TechConnect

...but I still feel it is retention that performs this task, and not the pre-scan.

Or else this is a "wood for the trees" scenario?

Regards,
George

 

[daba]

....

...but I still feel it is retention that performs this task, and not the pre-scan.

Or else this is a "wood for the trees" scenario?

Regards,
George

Some food for thought there, but missing the point that this may be a completely new program, freshly downloaded, and going into RUN mode.

I think your notion of "retention" may be a bit misguided. All data is retentive by nature, the memory image will power-up in the same state that it was in when the power went off. The purpose of the pre-scan, therefore, is to reset/preset any data that shouldn't be retentive, by design.

If the conditions on a rung preceding an ONS are true, then there can have been no prior knowledge of that state. The pre-scan (when we have determined on which machines it does, and which it doesn't) sets the storage bit, so that the first real scan doesn't trigger the ONS to "perform".

What we really need now is a definitive test that people can perform on the various platforms, to determine if a ONS is triggered falsely, or not. That will tell us which of the "Help" entries are incorrect.

Ron's "ONS - ADD" example will suffice, if the ADD instruction executes, then the pre-scan is not pre-conditioning the one-shot storage bit as it should, or even as indicated in the "help" that it does !!

 

[Ron Beaufort]

I'm teaching this week – and then going into "extra innings" each night – so I don't have a lot of time to comment on this right now ...

the point I'd like to make is that WHATEVER operation we decide would be "right" for the One-Shot instruction – we'll still end up dissatisfied with the results of the debate ... that's because the ONS instructions for the larger Allen-Bradley PLC-5 and ControlLogix systems have a DIFFERENT Pre-Scan procedure at "Go-To-Run" than the ONS for the smaller Allen-Bradley MicroLogix platforms ...

specifically ...

with the ControlLogix and PLC-5 systems, the Pre-Scan operation DOES set the ONS bit to a status of ONE ...

but ...

with the MicroLogix systems, the Pre-Scan operation does NOT set the ONS bit to a status of ONE ...

in the final analysis, the Help files for the MicroLogix platform are wrong regarding the "Go-To-Run" operation of the ONS instruction ... in some cases that might be an important thing to know ...

 

[Geospark]

Some food for thought there, but missing the point that this may be a completely new program, freshly downloaded, and going into RUN mode.

daba,

What exactly have I missed with regard to a completely new program going into Run Mode? What's the difference between a programs initial Run Mode and any of its subsequent Run Modes?

An ONS storage bit can be set(1) or reset(0) before going to Run Mode. Either of these states are possible, whether going to an initial Run Mode, or a return to Run Mode. Usually for an initial program, an ONS storage bit will be at the default reset state when downloading to the controller for the first time, unless the programmer manually changed it, for some reason, to the set state in the offline program before downloading.

If it is initially downloaded as reset, then this state becomes its first retentive state when going to Run Mode. If it is initially downloaded as set, then this becomes its first retentive state when going to Run Mode. This is the same as a storage bit being set, or reset when leaving and then returning to Run Mode.

In relation to the state of an ONS storage bit, I don't see how a "completely new program, freshly downloaded, and going into RUN mode" is any different from an existing program going to Run Mode.

I'm going to clear the 1400 after lunch and download a blank, completely new program, with just Ron's rung of logic. I'll leave the input turned ON before going to Run Mode. What are the bets that the initial state of reset for the ONS storage bit allows the rung to execute on the first scan?

...I think your notion of "retention" may be a bit misguided. All data is retentive by nature, the memory image will power-up in the same state that it was in when the power went off. The purpose of the pre-scan, therefore, is to reset/preset any data that shouldn't be retentive, by design...

I think your notion, of my notion, of "retention" may be a bit misguided?

I am fully aware of the fact that the controllers NVRAM is inherently retentive and the pre-scan is designed to alter the necessary data to a pre-determined state before going to Run Mode. My references to retentive data are program related and not from the classical sense of NVRAM being inherently retentive after warm or cold restarts.

When the controller goes to Program Mode, or power cycles, and then back to run mode, the pre-scan will leave retentive data, determined by the program, in the state it is in. All non-retentive data, determined by the program, is reset by the pre-scan. Special cases, again determined by the program, are pre-set to initialize them, such as the Counters CU bit that Ron mentioned.

Of course, if a pre-scan was not performed, and the controller goes straight to Run Mode, then all data will be retained as it was before.

When I mentioned the pre-scan carrying out retentive writes, I was hypothetically stretching the imagination, to consider what the Help files are saying. I was saying, at a "stretch" it might be possible that the pre-scan does write to retentive data, determined by the program, to double ensure that the data is indeed retained as intended, but, this would require the program having stored retentive data states elsewhere in memory to access during pre-scan so as to write to the retentive data addresses in memory. A far stretch of the imagination indeed. i.e. it does not happen, i.e. the pre-scan does not write to retentive data.

Again, to make the distinction, so I'm not misguided, I am referring to retentive data determined by the program, not inherently retentive data. The data for which the pre-scan does write to, such as our CU bit, is inherently retentive, but the program has determined, by design, that it needs to be written to for programmatic reasons.

...If the conditions on a rung preceding an ONS are true, then there can have been no prior knowledge of that state.

Again, as the Instruction Set Reference Manual for the 1400 states, and unless that section is incorrect as well, the ONS is a "retentive input instruction". This means it retains its state while transitioning in and out of Run Mode. The state it retains is the state of its storage bit when leaving Run Mode, which is determined by the "conditions on a rung preceding an ONS" being either true or false. The storage bit retains the "prior knowledge of that state".

...The pre-scan (when we have determined on which machines it does, and which it doesn't) sets the storage bit, so that the first real scan doesn't trigger the ONS to "perform"...

The Help files from RSLogix 500 state that it does this, but our test has proved it does not for the MicroLogix family.

I'm not one for stubbornly going against what Help files state, but RSLogix 500 covers a good few controllers. The fact that the name MicroLogix contains the same appendage as CompactLogix and ControlLogix, etc., makes it quite possible that someone writing that section made a mistake. Someone not too familiar with the differences, made a mistake, making a general reference for all "Logix" controllers, which actually only refers to RSLogix 5000 based controllers, which do set the storage bit during pre-scan. It could easily be missed during a proof reading as well, as often grammar mistakes are more looked for than the accuracy of the information. That's just a theory of course.

In this case, the retentive theory, backed by the individual controllers Instruction Set, fits what I have observed, and what I have always understood for the MicroLogix while using ONS instructions. The Instruction Set, while stating it is retentive, you will notice, makes no note of the fact that it is set during pre-scan. To state it is both retentive, and set during the pre-scan, would be contradictory. If it is always set during pre-scan, then a retentive reset state would never be possible...

...What we really need now is a definitive test that people can perform on the various platforms, to determine if a ONS is triggered falsely, or not. That will tell us which of the "Help" entries are incorrect...

...So which is correct and which is incorrect?

Here's one way of asking...

Is the MicroLogix controller's tested operation of being apparently retentive for the ONS instruction correct, as per the MicroLogix Instruction Set?

Or...

Is the RSLogix 500 Help file reference correct, and all MicroLogix controllers are not functioning as intended, also meaning the Instruction Set is incorrect?

The decision is yours...

Regards,
George

 

[Geospark]

...I'm going to clear the 1400 after lunch and download a blank, completely new program, with just Ron's rung of logic. I'll leave the input turned ON before going to Run Mode. What are the bets that the initial state of reset for the ONS storage bit allows the rung to execute on the first scan?...

I've just performed this test. I cleared the controller. I left the input turned ON. I checked that the ONS storage bit was default reset. I downloaded a blank program with just the test rung of logic and went online. The controller was still in Program Mode, as it should be. I checked again that the storage bit was still reset. I placed the controller into its initial Run Mode and the rung executed. The ADD incremented.

So again, it would appear that the pre-scan does not set the storage bit, even during a first pre-scan of a first program downloaded to a cleared controller.

Next, I cleared the controller again. I left the input ON again. In my offline program, I set the storage bit, saved, downloaded and went online. Again, in Program Mode, I checked that the storage bit was still set. I placed the controller into its initial Run Mode and the rung did not execute, the ADD did not increment.

It would appear that the state the storage bit is in before going to pre-scan is the state the storage bit is still in when leaving pre-scan and going to Run Mode. i.e. it is retentive.

It is also true to say of the SLC family that - with the rung-condition-in to an OSR being false, and with the storage bit being reset, and then going to Program Mode, and then setting the rung-condition-in true, and then returning to Run Mode, that the rung will execute. However, the RSLogix 500 Help files do not state that the SLC's OSR storage bit is set during pre-scan to prevent false triggers. But it does show a trend that the RSLogix 500 based controllers, that use ONS and OSR instructions, do not set their storage bits during pre-scan. That feature would appear to be the reserve of PLC-5 and Logix based controllers.

Another point to add...

The Logix5000 Controllers General Instructions Reference Manual does not define the ONS instruction as being retentive. Again, this would be contradictory, as the pre-scan always sets the ONS storage bit.

Until proved otherwise, for me, the evidence all points to the ONS instruction for the MicroLogix controllers being retentive and untouched by the pre-scan.

Regards,
George