Problems with Analog Card on Cegelec ALSPA 80/35 PLC and P1200 SCADA

Our client has a 2 rack Cegelec ALSPA 80/35 PLC with P1200 SCADA system. It appears to have a hardware fault in that one analogue card inputs have regular spikes which appear on the graphic trend. The spikes are semi-random and yet consistent in height and duration. We have isolated and/or replaced I/o cards, power supplies and even the second rack.

The software clearly reads in 'spiked' data and would appear to display it correctly on SCADA. We have assumed the PLC racks operate on 'bussed data' so cannot create spikes digitally, suggesting it is the central processor digitally creating false information.

Can you assist?
Who knows? That kind of published data is hard to find. But I seriously doubt that a PLC CPU is injecting bogus data values when AIs are known to have problems with common mode or noise coming in from the field, or a bit or two in the AI card's A/D are failing.

You need to troubleshoot this to isolate the problem and fix it.

Apparently some signals on some AI cards are good, other(s) are spikey.

Change/move one of the spikey input channels to another AI card that does not exhibit spikes and see if the problem moves to the new AI card.

If problem moves to the new card (still have spikes), then the problem is the signal itself, not the AI card.

If the problem does not move, (spikes disappear), then the problem is associated with the AI card, not the signal.

If the spikes are truly on the signal, analyze whatever is common between those signals that spike. common conduit runs, common junction boxes, common power supply, common shield/screen ground? from the same operating location? How do the spikey signals and their sources differ from the non-spikey signals?

If the spikes are associated with the AI card, and that AI card is single ended, a single input signal might contribute an intermittent 'random' common mode which affects other channels on that card. Or the AI card is just flakey.
Sorry David but we've isolated everything round the AI card (which is scaled 0-10 volts) including incoming signals and the possibility of Ov reference currents or earth currents.

We've also replaced the AI card several times and isolated all the other I/O cards and their related signals, which is why we also
replaced the rack. In other words there are no 'flakey' signals at all - it is generated within the PLC so we replaced the rack power supplies as well.

Trust the above helps.
Did this PLC/SCADA combination ever work properly?

SCADA is reading some kind of register in the PLC to get its data.

Is there a separate comm card which SCADA reads from? Could that be the problem?

I have seen a Modbus slave device put spurious (random and erroneous) high numbers into Modbus registers. The PV could not possibly made step jumps like that. The fix was a replacement Modbus card, an option on that device.

I usually leave the CPU as the last thing to consider.

But if you've substituted isolated signals and substituted replacement components and the problem is still there, then the last remaining device is likely the culprit, unless there are comm cards involved.
Thanks David for your reply - you are asking same questions as myself.

- Yes it has previously worked correctly. Quite how long the fault symptoms having persisted is not clear - probably several weeks
as the client used a bypass workaround at some expense.

- Yes there is a communication card to SCADA, however displaying the 'interference' in not important. Above a certain level it trips
the main drive which causes havoc with production.

- We have assumed neither SCADA or the comms card could send interference back into the system. On examination of the software,
analogue inputs are scaled, then compared with absolute integer values to alarm and trip. Where used in this logic, timers are
set at 10ms - scan time is around 42ms. Last week we left the system still displaying the fault symptoms on SCADA, but added timers
to delay alarm and trip logic by a fraction of a second.

It's now being monitored to see if this helps.