OK guys acking changes you didn't makek

[Steve Etter]

What type of modification did you need to do?

I had to replace a faulted safety input module in a CompactLogix L43S system. The hardware manual said this was my only option for the fault I had. If you've ever had to do this you know you can't simply replace one module with another. The processor knows the identity of the specific module and, once you replace it, it knows it is not the same module. This requires configuration modification that would otherwise be unavailable to me.

Steve

 

[TurpoUrpo]

That is why i wanted to know the type of modification. If it was about replacing part with part that is not originally in machine. I see no responsibility for manufacturer even if no code is provided.

But, I would hate as end user to be in position where code is not provided hassle free. We have corrected some errors in programs during warranty, but always have noticed the manufacturer of those modifications (usually we have vpn established for them and give them chance to correct first).

In the end, some things should stand in contract. One is the original programs provided as is and no locks, removed comments or anything like that.

 

[Paullys50]

That is why i wanted to know the type of modification. If it was about replacing part with part that is not originally in machine. I see no responsibility for manufacturer even if no code is provided.....

I would agree, in Steve's example he is placing blame of the hardware failure onto the builder. Ultimately it was a Rockwell part that failed, certainly could not hold the OEM responsible for a hardware failure. In a situation such as this I can't imagine a builder not doing all they could to assist in getting the plant back up and running. If I was in that situation, and it was password protected a simple phone call and you've got the information you need to fix the problem. A followup phone call would be made to determine how to best protect my liability.

 

[Paullys50]

Back to the original question...

There is not really an easy way, because of how “Open” PLCs are you can’t do much to track changes unless you have an elaborate version control system in place, even with version control changes can still be made and you won’t know unless you compare the uploaded PLC program with the program that is in the program vault. To really track these activities you then need some sort of audit schedule, much like an equipment calibration schedule. A proper PM/WO program in the plant would help document equipment modifications and changes. I think it should be acceptable that if the system needs warranty work the OEM/SI should have every right to compare what they delivered to what is currently in the system and determine whether or not the issue is indeed warranty work, or billable to the customer.

Unfortunately OEMs and Integrators are in a lose-lose situation. At the end of the day the customer has purchased the product which usually includes source code. If you leave the code “open” then you open yourself up to potential problems and liabilities as unqualified/underqualifed personal can get into the system and make changes, which could break the system (See the “The Nature of the Beast” thread). If you lock it down, then you open yourself up to absurd statements/demands from the customer(I’ll sick my lawyer on you, I’ll shop somewhere else...see the previous posts). The only way to minimize RISK for all parties involved is to have tedious validation testing during the commissioning process. Once commissioned password protect it, have remote access to the system and allow the OEM/SI to be available for immediate response if there is a PROGRAM related bug. I think that is the best solution, the OEM/SI is protected and the customer knows they have immediate support if it is a PROGRAM issue. BUT, this opens up the OEM/SI to become an extension of the customer’s maintenance department. The end user “may” become lazy troubleshooting problems, and the problem is always a “program” problem; when in reality it was a hardware failure or human error.

Notice how I emphasis PROGRAM bug, if there is a hardware failure (PLC specific hardware being an exception) or human error that is the root cause of the downtime, that does NOT constitute an immediate response of an OEM/SI. The end user needs to take responsibility for proper training and proper access to spare parts. The practice of re-writing logic in the PLC too “band-aide” hardware problems in these situations is an unacceptable reason for an end use to demand the PLC code to be “open” during a warranty period.

But, that is a fantasy world

 

[The Plc Kid]

Depends on the PLC but with AB we used to use a SLC for our controls on bakery equipment and we used a panel pc for the HMI and it ran rs view me and rs ladder 500. With this setup we kept the processor locked and they could still view the program to troubleshoot problems but they could not change anything and we had remote access if changes had to be made.

I wish there was a rs ladder for contrologix.

 

[OkiePC]

(for A/B) The checksum will detect logic changes not necessarily data table changes. For that you can assign protection and detection of changes with or without restricting them.

If you store the programmed limits of the machine in instruction constants (literals) or protected files and keep the ladder unlocked you should have no problem detecting changes unless they're deliberately hidden from you. If your customers are going to abuse your support and stab you in the back like that, I think you should be able to sniff that out.

If I were a freelance integrator or machine builder, I would still not lock my code, but I would put expectations on paper reserving the right to have controls over the engineered limits of the machine.

You might stand to gain new knowledge that can improve your equipment or software designs.

I would encourage cooperation with those who think they're smart enough to make the machine better faster or otherwise more suitable to them. Once you find out that they are clueless or dangerous, then take action to protect them from themsleves...and in the future budget projects with expected supports costs included.

I would be careful not to burn bridges though...

 

[Steve Etter]

in Steve's example he is placing blame of the hardware failure onto the builder.

No, you have misread my statement. At no point did I even suggest that the builder was at fault for this. What I said was that had I not had access to the code - necessary for this module replacement - my downtime would have been extensive and expensive and that THAT would have been unacceptable and on the builder's back.

OkiePC's statements are dead on.

If you lock it down, then you open yourself up to absurd statements/demands from the customer(I’ll sick my lawyer on you, I’ll shop somewhere else...).

You're entitled to your opinion, but I find nothing absurd about statements like this. If you hobble my business because you are simply ineffectual at running yours, be prepared for consequences. Actions like locking down code in non-safety controllers indicates to me that you might not be the best programmer or company for me to do business with.

Once again, I strongly suggest finding methods to allow you to keep your code open - remote access, contractual agreements, program comparisons, etc.

Steve

 

[TurpoUrpo]

No, you have misread my statement. At no point did I even suggest that the builder was at fault for this. What I said was that had I not had access to the code - necessary for this module replacement - my downtime would have been extensive and expensive and that THAT would have been unacceptable and on the builder's back.

OkiePC's statements are dead on.

You're entitled to your opinion, but I find nothing absurd about statements like this. If you hobble my business because you are simply ineffectual at running yours, be prepared for consequences. Actions like locking down code in non-safety controllers indicates to me that you might not be the best programmer or company for me to do business with.

Once again, I strongly suggest finding methods to allow you to keep your code open - remote access, contractual agreements, program comparisons, etc.

Steve

Yes, but it is your job to see the code comes hassle free for you. If you failed at that and accepted locked code, it can not be equipment manufacturers fault.

 

[Steve Etter]

Yes, but it is your job to see the code comes hassle free for you. If you failed at that and accepted locked code, it can not be equipment manufacturers fault.

You are absolutely correct in my situation - it is my job and exactly the reason I was able to make the necessary changes I did - I knew about and personally worked out the arrangements in advance. However, in larger organizations especially, plant-floor level people are not always involved in project specification and sign-off. In those cases, problems like locked-out code presents itself when everyone is in crisis mode. It's often in those moments when the effects of these choices are first recognized by the end-user. As an OEM, do you want to risk your reputation to those circumstances or make arrangements up front?

Steve

 

[kamenges]

There really is very little you can do, Jeff. If you want to give your customer the flexibility to get themselves out of trouble you open yourself up to changes that make things worse. As already stated a program compare is the easiest way to determine logic changes. Data changes are a much more tedious case. You will have an absolute slew of "false positives" because data, by its nature, can be expected to change. All you can do in that case is record some of the data values you believe to be important and see if they changed by looking at them directly.

Originally posted by brusechase:

If there is a manufacturer that will first look at the program and then deny the claim based solely on the fact that someone changed the program - regardless of what happened, then I guess the lawyers will hash it out and that will be the last time we purchase a machine from them.

It's obviously your money and you can spend it as you see fit, but I STRONGLY disagree with this position. Why should it fall to the OEM to determine if a change YOU made on site is the cause of a specific issue? For example, the OEM has 50 identical machines installed around the world that don't exhibit any issues. But yours, with the modified software, has a problem. I would think that it would be up to you to prove your modifications DIDN'T cause the issue.

The biggest issue is that for every Steve Etter and brucechase in the world, individuals who by all accounts can modify base software without causing other issues, there are 50 individuals who will modify software to "correct" a specific "problem" with little to no regard for how that modification affects other parts of a machine/process. And all of a sudden a burnt motor/blown drive/crashed cutting head is the OEM's fault. The age old adage "Never let a good deed go unpunished" most certainly applies here.

Keith

 

[Jeff23spl]

just 1 question can resume it a little bit:...Have you ever known someone that would like to try to push the "forward" and "reverse" bouton at the same time just to see what would happend???
This is why we need so basic mecanical and electrical interlock with a forward/reverse starter...(I personaly use a selector but...)
Having to lock our code is similar to a different level...few peoples won't mess with protections but some ******* will do just to see what happend while others will do to keep the plant working to keep worker on duty regardless of machine life.


The comapared file, checksum or data is a way but the guy just have to put back the oem program in the device before we come back to check and we won't see what have happened. How to figure that out???I have no clue without locking it somewhere...

 

[brucechase]

It's obviously your money and you can spend it as you see fit, but I STRONGLY disagree with this position. Why should it fall to the OEM to determine if a change YOU made on site is the cause of a specific issue? For example, the OEM has 50 identical machines installed around the world that don't exhibit any issues. But yours, with the modified software, has a problem. I would think that it would be up to you to prove your modifications DIDN'T cause the issue.

It doesn't FALL on the OEM to make that determination, I already did. That is why I called them. Believe me, in all the years, I've actually had very few warranty claims against any manufacturer.

But to continue on with your thoughts, I had dozens of Powerflex4 drives in service. All of a sudden, after powering them down they would not come back on. A call to AB gave me your respsonse, "we made thousands of these and yours are the only ones that failed, it must be you are installing them wrong". Well after many talks, pictures, and discussions with AB managers, they actually found that they had a bad precharge capacitor that would fail after powering down. AB still doesn't like to admit it, but there was a problem with their equipment (and yes, we were close to getting the lawyers involved). (see this thread - http://www.plctalk.net/qanda/showthread.php?t=25438 )

The biggest issue is that for every Steve Etter and brucechase in the world, individuals who by all accounts can modify base software without causing other issues, there are 50 individuals who will modify software to "correct" a specific "problem" with little to no regard for how that modification affects other parts of a machine/process. And all of a sudden a burnt motor/blown drive/crashed cutting head is the OEM's fault. The age old adage "Never let a good deed go unpunished" most certainly applies here.

Keith

Unfortunately I can't help what others do. I appreciate you suggesting that I am competent, many others obviously thing otherwise. I state that the PLC code must be unlock in all my purchase documents and specs. If a manufacturer will not comply, then we will not purchase the machine. Some may call that absurd, but it is spelled out ahead of time.

You can even look at it this way, we have 25 of the same machines with a 25 second cycle time. If I can figure out a way to reduce 1 second off the cycle time, then I can avoid purchasing an additional $1 million machine. I am expected to do that all the time (other than installing capital equipment). Yes, I have had some success in that on many machines - it's good business and what is necessary for any manufacturing company to remain competitive.