MicroLogix ONS Instruction Question

MikeVT · Aug 9, 2012

I think I found/discovered a quirk between a ML1400, and a ML1100, and I'm wondering if anyone has run into this.

I copied a count routine (ladder) created for a ML1400 processor, into a program for a ML100 processor, and my counter does not increment. When looking at the instruction set help pallete in RS Logix 500, it looks like the [ONS] instruction is only compatible with ML1200; 1400; 1500 processors. It looks like I must use the [OSR] instruction on the ML1100 processor. However, in the instruction help, the ML1100 is not specifically noted in either instruction help. Should I assume that the ML1100 is in the ML1000 class of processor? Am I on the right track, here? Looking at my logic, this is really the only possible hitch, compared to other successfully launched programs with this count routine in them.

Thanks for your help!

dmargineau · Aug 9, 2012

Execution Time for the ONS Instructions

Controller When Rung Is:
True / False

MicroLogix 1100 1.87 μs / 1.74 μs

MicroLogix 1400 0.2776 μs / 0.3110 μs

Clay B. · Aug 9, 2012

ONS works the same in both processors. Check that you are using a unique bit for the ONS that is not being used anywhere else in your program. That is the most common mistake.

Brijm · Aug 9, 2012

IF the ONS instruction is not compatible with the processor, it will give you an error, when verifying the program. (Same for the placement of the ONS). You will not be able to download the program. As Clay said, do a "find all" on the address of the one shot.

If you are using the CTU instruction, take the one shot out (you don't need it anyway)

dmargineau · Aug 9, 2012

Like I've stated in my first post, an ONS instruction within a ML1100 system needs NINE TIMES longer Rung Conditions In True for the instruction to execute than if the instruction is used within a ML1400 project.
(Reciprocally, the ML1100 ONS will not "release" for almost SIX TIMES longer than if it used within a ML1400 CPU).
If the CTU(D)s in both systems are operated via similar logic, the conditions' timing could be the reason the accumulator doesn't increment within the ML1100 application.

Brijm · Aug 9, 2012

dmargineau said:
Like I've stated in my first post, an ONS instruction within a ML1100 system needs NINE TIMES longer Rung Conditions In True for the instruction to execute than if the instruction is used within a ML1400 project.

I don't think that is correct. A RS500 program will execute the same way, even if the instruction time was 1 second. The difference is the longer it takes to execute an instruction the more it will effect your scan time. If your inputs are updating quicker than your scan time, then you may miss an external transition, before the next logic execution.

If you have 500 ONS instructions in your program, you may add about 800 μs to your scan time from a ML1400 to a ML1100.

I doubt this is a problem, unless you have fast I/O, and are pushing the limits of the ML1400 as to scan time vs IO update rates.

dmargineau · Aug 9, 2012

Brijm said:
I don't think that is correct. A RS500 program will execute the same way, even if the instruction time was 1 second. The difference is the longer it takes to execute an instruction the more it will effect your scan time. If your inputs are updating quicker than your scan time, then you may miss an external transition, before the next logic execution.

If you have 500 ONS instructions in your program, you may add about 800 μs to your scan time from a ML1400 to a ML1100.

I doubt this is a problem, unless you have fast I/O, and are pushing the limits of the ML1400 as to scan time vs IO update rates.

http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1766-rm001_-en-p.pdf Page 145.

http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1763-rm001_-en-p.pdf Page 163.

The rung conditions will have to maintain state for at least as long as the instruction takes to execute.

Mickey · Aug 9, 2012

You don't need a one-shot with a counter instruction (CTU) as it only increments once on a false to true transition.

Maybe if the OP can post the program ( it's .RSS file) someone can spot something.

Zip it first and tell us which rung is giving you the problem.

Brijm · Aug 9, 2012

dmargineau said:
http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1766-rm001_-en-p.pdf Page 145.

http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1763-rm001_-en-p.pdf Page 163.

The rung conditions will have to maintain state for at least as long as the instruction takes to execute.

The RS500 series is a synchronous scan.

I/O and Communications are updated only once during the program cycle. Therefore unless changed in the program, they will remain the same throughout the program scan. So instruction time is really mute, except that it will effect your overall scan time.

This is not true in a Logix series. An Input can be updated at any time during the scan.

dmargineau · Aug 9, 2012

Brijm said:
The RS500 series is a synchronous scan.

I/O and Communications are updated only once during the program cycle. Therefore unless changed in the program, they will remain the same throughout the program scan. So instruction time is really mute, except that it will effect your overall scan time.

This is not true in a Logix series. An Input can be updated at any time during the scan.

I agree...too much Logix lately...

However, just comparing the execution time for any instruction within the ML1400 and ML1100 systems, one could conclude that the overall scantime of the same application running on both MLs is significantly slower on the ML1100 (five, six times on average).
Since the ONS usage is generally required by communications transferred data, I still believe there is a timing issue.

MikeVT · Aug 10, 2012

This post's replies took a tangent I never expected. This program is not that complicated. The count trigger is a bottle passing a photo eye, not anything high speed. program scan time is not an issue. I checked for calling the subroutine (done that goof before). I checked for multiple instances of the one-shot bit, and other pieces of the involved logic, and I do not have duplicates in my program. I zipped a copy of the routine, and will attach it to this message. The actual input is triggering a 'status bit', which is what you will see in the zipped copy. The logic, when true, operates an ADD statement, to add '1' to a floating point register, not a CTU.

I have not had the chance to get back to this customer yet, and do some real troubleshooting. I will reply, when/if I find something.

Thanks

kolyur · Aug 10, 2012

I have used both the 1100 and 1400 and I can vouch for the fact that ONS works the same on both platforms.

You mentioned that the photoeye is not high speed, but is it possible that the input filters need adjusted? (I/O Configuration -> Adv Config -> Embedded IO Configuration)

Did you try driving the ONS/ADD with the input directly, and omitting the status bit temporarily?

Bob O · Aug 10, 2012

I just ran it in emulator and toggled the bit and it does increment.

MikeVT · Aug 10, 2012

Verifying that the ONS works the same on both platforms is what I was looking for, Kolyur.

Bob O - I didn't think about emulator. I usually use the 1400's on these machines, and I can't get my emulator to with with a 1400 processor chosen.

Thanks, both of you, for your help. Like I said, I need to get back to this machine and do some more detailed troubleshooting. It's just gotta be something silly that I overlooked.

daba · Aug 10, 2012

dmargineau said:
http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1766-rm001_-en-p.pdf Page 145.

http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1763-rm001_-en-p.pdf Page 163.

The rung conditions will have to maintain state for at least as long as the instruction takes to execute.

Not true....

dmargineau said:
Like I've stated in my first post, an ONS instruction within a ML1100 system needs NINE TIMES longer Rung Conditions In True for the instruction to execute than if the instruction is used within a ML1400 project.
(Reciprocally, the ML1100 ONS will not "release" for almost SIX TIMES longer than if it used within a ML1400 CPU).
If the CTU(D)s in both systems are operated via similar logic, the conditions' timing could be the reason the accumulator doesn't increment within the ML1100 application.

You have a slightly misguided view on this - the times you are referring to are just the execution time of the instruction itself, upon detection of a rung-condition in true or false. The instruction cannot see the rung change state once it is executing.

The difference in the timings is purely down to the the macro coding for the instructions in the different processors, and CPU speed.

MicroLogix ONS Instruction Question

MikeVT

Lifetime Supporting Member

dmargineau

Lifetime Supporting Member

Clay B.

Lifetime Supporting Member

Brijm

Lifetime Supporting Member

dmargineau

Lifetime Supporting Member

Brijm

Lifetime Supporting Member

dmargineau

Lifetime Supporting Member

Mickey

Lifetime Supporting Member

Brijm

Lifetime Supporting Member

dmargineau

Lifetime Supporting Member

MikeVT

Lifetime Supporting Member

kolyur

Lifetime Supporting Member + Moderator

Bob O

Member

MikeVT

Lifetime Supporting Member

daba

Lifetime Supporting Member

Similar Topics