jhfrontz Posted April 17, 2013 Report Share Posted April 17, 2013 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"? Thanks, Jeff Link to comment Share on other sites More sharing options...
Saragani Posted April 18, 2013 Report Share Posted April 18, 2013 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: http://www.unitronics.com/Data/Uploads/communication/Unitronics%20PCOM%20Protocol.pdf 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 More sharing options...
jhfrontz Posted April 18, 2013 Author Report Share Posted April 18, 2013 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 More sharing options...
arnaldodg Posted August 27, 2013 Report Share Posted August 27, 2013 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 = '192.168.1.210' 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 end socket.close 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. Cheers, AD Link to comment Share on other sites More sharing options...
Saragani Posted August 27, 2013 Report Share Posted August 27, 2013 Hi, thank you. The document on the website looks like a newer version that somehow had the Ethernet section removed. There is an older version of the document. Unitronics PCOM Protocol.pdf Link to comment Share on other sites More sharing options...
arnaldodg Posted August 27, 2013 Report Share Posted August 27, 2013 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, AD Link to comment Share on other sites More sharing options...
arnaldodg Posted August 27, 2013 Report Share Posted August 27, 2013 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: 192.168.1.210 192.168.1.213 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? Cheers, AD Link to comment Share on other sites More sharing options...
Saragani Posted August 28, 2013 Report Share Posted August 28, 2013 Both messages looks OK (I've checked the header and the checksum), so it makes me wonder: Does your PLC has Unit ID of 16? 10RB002005 10RC Try using Unit ID 0 (which means direct connect). Link to comment Share on other sites More sharing options...
arnaldodg Posted August 28, 2013 Report Share Posted August 28, 2013 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, AD Link to comment Share on other sites More sharing options...
Saragani Posted August 28, 2013 Report Share Posted August 28, 2013 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 More sharing options...
arnaldodg Posted August 30, 2013 Report Share Posted August 30, 2013 Hi, Saragani. Sorry for my late reply. Thank you for the valuable information. I am checking the source coude as instructed. Best whishes, AD Link to comment Share on other sites More sharing options...
mavitrols Posted January 27, 2015 Report Share Posted January 27, 2015 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 More sharing options...
Saragani Posted February 2, 2015 Report Share Posted February 2, 2015 I would guess that it is a PC side problem. I never seen your code, so I'm only guessing. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now