Siemens S7 Programming Best Practices

I've been doing PLC programming for about 15 years now but all of my experience has been with Allen-Bradley PLC's. A few months ago I started a new job and we have about 7 lines running Siemens S7 controllers. I've read a bunch of training material and and watched some videos and have figured out how to do the basics like get online, upload, download but I'm not quite sure what the proper procedure is for making programming changes and making sure I have good backups. With the AB controllers I would go online, upload, Save, then "Save As" with a new file name before I made any changes. This would give me a backup of the running program before any changes were made. I tried to do what I though was the same thing with the Siemens the other day but apparently ended up downloading an older program and I've been scared to go back and try to fix it until I learn a little more.

So my question is, what would be the proper sequence when making logic changes? I know there are several options but I'm not sure when to use each. For example, Upload to PG, Upload Station to PG, Download block, Download controller, Save to memory card.

Any suggestions appreciated.
Thanks
Mark

Don't take this the wrong way, but the first thing you need to implement is a proper version control in the plant where you're at. You were just a victim of someone else's mistake/lack of control.

It changed a little bit from Step7 to TIA Portal. But on Step 7, you'd open the program you have then right click on the source folder and an option for compare would appear. Clicking on that would allow you to compare the online versus the offline copy. You can then compare timestamps or complete code and settings. On huge programs over slow connections I would normally compare timestamps and if any difference was noted I would then do a full compare of the FC/FB/OB that had differences to understand what they were.

The results would be per block (meaning FC, FB and OB). If a green symbol displayed as a difference it meant that the code was the same but the time stamp was different. If the icon displayed red, the code was different. On the window where this list is, if you select the block with a difference and click on the button Go To, it would open the offline and online block side by side in the line where the difference was. In the editor three buttons on the bottom would allow you to go through all the differences in those online offline blocks and refresh the list should you have modified one of the blocks.

My usual approach was usually to upload the entire program from the PLC and save (this would be useless for troubleshooting due to lack of comments but was completely functional).
Then open the offline version of the software and compare. Usually there wouldn't be changes or very minor mods (limits, for example...) and if there were mods I would update the offline version with those differences and only then start working.

The TIA Portal is a tad different and I believe the upload now contains comments, which is a plus.

Whenever you do a change to a block, you can download only that block. If you click the download from the editor, that's all it will download to the PLC. You do need to take care about modifying FB's if you had or remove any internal variables as you will have to download the corresponding Instance DB.

If this is STEP 7 V5.x, I always create a new project, and do Upload Station to PG before doing anything.

You should have an archived backup (usually a .zip file), and retrieve it with STEP 7, and compare it to the PLC. If it's a good backup, work from that. The reason for this is that the documentation (symbol names, comments, etc.) is NOT stored in the PLC program online. It's nicer to work with a current project that has all that information, of course. Working with the upload, you would have to document as you go if you want to know what you're looking at.

When I make changes, I simply edit offline and download the block I'm working on. There is no purpose for online editing because you can download blocks in RUN mode. But... you have to be a bit careful, because, for example, if you use a non-existent address or call a not-yet-downloaded block, you can fault the CPU and it can go in STOP.

sigmadelta said:

But... you have to be a bit careful, because, for example, if you use a non-existent address or call a not-yet-downloaded block, you can fault the CPU and it can go in STOP.

Click to expand...

While we're on the subject of S7 programming best practices. To avoid the CPU going into STOP on a programming error, you need to create and download a OB122. It has to be OB122... and it can be an empty OB.

This being said, whenever you "finish" whatever modification you did, it's always good to have a look at the diagnostic buffer in the CPU. From Simatic Manager, select the CPU block and press Ctrl + D. There will be a flap with diagnostic buffer and if you're lucky enough to have the PLC synchronized with a local clock you'll see if there's something wrong. This is similar to the minor faults display in AB world.

You would usually "upload station to PG", by creating an empty project. From the dialog to upload you have to put in an IP address and more importantly the Rack and slot you're trying to upload from. This is important and has to be correct.
The Download block would let you download whatever blocks are selected if you're in Simatic Manager window. If you're in the code editor it's only the block that is currently open and active.
Download controller would be, if I remember correctly to download code and settings to a controller.
The save to memory card (I believe there was another option for this) applies to really old S7-300 or the S7-400 range where the program in burnt in a Compact Flash like cards. The last S7-300 I saw with this were in an installation that was about 17 years old.

One thing to remember if you are working on these PLC's with Flash cards is that you can still download as you would in a S7-300, but the modification will reside in the RAM memory of the controller. Whenever you cycle the power, the old code gets back in again unless you burn the card with the entire correct software.
While we're also talking about this particular case, if the system doesn't let you download a block to RAM, you can open the diagnostic window again, go to the memory flap and press "Compress Memory". This should let you get going again, but will usually require you to do a full reset eventually to free up memory.

This being said... I miss Siemens controllers.

Haven't had time to read everything yet, but personally I am not a fan of 'empty OB's'.

The OB's will allow your processor to run with a fault. If there is a condition where these is a fault I want to know about it. So I would typically have the OB 'SET' a bit when it is called, and this bit triggers an alarm. This way the operator will then be able to notify you that there is an alarm.

JOLTRON said:

Haven't had time to read everything yet, but personally I am not a fan of 'empty OB's'.

The OB's will allow your processor to run with a fault. If there is a condition where these is a fault I want to know about it. So I would typically have the OB 'SET' a bit when it is called, and this bit triggers an alarm. This way the operator will then be able to notify you that there is an alarm.

Click to expand...

I agree... some of the OB's actually give you the details to plug into SFC51 to get the details so you can determine what to do about it and notify the operator. However, going into that detail seemed a bit over what was requested and OB122 should (if you don't mess too much with pointers) not get called that often either.