Controllogix ADD or CTU not operating properly

[bernie_carlton]

Finally saw it - 'Logmein' to home, watched in from there. Something is weird. Analysis of the whole program is probably next.

 

[Ken Roach]

Ordinarily I would insist on having the program itself, and that videos and screenshots are nearly useless. But here.... a different story.

Take a step back and consider; what if this is a problem in the way that RSLogix 5000 GUI is updating the text digits inside the graphical display of the *.ACC value of the Counter, rather than an actual change in the .ACC element value ?

I would test this by using a comparison trap.

The accumulated value change might not really be happening, but actually be an artifact of the screen drawing mechanism. What kind of a PC/display are you running this on ?

 

[TConnolly]

Watching the counter increment to right around 340700 the accum value goes back down to about 340200. Very consistent.

I would look for something else writing to the accum value.

Mickey, Are you sure your player isn't in repeat mode?


Bradal,
If that is representative of the actual code and the counter increments from SYSTEM_100_MS_TIMER but won't increment from Local:3:I.Data.5 then I would check Local:3:I.Data.5. The PLC is not going to be selective and choose to ignore one and not the other. Either the input is not working or some instruction somewhere is clearing Local:3:I.Data.5 - either way the problem has to lie there. Don't forget that that CLX IO is asynchronous to the PLC scan.

The video shows the value incrementing almost 700 counts in 68 seconds, which is pretty consistent with a .1 second pulse, so even though the screen update rate is obviously showing only some of the pulses the count is consistent with the elapsed time. There don't appear to be any execution issues.

We really need to see more - if you can zip the .ACD file and attach it to a post that would be very helpful.

 

[bradal]

Alright guys, hopefully you can get onto our FTP site. Here is the link, read the readme, look at the videos, go through the logic.

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

Thanks!!!

 

[Mickey]

Mickey, Are you sure your player isn't in repeat mode?


.

Woops!!! your right. But there are moments when the hundreds place
will appear to go to a "2" then back to counting.

 

[bradal]

Mickey, Are you sure your player isn't in repeat mode?


Bradal,
If that is representative of the actual code and the counter increments from SYSTEM_100_MS_TIMER but won't increment from Local:3:I.Data.5 then I would check Local:3:I.Data.5. The PLC is not going to be selective and choose to ignore one and not the other. Either the input is not working or some instruction somewhere is clearing Local:3:I.Data.5 - either way the problem has to lie there. Don't forget that that CLX IO is asynchronous to the PLC scan.

This is not the case, it increments from the hard input, the 100ms timer is just to speed up the process of waiting so it isn't an 8 hour video.

Also the value does actually change, according the RSVIEW32, we see the value decrement by some random number every week or every 3 days...then pop back. The operator keeps detailed information on the flow total value from each meter, and it definitely does decrement randomly. I am now logging these values in the HMI, originally just to see if there is a pattern, but now just for information in the future if needed.

Thanks

 

[bradal]

Be sure to watch the second video on the FTP, I slowed this one down and just used CTRL+T, very noticeable jump in the value.

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

 

[TConnolly]

This is not the case, it increments from the hard input, the 100ms timer is just to speed up the process of waiting so it isn't an 8 hour video.

Also the value does actually change, according the RSVIEW32, we see the value decrement by some random number every week or every 3 days...then pop back. The operator keeps detailed information on the flow total value from each meter, and it definitely does decrement randomly. I am now logging these values in the HMI, originally just to see if there is a pattern, but now just for information in the future if needed.

Thanks

Ah, got it. I misunderstood you, I thought that it was not counting at all without the 100mS pulse.

 

[TConnolly]

I noticed something strange happening on the second video.

Between 10 and 13 seconds it appears that test bit does not change value - however the counter counts from 338373 to 338377. Something else is writing to test_bit, the counter ACC, or the counter .CU bit, or a CTU instruction uses the same counter tag on a false rung somewhere else in the project.

 

[bernie_carlton]

There also appear to be times when the test bit is on continously but the count increments more than once.

 

[bradal]

Sorry guys that is the best I can do, you will have to trust me that it does accumulate when I toggle the input, I am doing this over a remote connection via PCanywhere. There is nothing writing to TEST_BIT anywhere, 100% guaranteed unless the PLC is somehow doing internally, and same for counter. There is just a bit of a lag in the video, if you like a I can do another video but much slower showing each toggle. Let me know!

Thanks!

 

[bernie_carlton]

Ahh, thus the apparent count contradictions.

 

[bradal]

I have updated the FTP site with a new video, this is a slower toggle so you can see each one.

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

The Counter movie #3 will show up once our FTP site has synched.

thanks!!

 

[kamenges]

If I were a betting man, which I generally am not, I would say someone is performing an indirect access past the end of an array or UDT. The counter just happens to be the next thing in line.

Keith

 

[Ken Roach]

I am doing this over a remote connection via PCanywhere.

Okay, stop.

The video compression mechanisms used by PCAnywhere or LogMeIn or Windows RDP could themselves explain the mis-drawing of digits in the accumulated value tag display. That's enough for me to stop looking at videos.

But you say that you've got graphs, and logs, and charts of something that appears similar going on with the accumulated value in real life. That's the problem you are trying to solve.

I strongly recommend using ladder logic to trap changes in the accumulated value of the totalizer, rather than trying to use a graph or data log in RSView32. The controller is going to be a lot faster and not subject to aliasing or distortion effects in a trend.

What is the exact tag that is being displayed in RSView32 ? Is it "FIT_017.TOTALSTORE" (a DINT) or "FIT_017.TOTAL", a REAL ? We should measure as close to the display that is showing the anomaly as possible.

Because of the vintage of this controller, I would also recommend carefully checking the system for the "Atmel64" backplane bridge chip issue. It is very unlikely, but possible, for an incorrect value to be read through a ControlLogix buffer if a backplane bridge chip is failing.