PLC's Program Failed Checksum Test

[benb2000]

I have 25 T100MD-888+ plc's with MX-RTC and R48 Low Temperature Chipset  options in operation some approaching 2 years old. Recently I have had two units returned for repair, ( May 9th and May 24th), both units in the field for about a year. When connecting Trilogi to the units I got a " PLC's program failed Checksum Test ( corrupted). With online monitoring, I could see all the inputs were functioning ( I have an Encoder input, and input states were changing on the view display )and outputs could be controlled, 16x2 LCD display had cursor blinking in upper left corner. Re programming restored operation, but the data in the DM

• battery backed memory was lost, whether I reset the PLC at programming, or not. ( I thought I could possibly re-program, but not reset, and still retrieve data from the DM
• memeory. I use a portion of the DM
• memeory as s data logger, logging dates of use.

The program does not use the EEPROM as any memory storage other than the program, so the read operation is the only function used when starting up.

The system R48 operates in a mobile environment on 12 vdc. The input is configured as indicated in the installation manual, with a series diode, and a 10,000 uf cap across the input power lines. The inputs are one incremental encoder, a 4 key keypad, reading Four 0-20 ma currrent loops. Outputs to a 16x2 LCD, and two alarms, one LED bank, and one audible Piezio horn.

Any assistance to identify the problem would be appreciated.

[support]

In a mobile 12V environment means that you are running off battery that are connected to the vehicles generator for charging? Try to add some filtering device to the 12V power lines to prevent vehicle generated voltage spikes from generator, electrostatic discharge or lightning strike etc. At the very least try to add fast transient absorber or a zener diode across the 12V supply line to absorb voltage spikes.

If you are not using EEPROM for data storage, then try to put the EEPROM write enable jumper on the "WP" position after you have transferred your program to the PLC. This is a hardware disable function to prevent any possible spurious writes to the EEPROM if the CPU get knocked out by noise.

If you have MX-RTC installed and DIP switch #4 ON the DM would not be cleared unless it receives a reset command from the TRiLOGI software. In your case are the DM all cleared to zero? If so it have been accidentally reset by the PC.

If you need some of the data in the DM not to be cleared when you reset the PLC from TRiLOGI (i.e. not during power on), then you can try this command: "SETSYSTEM 5, n" . Once executed, the PLC will leave the DM[1] to DM[n] untouched even if it receives a reset command from the TRiLOGI software. This will work with firmware revision r47 and above.

[benb2000]

Thanks for the speedy reply.

The voltage on the RTC when powered ON is 4.966 Vdc, and OFF 3.151 Vdc.( Pins 14 and 28 )

Input power to the PLC ( on PLC terminals ) is 11.89VDC

When the unit comes in for repair, I run it from a 1.7 amp regulated bench supply

The installation on the vehicle includes a 3 amp 3EQ1 EMI Filter in series of the power leads.

Today, I let the current unit run for about 2 hours ( bench supply ), and went to lunch. when I returned, the LCD was blanc, and attempting to do online monitoring, gave me the same error message as before. That the Checksum Test failed,

In trying to Reset the PLC through the Online monitoring screen, I received a series of Runtime Errors in all the custom functions with a System Variable Index out of range.

i.e Runtime Error in Fn#1, System Variable Index out of range
then pushing the Reset again, I would get Runtime Error in Fn#2, System Variable Index out of range. The rror was the same, cycling through several Custom Functions.

This unit is reporting r49 as its firmware version.

On these units its Dip switch #1 ( SW1-1 ) that is turned ON ( for data retention when the unit is disconnected from power) , not #4. Have the DIP Switch functions changed?

Remember we have been operating without a problem for a year with the two that have failed, and there are units out there that have been operating longer without a problem, and with the same input power design. ( 3eq1 Filter ). I am fully aware of the electrical noise on vehicular systems, but if this was a consistant problem, I would have had more failures, and sooner.

My understanding would be when the unit is powered up, the program in the EEPROM is loaded into the RTC SDRAM. Do I assume the Checksum test is performed after this, and compared to one stored in the EEPROM? Is this value then stored in SDRAM? because my second failure today occured while the unit was running.

I added the SETSYSTEM 5, 3999 statement, and reprogrammed the system again. I'll leave it run this afternoon.

Typically when I set these systems up, I will let them run for 48 Hr, with a simulator, to check the calander clock, and DM

• memory retention, powering on/off at least 4 times during that 48 Hr. period.

I have a complete spare T100MD here and would like to replace the MX-RTC and or the EEprom. Which should I replace first?

Thank you for your assistance

[support]

When you transfer program to the PLC, the program is stored in the RAM and a copy is stored in the EEPROM. So even if the EEPROM has failed the program will still run on the PLC. You will only see the problem after a power ON or WDT reset since the CPU will attempt to load a copy of the program from the EEPROM and conduct a checksum test. It is at the point it will report that the EEPROM content is corrupted. But if your system failed when powered is applied and you don't think it has been reset by WDT, then it could be other components that is giving intermittent problem. One possibility is the RAM chip (62256) or the MX-RTC that sits between the RAM and the socket on the main PCB.

Try replacing the EEPROM chip first and transfer your program to it. If it still exhibits similar problem, then replace the RAM chip and then the MX-RTC in that order to determine the possible problematic IC.

DIP Switch #1 is the DIP switch to protect the RAM content from being cleared by a power on reset. However, this does not prevent the RAM content from being cleared by a "reset" command from the PC. SETSYSTEM 5 would do the job.

[benb2000]

Last night befor I went home, I rocked the MX-RTC / SDRAM combo back and forth in their sockets, instead of changing any parts. I did the same with the EEPROM. Turned it on, and left it run over night connected to our simulator. This morning it's still running correctly.

The PLC is housed in a gasketted, water proof housing that contains a VCI-101 Electronic Corrosion protective device that is a dual action: desiccant and multimetal protection, the interior of this instrument is prestine.

My conclusion at this time is is that the seating of the MX-RTC / SDRAM assembly has to be addressed periodically, shades of the ISA cards in the early PC's. If I see the "Failed Checksum" error again, the first thing I will do is re-seat the MX-RTC/SDRAM assembly.

Higher quality sockets for both the PLC and the MX-RTC would improve the reliability with portable /mobile applications.

Thankyou for your assistance

[support]

I see. It seems to be that the problem is likely to be caused by The MX-RTC being shaken loose from its IC socket on the PCB. The problem is that MX-RTC together with its RAM IC on its back forms a tall stack with high center of mass with respect to the PCB, and in a strong vibratory environment like moving vehicle it could have greater tendency of being shaken loose. This is similar to during an earthquake the tall buildings shake far more compared to lower building.

I would suggest you get a long but thin cable tie to bind the MX-RTC stack to its socket. This way it ensures that the MX-RTC always sits properly into its IC socket. Also ensure that when you assemble the MX-RTC to the PLC, keeps the IC pin cleans to provide good contacts. A contact cleaner such as WD-40 works great to ensure good contact. (Use a Q-tip to apply to the pins and the socket leafspring).

If you have batch quantities requirement, you could place special order with the dealer for the factory to arrange for the MX-RTC to be soldered directly to the PCB. You need to give a lead time of 4-6 weeks so that the factory could produce some units with MX-RTC being soldered directly to the PCB during their production run. You may lose the flexibility of being able to replace the components easily but you get the assurance that such issue would not occur.

Regarding IC sockets, we are using double leaf IC sockets which holds normal ICs very well. However, MX-RTC being tall and heavy does behave differently from normal ICs. We have previously experimented with using expensive turn-pin sockets, but what we found out is that turn-pin sockets actually don't hold the IC as strongly as the double-leaf type socket. So it is useless against protecting from vibration related problem. Anyway, we will feed this back to the supplier to see if there are special socket that employs high holding strength spring for the 28-pin IC socket.

[benb2000]

Thanks again for your help.