Host Engineering Forum
General Category => DirectSOFT => Topic started by: clyleadams on January 15, 2009, 02:53:32 PM
-
I have a machine that uses up to six dl-06's to control it.
I use E-COM's to communicate i/o and v-mem status to each of the other PLC's. Basically each PLC uses ECWX instructions to write its I/O status to each one of the other PLC's.
Occasionally one or more of the PLC's will stop communicating for no apparent reason. There is no physical ethernet problem (you can still connect to the "locked up" PLC however the PLC and Ecom itself will never attempt to restart communications even after a PLC power cycle.
Upon further investigation, I found that the workspace value (defaults to V401) in the ECOM100 Config is frozen during a lock-up. If you manually reset the workspace value to "0" communications restart normally.
So my solution to the problem is to add a line to reset the workspace value to 0 on the first scan. This way, a power cycle will allow the problem to correct itself. Example Below:
---(SP0)-----------------------------------------LD(K0)
OUT(V401)
Is there any way for the I-box to figure this out itself? or is there some other method for me to accomplish this?
Thanks,
Lyle Adams
adams.lyle@corrtechinc.com
-
Check your Cross Reference and make sure that the ECOM100 Configuration IBox buffer of 65 V memory words is NEVER used anywhere else in your program. Make sure the ECOM100 Config IBox is at the TOP of the program and IS ALWAYS EXECUTED EVERY PLC SCAN.
Similarly, look at each and ever ECxxxx IBox instruction's Workspace register in the XRef view and make sure that THOSE V addresses are NEVER used anywhere else in your program (each IBox must have its own unique workspace register).
Also, if you use Stage or some other "modular" type program construct (e.g. subroutines) that contain ANY ECxxxx IBoxes, you MUST ENSURE that those Stages or Subroutines are ALWAYS ACTIVE and EXECUTING WHILE the IBox is enabled (i.e. until the IBox's Done bit or Error bit is set).
The ECOM100 IBoxes utilize a token passing mechanism. So the IBox logic must continue to execute until "complete" (either successfully or in error), at which time the IBox "gives up the token" (there are actually 2 tokens for ECxxxx IBoxes, but the principle is the same).
If a Stage that contains an ECxxxx IBox is JMPed out of BEFORE the IBox recognizes that it is "complete", the entire ECOM100 IBox mechanism will remain "stuck", waiting for this one IBox to "give up" its token, but since it is not executing, it never is "done", so it never "gives up" the token, so the other IBoxes remain "stuck" waiting.
-
I am bringing this one up from the way back because I am having similar probems. I have several locations that have a 260 PLC with ECWX boxes writing data to some 06 PLCs. The 06's are using ECWX boxes to write data to the 260. They may work great for months and then one of the ECWX boxes will stop. In the past I have (or I have had the customer) just power cycle the offending PLC and all will be OK.
This morning a PLC that I have remote access to had this problem. I and the customer had the time so I did some research and found this post. The PLC with the problem had two other ECWX boxes that were working. I monitored the workspace for each of ECWXs. Two were changing values and the one not working was showing a four digit number that I failed to write down. When I placed a zero in that memory location with data view it took off working again.
The H0ECOM100 have firmware 4.0.334 and the H2ECOM100 has firmware 4.0.1808
-
Please check all the items in the previous post and let us know what you see.
Also, make sure no other PLCs are *WXing to any of the workspace V addresses.
-
Make sure the ECOM100 Config IBox is at the TOP of the program and IS ALWAYS EXECUTED EVERY PLC SCAN.
The ECOM100 Config is not at the top. It and all of my ECWXs are located in an ISG stage that is always on. There was only one of the ECWX that quit.
All of the memory locations appear to be unique.
-
The ECOM100 Config is not at the top. It and all of my ECWXs are located in an ISG stage that is always on. There was only one of the ECWX that quit.
All of the memory locations appear to be unique.
That should be fine. Can you find out the hexadecimal value of your V Workspace register in the failing ECWX that quit.
-
Can you find out the hexadecimal value of your V Workspace register in the failing ECWX that quit.
V405 is the workspace. The value in it toggles between 0 and 1.
This problem is not unique to this ECWX. It has happened at different locations and on different ECWXs. They may work OK for months at a time.
-
Do your ECOM100's have the most recent firmware in them?
-
The H0ECOM100 have firmware 4.0.334 and the H2ECOM100 has firmware 4.0.1808
-
V405 is the workspace. The value in it toggles between 0 and 1.
This problem is not unique to this ECWX. It has happened at different locations and on different ECWXs. They may work OK for months at a time.
Let me know what this value is when it "hangs". It can validly have the following hexadecimal values:
0x0 - home (waiting to arm, waiting for power flow to go high)
0x1 - Armed, waiting for ECOM100 RX/WX Token (input leg has received power at some point in time, now waiting for some other EC* IBox to finish its low-level backplane comm with the ECOM100 module)
0x2 - Got the ECOM100 RX/WX Token, waiting for the slot's SP "Busy Bit" to go off
0x4 - SP "Busy Bit" is off and it's sending the native WX request to the ECOM100 module (so the SP slot busy bit should now be ON), waiting for the slot's SP "Busy Bit" to go off to be "done" (and go back to home state 0x0)
It can technically "hang" in state 0x2, but this would also hang up all the other ECWX IBoxes, not just this one. ???
Make sure all the EC* IBox workspace registers are in NON-retentive V range to ensure they all reset after power loss. ???