SLC 5/03 Date and Time

[AlignPLC]

Hello everyone
I have a couple questions here about our AB SLC 5/03 for our waste treatment system. The date and time on our HMI is off and I've tried changing it through the PV several times but it eventually just resets to the incorrect and outdated date and time. Is this something the SLC itself needs to override to get it to stick?
And question two also concerning this plc, I've been tasked with trying to get the waste treatment system to start automatically say at 4am and turn off at 4pm everyday so that it will be ready when our operators show up for their shift without having to wait for the startup process. Is this possible through the SLC 5/03? Looking for some veteran experience here

 

[PLCDontUQuitOnMe]

You want to synchronize it with an NTP server. Newer systems will allow you to configure an NTP server in the PLC itself, and just point to the IP address of the server.


I don't think a 5/03 has this ability so the other option is install some kind of ethernet device like an E W O N or maybe an Adam module or something that can be configured as an NTP server with a digital output. Configure this device to turn on an output once a day at a specific time. Don't forget to configure this device as an NTP server and actually point it to the proper NTP clock on your network so that it is getting its time properly updated.


In the PLC, look at that input, and use it to move a time value (matching the time you set up the external device to trigger) into the proper memory area in the processor status file (S:40-42)


Doing this once a day should be sufficient I would think.


In terms of the HMI, is it drifting or just changing time completely at one point? If it's drifting is it drifting along with the PLC? What type of HMI? Most of them will have an area you can set up for time sync with the PLC.

 

[Ken Roach]

Welcome to the PLCTalk forum community !

This is a surprisingly difficult and complex topic and it's going to take some work to figure out on your part.

The SLC-5/03 has an onboard Real Time Clock. It has no ability to directly access an NTP Server, though.

Your PanelView also has an onboard Real Time Clock. But neither the PanelView Standard nor the PanelView Plus can directly access an NTP server.

So mis-set and mis-matched times and drifting clocks are a fact of life for systems like this.

The PV+ can update its own onboard RTC by reading tags from a PLC/SLC/Logix controller, as part of the Global Connections feature.

If I have the option, I usually make the PLC the "authoritative" source of time information, and let the PanelView follow it.

I have also seen systems that (inadvertently) create a creep/rounding feature by reading the time from the PLC, adjusting the time on the PanelView, then writing the time to the PLC.

Examine closely how you are changing the time setting in the PanelView, and post about that. My *guess* is that you are setting the PanelView's clock directly and it is then automatically applying the values it reads from the SLC-5/03 and writing over those changes.

If you have the PanelView's application project file, that should show you how/if the PanelView is getting its time from the SLC-5/03.

 

[Puddle]

I have an SLC 5/03 too! I'm currently in the process of replacing it for an S7-1500 after having a few problems with it.


If the onboard clock isn't reliable, you can get standalone time-of-day relays like this:
https://uk.rs-online.com/web/p/products/8966891/


I've fitted a similar one that kills power to a heat plate over the weekend when production stops.

 

[I_Automation]

What I did for a customer that wanted a SLC to be very close to the real time was get a digital appliance timer that had 20 ON's programmable per day.


I had it turn ON starting at 6:30AM, [OFF at 6:31] then every hour until 11:30PM, over the night it turned on every 2 hours.


Since the timer wasn't EXACTLY coming on at xx:30:00 I had the HMI settings page where he minute and second could be changed to exactly when the timer came on. After 59 minutes the SLC clock could be off a few seconds.


Also, I did not set this to come on at xx:00:00 because if the seconds needed adjusted up the minute and hour [and maybe day, month and year] would then have to be adjusted up 1 also. Sticking to xx:30:00 was a lot simpler



When it came ON on a OSR I did 5 MOV's:
Current Hour to Last Hour Came On

Current Minute to Last Minute It Came On
Current Second to Last Second It Came On
Setpoint Minute to Current Minute
Setpoint Second to Current Second

 

[Ken Roach]

In my opinion and experience, the time drift of an SLC-5/0x controller's Real Time Clock is... "not great, not terrible". It's on the order of 1 minute per month. Many purpose-built timing devices that have designs newer than the early-90's SLC-5/03 can do better, even inexpensive ones.

I wish that A-B controllers with Ethernet on them easily connected to NTP servers, especially systems that don't rely on the precision clock for motion or safety. But they don't.

Middleware and SCADA/enterprise software can be used, of course. I downloaded a Node-Red NTP client last night to fiddle with in a Raspberry Pi that also has the DF1 serial driver.

If this controller is connected to a supervisory network then there is a straightforward utility that will periodically correct the controller's clock: the Logix 5000 Clock Update Tool. It's a mature and no-new-support-being-added utility now but it will work fine on Windows 7 and 10 systems, and supports SLC controllers over any network connection.

PLCTalk Hack Challenge: Get an accurate time into an SLC-5/03 via a connected PanelView Plus and a $10 USB GPS dongle. GO !

 

[I_Automation]

In my opinion and experience, the time drift of an SLC-5/0x controller's Real Time Clock is... "not great, not terrible". It's on the order of 1 minute per month.

I found out the hard way that every time in a scan the program checks the Second the PLC skips counting the clock a little.


I had one SLC that was losing almost 5 minutes a day.



When I changed all the Seconds reads to read a N7 integer and only had 1 read of the Seconds at the beginning of every scan, writing to that integer, the clock got much more accurate.

 

[Ken Roach]

I didn't expect to learn something new about the SLC-500 operating system and architecture today... but there it is !

Thanks for that bit of info about access to the S:2 registers and how it might influence the data source or even the program scan.

I knew that "Module Files" M0/M1 references took a little bit of time to access the module over a backplane, like the 1747-SN or 1747-BAS.

So it makes sense that part of the S2 status file might also take time and resources to access a subsystem like a real-time clock too.

 

[Dayvieboy]

I wish that A-B controllers with Ethernet on them easily connected to NTP servers, especially systems that don't rely on the precision clock for motion or safety. But they don't.

You are talking about the old SLC 500 days pre Studio5000 ??

 

[Ken Roach]

We're drifting off topic, like a PLC clock

The old PLC/SLC/MicroLogix operating systems don't have an NTP client, even the ones that have Ethernet ports.

The modern ControlLogix/CompactLogix operating systems also don't have an NTP client, even the ones that have Ethernet ports.

It is my understanding that a ControlLogix/CompactLogix would have trouble using an NTP client to adjust their Wallclock objects, because of the connection between the ordinary microsecond UNIX epoch controller clock and the IEEE 1588 precision time clocks that support CIP Safety and CIP Motion.

I'm not 100% sure if changing the time and date on a ControlLogix will interfere with its precision-time-clock-dependent features like safety and motion. The RA Knowledgebase (document QA32247) says that clock skew errors "may" result when the Wall Clock object is adjusted manually, with an SSV, or via one of the external time clock utilities.

OP's system has an SLC-5/03, which of course has only a DH485 proprietary local network port and an RS-232 multipurpose port. And they probably have a PanelView Plus, which runs Windows CE and has an Ethernet port, but may not also be connected to an enterprise Ethernet LAN.

Because they are looking for a simple twice-a-day time event, the simplest thing to do would be to buy a clock relay with a dry contact output that closes at a specific time of day. The SLC can use that to either directly run their scheduled tasks, or to adjust its own real-time clock once a day so that even the worst clock drift conditions will result in a very small inaccuracy.

 

[Ken Roach]

A recent post has made me aware that there's an AOI available from RA that uses the "open sockets" method to implement an NTP Client on a modern ControlLogix Ethernet module (like the 1756-EN2T) or 5370/5380 generation CompactLogix.

I really don't like relying on that sort of extension to a controller's function set; it's often costly on memory or scantime and aren't as well-tested as integral functions.

And it won't apply to OP for this SLC-5/03 based system.

But it means I was out of date and incomplete on my "that doesn't exist" statement.

 

[drbitboy]

https://seriot.ch/projects/tiny_ntp_client.html

 

[drbitboy]

A Simple NTP UDP client (in Python):

1. Create the socket
2. Send the request: 48 bytes; only the first byte matters
3. Receive the response
4. Extract the four bytes of seconds since the epoch (1900) from the response

The rest is window dressing.

Assuming SLC/5s have some implementation of basic UDP/IP sockets, conversion to SLC would not be a huge effort; would an implementation on MicroLogix 1100 be close enough?

I assume SLC has Longs (DINTs) but not UDINTs. Or maybe it only has INTs? No matter, that would just add to the bit twiddling.

​

 

[Ken Roach]

I didn't realize how simple an NTP request can really be !

The only member of the SLC or MicroLogix family that has an open sockets feature is the MicroLogix 1400 Series B.

The SLC-5/03 described in the original post has no Ethernet interface or TCP/IP stack. Nor, of course, can it execute Python or bash.

We still haven't heard back from AlignPLC if their system has an enterprise network or an Internet connection, a stable mobile phone network signal, is within range of the low frequency atomic clock transmitters or has a view of the sky. The possibilities for helping that system keep time are numerous.

 

[drbitboy]

Yes, there needs to be an intermediate time source, i.e. proxy between the SLC and some reasonable source of time, the latter being tied to an NTP server somehow.

The suggestion in Post #4 about a Standalone Time of Day relay seems simplest, but I would prefer one that talks to NTP, if drift is an issue.

The need to reset clock drift seems custom-made to a RaspberryPI or other inexpensive equivalent SBC: built-in NTP; some kind of server* or relay output to trigger the SLC.

* Running a single-purpose Modbus RTU or Modbus TCP server to provide six holding registers (year, month, day, hour, minute, second - or for that matter only hour, minute, second) to be read by Function code 0x03 would be all but trivial. Even an Ethernet/IP or CIP server if that client is easier to set up on the SLC.

Can an SLC programmatically even write to S:37 through S:42 to update the RTC?

Thinking a bit outside the box, OP is in the USA, so power is a 60Hz time source accurate to several decimal places; counting 3600 pulses externally to trigger a top-of-minute input would not be difficult, but then there would have to be a way to handle power outages, so an external source of time would be required, so why bother with the counter?

The SLC instruction set manual mentions broadcast write messages being used to synchronize device clocks or actions see bottom of page [DF1/DH-485 broadcast support] at this link.

And this link from the MicroLogix 1100 Instruction Set manual has a quickstart example to have the SLC update a MicroLogix 1100 RTC over DH-485 or DF1; I don't know if it can be run in the other direction, and we don't even know what communication channels are available in OP's case.

Also, I am not sure if anyone answered OP's question two yet:

And question two also concerning this plc, I've been tasked with trying to get the waste treatment system to start automatically say at 4am and turn off at 4pm everyday so that it will be ready when our operators show up for their shift without having to wait for the startup process. Is this possible through the SLC 5/03?

The table at this link list Status file word S:40 as hour-of-day, so summat like this:

                             <bit>   trigger4am
------[LIM           ]-------[ONS]-------( )-----
      [Low Lim      4]
      [Test      S:40]
      [High Lim     7]


     trigger4am    inhibit_or_stop_warmup   startwarmup
--+-----] [------+--------] [------------------( }----
  |              |
  | startwarmup  |
  +-----] [------+

albeit clumsy, would attempt. once, to perform a warmup on the first time the SLC detects the time is between 4am and 8am**. What happens when that startwarmup bit becomes 1, especially regarding safety, is beyond the scope of this forum. Those are symbolic names, but of course on the SLC they would be data file addresses. I used the one-shot and a start/stop pattern so that if the warmup failed for some reason (via the inhibit_or_stop_warmup bit), it would not attempt another unattended warmup.

** the LIM is used in case power is out from 4am until after 5am; if that is not a concern, then [EQU s:40 4] would work instead.