Download PLC program from a server

Is there a way to download PLC program from a server through batch file or by script? i would like to download different application depend on my requirement to a particular PLC (Rockwell PLC).

Thanks

I *think* Rockwell doesn't allow this because they want it to be secure. They want a person to go in, select the right PLC, download, accept the warnings, etc. At least I have never found a way to do this.
Usually for this you would build all applications into the one plc, and let the PLC program decide which logic to use at a time.

I do not know of any plc that lets you do this, there may be one out there.
this is a very dangerous way to download the program !
the server has no clue what is going on at the production line, if the line is clear, the state of the machine, if maintenance is working on it, and so on.

you need a live person to make sure it's safe to download the program.

even when I remote into the plant from home and make plc changes, we have safety measures in place to ensure everyone if clear of the machine.

james

There's no reason I can think of to even attempt this in normal product environment.

The PLC program should be written in such a way to adjust to conditions. It's absolutely ok for a PLC to interface to a server to download recipes or other systems but never to download and run program automatically.

Siemens has offered this kind of functionality as long as i can remember Classic and TIA and i have used it many times.

We have systems consisting of up to 300 PLCS with identical PLC programs. Manually push out upgrades using the TIA GUI to those PLCS would be a nightmare and very time consuming. I know other OEMS with similar setup that also does batch upgrades from a server or PC. Small tested upgrades that doesn't require the PLC to restart we push out in full production!

That's interesting and I can't help but think of the whole Stuxnet thing on Siemen's PLC.

Do their new PLC still have that functionality?

harryting said:

That's interesting and I can't help but think of the whole Stuxnet thing on Siemen's PLC.

Do their new PLC still have that functionality?

Click to expand...

The Stuxnet team was far from the first third party to remotely download code to a Siemens controller. Perhaps they where the first to do this in a bad way or its simply that other cases have not gained any public attention.

If you used Step7 there was a programming API you could use to download and upload. But for the old cpus the knowledge on how to download code without the Siemens software has been widely known for many years before Stuxnet. One example among many is this tool SPS analyzer.

If you choose cycle exact recording a FIFO buffer is downloaded to the PLC and that worked already on the S5 controllers. Another tool for script download for the classic series 300/400 is BuddyForS7



The functionality to download/upload using "script" is still around for the new 1500 controllers but i have only tried it using Siemens tools. You can use TIA openness or Siemens automation tool that has an API to allow access from a C# or another programming language.



The major difference today compared to Stuxnet (300/400 controller) is that there are security settings, access protection and certificates for access control built in to the PLC that can prevent unauthorized access. This protection was very week and often not used at all in the old CPUS (300/400). So if you want to be safe protect your network and use the security features inside the CPU :nodi:.

Yes, this is supported in TIA Portal as well, via their Openness API. At least 75% of the buttons you can click are available via the API for your own custom programs to operate. Safety code cannot be downloaded via Openness, but standard code can. Simatic Manager had a similar function that was accessible via the command line.

Stuxnet didn't use this, though. The virus actually modified the communication driver to download extra code whenever the engineer downloaded (if the PLC met certain requirements), and to hide the extra code when they went online or did an upload.

Bratt said:

This protection was very week and often not used at all in the old CPUS (300/400). So if you want to be safe protect your network and use the security features inside the CPU :nodi:.

Click to expand...

To be fair, I've never seen them used in a 1500 either. Safety passwords, but never access control passwords.


I'm hoping that the global user administration built into Portal gets carried down to the PLC level in a future version. Right now, you can have TIA essentially ask a server if this user has rights to open this project. It'd be awesome to get user based management for the PLCs as well.

I'm not familiar with Siemens. So this functionality can put the PLC into program mode, download the program then turn on Run mode? Is there a physical "lockout" switch to prevent this from happening like an AB PLC?

harryting said:

I'm not familiar with Siemens. So this functionality can put the PLC into program mode, download the program then turn on Run mode? Is there a physical "lockout" switch to prevent this from happening like an AB PLC?

Click to expand...

The S7-1500 PLC switch only has three modes: "Run", "Stop", and "MRES". If you want to limit access, you can use a password on the PLC to allow no access, HMI only access, read only access, full (read/write) access, and full access including safety. You can have a different password for each of those levels at the same time, if desired.

The older 300s and 400s had the same run/stop switch. The password modes were slightly different. The PLC had one password, and you picked with level it was associated with.

Downloading to the PLC means something a bit different as well. My understanding is that on the AB side, a "Download" is pretty drastic. It causes the PLC to stop executing and overwrites all the tag data.

In the Siemens world, most downloads are much gentler. Normal software downloads don't stop the PLC (which is where the common complaint about no online edits comes from. you don't need to). Only downloads that include changes to HW (CPU properties, IO cards, etc) or safety code require a stop. Data is also handled a bit differently. The active values in the PLC don't get changed during a software download, unless you change the structure of the tags.

I could definitely see situations where a company might want to roll out updates to standard library blocks (think AOIs used across the facility) to many PLCs automatically, after they had been thoroughly tested in the lab, and as part of a documented change management program. Obviously, if you DL stupid changes you're gonna have a bad time, but automated code rollouts after a defined testing procedure is how the PC based programming world has done things for years.

At least Siemens and Schneider both can be programmed behind.

CODESYS is beta testing for Automation Server just now. Sits in the cloud, does version control, download to multitudes of controllers at once through edge gateways. Pretty neat, but also quite bleeding edge of automation. I think bigger companies that manage a large fleet of PLCs will use it to gain a competitive advantage on service delivery, but boy would you want to be doing a risk assessment or two!

I am in two minds on this. On the one hand, "what are these people doing logging in to my plant from head office?! Did they even call ops?!" On the other hand, "ok, I will send our £50/hr* PLC technician round to your site post haste so he can replace the broken PLC and download the old code. Just let him make sure he has your version of the PLC software installed before he gets in the car." I think having clear business processes in place, same as you would have on the shop floor can make this style of managing PLCs really take off and save us all some coin.

Sure, the CoDESYS IDE has had python scripting for a while now to automate loads of things - generating code, io trees, even downloading numerous projects to numerous PLCs. Might be nicer for the more traditional "don't do code changes unless you can see the machine" approach.

*I know from another thread that this figure may be as low as USD14/hr, so maybe this is ok.

I do not advise taking such a risk