Binary Data over Ethernet

[abradford]

Hi,

I'm transmitting data from my controller to a PC using the built-in ethernet module on the F2424.

I've got it connecting and mostly working.  When I run the custom function, no binary data comes through on the PC.

e.g. (on the controller):
OUTCOMM 4, 65
PRINT# 4, "hello"

The data I receive on the PC doesn't include the binary data.  All I see on the PC is "hello" when what I should see is "Ahello".  (65 is the ASCII value for 'A').

Any help is appreciated,
Andrew

[support]

What is the server program that is running on the PC? Is it the TLServer or some other server program? Can you show the content of custom function that you wrote to communicate with the PC so that we can run a similar test.

[abradford]

The PC is running a custom server program that I developed.  I've also tested the issue using netcat, a program similar to telnet but capable of acting as a server, with the same result.

The code on the controller is this:
PRINT# 4 "<TCPCONNECT 192.168.1.101:53463>"

PRINT# 4 "testing"

OUTCOMM 4, 0
OUTCOMM 4, 0
OUTCOMM 4, 0
OUTCOMM 4, 5
PRINT# 4 "hello";

What I'm doing here is sending a 4-byte integer before each message so that the receiving program knows the length of the message.  The documentation for OUTCOMM says only 8 bits are sent for each call.

[support]

Usually when you develop an ASCII code based protocol the length would be encoded in ASCII code as well. I would imagine you should be sending something like:

 PRINT $4 HEX$(5,4);"Hello"

If you send binary 0,0,0,5 then the 5 is unprintable.

Anyway, we will submit to the product development folks to run some test to check what happen when you send OUTCOMM 4 followed by PRINT #4. Will report back in a few days time,

[abradford]

Yes, I considered using a fixed-width ASCII length for the protocol, but I am also sending a large sensor log dump as well.  I can fit a much higher number (longer messages) in a 4-byte integer than in 4 ASCII characters.

Thank you for your help
Andrew

[support]

According to R&D, F-series PLC did not implement INCOMM(4) and OUTCOMM 4 function for sending binary data via Ethernet port. Only PRINT #4 and INPUT$(4) are implemented. It is possible to send both printable and non-printable ASCII data (except binary zero) using PRINT #4 since you can encode the non-zero data using the escape code e.g \0B\AC  or use the CHR$(n) function.

I checked the F-series PLC User's Manual and did not find any reference examples using OUTCOMM 4 or INCOMM(4) commands. Only PRINT #4 and INPUT$(4) are mentioned in the manual. If you do find any references to OUTCOMM 4 and INCOMM(4) that would be a misprint and please let us know so that we could fix the error in the manual for future release.  

For your project we suggest you encode your data using ASCII string to represent numbers and at your server you can then convert the ASCII string into binary form for final processing. Since TCP/IP communication carries quite a lot of overhead in the headers and Mac address, the use of ASCII string to represent numbers would not penalize the communication speed significantly.

[abradford]

Ok, thanks for looking into this for me.

In my copy of the F2424 User Manual, section 14.6, it mentions INCOMM, INPUT, PRINT, and OUTCOMM as methods of sending/receiving data through COMM ports.  It makes no mention that INCOMM and OUTCOMM don't work for COMM4.

[support]

Thank you for your feedback. We should edit the manual for future release that would emphasize that the INCOMM and OUTCOMM would not work on COMM 4.

We refer to COMM port 1,2,3  as the serial port on the PLC. COMM 4 is not a serial port but in order to avoid inventing new commands which essentially does similar thing, the pseudo port #4 is assigned to Ethernet port after a connection has been established with a remote server. PRINT #4 and INPUT$(4) can be used to communicate with the server. INCOMM and OUTCOMM however were not implemented on this pseudo COMM port because unlike serial port which are sent one byte at a time, the ethernet data are sent in packets. To implement the INCOMM and OUTCOMM on COMM4 would require some sophisticated algorithm to assemble the individual bytes to both an optimum packet and also to send them out in timely manner. My guess is that these are not implemented unless there are many application needs that demand such capability.

The <TCPconnect> capability is added for the PLC users to do simple TCP/IP communication easily (such as connecting to a time server) without the need to learn any TCP/IP programming in lower level language. It is not meant for very sophisticated TCP/IP programming that would be better handled by controller programmed using C and run under an RTOS.