SLC500 occasional CPU fault toggling

Indeed. And, so the hell what if I divided by zero? Yea, should be a flag, not a full-on stop. so many gotchas in the AB paradigm. Very embarrassing and sometimes very costly. AB is not at the forefront of innovation. They lead the world in cost and aggravation. You don't kill a kid for dividing by zero. And guess what? The world doesn't end either. Flag me and I'll pay attention if, I need to. Shut me down and guess what? I disdain you. It is not as if the processor is going to burst into flames. Drives me bananas and always has. AB determines what a 'major fault' is and leave the programmer in the wake of all the **** that results from a 'major' when the fault is really a 'nothing'. As Rodney would say: "no respect!"

I_Automation said:

Let me add a rant about the processor faulting if a pointer goes above an array dimension. ...

Click to expand...

I dunno

• If I had a device controlling a process comprising pieces of expensive and/or dangerous equipment, I might prefer everything to stop when that device tries to read or write, and then use, random bits outside the programmer's expected range of locations.
• And if I am a multi-national company building and selling said devices, I might not be interested in the liability implications of such operation. Programmers make mistakes: to design a device that makes no effort to anticipate and compensate for that fact is naive at best.

Jumping on this bandwagon ....

If a pointer into an address space (i.e. an array) goes beyond the limits of the array size = programming error


If a Timer Preset is calculated, and it becomes negative, it is a programming error



You CANNOT expect the processor to deal with your garbage, you must filter it out yourselves.

The processor shutting itself down is simply telling you it cannot continue with the data it has been given to work with, so don't give it excrement in the first place....

Work within the limits imposed = no problems

I disagree with the second(timer negative preset) point. All the negative number means is that the timer 'DN' bit should should be set to true. Yea, with AB you need to guard against such things. Thanks for the assertive insult. The processor's 'feelings' are not damaged by dividing by zero. No, it is not necessary that it exits the scene just because it gets insulted. A friendly processor reports(flags) the infraction and soldiers on.

Along the lines of automotive computers - they are programmed to run the vehicle any way it can unless a fault is too great to run it safely.

Cruising down the freeway at the nominal 87MPH in Detroit and getting a blue screen of death would shut down the engine, lights at night, and make braking and steering very difficult for anyone not a body-builder.

Company owners that are relying on the PLC to make production and get income for it are expecting more out of them.

If a DIV has a tag as the divisor, or a timer has a MOV to its preset or an array point is manipulated then it may take a while for the one unforeseen circumstance to trigger a fault. There should be a "Safety Value" that if it is divide by zero or array out of range then the safety value is used. And a Timer.PRE of a negative number would be done the first scan the same as it was zero.

Hehe. Reminds me of Chrysler's 'Ultra-Drive' back in 1989. 4-speed transaxle. It was programmed so naively that if speed sensor dropped out(they did), it would bang itself right into 1st gear w/o hesitation. The trans could handle that. But, generally, the engine could not. Let's throw a rod or two. Plus, pretty damned dangerous situation having the front wheels lock up at highway speed. That's the real Wrath of Kahn(Ricardo Montalban) was pushing 'Ultra-Drive and Crystal Key' at the time. Very naive on Chrysler's part.

I_Automation said:

There should be a "Safety Value" that if it is divide by zero or array out of range then the safety value is used.

Click to expand...

I'll say it again with vague examples.


Someone has a process where loss of lubrication to a bearing would cost millions of dollars.


Someone else has a process that can harm or kill someone if it does something unexpected.


What are the correct "Safety Values" for those situations? Is there any way the PLC manufacturer can know those values when they sell the un-programmed PLC? Those are rhetorical questions because the answer is "Of course not."


One viable alternative for the PLC mfr is to tell the programmer that certain cases will cause the PLC to fault, and what a fault means; along that line I think A-B's design decision is most likely about liability, specifically pushing liability for each process from the PLC mfr to the owner of the process.



Several times a year, maybe once per month, there is a post about scaling on this forum. There will follow replies explaining y=mx+b et al., which many of us have understood since grade school. But I often ask myself why has that OP been given that task when they don't understand summat as basic as that, and what other potentially critical knowledge don't they know? From a business perspective A-B has to ask itself the same question about the purchaser of every PLC they sell; to do otherwise would be business suicide.

The only thing worse than a PLC not doing what I want it to do is when it does exactly what I told it to do.


I think of myself as a half decent programmer, but when my brother told me Siemens lets you write to memory off the end of an array, my jaw dropped, because I have accidentally frozen and rebooted computers doing that*; fortunately there was nothing physical involved to damage.


It's about liability; if you think it's so inconvenient that a different choice should be made, you are probably over-estimating your own programming skills**, and you are certainly over-estimating mine.


** The fact that you consider faulting on programming errors an issue certainly supports this



At a minimum, every competent application programmer will consider what happens if the PLC loses power; the plan for that will cover the faulted case. I'm not saying there are no scenarios where it's inconvenient and/or unnecessary to have a PLC fault on a programming error, but A-B has both chosen to make the programmer find them and provided a workaround for them; I don't think it is reasonable to ask for more.



* Timex 2068 72kB computer, writing bit pixels on a line to graphics memory, flubbed the edge of display check and continued into system memory.