OK guys acking changes you didn't makek

[JeffKiper]

OK guys a lot if us build machines that are sold to others. So how do you all verify that nobody has changed any thing in a machine you built?

I was thinking of tracking the checksum on these small machines. I want the systems to be open so they can look but don't reinvent my wheel.
What do you guys do?

 

[TurpoUrpo]

Why you do not want them to make changes that may benefit them? It is their machine. Leasing is all different.

 

[JeffKiper]

Changes that benefit them are not what I am concerned about. The changes that hurt me during the warranty time is what I am concerned with. I quests I should have noted that in the first post.

 

[anealysr]

All you have to do on a claim is a compare from your original program and the running program, that will tell you any and all changes made.

 

[Tom Jenkins]

I always allowed owners to change the program any way they wanted once the warranty was over. We kept the version of the logic as commissioned so we could restore it or replace it if needed. We used to keep a hard copy printout in the project file too, just in case. The last few years we settled for off site storage of a CD with a PDF of the program.

Until the warranty is over they can't change anything, since we still have some responsibility. After that they can change anything they want on a single unit, since straightening it out is service revenue.

It never came up(risk averse society, lawyers, liability, etc.), but we always figured if someone changed the program during warranty period we could find out in two ways. First, by comparing the logic in the machine that is causing problems with our original. Second, most PLC programming packages have some kind of compare utility that let's you see changes.

Some programming packages keep data registers as well as logic when you save. I'm not sure if this would make the checksum different or not.

 

[brucechase]

Can't you just compare the programs?

I'm sure my situation is rare, but I change programs all the time. As for warranty, if something breaks that is program related, then I just eat the cost. Otherwise, I expect the manufacturer to stand behind their machine. 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.

There are a lot of people here that suggest changing a program is bad (just look at questions about locking processors or putting in time bombs). I don't understand why some people think (and I am not specifically referring to the OP) that once a program is written, then no one can come up with a way to improve it.

 

[Jeff23spl]

Can't you just compare the programs?

I'm sure my situation is rare, but I change programs all the time. As for warranty, if something breaks that is program related, then I just eat the cost. Otherwise, I expect the manufacturer to stand behind their machine. 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.

There are a lot of people here that suggest changing a program is bad (just look at questions about locking processors or putting in time bombs). I don't understand why some people think (and I am not specifically referring to the OP) that once a program is written, then no one can come up with a way to improve it.

I understand your point and i'm agree with the fact that peoples may have good idea to improve something or add features ect...
But in fact and often plc program are build with working process in mind but also with protective features...

For exemple: You have a temperature rise limit that stop the equipement to save it. But customers try to use it in a way that made it overheating and disable the protection in the program because he want to keep is process running instead of finding a clue....But call you a week later for a warranty issue with a seased bearing or another heat related issue...

Another exemple, you tested it and it was working but you got a call back because it didn't work anymore and found the cause it is the change that they made....Will you wanna charge for this issue ?

On my side, i don't lock the code but i keep it until the end of the warranty...some peoples try to justify security or maintance issue and i provide them with uncommented version of the code to make it harder to modify it until warranty is over but i would like to find something better than that...

comparing the code is fine with code issue but when you got somethning mecanically broken someone may just have put back the original program in it before you compared it and you won't be able to tell what happened ?

 

[JeffKiper]

When I work for a shop i modified code daily. I think everyone should be able to Modify what is theirs. I had a customer change the speed on a system. 3 weeks later I get called. They wanted me to fix it for free I have hard coded speed limits in the logic. A centrifical pump doesn't like running at slow speeds. It just creates heat. They wanted to slow the process down 2 half speed.

 

[Jeff23spl]

When I work for a shop i modified code daily. I think everyone should be able to Modify what is theirs. I had a customer change the speed on a system. 3 weeks later I get called. They wanted me to fix it for free I have hard coded speed limits in the logic. A centrifical pump doesn't like running at slow speeds. It just creates heat. They wanted to slow the process down 2 half speed.

in this case, i would have them right down and sign a warranty disclaimer...If the motor spec doesn't permit the speed ratio needed or propose to use a motor with an higher speed ratio with usually a forced cooling with a separated fan

 

[STL???]

On my side, i don't lock the code but i keep it until the end of the warranty...some peoples try to justify security or maintance issue and i provide them with uncommented version of the code to make it harder to modify it until warranty is over but i would like to find something better than that...

Harder to modify but also harder to faultfind the machine, so i hope your diagnostics are spot on.

why don't you make it read only until warranty has expired?

 

[Jeff23spl]

Harder to modify but also harder to faultfind the machine, so i hope your diagnostics are spot on.

why don't you make it read only until warranty has expired?

during warranty period if it fail, we have to put it back online...Also we supply hmi showing everything so in both case once started right, their is no real need to go online with the processor but to change something...Like mostly by-passing protections...

 

[Steve Etter]

why don't you make it read only until warranty has expired?

If you choose to make it read-only in my facility preventing me from having the ability to recover from a fault, be prepared to pay for my lost production. Either that or commit to being on-site with in 1/2 hour of a phone call to you throughout the warranty period.

Two days ago, our facility experienced a component failure in a new control system. Had the code been locked like you suggest, the builder (2 states and no less than hours away) could easily have found himself fighting a lawsuit today. Because I had ability to get in and make the necessary changes to the code, our downtime was kept to a minimum.

I understand that OEMs and programmers need to protect themselves, but there is a line. Locking out the code or setting passwords for anything other than honest-to-god safety reasons is, IMHO, crossing that line. Hard-copies, CDs with original code, and contractual agreements are the right kinds of solutions here. I strongly suggest staying away from the lock-out method.

Steve

 

[JeffKiper]

I didn't want this to turn into a password debate. I wanted to know how others did.

 

[TurpoUrpo]

If you choose to make it read-only in my facility preventing me from having the ability to recover from a fault, be prepared to pay for my lost production. Either that or commit to being on-site with in 1/2 hour of a phone call to you throughout the warranty period.

Two days ago, our facility experienced a component failure in a new control system. Had the code been locked like you suggest, the builder (2 states and no less than hours away) could easily have found himself fighting a lawsuit today. Because I had ability to get in and make the necessary changes to the code, our downtime was kept to a minimum.

I understand that OEMs and programmers need to protect themselves, but there is a line. Locking out the code or setting passwords for anything other than honest-to-god safety reasons is, IMHO, crossing that line. Hard-copies, CDs with original code, and contractual agreements are the right kinds of solutions here. I strongly suggest staying away from the lock-out method.

Steve

What type of modification did you need to do?

 

[Jeff23spl]

If you choose to make it read-only in my facility preventing me from having the ability to recover from a fault, be prepared to pay for my lost production. Either that or commit to being on-site with in 1/2 hour of a phone call to you throughout the warranty period.

Two days ago, our facility experienced a component failure in a new control system. Had the code been locked like you suggest, the builder (2 states and no less than hours away) could easily have found himself fighting a lawsuit today. Because I had ability to get in and make the necessary changes to the code, our downtime was kept to a minimum.

I understand that OEMs and programmers need to protect themselves, but there is a line. Locking out the code or setting passwords for anything other than honest-to-god safety reasons is, IMHO, crossing that line. Hard-copies, CDs with original code, and contractual agreements are the right kinds of solutions here. I strongly suggest staying away from the lock-out method.

Steve

Each case as their own rules but are you sure you can establish a pursuit for your downtime? Equipement supplyer are responsible for the equipement but for what you do with it...i'm not sure ?

Was it an AllenBradley faulted by an overflow trap ?

This is why i would give the uncommented code source or a memory card that would let you clear the fault or download it to a new cpu but give you a harder time bypassing protections by trying to figure out where they are...But unfortunately, this will just slow down the by-passing of the protections as anyone can figure it out with time.
But usually if you know you shouldn'T and you have to work manny hours to do it, you probably won't change it as your boss or companny won't allow you to do it because of warranty term etc. It diminish the chance...

But when a control unit is very critical with a costly downtime like you said, i would suggest you to have replacements parts in stock at your facility and maybe a ready programmed cpu. If you buy one from the suppliyer you wouldn't need the code to put it back working...

I know it would be more convenient to get the source code with comments where people can manage it but when you have that, you have also everything to destroy the equipement if you wish...this is where the problem comes and where we wanna find a solution that helps customer while keeping a peace of mind for the supplyer