Controllogix ADD or CTU not operating properly

[TConnolly]

Ken could answer this better but it seems to me that RSLogix most likely uses a standard library call to generate the string to display to represent a binary in base 10. The reason I mention this is if its something funny to bradal's machine, say a bad dll that replaced a standard dll that isn't doing a very good job of generating the string that is displayed for the number. Or it could be something that replaced an RSLogix dll. If that's the case then Ken might not ever be able to reproduce the problem. Bradal, when was this first noticed and is there a possiblity that some other software was installed around then? Anything funny with any other software, not software that has numbers as text, but software that uses numbers as binary and then converts to text for base 10 display, something that actually does calculations? Its just a stab in the dark, but I figured it was worth asking.

 

[Ken Roach]

One of the reasons I enjoy the TV series "House, M.D." is because it has revived popular interest in the philosophy of diagnosis, and also because of often implicitly cites Hickam's Dictum: "Patients can have as many diseases as they damn well please".

We might be looking at two or three different issues, here.

Consider the video from "PLC Counter.avi". Go through it carefully and you'll see values that appear "incorrect", and a close look at the value display shows that the digits are distorted. This is what I was looking at when I hypothesized that video compression or video display was responsible for the values that appeared wrong (the attached picture is eight instances of a "wrong" displayed value).

By the time we get to the video "4 Counter Array 1 Different Preset consistent jump in values.avi", the digits aren't distorted, they're just in the wrong sequence. That's weird, to be sure, but not outside the realm of possibility for a video compression effect. It could also really be something wrong in the graphical engine that RSLogix 5000 is using to draw those numbers on the screen.

Or, it could be that the ControlLogix is just adding 1 + 1 and getting -12.

I won't use such a blunt instrument as Occam's Razor here, but I will give the advice that if I was going to diagnose this issue, that I would use Relay Ladder Logic traps inside the controller to test data display, rather than the other way around.

All of this may simply be a sideshow to the original problem; that the totalizer value appears to "jump" around. Any additional information that can be harvested about the amplitude of the jump, or the frequency of the jump, or the exact tags that are being read and processed would help that effort a great deal.

 

[Ron Beaufort]

disclaimer: I have NOT been following this thread - and right now I don't have time to read through everything that's been done so far ...

but ...

I have a 1756-L55/A processor Rev. 15.5 up and running on my desk ... if you guys can give me a specific test you'd like to run, let me know and I'll be glad to try it out for you ...

the processor has a 1756-M12/A - but I doubt that matters ...

my RSlogix5000 software is version 15.02.00 ...

 

[Ron Beaufort]

not sure if it helps - but I just ran through the sequence Ken mentioned in Post #40 ...

337084
337085
337068
337087
337088
337089

the count worked perfectly correct using the rung shown below ... specifically, 337085 was properly followed by 337086 ... and so on ...

 

[MichaelG]

curly one

Gee this is a pain
Only things that I come up with are to help getting a handle on where the problem is:

Try a trend of the counter.acc does it spike down when we expect?
Store the values of the .ACC into an array to make sure that it is not a PLC visualisation problem

Does anybody know if the CPU is not the CST master if there is an effect (Especially if there is not a CST master in the backplane)?

Do you have any errors in the minor fault log?

Please confirm that this occurs in both the ADD and CTU instructions
If so then this is more likely a CPU processor / firmware add fault
Does it also occur counting down? (don't know where this would lead?)

Possible work around if the HMI does not directly access .TotalStore is to separate into two DINTS (a pain as you are using a UDT), just like using 2 INTs to count over 32767

Re-reading the topic I seem to prefer a comms issue
Can you trial code ADD(TEST_DINT, 1, TEST_DINT) DIV(TEST_DINT,2,TEST_REAL)
IF you have a comms problem then TEST_Real will be Half the Correct value of Test_Dint

Aside: How can you get the CPU to test itself? (getting my self tied up in logic knots)

 

[bernie_carlton]

Does the total count have any other effect in your system. Other than recording these values is the value used to control something else such that an effect is seen in the response of that other affected system? This is to try to help pin down if it is an artifact within the CPU or an artifact of the HMI/communication function.

 

[Peter Nachtwey]

Divide and conquer and data consistency.

I seriously doubt the problem is with the PLC's ability to add or count. To test this start with two counters and have one count down while the other counts up and add the two together. The sum should not change. You don't need an output device to test this you can simply set a bit but more importantly the sum of the count up and count down should not change.

I suspect you are seeing the effects of a non-atomic read or a read without data consistency. These are different terms for the same thing. This happens when the data is being modified as it is being sent to another device like a HMI. The data must be read in one uninterruptible read. Asynchronous PLCs like the ControlLogix are infamous for having data changed from the outside within a scan.

If the HMI gets a 32 bit value by doing two 16 bit reads then what is to stop the HMI from reading the first word then the PLC modified the second word before the HMI can read the second word?

My solution is to COP the data to an area or buffer that is only read by the HMI and not modified by the program or other external devices. The COP shouldn't be interruptible so the data will be copied without the being changed during the copy.

 

[kamenges]

Originally posted by Peter Nachtwey:

My solution is to COP the data ...

You're close. the Logix platform introduced the Synchronous Copy (CPS) to address this situation. A standard copy (COP) can still have the data read while it is changing, although the chances are much reduced.

Keith

 

[Ron Beaufort]

from Peter Nachtwey:

The COP shouldn't be interruptible so the data will be copied without the being changed during the copy.

take a look at the CPS (Synchronous Copy File) instruction ...

edit: obviously Keith types faster than I do ...

 

[bernie_carlton]

If the problem were reading two words (DINT) in mid change the change would be much greater than what is seen. And the numbers stated are not near a word boundary where such effect would be seen.

 

[bradal]

Ok, had a chance to look at this some more this morning. Put some trap logic in place as Ken had suggested. Software version 15.02, CPU 15.5. Please view the video of my test, I think the logic setup shows that the counter does not truly go backwards.

I really like the idea of something like a DLL on the computer effecting how the value is displayed since it appears to happen on RSVIEW as well. Let me know if you think I should try some other tests, should I use the CPS???

View "1 Counter with Trap Latch Setup"

http://207.34.95.213/Tender/Nason%20Municipal%20Services/Wabamun%20PLC%20Counter%20Issues/

 

[gscure]

periodic task

I have been trying to follow this post but it is a lot about the screen shots and video. My question would be this. Are you using a periodic task in your program? This could actually be interrupting your process causing the errors. Just a thought and something I have encountered a few times.

 

[OkiePC]

A periodic task wouldn't interrupt the middle of a math function.

The CPS should only be necessary when the data is being changed (more than one bit) by something else, like an absolute encoder wired to a digital input card.

It has got to be on the PC side, to do with video rendering or something similar.

 

[bradal]

I have been away dealing with some other stuff today but thinking about this issue. If this was a DLL or PC issue why wouldn't a certain value say 337086 that displayed as 337068, always display reversed. I can enter 337080 in the counter ACC and watch it count but it does not reverse the previously reversed 337086 but does reverse 337098 into 337089. Also completed a test where I found the numbers consistently swapped, I stopped the timer and clicked the number, the number switched back. Made a video which I am sure you are getting annoyed with by now. Labelled "Number Switch on Click"

http://207.34.95.213/Tender/Nason Municipal Services/Wabamun PLC Counter Issues/

 

[bernie_carlton]

Do you have the viewing software and/or RSLogix installed on a different computer?