adccommunitymod (AutomationDirect) asked a question.
Created Date: March 06,2007
Created By: jeremysji
**** This post has been imported from our legacy forum. Information in this post may be outdated and links contained in the post may no longer work.****
I'm trying to write a program that transfers data from one DL-06 to another using Ecom cards. Each PLC has an ecom card connected to a network switch with nothing else connected to it. I 've got some code that should work fine but it acts strange. When the code is used as posted below, the data from the first read shows up in the space alloted for the second read. Then the data from the second read is put into the space alloted for the third read. To finish things out, the data from the third read is put into the space for the first read. The odd part here is that it should run over into the second read but it doesn't. After a little while, this seems to break down and read 1 goes to the right place, read 2 dissappears, and read 3 is put in read 2's spot. To complicate matters further, if I remove any one of the RX commands, the remaining two network reads will straighten themselves out after a couple of cycles. The high timer value is so that I can watch what goes on from cycle to cycle. Normally this would be set to about 1 second so that the ecomms won't absolutely hammer the network. Anyone have an idea on getting this to work right? PLC 06 STRN C0 TMR T0 K100 STR T0 SET C0 STR C0 ANDE V2020 K0 ANDN SP126 LD K445 LD K24 LDA O3000 RX V3020 INC V2020 STR C0 ANDE V2020 K1 ANDN SP126 LD K445 LD K38 LDA O3014 RX V3034 INC V2020 STR C0 ANDE V2020 K2 ANDN SP126 LD K445 LD K100 LDA O10000 RX V3400 INC V2020 STR V2020 K3 RST C0 LD K0 OUT V2020 END
Created Date: March 06,2007
Created by: GKiser
I can see why it is getting confused. The RXs will not necessarily happen in a row due to asynchronicity of the ECOM communication.
The easiest solution for you is DirectSOFT v5.0 which has ECOM communication IBoxes (Intelligent Boxes) that will handle this kind of thing very easily for you.
Do you have DirectSOFT v5.0?
Best regards,
Greg Kiser
Host Engineering, Inc.
support@hosteng.com
(Case 861)
Created Date: March 06,2007
Created by: bcarlton
"asynchronicity "???
jeremysji's using V2020 as a sequencer through the calls. As he mentions - it looks like it should work fine. At least I don't see a problem. SP126 should prevent the next call until the previous is complete.
Created Date: March 06,2007
Created by: jeremysji
Originally posted by GKiser:
I can see why it is getting confused. The RXs will not necessarily happen in a row due to asynchronicity of the ECOM communication.
The easiest solution for you is DirectSOFT v5.0 which has ECOM communication IBoxes (Intelligent Boxes) that will handle this kind of thing very easily for you.
Do you have DirectSOFT v5.0?
Best regards,
Greg Kiser
Host Engineering, Inc.
support@hosteng.com
(Case 861)
Yes I 've got DS5, but the Iboxes take up so much room that I can't even get all of my ecoms in the program memory, much less all of the control logic that is associated with the data that I'm trying to get. That bit of code I posted represents 1 channel of a group of 12 with 3 possible groups.
I don't see the error in the synchronizer that would cause this. Like bcarlton said, the value in v2020 shouldn't get incremented until the last rx instruction has been fully processed (ANDN SP126) and the next has been called (INC V2020 comes after RX Vxxxx).
Xeno_deicici, your code looks pretty solid but I think it may get a little complicated with all of the conditional RX's that I need to do (not shown). I'll look into it more.
Thanks for the suggestions, I would be happy to just get this little snippet to work correctly at this point.
Created Date: March 06,2007
Created by: franji1
Do you have your master/slave element addresses set properly? i.e. the slave element addresses are in the RX instructions and the master addresses are in the LDA instructions?
Are any other PLCs on the network? Could there be other ECOMs w/the same Module IDs? Are you using TCP/IP protocol (setting up IP address table)?
Created Date: March 06,2007
Created by: jeremysji
I have checked, double checked, triple checked and had someone else look at it. All of the master/slave info is correct.
There are no other PLC's on the network. It consists of two DL-06s and an 8-port network switch. The Slave plc has an ecom100 with a module ID of 45 and the Master has an ecom with a module ID of 49 both are set via dip switches and verified in netedit. An IP address was assigned to each ecom so that I could program and view both them with my laptop (it doesn't play well with IPX...but that's another problem) one is 10.52.18.45, the other is 10.52.18.49
-Jeremy
Created Date: March 06,2007
Created by: marksji
Franji/Greg, I don't have any explanation for what's going on here, but I know the theory for the ECOM reads is sound because the basic structure has been used in many other projects without a problem. I 've looked at it several times, and can't figure out what is wrong, but something is most certainly wrong somewhere.
Created Date: March 06,2007
Created by: bcarlton
If possible, try the hookup with just a hub or even just a cross-over cable. The "module id " used broadcasts (I think) which may be confusing matters. if this makes a difference then try setting up the ECOM module-id to IP table. That way the transmission just uses the IP.
Created Date: March 06,2007
Created by: marksji
Its worth a try... I wouldn't think the broadcasts would be all that bad, but who knows...
Just an FYI since it came up. In an ECOM100 the peer-to-peer table actually maps to IP address, but in an ECOM it maps to MAC address (discovering that was a very painful learning experience).
Created Date: March 06,2007
Created by: jeremysji
Originally posted by bcarlton:
If possible, try the hookup with just a hub or even just a cross-over cable. The "module id " used broadcasts (I think) which may be confusing matters. if this makes a difference then try setting up the ECOM module-id to IP table. That way the transmission just uses the IP.
While the direct connection with a crossover cable would not work with the way we plan to implement this setup, it still didn't fix the problem. That leads me to believe that it's not network related.
While playing with the program, I added an extra read for no reason and everything works the way it's supposed to. Adding another Rx command (we 're up to 5 now) messes things up again. Is there something wrong with having 3(or 5 or 6 or 7 or 8 or....) network reads? Or is there something special about having exactly 4?
We 've got this set up on a test stand of sorts so if anyone has any ideas to fix this, let me know so we can give it a try.
Thanks for your time.
Created Date: March 06,2007
Created by: franji1
I hate to say this, but it sounds like the SP126 busy bit is not coming on IMMEDIATELY after executing the RX instruction???
Do me a favor, after each INC V2020, add
AND SP126
SET Cx
where x is C100 for the first, C101 for the 2nd, C102 for the third
and remove the "reset " logic (just stick an END before the last real rung)
ALL of them should turn ON. If you see every other one turning on, then that would explain why an "odd " number works.