Controllogix ADD or CTU not operating properly

[tomalbright]

I can't access the links at work, but is the counter 10000, and the accumulation is over 300000? I find that odd. Not impossible, just odd.

 

[Ken Roach]

Check carefully that accumulator reset tag FIT_017.TOTALRESET and how it is used in the HMI.

When that boolean tag is true, Rung 14 of your routine moves a value of zero into FIT_017.TOTALSTORE.

Then on the very next ControlLogix scan, Rung 12 will move whatever value exists in FIT_017_COUNTER.ACC into the FIT_017.TOTALSTORE tag.

This would cause the value of FIT_017.TOTALSTORE to "drop suddenly" to some value between 0 and 10,000, then start incrementing again.

A proper reset of the accumulator would reset FIT_017_COUNTER with a (RES) instruction, which would then cause FIT_017.TOTALSTORE to drop to zero.

 

[bradal]

Hey Ken,

That is too bad that you will not look at the video, it clearly shows the value jumping around and has absolutely nothing to do with PCanywhere compression or video. I have now added a 4th video with 4 different counters out of a 100 counter array I have just created all counting off of the same bit. They ALL jump at the same point, perhaps discounting the overrun of an array as suggested by kamenges.

I can distinctly see the value, in the PLC, forget the HMI/RSVIEW for viewing. I am looking right at the register and in this case 4 registers in the routine all behaving the same.

 

[bradal]

A proper reset of the accumulator would reset FIT_017_COUNTER with a (RES) instruction, which would then cause FIT_017.TOTALSTORE to drop to zero.

Ken,

The original program had a ADD function to do the same thing with a oneshot, it has been changed to try to find a resolution to the problem, if you check the other FIT routines you will see this layout, I have created separate timers exclusively for this test with no other reference as shown in video #4.

I really appreciate these suggestions.
http://207.34.95.213/Tender/Nason%20Municipal%20Services/Wabamun%20PLC%20Counter%20Issues/

 

[bradal]

Bradal,

Lets stop dancing around. Can you please post the program? If not the program then at least the entire subroutine and UDT structure. These videos give us nothing more than a peek through a key hole and display only the symptom and offer absolutely nothing whatsoever of use in determining the cause.

Yes Alaric, let us stop dancing, and by saying so I have no idea who you are referring to. Please feel free to goto the FTP link I have provided multiple times and grab a copy of the program.

Everytime someone asks me for information suggesting I am not providing some sort of information it is obvious they have not read the whole thread. So please Alaric can we keep this civil and keep pointless comments about dancing around out of it, please read the entire thread. I am no longer referencing ANY UDT for this problem, which you would know had you read the ENTIRE thread.

Ask for anything you need and I will provide it, I have no idea why your patience would be wearing thin, besides that fact that like myself, don't know what the heck is going on!!!

 

[TConnolly]

I see the program on the FTP site now. I was editing my previous post to add "we are trying to be helpful" and soften the tone to make sure you understood the tone that we really are trying to help you, somewhere in the edit I deleted the post. Please don't think I was being uncivil.

 

[bradal]

No problem Alaric I appreciate the help.

 

[bernie_carlton]

For Ken's sake please post all CPU and firmware relevant numbers of anything you can find in the system.

People are having a hard time with this because, as you observe, it really is weird. I think you have done all you can to show this. I think it's going to be some flakey CPU problem.. But what I have no idea what. A glance through the knowldgebase didn't show anything in particular.

It's obviously repeatable where you show the 4 counters going through the count sequence: 337895, 337869, 337897. That number transition doesn't coorespond do anything in particular in hex, octal or binary. This may end up being like the Pentium Floating Point problem from many years back.

 

[Ken Roach]

I did look at the videos, and I examined closely the *.ACD file as well. Thanks for reminding me to look at the other Instrument subroutines to see the ADD instructions; their Reset mechanism works the way I would expect them to.

The reason I said I was going to stop looking at videos is because the "digit jumps" that were so well captured in a frame-by-frame screenshot are consistent with video compression effects.

It is my hypothesis that the "digit jump" that you are seeing while accessing this program and other test programs via a remote connection is a different phenomenon than the "random value jump" being observed by your operators.

It is my opinion that using logic traps instead of videos of a remote desktop display would give you more accurate measurements of what is going on inside the controller tag database and memory.

This is a vexing problem that you've shown, and I'm eager to be of assistance in the community solution.

 

[Ken Roach]

The trick is not to cling too tightly to one hypothesis !

I took a look at the 1-second interval test video called "4 Counter Array 1 Different Preset Consistent Jump in Values" and it appears to disprove the video compression hypothesis. Right at 1:30 into the clip, the accumulated values of all four counters go through this sequence:

337084
337085
337068
337087
337088
337089

The proper value for that iteration is 337086, not 337068.

Another hypothesis: Is it possible the RSLogix 5000 display engine reversed the final two digits ?

You could check that by using ladder logic to see if the values are ever evaluated by the Logix controller as being *less* than the previous value.

 

[bernie_carlton]

Like in the other 4 counter avi the misshown number has the last two characters reversed (though not the same sequence of numbers).

 

[Ken Roach]

And in the video for PLCCounter3, it does it three times:

338368 instead of 338386
338369 instead of 338396
338389 instead of 338398

In each case, the last two digits are switched.

This could be proven to be a display issue instead of a value issue by using a logic comparison trap. Unless, of course, you've lost your faith in the instruction set of the controller to reliably handle integer numbers with the basic instruction set.

I would also try viewing these values in the Database Monitor view or in the Watch Window to see if they behave the same way.

The Pentium floating-point issue is certainly a cautionary tale; I'm sure that those engineers swore up and down it couldn't be possible. Deep and difficult bugs are just part of technology, and diagnostic technique is as much a matter of philosophy as it is mathematics.

Can I ask which version of RSLogix 5000 v15.0x software you are running ? No the controller firmware, but the RSLogix 5000 software itself. I want to read through the release notes to see if there's anything about integer values being displayed incorrectly in the Relay Ladder Logic view.

 

[bradal]

CTU instruction but if you need to count up higher than 32,767 (for instance on a high speed bottling line that does 10,000 pieces per HOUR), then you need to use a floating point value.

Huh? I do not believe they are limited to 32767 which is INT, the controllogix is DINT 32-bit. I will put some trap logic in place like you suggest Ken. If I could get the same value to display in RSVIEW would this prove anything Ken? I will set some stuff up here and get back to you with the results.

Thanks!!

 

[TConnolly]

I noticed the same thing Ken, and the apparent transposition that Bernie pointed out. It also occurs at 337097, 337089, 337099. The same thing happens at the 18 second mark in the second avi, 338385, 338368, 338387.

Although the transposition is erie, what is more telling is that it picks up right where it should be after, definitely like its a display issue and not an issue with the actual number.

Just out of curiosity I pasted 2#00000000000001010010010010111110 into the counter ACC (offline) and then switched back to decimal. I got 337086 as expected. Just to rule it out, I pasted 2#00000000000001010010010010111110 into an unused DINT in a running controller and again got 337086 exactly as expected.

Bradal, I would be curious to see what happens if you look at the counter ACC using the tag monitor and switch the display from decimal to binary.

I exported the ACD to a L5K and went hunting for anything suspicious with any file instructions (COP, FLL, FAL, FFL, etc.) and didn't find anything that looked funny.


edit: I gotta learn to type faster and not compose half a post, walk away for a while, and then come back to finish it without updating to see new posts.

 

[Ken Roach]

You are correct that in ControlLogix, the .PRE and .ACC values of a Counter or Timer are DINT data types, with a maximum value of 2,147,483,647.

This sort of thing gets perilously close to "don't believe your eyes" territory; I can see where you have malfunctions that appear to be random in your system, and you are observing something that appears to be similar, so you go to the conclusion that the ADD or CTU instructions are just malfunctioning.

Let's not go looking over our shoulders for zebras, just yet.

I may have a 1756-L55 in the office that I can load with 15.05 firmware and run exactly this sort of test. That's why I want to know the precise sub-revision of v15.0x RSLogix 5000 software, so I can set it up on a VM if necessary.