
adccommunitymod (AutomationDirect) asked a question.
Created Date: August 17,2006
Created By: marksji
**** 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 was helping one of our guys troubleshoot communications between two PLCs last night and we found something we can't explain. From his notebook using NetEdit to look at the two ECOM cards (one H2-ECOM in a 9-slot with a 250-1 CPU and one H0-ECOM100 in slot-4 of a DL06) he was able to see both, but only able to successfully test CPU access on the card in the 205 base. Every time he tested CPU access on the card in the DL06 he got an error message ( "hmm, here's some things to try... "). He observed this behaviour using both IPX and TCP/IP. He was able to communicate with both PLCs via the Ethernet connection using DirectSoft in either IPX or UDP/IP mode. We found the problem (unrelated to this) and everything is now working, but I'm curious why NetEdit couldn't test CPU access on the DL06 (still doesn't work, even though everything is now functional with our products). I use that as a quick test of the network and PLC frequently and it worries me a bit that this simple test failed, yet everything works perfectly. Ideas anyone?
Created Date: August 18,2006
Created by: CroCop
I 've had this happen once. I grabbed an IP address, and someone else assigned the same address on the network. The NetEdit wouldn't/couldn't get to the CPU. Soon as I downloaded Look@Lan, and realized I had a conflicting address, I got it changed, and was good to go.
Created Date: August 18,2006
Created by: marksji
I doubt this was the problem in this case... the network was a 5 port switch, 2 PLCs, a 10 " C-More, and his notebook, we made sure we didn't have a conflict several times, but still could never test CPU access on the DL06... DS worked fine and so did PLC-PLC communication once we got the H2-ECOM in the correct slot in the 205 base.
Created Date: August 21,2006
Created by: GKiser
marksji,
Did your PC have 2 NICs? Most laptops have 2 NICs, one of them is wireless. You may have to disable the wireless NIC and then try again. The ECOM doesn't care about things like subnet mask and gateway address, but the ECOM100 does. The reason is that the ECOM100 supports TCP/IP as a client and has a "full-blown " TCP/IP stack.
Greg Kiser
Host Engineering, Inc.
support@hosteng.com
Created Date: August 21,2006
Created by: marksji
Yes the notebook has 2 NICs (wireless & wired), and we had the wireless NIC disabled; even tried rebooting after disabling.
Created Date: September 08,2006
Created by: GKiser
marksji,
We cannot duplicate this behavior, however, we made some changes to NetEdit and we are testing it. However, if you would like a copy to try (it is beta software) then I can send it to you. Just send me an e-mail at support@hosteng.com.
Greg Kiser
Host Engineering, Inc.
support@hosteng.com
Created Date: September 08,2006
Created by: Kristjan H
And you are sure you are running the latest PLC firmware? I got this "hmmm... " message upon trying the CPU access with NetEdit on a DL05 the other day. The firmware upgrade cleared the error.
Created Date: September 08,2006
Created by: marksji
We did not think to check the PLC firmware, just the ECOM firmware.
We haven't had this problem again, but it made me wonder... Greg I'll send you an email.
Created Date: August 17,2006
Created by: marksji
I was helping one of our guys troubleshoot communications between two PLCs last night and we found something we can't explain.
From his notebook using NetEdit to look at the two ECOM cards (one H2-ECOM in a 9-slot with a 250-1 CPU and one H0-ECOM100 in slot-4 of a DL06) he was able to see both, but only able to successfully test CPU access on the card in the 205 base. Every time he tested CPU access on the card in the DL06 he got an error message ( "hmm, here's some things to try... "). He observed this behaviour using both IPX and TCP/IP. He was able to communicate with both PLCs via the Ethernet connection using DirectSoft in either IPX or UDP/IP mode.
We found the problem (unrelated to this) and everything is now working, but I'm curious why NetEdit couldn't test CPU access on the DL06 (still doesn't work, even though everything is now functional with our products). I use that as a quick test of the network and PLC frequently and it worries me a bit that this simple test failed, yet everything works perfectly.
Ideas anyone?