PLC5 clock changing

[frw312]

looking bac through posts, you must be referring to the global bit in the other plc. It is an input tht is forced off. that input is mapped to an internal bit that cannot fire and the logic never get solved.

 

[TConnolly]

Bernie,

You are right my discription wasn't clear. At 8 am this morning it was 20 making the logic think it was 8 pm. normally at midnight the lights turn off, they have been going off at noon. thats what got our attention. As long as i reset it we're good till tommorrow. I am going to build some logic to see what time the hour data gets corrupted. frw

Its just too co-incidental that its off by precisely 1/2 day and that the 0 hour is nicely aligned with noon. That makes it very unlikely that its a random malfunction. If its being reset over a network there may not even be any logic in the PLC/5 - somewhere else on the network is another device that is off by 12 hours.

 

[frw312]

Its just too co-incidental that its off by precisely 1/2 day and that the 0 hour is nicely aligned with noon. That makes it very unlikely that its a random malfunction. If its being reset over a network there may not even be any logic in the PLC/5 - somewhere else on the network is another device that is off by 12 hours.

I agree it just too co-incidental. I did the test described above to track the hour changes. Today is was right anfter 3 days of changing by the 12 hours. I will track over the weekend. I am going through anything else on the network. The thing that narrows it down is that what ever would affect the hour word would have to be addressed to S:21 and there isn't that many app that have the capacity to write that data on this network.

Thanks to ALL for the input it has helped. frw

 

[frw312]

Update: after hour changing by 12 hours three days in a row it didn’t change over Thursday night and everything correct Friday morning. However Friday afternoon at 1600, 0 min. S:21 = 16, then at min 1 of S:22, S:21 went to 4. Sat Okay, sun Okay, Mon Okay, just off by 12 hours. Reset to current time and okay this morning (Tue). Still tracking in FFL.

I have checked all HMIs on the network and all PLCs for MSG, BTW, and global bit instructions. We are wondering if there could be a hardware malfunction. Any other suggestions are welcome. Thanks for previous and future input. frw

 

[kamenges]

Originally posted by frw312:

The fact minutes are correct and only hours changes points to something changing the hour word

I don't know that you have enough information to say that the minute value isn't being changed. It may also be that the minute value is being changed correctly. So you wouldn't see any movement in that value, or at least not much. Since more information is always beter than less information I suggest you set the minutes value to 10 minutes or so fast (assuming that doesn't break your program somehow) and see if it is correct when the hours go hinky.

BTW, what network is this PLC5 on?

Keith

 

[OkiePC]

It is possible that a PC which can access the network is running the "clock update utility" from rockwell or a similar bit of code that is causing the problem. This would not show up when looking for normal tag addresses within an HMI.

 

[frw312]

the minute data is sved to a ffl table at the same time as the hour data so I believe it is correect as it still matches the pc clock minutes. the netywork is DH+ and ethernet.

To the best of my knowledge they are not running the clock utility program.

 

[TConnolly]

In the mean time you could trap the change in code and auto correct it, any change in S:21 that is not equal to +1, except the change from 23 to 0, will automatically reset the time to the previously stored value. If someone then comes forward complaining that they can't correct the time then you will have identified who needs to be taught about 24 hour clocks.

 

[Ken Roach]

I'm not an expert with PLC-5 Data File Priveleges, but I think you should be able to write-protect the Status file so it cannot be modified over the communication channels.

You could write-protect Data File 2 first from the DH+ channel, then from the Ethernet channel, to narrow it down which one of them is the vector this is coming in from.

It's a lot easier to capture Ethernet traffic than DH+ traffic, but this might be one of those instances where you want to.

 

[kamenges]

Originally posted by frw312:

...I believe it is correect as it still matches the pc clock minutes.

You would expect the minutes to always be right since the clock is shifting exactly 12 hours and it is being updated about every 4 days. The PLC5 clock won't drift far enough in that time to notice an error in the minutes. You wouldn't notice an error in the hours either if you didn't change the hours to be correct. The only way to notice if a change happens is to intentionally induce an error.

However, Ken Roach has a very good idea. If you restrict access to the S file on each channel alternately you should be able to tell which channel the change is coming in on within about a week. You may have to make that change offline, though.

Also, since you have an Ethernet connection any PC with an OPC server with AB drivers can mess with your plc. You could do it from Excel if you wanted to.

Keith