Real Time Clock in Simatic S7?

[jvdcande]

sreev,

you can program a L-T combination in ladder. It's called a MOVE instruction, comparable to the MOV instruction with A-B.

Kind regards,

 

[rdrast]

jvdcande, Your example highlights one thing that has always bothered me about Simatic (and to be fair, almost ALL PLC's)...

Any PLC that requires an instruction to set the initial RLO of a rung (as you do by OR'ing a contact with a complement of itself) should have an easily accessible flag for "Always True" and/or "Always False".

True, for Simatic, it's only required when in LAD, but it is a royal pain. Especially when some moron (cough.. me) mistypes an address somewhere, and unlatches my "Always True" bit. /sigh.

My other huge peeve with Simatic, is lack of a single instruction to cast a DINT to an INT, but that's another story.

 

[Ken M]

Rdrast

I don't believe that the ladder network JvdCande drew actually needs the OR'd M0.0 - it should work with all the MOVEs simply connected to the left rail.

On the issue of recasting data types this isn't possible in standard STL, LAD or FBD in STEP7, but it can be done using Siemens implementation of IEC Structured Text - they call it SCL (Structured Control Language). Depending on your way of thinking about problems, this can be a real breath of fresh air. Re-casting of datatypes, proper indexed addressing of arrays ( TestVal[x], change x to whatever value you want), all the things that are missing from STL and LAD. Obviously it is entirely text-based so you lose out on the visibility of LAD, but hey, if the code works, who cares?

Regards

Ken

 

[Eric Nelson]

In PLCs that don't have a built-in "Always True" bit, I just make my own and give it a nickname.

  ALW_ON         ALW_ON

---] [---+-------(OUT)

         |

  ALW_ON |

---]/[---+

This one won't get accidentally unlatched...

beerchug

-Eric

P.S. to Jean Pierre... I like how you made the background color transparent in your picture...

Er, you did do that on purpose, right?... utoh

 

[S7Guy]

Sreev, I would stay with STL if I were you. You will get faster scan times, it is much faster to program with it, and the instruction set is more powerful. Every person that I have convinced to give STL a try would never go back to ladder again.

Another way to get around all of those load/transfers while still maintaining the ability to use the individual date/time elements symbolically would be to pass the date/time to a data block using SFC20. For instance, I could set up a data struct in DB10, starting at byte 0, and then point to that struct:

      CALL  SFC   20
       SRCBLK :=#OB1_DATE_TIME
       RET_VAL:=#Return
       DSTBLK :=P#DB10.DBX0.0 BYTE 8

It's such a small amount of data that it really doesn't matter how you do it, but thought I'd just throw out another idea.

Rdrast, I'm just curious. When would you need the DINT to INT instruction?

 

[jvdcande]

Ken wrote:

I don't believe that the ladder network JvdCande drew actually needs the OR'd M0.0 - it should work with all the MOVEs simply connected to the left rail.

Well, Ken, you better believe it. After all, we're talking Siemens.

Eric,

yes, I made the background transparent on purpose. Why? Well, there are people out there who like it. It definitely looks better and I like to please. Besides that, I do a lot of course writing for my company and this way it looks more professional.

Kind regards,

 

[jvdcande]

S7Guy, you wrote:

Sreev, I would stay with STL if I were you. You will get faster scan times, it is much faster to program with it, and the instruction set is more powerful. Every person that I have convinced to give STL a try would never go back to ladder again.

Well, I do know that a lot of the maintenance guys out there do not like STL. They do like ladder a lot better. So, I always advice to use ladder as often as possible. After all, you only have to write the program once, but the maintenance people have to look at it for another 20 odd years. Have some mercy on them and don't make their lives harder than necessary.

Kind regards,

 

[S7Guy]

JV, it depends on the maintenance people. I can usually take a guy aside and explain STL troubleshooting, and he picks up on it very quickly. Honestly, I can say that my STL coding has never been an issue. If my code is something that they have to look at all the time, then maybe the problem is me, not them, in the first place. In fact, during the past five years, most of my customers haven't even asked for the PLC source code anyway, since I provide an HMI that details every conceivable fault that can happen.

When I write code, my goal is to make it as fast and clean as possible, and STL is much better at that than ladder. Just looking at the ladder code you posted above, you had to use over twice as many actual instructions to do the job. If you are working with small programs, that wouldn't matter, but in very large programs, I just can't give up that edge.

 

[Ken M]

Damn those leading contacts, JvdC!!

Like S7Guy I tend to work on the basis that good software stays good. It doesn't wear, rot or corrode. If it worked when the machine was installed, and the machine's not working now, then it probably (99.99%) isn't the software's fault. And if it turns out to be a switch gone bad, then please don't get in to the habit of allowing people to use software solutions to fix hardware problems. How often have you seen an example when a work-around gets added to the code "just till the end of shift", and the next thing you know that undocumented change is still there 5 years later.

By all means give the maintenance guys enough information to see the results of the software. "Good" software doesn't just encompass the control of the machine. I hope S7Guy uses some of the memory space he saves by writing better fault-handling and indication routines.

But hey, I'm probably preaching to the converted.

Regards

Ken.

 

[S7Guy]

Absolutely Ken. The way I look at it, anyone can program a machine to do something when conditions are right. But most of my programming effort goes into handling the machine properly when things go wrong (switches fail, contactors fail, who knows). So, well over half of my programming goes into fault handling and displaying faults for a marquee display.

Perhaps there were valid reasons for making the code simpler to troubleshoot for the layman 20 years ago before there were displays (I remember combining all of the fault bits in one PB so it would be easy to find out what stopped the machine), but in this day of HMIs, I'll just concentrate on making the code run flawlessly. That methodology has worked for me so far, and I rarely get call backs.

 

[sreev]

Although I am more comfortable with ladder logic by habit at this time, I can see myself converting to STL in the long run. For now, I have been playing with both and noticed something. When I tried comparator LE_I with LB14 as IN1 in ladder logic, I get data type error but it works when I do the same thing in STL using:
L LB 14
L 15
<=I
= "P110START"

Thank you all for kindly sharing your knowledge. I have learned a lot from you.

 

[Ken M]

Ahhh, the joys of data types are waiting for you Sreev!

LAD is somehwat more strict than STL about using the correct data types as parameters to instructions. You're trying to do a "Less Than or Equal to" comparison based on integers (LE_I). So when you try to feed it a byte as one of the parameters, LAD rightly rejects this.

On the other hand, STL doesn't care for most of these issues. You've specified a byte address and an integer constant and then said "do an integer comparison". And it does. This freedom to mix and match may be seen as some by a benefit in STL, but don't get in to the habit of just throwing any values in to instructions without at least trying to anticipate the full consequences.

Strictly speaking the LE_I or >=I are performing their works on the contents of the two accumulators ACCU1 and ACCU2. These are both 32-bit registers and the 'I' part of the instruction tells S7 to only evaluate the 16 LSBs of these. LAD prevents you loading anything other than a 16-bit INT in to the ACCUs for this instruction. On the other hand STL says " 'L LB14' is a perfectly valid instruction - I'll do that." And then "L 15 - no problems - I'll do that too."
And then "Oh you want an integer comparison on the contents of the accumulators? OK, I can do that" And so on. STL instructions are not evaluated in the context of the preceding and following lines - the CPU just follows your orders. Now that might be just what you want, ... or not!

Regards

Ken.

 

[rdrast]

Rdrast, I'm just curious. When would you need the DINT to INT instruction?

Well, Just about every single time I use and S7.

I'd say, 90% of the time I use S7's here, it's in conjunction with Siemens MasterDrives on Profibus. In our programs, we scale all reference and feedback values to engineering units, as reals. No problem coming IN to the PLC, (IDT, DTR), but going back to the drives, the values need to be INTS.

And I'm anal about things like that, so my REAL to DINT to INT converter does a lot of limits checking, as well as sign preservation. It irks the heck out of me that I have to spend so much time (CPU Cycle wise) in what should be a simple conversion.

The 300 Series (even the new ones) aren't exactly speed demons.

 

[rdrast]

JV, it depends on the maintenance people. I can usually take a guy aside and explain STL troubleshooting, and he picks up on it very quickly. Honestly, I can say that my STL coding has never been an issue. If my code is something that they have to look at all the time, then maybe the problem is me, not them, in the first place. In fact, during the past five years, most of my customers haven't even asked for the PLC source code anyway, since I provide an HMI that details every conceivable fault that can happen.

/Agree, but partially.

Here, S7's are programmed sort of like uhh... a Visual Basic Wrapper program calling DLL's written in C/C++? ... Hrm.. Yep.

First pass, is write and thoroughly test/debug small pieces of control logic, using all internal values (Not I/O). Those get packaged up in neat little FB's and FC's.

Second pass is do the I/O side mainly in ladder, meaning interlock strings, overall start/stop/mode logic, overall section enable/disable logic, and the "big stuff" that a maint. Electrician will look at if there's a problem

Third pass is put a ladder wrapper around the whole thing, calling the sub-programs sequentially.

Sometimes (when I have scan time issues), I will go back and try to change coding, or STLize more.

/sigh.. One day, someone will make code monitor/profilers for PLC's... Some day...

 

[S7Guy]

I'd say, 90% of the time I use S7's here, it's in conjunction with Siemens MasterDrives on Profibus. In our programs, we scale all reference and feedback values to engineering units, as reals. No problem coming IN to the PLC, (IDT, DTR), but going back to the drives, the values need to be INTS.

I work extensively with Siemens Masterdrives, and you really don't need to do a specific DINT to INT conversion. I'm assuming you use the RND command, and you can just transfer it to your INT variable directly. For instance:

      L     4.500057e+005
      L     2.500000e+001
      /R    
      RND   
      T     MW    10

This isn't so obvious, because the Siemens help specifically says that the RND instruction is for REAL to DINT, but all I really care about is the value in the accumulator. As long as it is in the range of an INT, by definition it is an INT even though it occupies 32 bits of memory. I do all of the range checking just before the INT transfer, and I've never had a problem.

I like your comparison to DLLs. Somehow, it seems like a very logical way to program, and I've done it that way right from the beginning (long before I knew what a DLL was).