Jump to content

arnaldodg

Members
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

0 Neutral

About arnaldodg

  • Rank
    Member
  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
  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
  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: 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
  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,
  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 = '192.168.1.210' port = '20256' socket =
×
×
  • Create New...