Ethical ownership and proprietary OEM

[STEVEBOT]

Monkeyhead
Fascinated by the statement

I mentioned it to the field tech helping us install it and he gave some bullshit line about letting the machine cycle to a stop was the "old plc way" and this "computer is much more capable then a plc. you can even play games on it!" I don't know what he was yammering on about.

and the guys who have to fix it can't view it fully.
As I see it from your posts the problem lies with integrating a machine specified by process with it would appear either little or wrong input from facilities.
If it is your task to fix/modify machines for the benefit of your company and you are trusted to do that then managment should ensure all machines are acessible by you. If the OEM has concerns about his product and wants to password it then he should either gaurentee a good response time in the event of a breakdown, (downtime on our site is costly)or leave the passwords with managers so in the event of an emergency the software can be accessed.
I like you am the one who gets the 3am morning call when the "dingle dangle" thing is "dangle dingling" instead and we don't know why.
I agree with Peter in the repect of justifying your need but your later posts seem to do that.
Personally I see the need for and against passwords, most of our machines are PLC and as such only acessible by certain trained personnel our Scada Data system unfortunately has to be passworded and restricted to hell because certain people misuse the PC instead of looking after their own machines.
Like you if your process and change managers think their new machinery is the tops let them get the 3am headache.

 

[Leadfoot]

I am also one that has to deal with both delivering new equipment and servicing equipment out there. Too many times I have had to literally follow a wire to find out were it goes while trouble shooting.

I feel Schematics, a copy of the program, manuals for the hardware and 3rd party equipment manuals/documents should be turned over to the maintenance supervisor/manager.

I do believe that when you have a program that controls your equipment, during the warranty period, leave the OEM work on it. During the start up and warranty period, I feel the maintenance personnel should be trained to trouble shoot the system.

Passwords are no better than key locks, they keep honest people honest.

I have noticed just how empowered the average person feels when they are IMPORTANT enough to have the password. Usually one person with the password was given it so the maintenance guy did not have to come out at 3 AM just to do a 10 second job.

 

[monkeyhead]

I'll quit ranting now. This IS a thorny issue.

You're right about that one. I can actually see this issue from both sides which is part of the reason I brought this up.

I've also had bad luck with OEMs since most of our equipment is not customized since distribution is still such a big industry. It's stock equipment bought from manufacturers that make hundreds of the same machine. A lot of them are just unwilling to work with us. The only customized machinery we have... well the firm that set it up for us went out of business. So much for support, eh?

I have the luxury of being the only person in the building with enough knowledge and the tools needed to get into our machines. The laptop that has all my control programs on it comes home with me since I'm on call and can dial in. So i've never had to deal with someone following me up and messing up anything I've purposely set up, but I can imagine the level of frustration it must cause.

I also admit that I'm in the wrong in the scenario I described above. I should definately find out about the terms of the contract, follow up with the proper people and all that before taking any action. The sad reality is that my company would rather support our equipment ourselves. Downtime hurts... but it's still cheaper to have me spend a day learning a new program and disecting logic to track down a problem than to fly someone in from the OEM and pay them hundreds of dollars an hour.

Thanks everyone for the insightful responses. As always it's completely appreciated.

 

[monkeyhead]

I didn't know Rexroth had a softPLC.

I'm not at work, so I can't verify, but I believe this is it:

http://www.boschrexroth.com/business_units/brc/subwebsites/product_catalogue/en/AutomationSystems_en/IndraLogic_en/IndraLogic_V_en/index.jsp

 

[elevmike]

I'd like RSDoran and ElevatorMike's take on this - how do we ring their doorbell

I'd like to hear Ron's take too.. But from my own perspective, we really dont want ANYBODY fooling with the code that we installed. Unlike a production shop machine, elevator people are licensed by the state or local authorities, like sparkys, lawyers & doctors. You are not allowed to do ANY work on an elevator without a license. In a production shop all you need is for the owner to decide that your qualified (for the most cases). Hence; legal barrier 1.

Safety issues: When it comes to goof-offs screwing with the program, AMSE A17.1 provides for a safety circuit that should be designed to prevent any garbage programming from causing the machine to act in an unsafe manner.

With this in mind I have provided the customer with the program on CD for his spicific unit. This provides a comfort level that often helps to sell the job. I have no problem doing this as long as the owner signs a confidentiality agreement. But the reality is that it's usually not worthwhile for anybody to take our program and try to use it in another unit. This is due to the fact that the program is often altered at least some for each project, based on that projects configuration.

3rd-ly: We dont do ALL of our own panels. On mabey 50% of our projects we sub them out depending on the project type. Our panel vendors provide us with the full boat program & documentation. HOWEVER, I would never, and have never made an alteration without consulting that vendor. As Rod implied, you should have a good relationship with your vendor, and he should be supporting (tech support) you on whatever alterations your intending to make; or you should be willing to pay a fair price for alterations from the orig spec. If not, then you've got the wrong vendor, or he's got the wrong customer.

In short; keep your paws off of somebody els's program code, unless he's dead, or totally unwilling to work with you. Additionally, if he's unwilling to work with you on your proposed alterations, stop and ask yourself WHY??

So that's my take on the subject.....

 

[monkeyhead]

You bring up some valid points Mike, but it seems to me the corporate distribution world is totally different. Slick salesman promise drooling change managers better production numbers, make the sale and then get the hell out of dodge. I talked to a former conveyor salesman who told me, all they cared about was getting the customer to sign off on the system. He actually said, "We coulda cared less if once we walked out the door if the thing blew up." And this wasn't a dead end shop. This is one of the US's largest vendors.

After the sale OEM responsibility is null unless you want to pay them ridiculous amounts of money to send one of their field techs out.

Honestly, I have no qualms re-writing poorly done logic, especially when the OEM give a **** less.

Guess it's a combination of the wrong vendor selling to the wrong customer in our case.

 

[bernie_carlton]

We are an OEM of packaging machinery. We send the PLC program out on disk with each machine. We ask that the customer check with us if they wish to make changes to plan on the best modification to achieve what they want. For me, one of the best helps in troubleshooting a machine by phone is a person who is familiar with the normal operation of the machine who can say, "It normally does 1 then 2 then 3 but now it jsut stops at 2". It is also very helpful if they can be connected to the PLC and looking at the program. I will guide them to finding the problem, correcting any faulty inputs or outputs or (of course this NEVER happens) correcting a faulty point in the program. I always take great pins to explain exactly what happened and how the fix affected the operation.

I have good relationships with those end users who actually want to understand the program and have qualified personnel. I will guide them through the machine operations from the program's view. They quicklly understand that the fastest way to find a problem or do a modification is to call me. As our machines, while of a similar style, have a great deal of custom code, it is unlikely that it would be useful to copy the code for use in another machine.

 

[Doug_Adam]

As an end user, we specify in our contracts that all code is our property.
The few times that a contractor has objected to this, we negotiated a deal that we were both happy with.
As for safety, the PLC does not control that (unless its one of the new Pilz safety PLCs). We also take a great interest in safety, since our local laws state that if we install the machine on site, then it is our responsability.

Always settle IP issues before you sign the contract. It makes it easier that way.

 

[rsdoran]

I dont know that I have a take on this. I have worked on the fence as well as both sides of it.

I also know that its just as easy for someone to embed a method to "record" access, especially on a PC, as it is for someone to "crack" their way into a program. With the legal and safety issues involved if you do not have "legitimate" access to a machine's code then it is best to leave it alone and have "management" handle the issue of obtaining documents and permission or using the OEM techs for modifications and/or service calls. If an OEM has a program "protected" and that protection is "compromised" then it may give the OEM an out on fulfillment of "services" etc provided by the contract.

If for whatever reason a problem did occur and the OEM determined their code was accessed (without their expressed consent)...modified or not...they could null and void warranty and disclaim any responsibility. This is probably written into the contract when the machine was purchased.

There is nothing wrong with being a geek and wanting to know how something works but some things are better left alone or not discussed when done, especially on a open forum.

In the end it doesnt matter "why it was done", the issue is of responsibility and legality of "should it be done". Just a suggestion but slow down a little on being the "guy that can do" because sometimes it can come back to bite you in the arse. One little mistake can have you held financially responsible...and companies do this to their own employees. I have seen this happen first hand...ie a person lose a job and a civil lawsuit holding him responsible for damages.

I can not say what to do or not to do just be careful when you deal with new machines (technically any machines) and the code etc is not provided.

Its not just the machines you have to deal with and know about in this day and age.

 

[TimeFluxCap]

Without the code or access to it, how the hell is the maintenance team meant to diagnose what is wrong with the machine when it breaks?

Call the OEM and bring them to site? Not when you are talking the about the cost of downtime at my site!

 

[elevmike]

monkeyhead,

As far as "making the code better". IMO if it's not broke, or you dont need some added feature that you cant get the vendor to help out with, then why? There's six ways from Sunday to do anything. What you would do and what somebody else would do really dosnt matter as long as you get to where your going. Once you've reached the destination, there's really no point in going back just to try a different route. I'm forever "cleaning up" my own code but very rarely would do so with somebody elses code unless it's to add another bell or whistle.

 

[monkeyhead]

As far as "making the code better". IMO if it's not broke, or you dont need some added feature that you cant get the vendor to help out with, then why?

Safety is the first reason. Someone gets hurt... then I'm gonna be subjected a whole host of modifications from adding e-stops, interlocked guards, pressure sensitive clutches etc. And well... who wants the HMI to say E-stop #1 or gaurd #2 was pulled when it was really the non-OEM E-stop #6 that we added. Sure I could get away with adding another stop in the series, but at that point it's about the professional touch. Safety is #1, and my employers won't wait for the OEM to make the mod. It has to be done yesterday.

The second reason is usually integration with our specific needs. Example: We had a shipping lane that was rated at 30 packages a minute. The snag was that the line had to be set up around the smallest package size. Running mixed sizes reduced the effective rate to around 22. I used an existing photo eye to measure package length and scale the speed. Effective rate now: 29.5. OEM went out of business. No support.

The third reason is lack of support from the OEM. Example: I started as a machine operator. The machine I ran uses a proximity photo eye to detect product wrapped in clear plastic. It was a nightmare that called for maintenance adjusting the eye constantly. On two occasions, once as an operator, and once as a maintenance guy, I talked management into contacting the OEM about the problem. Their solution? Sent us the part number for a different photo eye that experienced the same problem. My response? Re-wrote some code to deal with the flickering since it would have called for some major downtime to modify the machine to use a transmit/recieve setup due to physical contraints.

The fourth reason? Management wants something changed, and I'm the only one with the know how, and the quote from the OEM was too high.

The fifth... Data collection not inherently provided by the base machine.

 

[monkeyhead]

There is nothing wrong with being a geek and wanting to know how something works but some things are better left alone or not discussed when done, especially on a open forum.

You all have offered some awesome insight and really made me think about things, but this is probably the best piece of advice in the whole thread.

 

[BobB]

I have absolutely no problem with protecting a PLC program with a password for 12 months and a day. The password then, as far as I am concerned, belongs to the customer but defiantely not during defects liability period.

I have a fea customers where we have "worked something out" and covered it legally and that is OK also.

Once defects liability is over, I believe the customer owns the password for whatever code is in the machine - ha has paid for it and far too much sometimes.

By the way monkeyhead, do not try to break the password on the Omron CS1 or CJ1 PLCs. You only get 3 goes and then everyone is locked out, even the programmer who put the password in the PLC. Password cracker programs really lock the PLC up very quickly. 3 goes ain't many.

 

[PhilipW]

You only get 3 goes and then everyone is locked out, even the programmer who put the password in the PLC

eerrK! === wow! Now that is protection! Clearly reflects the requirements of Omron's strong OEM market.

Whichever way you cut this discussion, and there are merits to both sides of it, I still maintain that it is the party that has legal or contractural liability that has the right to maintain exclusive access.