slc 500

urvinder_pal

Member
Join Date
Mar 2009
Location
surrey
Posts
38
Dear all,


Is it possible that the plc can go to fault after completing a certain number of cycles/ operations. I mean can someone play with an existing program so that after certain fixed number of operations the PLC status shows error and stops. Is there any way to find out if this is being done intentionally.

thanks

kanwar
 
I imagine its possible is the logic starts writing over some of the important bits in the status registers. You'll have to search for any instructions that reference the status bits.

What is the fault? Its also possible you are experiencing a overflow condition on a math instruction. There are status registers that tell you the file and rung that the slc faulted on; that would be the first place I would look.
 
Possibly an integer accumulator overflow, they're easy enough to do unintentionally. A colleague tells me he found one in someone else's program that'd overflow about once monthly, assuring a service call. Unluckily for the culprit he was away on this occasion so my pal was called and found the sabotage.
 
I have seen this being done to some newly purchased equipment. Basically if you purchase some equipment from a company and the payment does not clear with a certain amount of time the program will go to fault. Of course the technician has to clear this logic if the payment is cleared via modem or will arrive at the plant. I have never seen this logic, but I know it gets done quite often to some of the equipment we purchase.
 
Well, I just did it with my SLC 5/04. Set a counter (just rigged to a timer). When my counter was GEQ to my number I latched S:5/0 (which happens to be the a SLC 5/0x 's Math Overflow bit). One faulted processor.

Blippity blam, now I get paid for a service call (hopefully in the middle of the night) to come to the plant and "save the day". Err, mind if we ask WHY you want to intentionally fault out a SLC?
 
just a 'for what its worth' next time this happens go to Processor Status, and open the Errors tab. It should tell you the ladder and rung of the fault.
 
No need to explicitly set the bit. The usual way is to keep adding to an integer, when it goes beyond 32767 the bit gets set by the PLC. Or add two integers to another. A divide by zero is nice too. In fact, it can happen in a number of ways, most of them honest oops but if you're feeling malicious, well...
Blippity blam, now I get paid for a service call (hopefully in the middle of the night) to come to the plant and "save the day". Err, mind if we ask WHY you want to intentionally fault out a SLC?
I think you answered that yourself :)
 
Well, I just did it with my SLC 5/04. Set a counter (just rigged to a timer). When my counter was GEQ to my number I latched S:5/0 (which happens to be the a SLC 5/0x 's Math Overflow bit). One faulted processor.

Blippity blam, now I get paid for a service call (hopefully in the middle of the night) to come to the plant and "save the day". Err, mind if we ask WHY you want to intentionally fault out a SLC?


If one of our employees did that (intentionally sabotage a machine) he would be fired immediately, without question.

If a contractor/integrator did that, he wouldn't be working for us anymore.

Please do me the favor of not applying for work here.
 
If one of our employees did that (intentionally sabotage a machine) he would be fired immediately, without question.

If a contractor/integrator did that, he wouldn't be working for us anymore.

Please do me the favor of not applying for work here.


I think he's just saying that he found a way it could be done, not saying he adds it to every program!
 
slightly O/T, but a controls engineer at Chrysler was telling me about some older robot cells they had that were sitting next to each other and couldn't figure out why one of them would randomly drop into a e-stop condition. Turned out one of contract techs had programmed one of the robots to reach, randomly, over the fencing between the cells and press one its neighbor's e-stop button. They found it by triggering a camera off the button's monitoring contact.
 
slightly O/T, but a controls engineer at Chrysler was telling me about some older robot cells they had that were sitting next to each other and couldn't figure out why one of them would randomly drop into a e-stop condition. Turned out one of contract techs had programmed one of the robots to reach, randomly, over the fencing between the cells and press one its neighbor's e-stop button. They found it by triggering a camera off the button's monitoring contact.

That'd be really funny if it wasn't infuriating.
 
That'd be really funny if it wasn't infuriating.

She (the Chrysler engineer) thought it was funny and she was the one tasked with figuring it out and searching out the robot code that was causing the problem; not easy because they were older robots with code that wasn't as friendly as the newer stuff.
 
If one of our employees did that (intentionally sabotage a machine) he would be fired immediately, without question.

If a contractor/integrator did that, he wouldn't be working for us anymore.

Please do me the favor of not applying for work here.
Seems I can troll without even trying!

No worries. While "plant a time bomb" is on my To Do list, it is very far behind tracking down where you work and applying there.

To lay it out for ya, the poor sod has posted a few times, suspecting foul play. At least two of them you reply with the "dont apply here" stuff. If helping him find the bad code is an admission of guilt, I would be interested in knowing what company you work for.

I guess I could have just said 'look in the error tab, and figure it out... noob' but this isn't World of Warcraft.
 
Last edited:
Dear all,


Is it possible that the plc can go to fault after completing a certain number of cycles/ operations. I mean can someone play with an existing program so that after certain fixed number of operations the PLC status shows error and stops. Is there any way to find out if this is being done intentionally.

thanks

kanwar


Sort through all this ;
http://www.google.com/search?rlz=1C1CHNG_enUS329US335&sourceid=chrome&ie=UTF-8&q=slc+500+faults

Funny story about the robot.
 

Similar Topics

I have a program that I've used 100 times. SQO settings: File N7:0, Mask 0FFFFh, Dest B3:1, Control R6:0, Length 8, Pos 2. Length & Position...
Replies
48
Views
955
Everyone, i am in the process of purchasing the Slc 500 version of software to support what we have and i have a question. Several of our...
Replies
9
Views
764
In a slc 500 plc I am trying to move data with out using a lot of moves. I want to move data from n7:1 to n7:2 and data that was in n7:2 to n7:3...
Replies
16
Views
1,355
Customer has a circa 2004 SLC-500 PLC. Fieldbus is a 1747-SDN DeviceNet scanner. Customer has SLC-500 file (.rss) with no comments. Has no *.dnt...
Replies
7
Views
552
After I tried wiring, I used computer program communication to read the PLC N value, but received a NAK signal. And the DL3500 CHA light keeps...
Replies
0
Views
424
Back
Top Bottom