Logix 5000 ONS Across Multiple Programs

[joseph_e2]

Schrodinger's code is the worst...
Can you share the ACD files of the working and non-working PLCs? I assume you've used the Logix compare tool on them, right?

 

[drbitboy]

Are the ApplyDST and CSTOffset attributes of the GSV WALLCLOCKTIME entries the same on both PLCs?

 

[AMarks95]

Are the ApplyDST and CSTOffset attributes of the GSV WALLCLOCKTIME entries the same on both PLCs?

In fact, they are not. It is enabled on the one that is working. Not enabled on the one that is not working. Their times are synced daily at 4am from a windows PC that will adjust for DST. Should it be enabled? I'm not sure what that option actually does. I will update that, but I wouldn't expect that to make a difference unless it's the day the clocks change.

 

[L33er]

Too much to read 5 darn long pages.
it must be something really smart.

 

[AMarks95]

Too much to read 5 darn long pages.
it must be something really smart.

Really, it's not. It's doing something so simple that there's no reason why it shouldn't be working. Hence, all the confusion.

 

[drbitboy]

In fact, they are not. It is enabled on the one that is working. Not enabled on the one that is not working. Their times are synced daily at 4am from a windows PC that will adjust for DST. Should it be enabled? I'm not sure what that option actually does. I will update that, but I wouldn't expect that to make a difference unless it's the day the clocks change.

If they have the same local time (even if one is using the CST (GMT or UTC) as the local time), then I agree it should not make a difference, because your code is using LocalDateTime to calculate the PLC_Time_DINT value.

But stranger things have happened, and since they are set differently on the two PLCs, that is a suspect for why (presumed) identical code gives different results on the two PLCs.

 

[AMarks95]

If they have the same local time (even if one is using the CST (GMT or UTC) as the local time), then I agree it should not make a difference, because your code is using LocalDateTime to calculate the PLC_Time_DINT value.

But stranger things have happened, and since they are set differently on the two PLCs, that is a suspect for why (presumed) identical code gives different results on the two PLCs.

Finally found the culprit. It was not an issue with the PLC code at all.

1. This is a distributed Ignition system running a central gateway and 5 edge gateways. (call it central and areas 1-5)

2. Each edge gateway runs the exact same program as the central, just limited to the screens in that operation area and only connected to that area's PLC. (call them PLC 1-5 for areas 1-5, respectively)

3. There is a script on the central gateway that runs at 4am to set all of the PLC times based on the computer time.


a. This script execution needed to be restricted to the central gateway, but was not.

b. Area 3's PC time was set wrong.

The combination of (a) and (b) above caused the area 3 PLC time to be reset to 4am at 4am from the central gateway, and again at ~3pm from the area 3 gateway. That's why this comparison never executed.

I've now limited that clock reset execution to only happen from the central gateway. (and updated the area PC time, of course)

 

[robertmee]

Finally found the culprit. It was not an issue with the PLC code at all.

1. This is a distributed Ignition system running a central gateway and 5 edge gateways. (call it central and areas 1-5)

2. Each edge gateway runs the exact same program as the central, just limited to the screens in that operation area and only connected to that area's PLC. (call them PLC 1-5 for areas 1-5, respectively)

3. There is a script on the central gateway that runs at 4am to set all of the PLC times based on the computer time.


a. This script execution needed to be restricted to the central gateway, but was not.

b. Area 3's PC time was set wrong.

The combination of (a) and (b) above caused the area 3 PLC time to be reset to 4am at 4am from the central gateway, and again at ~3pm from the area 3 gateway. That's why this comparison never executed.

I've now limited that clock reset execution to only happen from the central gateway. (and updated the area PC time, of course)

Poor old ONS got drug though the mud for 5 pages...you owe him an apology

 

[drbitboy]

Finally found the culprit. It was not an issue with the PLC code at all ...

Welcome to the I-once-was-convinced-the-PLC-was-not-doing-what-I-told-it-to-do club; we're having jackets made up.

​

Hopefully you will also join the ...but-never-again club.

I'm not always right, but for a dumb ************ it does surprisingly often work out that way:

The PLC program cares not a whit what you want or expect it to do, but it will mercilessly and inexorably do exactly what you tell it to do.

Stated another way:

The only thing worse than the PLC not doing what you wanted it to do is when it does exactly what you told it to do.