CP1E TXD RXD RS485 Send/Rcv Hex Values?

[Thor Hammer 0]

According to the instruction help file for a CP1E; data for TXD and RXD must be in UINT. However the device I am communicating with over RS485 in no protocol mode requires I send it a command string in Hex and Read back in Hex. I am a bit confused and could use some clarification on this. Can I send my data as UINT BCD or will the RS485 option port not recognize that data type? This project is a nightmare. The device I am communicating with is a Thermofisher chiller that has its own proprietary protocol. It states in the manual all data must be sent and received in HEX. Not ASCII. Would appreciate any insight.

[Sunbic 1]

Hex, decimal and ASCII are just ways to show the same data.. they represent the same bytes in different ways.

You can change the way you see memory channels in CX Programmer (hex, decimal) in the view tab. You will just be changing THE WAY you see the data, not the actual data.

UINT, INT, LONG or BOOL are the actual data. They are objects that occupy memory (bytes). Take a look at this https://www.manualslib.com/manual/346543/Omron-Cx-Programmer-V8-1.html?page=162

Note that UINT holds two bytes, as most data you will operate in your PLC.

To use UINTs, open up a D channel and write some number there or write a MOV instruction targetting a D channel, and there you have it (D channels are two byte).

To make a string you have to write data in consecutive channels. So if your device requires the following command:

Hello world!

Which occupies 12 bytes, in your PLC you will have to write six consecutive channels

D100 = #4865	//#48 H #65 e
D101 = #6C6C	//#6C l #6c l
D102 = #6F20    //#6F o #20 space
D103 = #776F	//#77 w #6F o
D104 = #726C	//#72 r #6F l
D105 = #6421	//#64 d #21 !

If you give the PLC all those channels to send over the port you will be sending 12 bytes, and the device will receive 12 bytes. If that's what it wants it will work.

I suggest you write data in hex format since in hex you can see the pairs of bytes (like the example), unlike decimal, which shows the sum of both bytes.

Edited 24 Feb 2017 by Sunbic

[Thor Hammer 0]

As of right now my data in consecutive D-Memory locations to send to the chiller over the RS485 line is UINT. So what you are saying is I should change the data type to Channel? Will that make a difference and if so, why? Just curious.

Thank you for clarifying and the table. I have that same table printed out on my desk.

 

 

[IO_Rack 181]

Changing the data type does not change the way the PLC will operate on it or transmit it.

I took a brief look at your manual again and it looks like it wants integers. If you want to send it a decimal 10, then monitoring in Decimal will look like &0010, monitoring in Hex will look like #000A.

One of their examples was setting the set point to 25.0. Decimal &0250, Hex #00FA.

I hope that doesn't confuse matters.

[Thor Hammer 0]

Not confusing at all. Thank you for the reply. I now completely understand the different data types and how they translate.

The attached code is what I last tried in an attempt to communicate with the Chiller. No luck. My boss said I needed to clear the buffer before transmitting my TXD so that's what I did.

When I send the TXD the reception complete flag never turns on. And the port ready flag A392.13 flashes repeatedly. Would anyone care to look at my logic and see if anything jumps out at you as being blatantly wrong? I only included the sections in question from my complete program.

I emailed Thermofisher and their lead tech said I do indeed need to send the zero's in the hex command string.

His email to me:

Hi Anthony,

 

Zero bytes (00) are required by the NC protocol.

In the example used below, a total of 8 bytes must be transmitted by the master for this command.

Master Sends: CC 00 01 F0 02 00 FA 12

 

All of the examples use bytes represented in hex as indicated by the letters (A,B,C,D,E and F).  No conversion is necessary.

 

The checksum is the last byte.  No additional end byte is required.  The chiller knows how long the command is based on the “n-bytes” that is transmitted with each command.

 

Best regards,

 

Scott

 

You can see that in my MOV instructions I have included the zero's where necessary. And in the above command after the F0 you see 02 This is the "n-bytes" field as there are 2 each. FA (00 which has no value but supposedly necessary in the command string) and the checksum value of 12. I assume that is correct.

 

In order for the checksum to calculate correctly I had to use the MOVD instruction and add up the bytes separately or it would not work. When I test my CS code using the example in the manual the result is correct. At least one thing works!

 

8262_PLC_V9 SVCS.cxp

[IO_Rack 181]

I believe I may have given you wrong information in your other thread concerning the Start Code and End Code. I apologize.

I believe the End Code is what the port is looking for from the receive in order to trigger the A392.14 flag. I would review the TXD/RXD instruction manual to be sure.

I'm not sure if it will make any difference but some of the examples I've seen use @TXD instead of TXD. Using the @ will execute the instruction for one PLC scan on the rising edge only.

[Sunbic 1]

I suggest you start a new program only targetting the data transmission, and hardcode a command and each instruction value and see first if the port is actually transmitting data, and if so if your device is interpreting it. The problem may or may not lie in your code, it's impossible to know without the hardware to test it.