Jump to content

Documentation on Ethernet header

Recommended Posts

After reading about protocol to talk with a PLC (from the Communication with Unitronics PLC" on the Technical Library page), I tried sniffing the packets sent out by the download tool to the PLC. To my surprise, the payload had some extra information at the start of the messages.

In looking around at the Unitronics site, I've seen mention of an "Ethernet header" in several postings on this forum as well as on the archived forums. There's also mention of a document describing it, but the title mentioned in http://www.unitronics.com/forum/topic.asp?TOPIC_ID=2982, VisionCommunication, is nowhere to be found on the Unitronics technical library page.

I was able to use google to locate a document with a file mentioning "Ethernet header" at http://www.unitronics.com/data/uploads/%20utilities/VisionCommunication.pdf Is this document no longer current? If it is, why isn't it on the Technical Library page? If it's not current, what's the best place to find a definition for the "Ethernet header"?



Link to comment
Share on other sites

You can get the PCOM document thriough Support-> Downloads .. then scroll to the bottom of the page. You should see:

Unitronics PCOM Protocol

The link to the document is:


Then go to Appendix 3: PCOM via Ethernet

Bytes 0& 1: Transaction identifier.

This number is assigned by the user. The number is used by the PCOM master to identify which slave is

answering a command request.

Byte 2: Select Protocol.

Identifies the protocol used for the command request. Enter:

101 (DEC) for ASCCI

102 (DEC) for Binary

Byte 3: Reserved. Leave blank.

Bytes 4&5: Length of transaction.

Enter the number of bytes required for the command request.

Link to comment
Share on other sites

You can get the PCOM document thriough Support-> Downloads .. then scroll to the bottom of the page. You should see:

Unitronics PCOM Protocol

Thanks. Perhaps for the next person looking for it, a link from the Technical Library could be added (and the obsolete documents removed).

Link to comment
Share on other sites

  • 4 months later...

Hello, jhfrontz. Hi, Saragani.


I am facing the same issue with the documentation.

Actually the Unitronics PCOM Protocol PDF available is outdated and probably incomplete.

There is no Appendix 3 at all. And the link provided by Saragani os broken: 404!


I have been struggling the last 2 days (and nites =\) to find out why I can get a response from my V130 testbed.

No success at all.


I wrote a piece of test code in Ruby, based on #1767 and #1851, that does not work.

As you can see, there must be something missing:

require 'socket'

host = ''
port = '20256'

socket = TCPSocket.new(host, port)
stx = 47 # '/'
cmd = "10RB002005"
etx = 13 # "\r"

array = cmd.bytes
checksum = array.inject(0) {|sum, i| sum + i}
checksum = checksum.modulo(256)
crc = checksum.to_s(16)
crc_1 = crc[0, 1].to_i(16)
crc_2 = crc[1, 1].to_i(16)
crc_array = [crc_1, crc_2]
header = [0, 0, # msg id
  	101, 0,   # protocol = ASCii
  	14, 0]	  # Payload -> msg size + CRC (2)
puts "Checksum is: #{ crc }"
cmd_array = [stx].concat(array).concat(crc_array).concat([etx])
msg = header.concat(cmd_array)
print "Send CMD: #{ msg }"
socket.send msg, msg.size

print "Waiting for response..."
while line = socket.readpartial(2)
  puts line

So I ask: where can one find consistent and complete information about the PCOM TCP ASCii structures and methods?

Why there is not even a pseudo-code example of how to "assemble" the protocol message buffer?


If I learn how to do this I should be sharing it here right away!

Please, Saragani, help us make it happen.





Link to comment
Share on other sites

Hi, Saragani.


Thank you very much for the link. This document is much better about the header information.


Anyhow, I must be a dumb stone... experimenting the updated "format" with my small Ruby script did not do the trick.

Here is the array I produced to send usung Ruby: 

> Send CMD[size:20]: [210, 4, 101, 0, 14, 0, 47, 49, 48, 82, 69, 48, 48, 50, 48, 48, 53, 49, 70, 13]


This refers to the command string '/10RE0020051F\r', which returns CRC = 1F (49, 70 byte values at the end of message, just before CR, byte 13). The header was added at the begining with values [210, 4, 101, 0, 14, 0] as you can see above.


So, my questions are:


1> The docs says the header is "binary"; here I understand it is BYTE coded numbers - makes sense?

2> The command string is "char", or may I say, ASCII BYTE coded chars, so '/' becomes 47, <CR> becomes 13 and so on - right?


So if I get an byte array with the above values sent to the PLC (which is TCP socket connected for sure), how come it is not responding the request?


If you could shed some guru light over this issues... =]


Best regards,



Link to comment
Share on other sites

Hi, Saragani.


Bringing more info on the subject: jujst tested the packets with a sniffer.

Changed to a shorted command /10RC

Got: d2 04 65 00 08 00 2f 31 30 52 43 46 36 0d        ..e.../10RCF6.

The '.' (dots) do represent unprintable chars but we can read the HEX with success (last char is 0d -> 13).


This means message was sent good. But got no reply from PLC at all =|


This is the "reply" packet from the PLC: TCP 60 20256 > 55548 [ACK] Seq=1 Ack=15 Win=2048 Len=0 <<<- See. No content, just an ACK.


I think we are almost there... Any clues?





Link to comment
Share on other sites

Marvelous, Saragani!


Indeed the PLC ID was wrong. And it is very wrong; weird!

Actually the PLC only responds if I use ID=01. Even if I "set" it to ID 05 or 10, it does not respond to the commands.

I believe there must be a problem with my programming inside the "beast" that is not actually setting the ID =]


But anyhow, you gave me the best clues and a solution as now I can finally query th PLC.

Thank you very much!


By the way, is there an ASCII command to get the PLC info (model, ver, etc)?

I couldn't find it in the last hours.


Best regards,



Link to comment
Share on other sites

Yes and no...

The Command is "ID", but the string it returns must be parsed, and each time a new model is released, the code that parses it must be updated (The retuned string contains 4-6 letters that represents the Model + some more letters and numbers that represents the OS, BinLin, and Boot versions.

We are doing a Swtich Case on the 4-6 Letters in order to know which PLC it is).

(It is actually a little smarter that Switch case. There are 3 patterns, and an XML that contains the replies, so the code itself is not changed, only the XML).


You can inspect/user the code of the .Net communication driver that parses the reply.

Link to comment
Share on other sites

  • 1 year later...

I am working of Ethernet my v570 plc is connected to one PC address through port 0 port 1 and port 2 via listening mode. now my problem is that when PLC open the 2 port at time the PC get confused it stop to working. my working is that once PLC is open the port the PC is close the port. My questions is that the conflate we are facing is either PLC side or at PC side. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...