PLC CPU "illegal Instruction"

Here is a question for people are familar with the use of 68000 series microprocessors in PLC CPUs.

I recently received a failed CPU from a customer, I won't name the brand of PLC because it is not important. Anyway, this type of PLC keeps an internal error log containing the state of the microprocessor when the PLC has a fault. The information includes status register, program counter, data registers, address registers, etc.

The error log contained an entry stating that the microprocessor had been given an illegal instruction to process (i.e. an instruction that the microprocessor doesn't recognise).

My question is this, what might be the cause of an illegal instruction being passed to the microprocessor of a PLC system?

My knowledge of computer architecture is minimal so if you have an answer or suggestion, please explain in layman's terms.

Many thanks in advance.

First thought, of course, is corrupt memory.

The second thought, is that the 68000 series of CPU's use 'Illegal Instructions' in order to trigger an internal interrupt trap. That is commonly used to extend the CPU's machine language, or provide specific handling for hardware, but can be used as any programmable interrupt.

Edit - Another possibility is indeed a bug in the program, especially if this is one of the PLC's that supports compiled code modules to be loaded in (like the Simatic/TI 505 series). In that case, it could just be a bug of the developer of the additional (user-loadable) code module.

Thank you for the suggestions, it's good to know there is someone to give helpful advice.

To add a bit more info on the problem: It's not the first time the customer has had this problem, there are about 10 of these PLCs on-site and they get a problem about once or twice a year (several of the PLCs have been affected by it). The PLC has two types of reset (soft and total), a soft reset won't clear the problem but a total reset will. The total reset clears that application program so it has to be downloaded again. The "operating system" must be in firmware somewhere, and I guess that it is transferred to RAM when the PLC is given a total reset. So maybe your idea of corrupt memory could be the cause of this problem. I hope not because there isn't much I can do about that.

This PLC does support compiled control modules but as far as I know they haven't been used for this application.

Some more things to look at:

Power glitches. Are there power conditioners installed before the PLC power supply? Are there any unfiltered surge loads on I/O (solenoids, starter coils, etc)?

Has anybody been welding near the equipment with it live?

Could there be induced RF noise? Either from radios, or drives?

How about physically? is there a vibration problem on the PLC rack? Sometimes socketed IC's or connectors can get annoyingly intermittent.

check math instructions,

if somehow a negative number was produced and you tried to divide it
it would cause an error, i have a number of plc's that sometimes this happens too, i could look into it more deeply and program it so it cannot happen but just have not gotten around to it yet.

I would suspect flakey memory before bad coding in the ladder (or whatever language the machine control is written in). Any kind of math error should be caught by the system process. At the most it would give a math error not an 'illegal instruction' error. This (illegal instruction) typically happens in a microprocessor when the code to be executed is actually data. This comes from some type of stack corruption.

Illegal Instruction.

Status registers are generally for PLC and I/O Health. Fault codes or registers are used for generating errors in program execution. This error can occure on a conditional jump to no label. Also on an index address outside memory range. Ive seen complex sorting programs increment the offset address, without checking to see if it is valid. This will fault the processor if it is out of range. There are others as well. It could be a combination of hardware and software, but the status registers would rat out hardware issues. These errors may not happen right away and can be hard to trace. If someone changes a value in register that someone else is using as a index offset value funny things can start happening. It is a good idea to keep a log book of all PLC changes. Allen Bradley gives a fault code and the rung that caused it. A hard reset and reloading the program working smells of rotten code. If you post the code here lots of eyes will help you weed out the problem, or atleast ellimate the code as a source... Have a good week.

I won't name the brand of PLC because it is not important

Click to expand...

Yes, important how to get specific code error!?

I guess that it is transferred to RAM when the PLC is given a total reset.

Click to expand...

No, in powerup.

rdrast said:

Some more things to look at:

Power glitches. Are there power conditioners installed before the PLC power supply? Are there any unfiltered surge loads on I/O (solenoids, starter coils, etc)?

Has anybody been welding near the equipment with it live?

Could there be induced RF noise? Either from radios, or drives?

How about physically? is there a vibration problem on the PLC rack? Sometimes socketed IC's or connectors can get annoyingly intermittent.

Click to expand...

I checked the panel drawings and found the following;

1. The PLC is supplied from a 230V AC to 24V DC power supply unit(PSU).
2. There is no noise filter installed between the PSU and the PLC.
3. The only other device connected to this PSU is an Operator Panel (Quickpanel). The I/O is powered from a separate PSU.
4. The Operator panel does have a noise filter between it and the PSU.

There hasn't been any welding done in this factory when the fault occurred.

There are no inverter drives installed in the same panel. Also the panel isn't affected by vibration.

So perhaps the lack of noise filter on the power supply to the PLC could be a problem.

I've been in contact with the PLC manufacturer but the people would could possibly identify the problem aren't available right now (on holiday?). I'm sort of hoping that its a fault in the operating system of the PLC, at least that can be fixed by a firmware upgrade.

When I get some feedback from the manufacturer, I will post it here (and if they don't give me a satisfactory reply, I will name them too).

Cheers

I can see no problem with naming the PLC brand right mow. Some PLCs are more susceptible to noise than others.

Is there an EEPROM in the PLC? If so, how old is the PLC/EEPROM combination? Some of the early EEPROMs were very susceptible to noise and were capable of very few writes.

I no longer use EEPROMs, even if they are specified, due to problems in the past with several brands of PLC.

My favourite brand now uses flash cards. Much more reliable so far. If any bad experiences, please post.

Okay, enough people have asked, I will name the PLC. It is a Sattcon 200, which was originally built by Alfa Laval Automation who were later taken over by ABB. It has a Motorola 68020 microprocessor and uses the pSOS+ real time operating system (hence I was able to see the state of the microprocessor by using pROBE+). The CPU seems to contain RAM, PROM and FLASH memory. There is a system program running on the pSOS+ RTOS, I think that this system program is in the FLASH memory. The PLC program is created with a program editor called DOX10, this PLC program is then downloaded and I guess it is executed by the system program mentioned previously.

I had never heard of pSOS+ before today, so please correct me if my assumptions are wrong.

Here abbsatt website manuals , not find exact it is dutch language, if need look in Japanese.

http://www.abb.ee/global/seapr/SEAPR035.NSF/viewunid/7080817EBD54515F4125677400318656/$file/0602EN51.pdf

http://www.abbsatt.com/pk/html/produkt.htm
http://www.abbsatt.com/pk/pdfe/1078.pdf
http://www.abbsatt.com/pk/pdfe/0602.pdf

ABB FORUM
http://www.abbplc.com/forumframe.htm

Telephone: HEAD OFFICE: Malmö, Sweden: +46 40 222000, Fax: +46 40 219539, Internet: www.automation.alfalaval.com. ARGENTINA: Buenos Aires: +54 1 7462300, AUSTRIA: Vienna: +43 2236 682810, BELGIUM: Brussels: +32 2 7283802, BRAZIL: Sao Paulo: +55 11 518 11311, CANADA: Scarborough: +1 416 2996101, CHILE: Santiago: +56 2 2335366, DENMARK: Copenhagen: +45 42 848844, Silkeborg: +45 86 822811, ESTONIA: Tallinn: +372 6 557800,FINLAND: Espoo: +358 9 804041, FRANCE: Le Blanc-Mesnil: +33 1 55815200, GERMANY: Munich: +49 89 840000, Glinde: +49 40 727409, Haan: +49 2129 94130, HUNGARY: Budapest: +36 1 4635270, INDIA: Pune: +91 212 797721,IRELAND: Dublin: +353 1 4573399, ITALY: Monza: +39 3624951, LATVIA: Riga: +371 7 828508, LITHUANIA: Vilnius: +370 2 233566, MEXICO: Mexico City: +52 5 3986162, NETHERLANDS: Etten-Leur: +31 76 5086200, NORWAY: Oslo:+47 64 835200, PERU: Lima: +51 12248801, POLAND: Warzaw: +48 22 8281200, ROMANIA: Bucharest: +40 1 3370615, RUSSIA: Moscow: +7 095 2322593, SINGAPORE: Jurong: +65 862 2711, SLOVAK REPUBLIC: Bratislava:+421 7 5254473, SPAIN: Madrid: +34 1 3790741, SWEDEN: Malmö: +46 40 222000, Gislaved: +46 371 80151, Göteborg: +46 31 7276950, Jönköping: +46 36 175030, Karlskoga: +46 586 39330, Stockholm: +46 8 53066100, Sundsvall:+46 60 129380, Västerås: +46 21 810135, SWITZERLAND: Kloten: +41 1 8046600, UNITED KINGDOM: Northwich: + 44 1606 49935, USA: Kenosha: +1 414 9429310, Warminster: +1 215 9578980, Greenwood: +1 317 8894626.

Click to expand...

I received a reply from ABB concerning the illegal instruction that caused the microprocessor of the PLC to go into fault. They told me that it was a bad connection in the PLC backplane (This particular PLC has a modular backplane where multiple backplanes can be connected by a cable). This seemed like a stupid reply to me, so I have asked them for a second opinion!

To wrap this one up. The backplane error reported by ABB was something altogether different, when I uploaded the error log from the CPU module I put the module on a single backplane, the CPU was expecting additional backplanes when it was restarted and raised a bus/address fault because it was trying to read from a backplane that wasn't there. ABB then gave there diagnosis of the illegal instruction error (the "real" fault). They said that the instruction pointer had been corrupted. In other words, while the CPU was executing a series of instructions, the pointer that holds the address of the next instruction suddenly held the wrong address. They said that this was most likely due to noise.

I am starting to dread being told that a fault is due to "noise". It seems to be the get out clause for manufacturer's of PLC equipment these days. A panel can be constructed well, with good segregation of AC and DC circuits, noise filters on PLC supplies, low impedance connection of cable screens. BUT THEY STILL SAY, IT'S YOUR PROBLEM! If the PLC is installed as per their instructions, then I (naively?) believe it is their PROBLEM. I shall make a few phone calls and see if I can get one of their engineers to go to site and see for themselves. It'll only take a few hours, Sweden to Japan, not likely. :-(