Unable to Recieve data from RS485 in protocol macros

[T J SHARON 3]

HI all, 

 I was trying to connect my compass with PLC via SCU32 RS485 (2 wire ) in protocol macros.[ Unit 1 port2]

 My send command is   " 01 03 00 01 00 03 54 0B'  &  Expected reply is '01 03 06 XX XX YY YY ZZ ZZ ZZ ZZ"

I created a new protocol using CX protocol and created  a send message & a receive message command  and added to sequence 000. (refer pics)

Also added PMCR instrcution in cx programmer (refer pic).

I can transmit the data , but i cant see any recieve data in D2000.

I am not sure what had done wrong, or am i missing something?

 

Any help is much appreciated!!

compass_macro2.psw

Compass_TEST.cxp

[DanW 38]

It uses the Modbus RTU 'read Holding register' message format, so the stuff that creates a 'can't connect' Modbus RTU situation applies.

Here's my list, if it doesn't apply, like the multidrop items, skip it.

Modbus RTU over RS-485 'can't connect' issues:

- do both ends have Modbus installed and enabled ? (Modbus frequently an option)  RS-485 is NOT Modbus, it is a hardware bus.
- Right protocol?  RTU or ASCII protocol being used? - neither is compatible with the other
- is slave field device powered, connected and on-line?
- Correct pin-out for RS-485 on an RJ-45 or DB-9 connector, or any non-screw terminal connector?
- DB9 gender changer adapter is a null modem adapter
- DB9 shell is grounded, common mode pulls down the network
- RJ11/12/DB9 adapter wiring is faulty, wrong, missing
- RS-485 cabling connected and integral for entire run?
- use of non-shielded, non-twisted pair cable
- serial settings identical on both ends? RTU uses 8 bit data word, 1 start bit, 1 stop bit, parity?  2 stop bits can be a no-go;  ASCII 7 bit data word
- has the power been cycled after serial comm settings were configured to force the recognition of the changes?
- RS-485 A/B driver lines backwards.  Even though should be (+) to (+), (-) to (-), labeling is not consistent vendor to vendor.  Try swapping the A/B driver lines.
- serial port powered 232/485 adapters on laptops frequently fail to operate if not powered by external supply because laptop serial ports limit power to the serial port to conserver laptop battery power
- Using the wrong COM port - USB/485 converter installed on virtual COM port - check Windows' Device Manager > ports
- RS-485 signal ground is case ground - excessive common mode swamps the RS-485 signal.  Solution - RS-485 isolator/repeater module
- lack of 3rd wire signal ground causes common mode fault
- older 485 signal driver can not handle the number of multidrop nodes
- more recent vintage USB-485 converters do NOT jumper Tx(-) to Rx(-), Tx(+) to Rx(+), check wiring
- 232-485 converter DIP switch settings for serial or soldered resistor for intercharacter delay
- faulted driver is locking up the network - one device can pull down an entire multidrop network
- two or more masters on an RS-485 network will fail - PDU collisions
- master time-out set to infinity - lack of comm to one faulted slave on a multidrop locks master into infinite wait for something is going to happen
- bus wiring issues - junction box misconnection, JB flooded, shield continuity broken at JB, stranded wire whisker shorts
- cabling run exceeds the capability of RS-485 for distance vs baud rate.   The 1200m max spec does not apply to baud rates > 90k.
- stub wiring at multidrop nodes causing reflections which create 'noise', false data bits.
- Added biasing resistors load the drivers
- terminating resistor somewhere other than the 485 bus end nodes
- attempted full duplex operation for a protocol that is by design, a half duplex protocol
- addressing the wrong slave, getting someone else's reply, or no reply if there is no slave at that address
- slave node ID can NOT be 00.  Master uses 00 to broadcast a message to which a slave is not to reply
- electrical noise on the data lines causes fake start bits, continuous errors, real data never gets through  

 

[T J SHARON 3]

thanks

[T J SHARON 3]

hi Dan & team,

 

So can I use MODBUS-RTU for SCU and General purpose device communication ? 

Does it work if i follow the following ways?

1. connect device to SCU
2. Change SCU setting (MODBUS, baudrate , parity, etc).
3. Use CMND instruction  in ladder.

Thanks in advance.

[DanW 38]

The format shown in the 5th screen shot (2.4) is a Modbus RTU query and response, so I would expect that reading the three values can be accomplished with a Modbus instruction.   The advantage of using a commercial Modbus firmware/routine is that the nitty gritty of stuff like calculating the CRC already done for you.   In fact the following screen shot mentions Modbus.   The data field in the answer is not correct.   It says 3 bytes, but shows 6 bytes (3 registers).   The Modbus Function Code 06 is normally a "write single 16 bit register", so you'd have to write each register value one at a time with separate 'transactions'. 

I suspect it'll work, however, I have zero experience with either master or slave.

[T J SHARON 3]

Hi dan, 

 

Thanks a lot. Let me try again!!

[T J SHARON 3]

hi Dan , 

"The Modbus Function Code 06 is normally a "write single 16 bit register", so you'd have to write each register value one at a time with separate 'transactions'.  " 

How can i write it in each registers ? Should i write my protocol  as " <a>+[0306]+&(W(1),2)+&(W(1+2),2)+&(W(1+4),2)+W(1+6),2 ' , which is (01 03 06 XXXX YYYY ZZZZ CRC)

[T J SHARON 3]

Hi all, 

I managed to wrote the response data strings to data memory.

What i did was ,I changed the send and receive message data bit from 'variable Hex' to 'variable' in the CX Protocol file. 

Now its working. I tried different combinations of send and receive messages. All worked well . ( refer to the attached pics).

compass_macro2.psw

Compass_PMCR_WORKING.cxp

[DanW 38]

Thanks for the update.