Secret counter in SLC503

Is there a place in the SLC5/03 where I can count and keep the numbers forever?

And according to my ex-wife forever is 5 years._____Relax! Its only a joke...
I want to count some cycle and it will go up to 10 million. I would like nobody to reset this count.

If its impossible I will use a scheme to index / mask move the value from here to there to here and back arounf here so its hard to find where it really comes from hence preventing deletion.

That is unless there is indeed that special place

You can trigger the overflow to reset at the magic 32767 or any round number say 25000 and then also increment a second counter to keep track of how many times you have incremented. Your total count will be the multiples of 25000 counter plus the base counter.

10,000,000 will give you a count of 400 in the secound counter.

IE: If you incremented the 25000 count three times and have a value of 15000 in the base counter then you have a total count of 90,000.

To my knowledge there is no "safe" memory in any of the SLC's. True there are the protection options but they do not "protect" against a download. You could protect some memory and if you ever had to download again you would have to upload or record the value previous to that. Keep in mind as well the an automatic load from an EEProm will wipe it as well.
This has been one of my biggest problems with AB processors. No way to not over-write the data on a download. Oh well! Hopefully the Cntrlgx will have that soon.

Tanks b-t, but the real issue is not how to count to millions, its where to place the value so only a very experience tech. could find it to reset the value.

It as to do with protecting the program or not.

My OEM client wants to track the production from his equipments and the purpose is his new 5 years parts warranty... which also has to do with the machine production.

He wants me to lock the program but I would rather not.

He says IF his in-house programmer cannot find how to reset my value to ZERO in 4 hours he lets me ship the PLC without program protection ...

I want to know if I have other options.

I have done this in the past with other brands and I zigged and zagged my value around so much that they could almost never find where it came from.

Can AB do better?

And according to my ex-wife forever is 5 years._____Relax! Its only a joke...

Click to expand...

It all depends on how many ex-wifes you have.
No. 1 forever is 6 years
No. 2 forever is 3 years

and I am still sane, I think ?

You Californians ....

From the Left Field Dept:

Basically there is no way to protect SLC data from a download. The only way is to store the data OUTSIDE if the processor. The simplest way might be to install the smallest MicroLogix (about $150 worth) next to it in the panel and connected to the SLC on Ch0 via DF1.

All you have to do is MSG the data you want accross the Micro and viola the result you want. The program in the Micro can be protected and if the power fails all of its memory is non-volatile.

Houdini time.

If I were to try my hand at it, I would do something like this:
First, I would put something that's out in the open, that LOOKS like its doing the counting, like so:

   I:2/10      +-------- CTU ---+

----| |--------| Counter:  C5:0 |

               | Preset:  32767 |

               | Accum:       0 | 

               +----------------+

Now, I would obfuscate the REAL counter, so that any ol' maintenance guy, won't know that this is the counter.

       +-------- MOV --+

-------| Source:    90 |

       | Dest:  N12:25 |

       +---------------+



       +-------- COP ---+

-------| Source: #I:1   |

       | Dest:   #B13:4 |

       | Len:    2      |

       +----------------+





    B13/[N12:25]             +--- ADD --+

---------| |-------[OSR]-----|   N12:17 |

                             |        1 |

                             |   N12:17 |

                             +----------+

A couple of comments:
The above rungs should be scattered throughout the program.

The addresses N12:25, B13:4 (and 5) and N12:17 should be in the middle of some data file, intersperced among other used addresses. You don't want these to stick out. And of course, comment them with something that sounds normal for you system.

The "90" used in the first rung makes the address B13/[N12:25] = B13:90 = B13:5/10, which is the location of the mapping from I:2/10 in the COP.

Now for one more piece:

        +--------- MOV --+

---+----| Source:     30 |

   |    | Dest:     S:24 |

   |    +----------------+

   | 

   |    +------------- MOV --+

   +----| Source:     N12:17 |

        | Dest:   #T4:30.ACC |

        +--------------------+

Some important points:
You need to set S:2/3 - "Index across Data Files".
You need to make sure that the # is in front of the T4 address. This is Indexed addressing, and so N12:17 won't write to T4:30.ACC but 30 words off of it (to T4:40.ACC)
You need to make sure that T4 is only 39 words long. Since there is no T4:40.ACC, the value will go to the next data table (C5), and thus land in C5:0.ACC.

So, the counter will have the correct count, and will, to all appearances look like it is actually counting. There will be no cross-reference, search, or ANYTHING that will show that its being used anywhere but on the one rung.

But the rung is a fake. The real work is done elsewhere. But the source can't be traced either. I:2/10 is only used in one place in the program - and that's at the dummy counter.

This should drive the maintenance guy crazy.

Unless, of course, he subsribes to this forum......

I think I would go another route if possible.

Setup an OPC/DDE connection to his computer and log the numbers into an Excel file. He has them, no one can take them away and/or erase them. The connection could be setup on a variety of protocols.

If its strictly a production count then Vorne displays and their associated software offer that feature.

Hide it in plain view...

WARNING Pierre... this post is tempered with MGD, so try to get the gist.

If someone is going to mess with the cycle count, it will only be because the system failed and they want to claim it failed while the system was still in warranty (based on cycle counts).

Now... how can you hide the cycle count without hiding the cycle count?

As Allen suggested, create an obvious counter. The cycle causes the increment in the obvious counter. Have the obvious counter activated by the "cycle initiator" signal. This is logical and reasonable.

However, build your "real counter" so that it is activated by some event that always follows a cycle.

Make it so that your "cycle" ALWAYS produces a particular non-fatal error, or a particular operational flag of some kind.

Have your "real counter" count those non-fatal errors. Label your "real counter" as a such-n-such Non-Fatal Fault Counter. The output from that counter could say something like... "Non-Fatal Fault such-n-such Detected" or some such.

So... what kind of non-fatal error, or flag condition, could you create...?

You might use something as obvious as a divide-by-zero. That is probably too obvious for a bright person to miss.

Every cycle, you could have the current count subtracted from the previous count... this should always produce a negative result. That would cause the flag register to indicate a negative result. Then have the current count incremented. That value gets saved into the current count.

Somewhere, far removed from the obvious counter, you would have your "Fault Counter". Every time you see the after-cycle event and a negative result, increment the "Non-Fatal Fault Count". You might have to play games to get the timing down.

If, at anytime, you see the after-cycle event and a positive result, then you know that someone is messing around with the count. You can latch this fact, in retentive memory, as... "Call Service" or "Call the Provider" or some such. This is really a "Tampered Flag". If that bit is ON then you KNOW that the count value has been modified downward.

Even if they see through the obvious counter, and are able to find the real counter, they will be less likely to see the "Tampered Flag".

If the Tampered Flag is ON then the Warranty is VOID! Even if they find the "real" counter and adjust it to match the obvious counter.

Another option would be to set a particular retentive bit once the cycle-count reaches max. The bit could be called "Service is Needed" or "I'm tired, have ya got a beer handy?" or some such.

I too am tired, and I do have an MGD handy, so I'm gonna do the MGD and hope that this this gives you food for thought Pierre.

Let us know what you finally decide on.

Id be going with the method that Allen Nelson suggested but you dont even need to put it into a counter. Bury the value in a pos word of a control data type or similar.
If you have a lot of money then you may be able to fit a basic module and write the values to the module (maybe)

This could be a good project for someone, it sure is more interesting than a traffic light.
Regards Alan

Protect it and be done with it - it sounds like you are dealing with children who are trying to cheat their way around something . You will be able to delay it for a while , but in the end if they are set on cheating , they will .
Tell him to hide a mechanical counter somewhere on the machine , and if there is a difference between the two counters , then start sacking people for industrial misconduct .
Another thought , why not just make a dummy db9 plug up , screw it onto the programming port , and lead wire seal it , if you need to program or fault find , get the boss and break the seal , but it is getting a bit pathetic when you have to treat people like that.

How about a 'hardware' counter (non-resettable), driven independantly from the PLC, perhaps from a 'once per cycle' proximity sensor or limit switch.
Why does it have to be in software?

Memory permanent Hardware

Memory secret = > Memory to register errors

Frequent the memory of errors of hadrware remains insurance. Except one will be had reset on the code of the program, depending the register protected for "Clear all memory".

Use registers: Power-Up or Power-down to counter, some others
It is enough to insert code to manage.
Valley to verify if PLC specify is possible.

I'm with lc03 on this one.

Sometimes we just make things way too complicated. Just put a simple hardware counter Inside the enclosure and voila. Drive it off a plc output or otherwise as described above and Done!

No matter where you put it inside a SLC/500, all you would have to do is walk up to the machine and download a program even if it is the same program you downloaded 6 months ago without any changes and bam! You wiped out the data table and your current count gets hosed.