Host Engineering Forum
General Category => ECOMs and ECOM100s => Topic started by: WRT on May 10, 2010, 05:18:11 PM
-
I have a DL06 program that when run stops communicating with the ECOM100 card, preventing all further ECOM programming or DS control through the ECOM card. On two PLCs with the same program, one stops communicating and the other doesn't. This happens even though I have all ECOM RX/WX Comms disabled in the program. I can still talk to the PLC using a serial cable. Also simply stopping the program does not return ECOM communications, a power cycle is required. Can I have some suggestions what to look for?
Cleared the scratchpad, reinstalled everything, version 227 on the ECOM, 2.50 on the DL06. Still does it.
Since this has happened on two different sets of hardware, I don't think this is a hardware failure.
-
Check out http://forum.hosteng.com/index.php/topic,137.0.html (http://forum.hosteng.com/index.php/topic,137.0.html). Seems like kind of a similar problem, although I didn't have the time to go back and review the old thread.
-
I'm embarrassed about this one once I figured it out. It was *only* an endless program loop that's all, so I didn't even post it in the right forum. This was a remote site so I couldn't look at or touch the PLC.
I guess it is always good to remember the following:
If the program does a death loop it will not respond to the ECOM in any way.
If the program does a death loop it will not even respond to the STOP switch.
If the program does a death loop the watchdog is useless as well.
The only way to recover a death loop is to
1) set the toggle to STOP
2) cycle the power
3) Set the toggle to TERM and fix the loop.
So the moral is that whenever you have a backwards GOTO in your program, ALWAYS set a maximum number of iterations into the loop, then stop the program.
-
If the program does a death loop it will not even respond to the STOP switch.
Really? Surprising. The processor must only check the state of the switch and only do so at end-of-scan, rather than the switch being truly preemptive.
-
If the program does a death loop the watchdog is useless as well.
There must have been a RSTWT in that loop somewhere.
-
i agree, unless there's an RSTWT instruction inside the loop, the DL06 should have dropped out of RUN mode after 200ms and you'd still be able to talk to it over the ECOM.
-
Well, you would think that wouldn't you? All I can suggest is you try it. I have the latest versions for both the ECOM100 (227) and the DL06 (2.50).
When the death loop is executed, the RUN light stays on, the CPU light goes red (I assume that is the WD) and the PLC stops communicating with the ECOM card.
Wait! there's more.
Connecting up with the serial cable does not work either. Switching the toggle to OFF doesn't work either. It looks like the watchdog and the toggle only work if you complete the scan. Not much use then. A power cycle is required!
If this is all true, and I have it right in front of me, then the seemingly documented use of the watchdog gives a false sense of security. It is not very useful in practice.
Bill
-
Can you post the code for the "death loop". Does it have anything do do with pointers?
-
once the CPU light comes ON, bets are off, it's the PLC equivalent of a BSOD (blue screen of death) on a PC, that explains the symptoms. once the PLC crashes, it stop processing comm and the switches won't help, power-cycle is all that will get anything going again.
have you brought this up with the tech guys at ADC? it seems odd to me that the WDTimer going off would cause a CPU fault.
-
The program can be as simple as:
LBL K666
GOTO K666
END
I have not taken it up with AD yet, I originally thought it was only an ECOM problem, before digging deeper.
I will now though. PLCs that lock-up are not really acceptable, even if it is my fault.
-
OK, there seems to be a problem with the 2.50 firmware. No one knows yet how far back it goes. Waiting for a response from Japan.
-
The program can be as simple as:
LBL K666
GOTO K666
END
Well, there's your problem. It's that 666 stuff!
-
A rather disappointing answer that any DL06 programmer needs to be aware of:
"This is the way the WD timer has worked in all previous versions of the DL PLC CPUs. There would be some interoperability issues if it was changed..."
So the watchdog is not really a watchdog, it is rather useless really and the documentation should be cleared up on this point.
Back to my previous moral: If you use a backwards GOTO or a FOR NEXT loop make ABSOLUTELY SURE that it will not get stuck.
-
Glad you noticed that Darth. I rather hoped someone would notice my wit :)
-
The program can be as simple as:
LBL K666
GOTO K666
END...
I'm sorry, but that is hilarious... :D
-
Glad you noticed that Darth. I rather hoped someone would notice my wit :)
LBL K666
GOTO K666
PLC Program of the Beast
-
This is more fun than Facebook!
-
'Farmville' on a PLC?
-
I finally found the lock out problem after a week of remote troubleshooting. A Solid State relay "coil" connected to one of the PLC outputs was shorted. I thought I was clever putting in a 1 amp power supply so that all the circuits were protected, but what happened is that the low voltage from the short killed the PLC and left it in a bad state. No wonder it was not communicating! I couldn't forensic it because the PLC wasn't talking every time it tried to turn that output on!
So another moral:
Put a power supply in that is hefty enough to open a separate fuse on the output circuits without dropping the voltage so much that the PLC goes down. Even better, annunciate the fuse so you know what the problem is.
-
I agree. I usually have a dedicated fuse or breaker on the output common. When you send your kids (wires) out in the world, you never know what's going to happen to them. ;)