Time/Day Schedule: from RSLogix 5000 or Crimson 3?

Elcan

Lifetime Supporting Member
Join Date
Apr 2008
Location
NC
Posts
935
Hello all,
I'm programming a project using a CompactLogix PLC and a Red Lion touch screen running Crimson 3.
I have to run some specific processes according to the day of the week (Sunday, Monday, etc.) and/or the hour (5:00 am, 7:30 pm, etc.).
I know you can use "wallclocktime" in RSLogix in order to find out the day (but maybe not the day of the week), month, time, etc. I heard that using "wallclocktime" can increment the PLC processor load, not sure how much.
I also know that you can use Crimson 3 to work with time, date, day of the week, etc.

What would you experienced guys recommend to do in this case?
I will appreciate your comments!
 
In the company I work for we have 5 control logix and 20 compact logix, and I use GSV (wallclocktime) in all of them with no problem at all, I haven´t noticed nothing about cpu load due to real time clock.
 
There is a custom instruction you can get from the Rockwell website that will determine day of week.

From my experience using wallclocktime does not add any significant load to the CPU.
 
What I do is increment a counter (with a preset of six) at midnight (based on wallclocktime). Each day of the week has a value, Sunday being zero through Saturday being six. The value in the accumulator of the counter determines DOW (Day-of-Week).

For example, we avoid running certain pump stations during peak demand hours Mon-Fri. So, if the hour is equal to or greater than 1200 and less than 1800, and the day is not zero or six (>0 and <6), don't run the pumps.

You get the idea.

Bill
 
It's very unlikely that using a GSV instruction to retrieve the LocalDateTime will have a negative impact on your processor scan time.

There is not a day of the week value included in the LocalDateTime array, so as MasterBlaster menitioned you might need to create your own code to generate a day of the week value.

The GSV objects are available for a reason, so feel free to use them as needed.
 
Doing a GSV on the WallClockTime does have a impact on the processor scan. Whether that impact is negative on not depends on your definition slowing down the scan.

But you already have a Red Lion so why bother with the WallClockTime or the formulas for the day of the week.

GetDate - Returns the day-of-month portion of time.
[HIGHLIGHT]GetDay - Returns the day-of-week portion of time.[/HIGHLIGHT]
GetHour - Returns the hours portion of time.
GetMin - Returns the minutes portion of time.
GetMonth - Returns the month portion of time.
GetSec - Returns the seconds portion of time.
GetWeek - Returns the week-of-year portion of time.
GetWeeks - Returns the number of weeks in time.
GetWeekYear - Returns the week year when using week numbers.
GetYear - Returns the year portion of time.
 
If you have to run specific processes based on the day of week or the hour then chances are you need this information available in the PLC. To me it would make the most sense to generate / retrieve this data in the PLC rather than generate the data in the HMI and transfer it to the PLC or try to automate these processes in the HMI. In my experience it is more straight forward to keep logic in the PLC and display the information on the HMI.
 
Not to shoot down you method blamb because it is a workable solution, but do you realize just how little effort is required to get this information from the G3 to the PLC? Red Lion has made it extremely easy. I could make a program to do it which wouldn't be hard at all, but I can actually do it in the tag configuration with no program required.

I would argue against the GSV of the WallClockTime having a negative impact on the scan time but I always loose out on those programmers who count microseconds

Another reason to do it in the HMI is if you are going to have it so that the operator can set the time, it is much easier to set the time in the HMI instead of the PLC via the HMI. Again both are doable, but we're talking about ease of programming and overall less code.
 
Not to shoot down you method blamb because it is a workable solution, but do you realize just how little effort is required to get this information from the G3 to the PLC? Red Lion has made it extremely easy. I could make a program to do it which wouldn't be hard at all, but I can actually do it in the tag configuration with no program required.

I would argue against the GSV of the WallClockTime having a negative impact on the scan time but I always loose out on those programmers who count microseconds

Another reason to do it in the HMI is if you are going to have it so that the operator can set the time, it is much easier to set the time in the HMI instead of the PLC via the HMI. Again both are doable, but we're talking about ease of programming and overall less code.

My preference for doing it in the PLC is that I can sync the clock of the PLC very easily using A-B's Logix5000 Clock Update Tool. I once tried updating PLC-5 clocks from the HMI, which was pure ugly.

The GSV instruction is a bit of a resource pig, but nothing says you need to execute that particular GSV every scan. Once per second or two is probably often enough.

Bill
 
Do think about this:
If you are going to use a wallclock time from either the PLC or the HMI - be sure the display that same time/date SOMEWHERE on the HMI, so if the clock **ever** changes (Daylight saving time?, reboots? new compnent?) you at least can visually verify the time without having to dig out your software and surf into the controller.

-John
 
Do think about this:
If you are going to use a wallclock time from either the PLC or the HMI - be sure the display that same time/date SOMEWHERE on the HMI, so if the clock **ever** changes (Daylight saving time?, reboots? new compnent?) you at least can visually verify the time without having to dig out your software and surf into the controller.

-John

I agree completely. It is important to ensure the PLC / HMI times are synced regularly. It is also convenient to give the user(s) the ability to change the PLC time from the HMI.
 
Thank you very much for all your comments1
I had the feeling that it would not be a black or white solution. Both approaches have its pros and cons.
I think I will work with the PLC data/time (unless somebody can convince me of the contrary).
I haven't found a version of DayofWeek.acd for my CompactLogix (my RSLogix 5000 version is just for the CompactLogix). I guess I will have to create my own formula. Or using the Day of the Week function in Crimson. :)
Regarding the processor load when accessing WallClockTime, I read that it can be a good idea to use a periodic task (every second) to do it.
 

Similar Topics

Can anyone assist me deleting Unschedule programs in RSLogix 5000? I am using an old program and don't need several routines that i shifted it in...
Replies
4
Views
7,780
Hi, I’m having a hard time wrapping my head around creating a weekly schedule for a pump to turn on. Setup: Micrologix 1400 1766-L32BWAA RsLogix...
Replies
39
Views
13,604
I'm fairly new to Rockwell software, I've had some basic training in the past but nothing too advanced. My company and I use Reliable products for...
Replies
11
Views
331
I'm using a Micro850 with a Panelview 800, programming in CCW. We'd like the customer to be able to schedule the system to startup at a certain...
Replies
5
Views
130
Hi All, Thanks in advance for any information. We will be upgrading an 1756-L63 controller and two Ethernet Communications Modules (1756-ENBT)...
Replies
2
Views
1,214
Back
Top Bottom