Real Time Clock in Simatic S7?

I am used to accessing real time clock functions from S: registers in Allen Bradley PLCs. I am new to Simatic S7 and Step 7 software. I am wondering if there is a similar function for S7-314 CPU and how it can be accessed in Step 7 programming. I would highly appreciate any help in this area. I tried searching the forum and Step 7 documentation.

With SFC 1 "READ_CLK" (read system clock), you read the current date or current time of the system clock of the CPU.

You can also in alternative:
open the OB1 block.
write these 6 lines

L LB 12 // Year
L LB 13 // Month
L LB 14 // day
L LB 15 // Hour
L LB 16 // Minute
L LB 17 // Second

Sreev, this has been discussed before. Take a look at this thread, and you'll find additional info on how to use SFC1.

Rgua, the date and time variable that you find in OB1 only indicates the start-up time of OB1, not the current time.

Date & Time in OB1 are start time of OB1 and it starts every cycle.

Rgua, that is great info. All these years I thought OB1's date_time variable referred to the time that OB1 started after going from Stop to Run. If it is the dynamic time, I will be able to eliminate SFC1 from most of my programs. Thanks for setting this straight.

You guys are great! Can't wait to try your suggestions in the morning. This Step 7 is quite different from RSLogix stuff (which I have been using for years) but I think I will get a hang of it one of these days. I am glad one of my clients has forced me to use Siemens on a project. I look forward to learning a lot from this great forum and also hope to contribute some of my own experience.

Wow, an S7 item S7Guy didn't know! This has got to be news. Since I started reading/using this forum, I think just about every S7 question came to an end when the God had spoken.

I've been in awe so far, but maybe there's hope for us all. He does have an Achilles heel.

Regards

Ken.

You flatter me Ken. But I'm more of an S7 hacker than an S7 expert. I've been doing strictly S5 and S7 stuff since about 1988, so I've learned a lot of little tricks by trial and error (like Rgua's suggestion above) and like to pass them on so I can save someone else some time. This is truly a great site and I learn something every day.

S7Guy said:

I'm more of an S7 hacker than an S7 expert.

Click to expand...

That probably applies to most of us here who use S7 :nodi:

Also like you, I assumed that the date and time in OB1 was when OB1 was called after a transition from stop to run.

S7Guy said:

I will be able to eliminate SFC1 from most of my programs

Click to expand...

Most of my SFC1 calls are not within OB1, I tend to keep that clear and do most of my programing in FC's, so rgua's bit of info will not help me much, but it's certainly something to store at the back of the ol' grey matter

Paul

I don't call SFC1 in OB1 either, but there is no reason I couldn't pass the date and time into global variables right from OB1. Like I say, it eliminates an SFC1 call somewhere else, and I don't care about the six or seven milliseconds that might have passed in the meantime (I usually just use it for date stamping anyway).

The thing that galls me most is that I really knew those OB date and time stamps applied every time an OB ran. I've used them in the past with error OBs.

I just didn't make the inspired leap that Rgua (by the way, how do you pronounce that?) did to realise you could then use the OB1 data as a real-time clock. Touch of genius.

From now on I think I'll always document this bit of code as (c) Rgua.

Thanks and regards

Ken

S7Guy said:

there is no reason I couldn't pass the date and time into global variables right from OB1. Like I say, it eliminates an SFC1 call somewhere else, and I don't care about the six or seven milliseconds that might have passed in the meantime

Click to expand...

Good point!

I use the date, hours and minutes, so that little time difference will not matter to me either!!

Perhaps I will store that bit of information at the front of the ol' grey matter not the back

Cheers rgua

Paul

I tried to add LB12, LB13, etc addresses to the Symbol Table without success. So I created symbols Year, Month, Day, Hour, Minute and Second for addresses MB0 through MB5. Then I added the following lines in OB1 which seem to do the job:


L LB 12 //Year
T "Year"
L LB 13 // Month
T "Month"
L LB 14 // day
T "Day"
L LB 15 // Hour
T "Hour"
L LB 16 // Minute
T "Minute"
L LB 17 // Second
T "Second"


Now, I can use day, hour etc. for some real time controlling (e.g. switching lead/lag status on 1st and 15th of every month). This STL stuff is totally new to me (I am used to RSLogix ladder programming) but is very interesting.

Thank you very much, rgua and S7Guy for your guidance! Please comment if there is a better way of doing this.

Sreev,

You can't apply names in the Symbol Table to LB, LW or LD addreses since they have no existence outside the block in which they are referenced. These addresses are 'Local' bytes, words, or doubles and are simply methods of addressing the same stack of memory which is created dynamically for the TEMP declarations of every block. When the block is called, whether it is an OB called by the operating system, or an FC or an FB, an area of memory is assigned to hold these TEMPs. As soon as the block completes and control exits this piece of memory is simply unallocated and then can be assigned to the next block that requires it.

Be aware : the operating system leaves the contents of this memory unchanged when it unallocates it. So never make assumptions about what is in these registers when a block starts executing. Write to them before reading them is a good rule. In the case of OB1 variables, the operating system writes to them as soon as it starts executing so you can rely on these data and read them immediately.

If you want to use symbolic addressing you have to stick to the datatype used for declaring the TEMPs. OB1_DATE_TIME is declared as a DATE_AND_TIME variable, so you could use the symbolic name #OB1_DATE_TIME for it. However, if you want to access individual bits or bytes within this variable you end up using direct LB addressing etc.

Regards

Ken