PLC Lockout For Non-Payment

[bernie_carlton]

We're an OEM looking to implement a system to require periodic entry of codes in the PLC to prevent machine shutdown. The codes will be supplied by us to the end user conditional on current payments. We use Allen-Bradley and AutomationDirect PLCs. Has anyone dealt with this? Any advice? Is there any literature anywhere toward implementing such a scheme?

Obviously I'll have to set the 'locked unless an exact copy of the program is present in the PC' condition and not provide the original program. We would also have to supply a 'final payment' code to disable this system.

 

[Thomas]

It's a trust thing

Maybe it's time to get more reliable customers....

 

[bernie_carlton]

Touche! Unfortunately, it's not my call on that. I've just been asked to see if this is feasable.

 

[Steve Bailey]

It's feasible, but not foolproof. How far are you willing to go with it? A simple method would be to periodically call a subroutine that executes a divide by zero. Once your company has received final payment, you delete the subroutine. If the customer has people who know their way around the programming software, then they'll probably be able to figure out what you did.

My advice would be to tell your customers that the scheme exists rather than let them find out the hard way. That way it becomes something more like a pre-nuptial agreement than a punishment. If your customer is withholding payment, it may be because he has a legitimate complaint about your company's performance. Your detonating a time bomb isn't going to improve his opinion of you, especially if it comes as a surprise. You really need to evaluate whether the cost to your company in terms of forfeited good will and lost sales is worth the additional dollars it squeezes (some might say extorts) from the client.

 

[bernie_carlton]

I don't know about faulting the processor. I'd just rather not start the process with a visual message why, probably with a week's pre-warning. We do intend to inform the customer up front. Whether this system will cause customer relations problems is up to the big boys. I'm just looking for the technical methodology.

 

[Eric Nelson]

Maybe you should call it 'BernieSoft XP'...

Feasable, yes, but I disagree with the idea...

That said, it shouldn't be that difficult to implement. Just a few comparison instructions should do it. If 'current date' GEQ 'payment date' AND 'password' NEQ 'lock code', then inhibit operation. Put the 'lock code' variable in a retentive memeory location so they don't have to re-enter it every time the machine is started.

Any competent programmer will be able to disable this in a hurry, even with the OEM lock turned on, but if the customer has no decent programmer in house, they'll be stuck with your 'rules'... skuller

Make sure the customer makes a permanent note of the 'unlock code' in the panel. If they ever lose the retentive memory, the code would have to be re-entered.

Foolish idea IMO...

beerchug

-Eric

 

[Steve Bailey]

If you normally include an initialization subroutine to load data registers with default data, you could include code to set or clear a run permissive bit. Upon final payment, you delete that run permissive. You could write logic to control the permissive bit such that it doesn't stop the machine from running, only prohibits starting.

Configure the PLC to load from Flash (or EEPROM) memory on power-up. Include stored values in Flash, one of which is a permissive bit.

This is case where there are as many options as programmers. Some may not work with certain models. Most of the schemes you come up with will be able to be defeated by a sharp troubleshooter.

 

[gbradley]

Don't do it! You'll just be feedin lawyers.

 

[SAK-CO TECH]

Legal Ramifications Also!

Steve,

Be carefull!

With a company I worked for a few years back, we did something similar with a couple of known "Subjective" paying customers but instead of shutting down the whole process we just shut down a few process' that became a nusiance (This was based on counters or timers).

The idea of course was that if they had not paid, we could'nt fix the problem. This situation could open up a huge can of worms!

We also consulted with a lawyer at that time and he definitley didn't like idea. The lawyer had spouted off a number of legal problems dealing with this if we didn't let the customer know up front what we were doing.

Personally, I would not do this now with my own company. Besides the past experiences with this type of thing, usually nothing but ill will results.

Suggestion: if possible, set-up progress payments for the work performed e.g. - 1.) 33% downpayment 2.) 33% upon delivery of control cabinet and/or material 3.) 24% When system is installed and proved out AND PRIOR TO RELEASE OF SYSTEM TO CUSTOMER (lock it out through logic till customer pay's this portion) 4.) 10% due after 30 days pending customer approval (this of course is pretty common and insures that the customer is happy also).

All customers are different of course in payment terms, etc. but this seems to work well if the customer agree's to these type of terms.

Make sure you get legal advice if you do decide to go the route you are contemplating.

Regards,
Chris

 

[Steve Bailey]

SAK-CO-TECH

Its Bernie that's looking for suggestions on how to implement the time bomb, not me. I agree with Eric that its a lousy idea. You get tempted to do it when somebody stiffs you, but once you start thinking straight, you realize its no way to do business.

 

[Jiri Toman]

I like the idea

Password the section of the PLC program holding the activation code
logic. If the activation code is not supplied within the allowed time
( using the time of the day clock in the PLC might be a problem since they could keep resetting it) shut down the machine. I would use an operator interface to display and let customer know that they are
in a try-out period, I would have a message on every screen reminding them that the process could be terminated if activation code is not entered by a certain date. I would have a way to enter this activation code from the Operator interface.

It sounds like a good idea to me. I don't know about legal ramifications but I don't see anything wrong with trying to
protect your interests. Further more, Copyrighting your code
might also be a good idea. I would also provide the customer
with only a totally un-commented back up file of the program or
no back up at all during the try-out period. Final fully commented file should supplied upon receipt of the payment in full.

Let us know what you decide to do.

 

[Eric Nelson]

Since the idea is basically ridiculous, let's think of some humorous alternatives. Here's a start...

Mount the PLC in such a way that the UVPROM 'window' can see outside the cabinet. Eventually, the program will 'go away' on it's own. If the customer pays quickly enough, you can send them the 'code' (a piece of tape)... lolis

Use a bio-degradable CPU that will 'dissolve' itself after a few months. Similar to the opening scenes in the 'Mission Impossible' TV series...

beerchug

-Eric

 

[bernie_carlton]

Personally I was pushing for a coin slot on the machine. I was going to steal one from the bed vibrator at a local motel. But seriously. I appreciate you technical advice as well as the comments on the advisability of this move. I'm saving the latter suggestions for presentation to the management. If they're still a go I'll use the technical suggestions as a guide (First and second place being the bio-degradable CPU and the 'coin slot').

 

[Tom Jenkins]

I don't like the idea, because it can create a lot of ill will from the guys in production and engineering that have to live with the problem, are influential in the source decision, but can't control the bean counters and cash flow. For some machines there could be safety related issues too. Instead I rely on sending written notice to the installation contractor and ultimate owner that payment is past due, and the warranty will terminate on such and such date unless full payment is received. With my customers (municipal facilities) that raises enough flags to get me the check.

I do know a guy that used the "Trojan Horse" approach on all of his systems. If he got the check within the preset time, he called the operators and told them to enter a specific code on the HMI. This would bypass a date check in the ladder logic. If the code wasn't there the date check would go to the END statement, effectively stopping the logic scan.

 

[Allen Nelson]

Bernie:

Like everyone else, I'm against this kind of scheme. Especially because, the way you describe it, you won't be visiting the site to remove the "kill" code - it will always be there, waiting to bite someone.

I don't know the AD, but on AB SLCs there is something called the "OEM lock" that will aid you in what you are trying to do. When this is set (In RSLogix, in Processor Status, on the Protection tab), the only one who can have online access to the PLC must have the last saved program as their offline file. There are ways around it, of course, but it's fairly secure. This will prevent your customer from just going online and "fixing" the PLC himself (provided that you DON'T give him the LATEST copy).

The best method I've had to use (and there are no good methods) when dealing with bad customer relations is to have your guys in the field DELETE the PLC code each night before going home/hotel. Things can progress each day, but unless final payment is delivered when startup is complete, the customer has hardware, but which essentially is useless.

It's bad business (in every sense of the phrase), but sometimes that's what you've got to do.

It sounds like you are trying to extend the bad relationship into the warrenty period, by supplying the customer with codes each week to allow them to keep running while they hold back payment to make sure that everything is OK. The warrenty period is based on trust. None exists between you and your client.