Binary Request Bytes and CRC

[arnaldodg]

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

[Saragani]

It appears that there are some problems with the documents.

Byte 9 should be 0 (The document I've attached in the other post shows the example with the correct value).

 

Furthermore, the number of groups does not start from index 13, but from 18.

Byte 13 to 17 should be 0

So bytes 18-19 have the number of groups, meaning 01 00 (so you can see, the bytes order is not reversed... The lower byte is 01 and the higher is 00).

Data Length on bytes 20 and 21: 06 00 (again not revered, lowe byte is 06).

 

Checksum has the same order as all the other numbers.

 

 

 

Lets do the small example of reading MB1 as suggested in the documented example:

 

[0] 47 byte     /

[1] 95 byte     _

[2] 79 byte     O

[3] 80 byte     P

[4] 76 byte     L

[5] 67 byte     C

[6] 0 byte     CANbus ID = 0

[7] 254 byte     254 (Reserved)

[8] 1 byte     1 (Reserved)

[9] 0 byte     0 (Reserved)

[10] 0 byte     0

[11] 0 byte     0

[12] 77 byte     Command Number (77 = Read Operands)

[13] 0 byte     0

[14] 0 byte     0

[15] 0 byte     0

[16] 0 byte     0

[17] 0 byte     0

[18] 1 byte     Number of Groups (low)

[19] 0 byte     Number of Groups (high)

[20] 6 byte     Number of Details bytes (low)  We have 6 bytes

[21] 0 byte     Number of Details bytes (high)

[22] 241 byte     0xF1 (Header Checksum low byte)

[23] 252 byte     0xFC (Header Checksum high byte)

[24] 1 byte     Number of Operands (low)

[25] 0 byte     Number of Operands (high)

[26] 129 byte     1 + 128 *See note

[27] 255 byte     0xFF (Reserved)

[28] 1 byte     Address (low)

[29] 0 byte     Address (high)

[30] 126 byte     0x7E Details Checksum (low)

[31] 254 byte    0xFE Details Checksum (high)

[32] 92 byte     0x5C (ETX)

 

 

 

 

* Note: As documented... The default method of "addressing" is the explicit method. To indicate the 

implicit (continuous) method in the query, add 128 (80 hex) to the operand type. 

(it is strongly recommended to see the detailed example at the end of this 

section).

 

I have requested to read 1 MB starting address 1. It is a vector of size 1, meaning I could also use Operand Type = 1 (and not 129) and the Checksum would be FE FE

 

 

 

 

The Example above works. The bytes stream was taken directory from the communication driver.

[arnaldodg]

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

[arnaldodg]

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

[Saragani]

Yes:

0 - 1 Number of bytes that you want to read in a single row (for example, Row size is 120 bytes, but you want to read columns 4,5 which are 8 bytes, so this number would be 8)

2 - 3 Number of rows to read

4 - 7 Number of bytes in row (this number would be 120)

24 more spare bytes (so you get a total of 32 bytes)

 

 

You are right that the address is located on bytes 14-17 of the header

 

Please note that if the size if the data you want to read (Num Of bytes to read in row * num of rows) or write is greater than the chunk size of the PLC (about 960 in the V1210, V1040, V570 and the other enhanced PLCs), you will need to split it to several requests, so each of them will fit.

[arnaldodg]

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

[Saragani]

Hi, Binary Command 77 is for reading only.

For writing operands, you can either use ASCII protocol or use Binary Command 80

About endianess, it is the usual.

 

 

About PCOM 80, read here:

http://forum.unitronics.com/index.php?/topic/2130-binary-write/

[arnaldodg]

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