Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About arnaldodg

  • Rank
  1. Thanks once again, Saragani. I am reading and learning from the provided guide right now. Seems it will do all the magic I need. Cheers, AD
  2. Dear, Saragani. Folks, hope you doing good. After having success on reading functions (Ints/Longs, DWs, etc), I am trying to write to the PLC. I couldn't find examples about writing on the docs. Where should the data to be written go? When writing DTs we put it after the 32nd details byte... but when writing MIs MLs etc, where should this data go? And what about endianess? LO/HI as usual? Best wishes, AD
  3. Hi there, folks. Dear Saragani. I am very happy about learning from you. My tests are doing quite good and I can read operands from the V130. Now I am facing the last wall (or pit) to get things done: Data Tables. Let me show you what works now for PComB: @header = [ 47, 95, 79, 80, 76, 67, # / _ O P L C 0, # CANbus ID = 0 254, # reserved FE 1, # reserved 01 0, # Msg Key, usually ZERO 0, # 0 0, # 0 77, # Command Code (byte 12) -> Read Operands 0, # SubCmd, usually ZERO 0, 0, 0, 0, #[14..17] 4 byte Addr 1, 0, # Num of Groups: 2 byte Element Count (LSB/MSB) 6, 0 # Data Length in Detail Section (LSB/MSB) bytes 20 n 21 ] @details = [ 1, 0, # num operands (LSB/MSB) 1, # Oper Type -> 1 read addr; 129 read vector len(??) 255, # reserved 0xFF 1, 0 # Addr (Low/Hi) ] These are the header and details structure as you explained. It works. The docs says I should replace 77 in the header with 04 to read DTs. And then the Details "record" woudl change to a fixed 32 bytes structure: bytes 0-1 Num Bytes from each row bytes 2-3 Num Rows to read from DT bytes 4-7 Num bytes in entire row of DT bytes 8-31 Reserved as 0s And additionally I should set the address of the 1st element to read in the Header, bytes 14-17, lsb to msb. This should get readings from DTs. Do you confirm this instructions? Best regards, AD
  4. Very nice, Saragani. Thank you once again. Together with other posts this essay put a check on bin requests. Here I leave a remark/note for others: remember the "msg header" stating msg ID, protocol type and "payload" size of the request. This is the 6 bytes "preamble" for both request types (ASC/BIN) depicted in the appendix of PCOM docs (link in this thread). Cheers, AD
  5. Hi, folks. After playing a lot with the PCOM ASCii requests with success I am trying to make binary requests. Here I faced some problems and doubts on the documentation: 1> Example 1 (MI request) states the following values: Header: [0..5] 2F 5F 4F 50 4C 43 -> /_OPLC [06] 00 -> Dest Addr [07] FE -> Reserved [08] 01 -> Reserved [09] 01 -> Docs says it should be 00 but examples values shows 01 !!! [10..11] 00 00 -> should be all 0s from 09..11 altogether [12] 4D -> 77 decimal "commmand code" [13..19] 00 00 00 00 00 01 00 -> Num of Groups; here I did not understand why the last byte is 00 if the count is 01. Is the byte order reversed in pairs? [20..21] 06 00 -> Data Length also use reversed byte order for "integer"? [22..23] F0 FC -> CRC; any specific byte order? Details: here I found something missing... 00 01 -> num bytes to be read ?? -> missing param FF -> reserved 255 01 00 -> 1st address; reversed byte order? Footer: FE FE -> CRC 5C -> "\" So my question is: despite the missing param in the example (Details[2] -> Oper Type), is there a byte order for addresses and the CRC? Thanks in advance. AD
  6. Hi, Saragani. Sorry for my late reply. Thank you for the valuable information. I am checking the source coude as instructed. Best whishes, AD
  7. 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
  8. 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? Cheers, AD
  9. 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
  10. 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 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
  • Create New...