Need help on setting Time Clock on RS Logix 5000, 1756-L61 CPU using V16 software

Dear Kind advisors,

I need help on the title mentioned subject. The logic i wrote as attached is working and will update the CPU time clock after receiving a pulse at 2000hrs from the DCS to update the clock time to 2000hrs.

However, after some time say about 30 mins or 40 mins, it seems that the time will be drifted by 1 or 2mins which i don't understand why?

Could it be due to the cycle time?

Please can kind souls help to advise. Urgently needed. Thanks!

From what I can see of your logic, you are only reading the PLC clock (with a GSV instruction).

How are you setting the PLC clock from the DCS 20:00 hrs pulse ?

Welcome to the Forum! It sounds like you're working in the offshore energy business, so there's both excitement and hazard there.

There are multiple problems with this logic.

You don't have to perform a GSV every scan if you aren't using the result of the GSV every scan. The GSV takes up some controller resources, so don't execute it if you don't have to.

The multiple MOV instructions that move the Sync_Clock_Time to the Write_PLC_Clock array don't move the last element, which is the number of Microseconds. To completely move this array, use a COP instruction.

The Set_PLC_Clock timer repeatedly executes the SSV instruction for 100 milliseconds. Because the source value for that time has just been read from the clock but the Microseconds value is omitted, the effect is that the controller keeps getting reset to zero microseconds for 100 ms.

That will cause you to lose 100 milliseconds of time in the clock every time the Port or Starboard Sync bit becomes true.

It is not necessary to repeatedly execute the SSV instruction for 100 ms, or to "hold it on" so the controller accepts it.

The timer used to extend the time of the trigger bit for Set_HMI_Time_Pulse for two seconds is necessary because the HMI only reads that bit every second at the most (if it's FactoryTalk View).

I don't know how the 100 millisecond time loss translates into 1 or 2 minutes of "lost time" every 30 to 40 minutes. You need to figure out how often those Port and Starboard sync pulses come.

If you actually want to set the time to a specific value (like 20:00), your logic will need to be different. I may have time later to write an example.

Actually, it looks like the program does reset the time to 20:00 (current Year, Month, Date) when Time_Sync_From_Port and Time_Sync_From_Stbd are true. If you look closely the source for MOV command changes from Current_PLC_Clock to Sync_Clock_Time which I assume be a constant set for 20:00.

He isn't writing microseconds but that would account for only one second of drift. The clock should only drift about four minutes a day worse case.

The questions I have are:
What is your reference clock?
Is it two minutes fast or two minutes slow compared to the reference?
Does the time slowly drift over the thirty minutes after reset or does it jump?
Are Time_Sync_From_Port and Stbd synced to each other?

Nice catch, Timbert.

That makes more sense: he's capturing the current Year, Month, and Day but using a static value for the Hour, Minute, and Second.

The SSV should still only execute once, off the Set_PLC_Clock_Pulse tag.

I can't explain the large drift value unless the Sync pulses are coming much more frequently than once a day.

Dear all, thanks for the response. It since that the problem here somehow is the CPU time clock will fall back to its original time somehow which i dont understand why. For example if i execute the pulse at actual 14:00hrs for testing, it go to 20:00hrs but after sometime the clock time falls back to 14:xx time, which i dont understand why? Any light on this? Thanks.

I can think of two things that could reset the clock. If you have a PC running the Logix 5000 clock update tool. It can be configured to periodically set the PLC time from the PC time. Check to see if this is running on your PC. I think it could have been configured to autorun as a service.

Another possibility is a second PLC (or there are a few other devices) on the network is configured as CIP Sync (IEEE 1588) time master and this PLC is a slave. Look in controller properties, if the PLC has time synchronization enabled, and if the PLC is indeed master.

I actually prefer to use the DateTime attribute for both reading and writing, instead of the LocalDateTime attribute.

There was actually a bug in v16 firmware that could fault the controller if you wrote to LocalDateTime with an SSV.

Try writing the correct "Zulu Time" to the DateTime instead of the LocalDateTime.

Timbert said:

I can think of two things that could reset the clock. If you have a PC running the Logix 5000 clock update tool. It can be configured to periodically set the PLC time from the PC time. Check to see if this is running on your PC. I think it could have been configured to autorun as a service.

Another possibility is a second PLC (or there are a few other devices) on the network is configured as CIP Sync (IEEE 1588) time master and this PLC is a slave. Look in controller properties, if the PLC has time synchronization enabled, and if the PLC is indeed master.

Click to expand...

Hi Timbert, i have checked through your advises thanks. 1. It seems to have a 1hr sync configure, i removed it but still after 40 over minutes it will fall back to its "own" clock.

I have checked through, there isnt a time master set in any of the controllers. It's a non redundancy system with the various PLC.

Any more light? Thanks,

Ken Roach said:

I actually prefer to use the DateTime attribute for both reading and writing, instead of the LocalDateTime attribute.

There was actually a bug in v16 firmware that could fault the controller if you wrote to LocalDateTime with an SSV.

Try writing the correct "Zulu Time" to the DateTime instead of the LocalDateTime.

Click to expand...

Hi Ken, i tried your method with SSV change to DateTime, GSV has to remain at LocalDateTime due to the alarm time following the PLC clock. Still the time clock will fall back.

If using Factorytalk View HMI under global connections you can modify time using tags. The Remote Date and Time tag will update the terminal time when it transitions from zero to a non-zero value. Maybe the HMI program is updating your time also. Might be worth checking. You will need a copy RS Studio to be able to check the application.

FactoryTalk View is writing the FactoryTalk computer system time into the tags you specify.

It is *not* actually writing any value to the CST clock. For that, you need an SSV instruction.

The RSLogix 5000 Clock Tool, by contrast, does directly affect the CST clock.

This sounds more and more like the Clock Tool might be running somewhere.

Ken Roach said:

FactoryTalk View is writing the FactoryTalk computer system time into the tags you specify.

It is *not* actually writing any value to the CST clock. For that, you need an SSV instruction.

The RSLogix 5000 Clock Tool, by contrast, does directly affect the CST clock.

This sounds more and more like the Clock Tool might be running somewhere.

Click to expand...

Hi Ken,

Totally agree with you. There must be a hidden clock somewhere which i need to dig it out. Another way which i don't mind doing is to use the RS View Studio terminal time normally written as system\time, system\hour etc. Can you guys advise me how to write to the RS View Studio terminal time? It is clearly understood that PLC system time is different from the RS View Studio terminal system time.

I am trying to create derived tags or macros to write to RS terminal system time but failed, maybe the syntax i wrote has some problems. Can you guys guide me with a sample on how to do it?

Thank you so much!

see attached:

cwal61 said:

see attached:

Click to expand...

Thanks Cwal. That is already checked. I am asking about methods of writing RS View Works to throw the time value to the RS View Terminal (Computer) time when a pulse is received by the PLC. Thus will be writing to system\hour, system\min. Thanks.