I currently use Proworx32 which has Source Control built into the server product. I want to transition to Unity, which does not have any source control built in.

1. What products do PLC programmers use for source control?

2. Or do you not use source control at all? And just trust that everyone will upload the latest version and be able to keep track of what is used on what?

I looked at one product that was licensed by the number and size of PLC programs stored, which seemed excessive to me at first glance.

GBrown

 

Does this kind of thing serve any real purpose for most installations?

--
Bob

 

I have tried in the past to use source control software; but have always found it to be a bit much for our purposes. It has been my experience that the users of the hardware/software will either contact the OEM that the hardware is installed in, which means it eventually gets back to the original programmer or they go to a different company entirely which means that we don't want them to have the source code. I am interested to see what others recommend.

 

Bob,

Maybe not source control per se, but version tracking at least.

I just had a case where I was trying to troubleshoot over the phone, and the symptoms seemed literally impossible. The company had just purchased a machine, and the previous owner had somehow reverted to a previous version of the MMI app. So the troubleshooting I was doing was leading me down the wrong path because I was working backward from the display he was seeing and telling him what to look for, but I was looking at an archive copy of the latest version of the app.

I resolved to start putting version information on the screen (and one for the PLC app as well), and begin any troubleshooting by checking the version.

 

I've used SourceSafe before. The problem with rev control on controls projects is that the source is not text, it is usually coded binary of some sort. So in essence every time you save and check in your project you will be creating a new instance of the project in the database. IT works, just uses more disk. One problem is idnetifying which files in your project folder need backing up, and which are temp files generated by some preprocessor or compiler in the PLC editor itself.

The way I usually work is to keep the current version in a folder under the main project folder. Older versions get put in a subdirectory called "backups" or something like that and are sorted by date. So you just copy and paste the entire project folders to do crude versioning.

It all depends on what you need to do, however. If you have others using the system that are sloppy and/or lazy you may WANT to enforce a strict check-in check-out policy with different user rights and things like that. My work doesn't tend to be that way.

KEJR

 

Bob,

I don't know what most installations are like. My environment includes an engineering and an operations group totaling up to 7 people who may be modifying PLC code. I want to know before I touch PLC code, is anyone already modifying it for some other purpose and do I have the latest version of documentation.

Our standard procedure is, we are going to lock the PLC code in the server library if we are going to work on it offline or make changes online that will take some time to do.

If we are working online, we will first download the latest version from the server, then read from the PLC directly to make sure we have the current version, make what ever changes that we are going to make, save it, then upload the program back to the PLC software server. Utilizing Proworx32 server, makes this a seamless process for documenting and up/downloading the programs.

We have both network based PLCs and remote PLCs, and it is the remote PLCs that become the biggest problem. Sometimes, the last change will be on someones laptop and they will forget to upload to the server when they come back from the field. Or if a programmer forgets to unlock a source, you have to ask them, what are they still doing with it locked.