Host Engineering Forum

General Category => ECOMs and ECOM100s => Topic started by: gemini1364 on March 31, 2015, 03:52:08 PM

Title: H2 ECOM100 Port problem
Post by: gemini1364 on March 31, 2015, 03:52:08 PM

Hi,
I have a PLC program that I wrote that sends data to a Labview program running in a PC.  If I use port 7777 in the PLC and have my Labview program set to read that port, everything is fine.  If I change the port to any other number and make the change accordingly in the PC, the data doesn't get through. Is there something that I am overlooking?  Is there a way to see if a certain port is able to do this besides 7777?  I don't have access to router settings, etc. as this would require IT.

Thanks for any assistance!

Todd

Title: Re: H2 ECOM100 Port problem
Post by: Greg on March 31, 2015, 04:57:40 PM

If you could post a Wireshark file here, or attach a Wireshark file to an email and send it to me (support@hosteng.com), we should be able to see what is happening. I assume you are using RBE (Report-By-Exception) and UDP in the H2-ECOM100 to send data and you are just changing the "Socket Number" in the V-memory header, yes?

BTW, Wireshark is a free Ethernet sniffer that you can download from the web.

Title: Re: H2 ECOM100 Port problem
Post by: Greg on April 01, 2015, 02:38:06 PM

For those reading... gemini1364 sent me a Wireshark trace file. The trace showed telegrams coming from an ECOM module over UDP to port #0x7777 but no response coming from the PC. Since 0x7777 is the port that was working before, this probably means:

1. The header was not changed to 0x7777 and his PC is listening to some other port, or...
2. The PC is not responding with the required ACK as requested in the telegram from the ECOM (as configured in the RBE header)

Title: Re: H2 ECOM100 Port problem
Post by: Greg on April 02, 2015, 07:08:14 PM

For those reading... gemini1364 got it working.

The actual problem is in the RBE documentation example using UDP protocol, V2015 contains the Socket Number. The example shows 0x7777 which, of course, worked. gemini1364 was attempting to use 0x7776, but what Wireshark showed was that the actual UDP telegram being generated was with a Socket Number of 0x7677; the bytes were swapped.

Thus I added a note to the RBE documentation that when using UDP protocol V2015's value is a byte-swapped value and must be set accordingly.