Controllogix Cpt instruction result wrong.

ghriver

Member
ghriver
Join Date
Aug 2002
Location
Earth>North America>US>CA>Hanford
Posts
65
i have a wierd issue. about 4-10 times per day the result of a cpt instruction is incorrect. the result is always off by 60. see attached. any ideas? In addition its only off for a few seconds then its correct again.

screenshot.jpg
 
Last edited:
recording data

i am recording the data now. the current hour and minute from the processor. the GSV instruction gets WALLCLOCKTIME and returns them to the array called currenttime. Now that I am recording with a historian the hour, minute and the calculation result i saw that the hour being returned from the processor is fluctuating. Which is why the result flucuates. Guess im going to have to call AB.

screenshot2.jpg screenshot3.jpg
 
Last edited:
Now that's a head-scratcher. The WallClockTime certainly should correctly indicate the Hour.

On your screenshots those events looked like they were 10 minutes apart, but you mentioned this happening "4-10 times per day". That might just be an artifact of the sampling rate of your SCADA system, missing a short-duration event.

Are you running the GSV every scan of the Continuous Task ?

Is there an instance of the RA Controller Clock Sync Tool running somewhere on your network ?

Is there any logic that uses an SSV to write to the WallClockTime ?

What firmware revision is your ControlLogix ?
 
Correct, it is the sampling rate on the chart. the GSV is running every scan and the RA Sync tool is installed on a server but has been offline since its first test. There was an SSV instruction in the past but the logic still exists but has been AFI'd out. Version 16.3 of the firmware. I called rockwell and version 16.3 after running for some time w/o being power cycled will wipe the processors memory. I cant blame that on the electriaicans any more, ooops.

What rockwell wants me to do now is put in another gsv instruction and create a new destination to isolate that the destination isnt been stomped on from across the network.
 
I think Tech Support may be right, something else is zapping the data.

Here's a test program I am running now...
1756-L62 flashed to Rev.16

The code is in a Periodic Task - Period = 50mS

Rung 0 gets the WallClock data, and computes the minutes of the day, exactly as you described

Rung 1 increments a check-count, and bumps the wall-clock near to minute rollover (59.999990 Seconds)

Rung 2 handles re-synchronisation on a new day

Rung 3 checks the computed minutes against the pseudo minutes

The code has run for a simulated year now, and the fail flag is not set
 
Can you do an additional GSV and this time get the wallclocktime "currentvalue"
What you are looking for is this value as a LINT going backwards for a couple of scans

I had this issue with CST once and was wondering if it was happening here

It is also another way of proving where the code fault exists - your code or inside firmware

LINT Code See http://samplecode.rockwellautomation.com
then Search LINT
you are after the LINT Math Library
 
Hey, hey, let's not toss around scurrilous accusations about my favorite controller. Only some CPUs with specific firmware revisions are affected by the issue you mentioned.

Versions 16.03, 16.04, and 16.20 firmware in 1756-L55 and 1794-L34 controllers suffers from the incorrect background checksum fault. This is similar to the issue in versions 15.03 and 15.04 (and 15.05 for the 1794-L34).

This does not affect the 1756-L6 controllers or 1769-L3x controllers and it's fixed in the 1756-L55 in version 16.21 and 15.05 (15.06 for the 1794-L34).

RA Knowledgebase article 45709 and 34430 contain details from the gloomy days of 2007, when controllers were faulting and a pall hung dark over the land, as paladins of Technical Support roamed astride their minivans, armed only with CompactFlash and a will of steel.
 
Ken Roach said:
Hey, hey, let's not toss around scurrilous accusations about my favorite controller. Only some CPUs with specific firmware revisions are affected by the issue you mentioned.

Versions 16.03, 16.04, and 16.20 firmware in 1756-L55 and 1794-L34 controllers suffers from the incorrect background checksum fault. This is similar to the issue in versions 15.03 and 15.04 (and 15.05 for the 1794-L34).

This does not affect the 1756-L6 controllers or 1769-L3x controllers and it's fixed in the 1756-L55 in version 16.21 and 15.05 (15.06 for the 1794-L34).

RA Knowledgebase article 45709 and 34430 contain details from the gloomy days of 2007, when controllers were faulting and a pall hung dark over the land, as paladins of Technical Support roamed astride their minivans, armed only with CompactFlash and a will of steel.
Click to expand...

Wit, and Wisdom ! :geek:
 
I sure looks an asynchronous update problem

daba said:
I think Tech Support may be right, something else is zapping the data.
Click to expand...
I don't think so. Not when the minutes is off by 60 minutes each time. It is almost like the hours and minutes are not being updated at the same time or they are being update at the same time while the compute block is calculating.

The GSV should be done synchronously with the CPT block OR the hours and minutes should be copied to another area that the GSV doesn't update prior to executing the CPT instruction. Hopefully Rockwell made the COP instruction uninterruptible. BTW, can interrupts be turned off and on during critical times?
 
Actually, the COP instruction can be interrupted !

That's why there was a Copy Synchronous (CPS) instruction added, which locks the source and destination (and therefore takes longer).

As far as I know, the GSV is synchronous, so all the data is definitely in the destination array before the next instruction is executed. This doesn't prevent an HMI from grabbing that array during the GSV execution, but it prevents the subsequent logic from calculating incorrectly.

The OP doesn't show the sequence of his rungs, even though the screenshot suggests that they are sequential.

I'm curious about what anomaly MichaelG is describing. Nothing in the LINT sample code library describes a CST anomaly.
 
Last edited:
How did COP and CPS get into the discussion ?

The o.p. simply stated that his computed minutes are 60 "off" several times a day....

Ken is correct, a GSV will complete before the next instruction is executed, so there can be no issues relating to "split data"

My test code is still running, still no failures. So unless it is a hardware/firmware failure in the modules the o.p. is using, then the only conclusion is that something else is writing to the data area he is using.

I'm wondering now if he is also consuming the wall-clock data from another controller ????
 
It sounds like hour changed the value while minutes are stil at 59, but in this case it will happen all the time at the top of the hour. with mintes ans seconds =59. Did you look at this?

If this is not a fact then it also possible that there is something with internal CPT callculations and rounding up
I would try to use MUL and ADD separately saving calculation results in some storage for future review.
Can you post your program?
Did you try to strip the program down to these instructions only?
 
another straw at which to grasp ...

this is probably a wild goose chase – but I was curious about the OP's use of the GSV attribute for "LocalDateTime" – rather than the simpler "DateTime" attribute ...

just for kicks, I wrote a bare-bones program for one of my L55 processors (Version 16.20) and compared the "Max Scan Times" reading for the following GSV configurations ...

(1) using the OP's "LocalDateTime" attribute, the highest Elapsed Time reading that I got was 3.908000 ms (as shown below) ...

(2) using the simpler "DateTime" attribute, the highest Elapsed Time reading that I got was 1.609000 ms (less than half as much time) ...

the single rung shown below is the only one in the entire project – and it's set to execute on every scan of the Continuous Task ...

like I said, this is probably just a wild goose chase – but I'm forced to wonder if the operation of the OP's system would be any different if he switched the setting of his GSV to use the "DateTime" attribute ...

the difference in the scan time readings indicate that there's clearly some amount of "extra stuff" going on behind the scenes whenever the LocalDateTime attribute is being used ... maybe (just "maybe") the intermittent glitch is coming up during the GSV's internal calculations which are required by that "extra stuff" ...

(the documentation for the GSV mentions that the LocalDateTime is calculated based on the TimeZoneString, etc. for those who want to read up on it) ...

feel free to ignore this post ... party on ...

.

LocalDateTime.PNG
 

Similar Topics

T
ControlLogix Redundancy Module Single Mode Fiber
Why does the controllogix redundancy modules use a single mode fiber vs multimode fiber?
Replies
1
Views
58
Ken Moore
Ken Moore
B
ControlLogix IB16IF and OB16IEF
Hello, I have two 16 point input cards and 1 16 point output card showing module faulted on my IO tree in Logix Designer. The fault code is...
Replies
7
Views
207
Contr_Conn
Contr_Conn
S
ControlLogix Redundancy with EN2TR
Hello, My associate and I are trying to sync up two ControlLogix racks (7-slot chassis) with identical modules. We are able to see the secondary...
Replies
4
Views
184
Contr_Conn
Contr_Conn
J
ControlLogix L71 Reading from 5/80E ver D.1
Trying to setup a message read via Ethernet. I have the path setup as 1, 1, 2, 192.168.66.10 I get an error code 1, ext err 315. I am beating...
Replies
9
Views
225
just_lionel
J
A
SLC messaging with a ControlLogix redundant system
I have a redundant ControlLogix being set up. This program reads a value from a remote site which happens to be SLC PLC. Rockwell mentions SLC...
Replies
2
Views
91
robertmee
R
Back
Top Bottom