help with scale and rs485

[jbliss15]

Hey,

i'm a software engineer, and getting started in PLC programming with phoenix contact / plcnext

i don't know a lot about the wiring aspect of the PLC world.

i'm trying to test out a scale serial communication, its easy with a rs232 to USB adapter, but this project its not possible to connect via usb.

i have a scale with rs232 output, a rs485 converter, and a plcnext rs485 smart module

can someone help me with the wiring and if you know the plc next engineer steps to receive the weight via rs485

i've done other projects with plcnext controls, so i know a bit about getting the modules configured and all that. this is the first time i've had to use serial communication.

there isn't a lot to google with plcnext because its still fairly new and there isn't a lot of content.

scale -> rs232 -> rs485 -> plc

i think the wiring is hooked up right but just to confirm if someone knows for sure. its tx+ tx- rx+ rx-

johnny

 

[jbliss15]

 

[cardosocea]

Without knowing the make of modules you're using, it's pretty impossible.

 

[drbitboy]

Without knowing the make of modules you're using, it's pretty impossible.

+1


It sounds like the scale is RS232, and there is an RS485 interface on the PLCNEXT.

What I would do is approach it incrementally: use the USB-RS232 cable to connect the PC (Windows or Linux) to the DLTECH RS232 side (DB9?) and the DLtech RS485 side to the PLCNEXT, and see if you can send any characters (e.g. the query string for the scale, or even just "ABC") from the PLCNEXT and read it on the PC. E.g.

% python

>>> import serial

>>> ser=serial.Serial('/dev/ttyUSB1')

>>> while True: b=ser.read(1); print(('{0:02x} {0:03d}'.format(ord(b.decode(encoding='8859'))),b,))

​

Then you can swap around the pinouts, wiring, baud rate, data bits, stop bits, parity, etc., until it works.




...

 

[jbliss15]

hey all thanks for the help i appreciate the forum not being dead like a lot of them. especially the PLCNEXT forum. totally dead / buggy / worthless

here is the smart module
https://www.phoenixcontact.com/onli...=pien&pcck=P-21-13&tab=1&selectedCategory=ALL

i have a teams meeting with someone from phoenix contact in 10mins.

i will post here how to get it working for someone in the future.

 

[jbliss15]

+1


It sounds like the scale is RS232, and there is an RS485 interface on the PLCNEXT.

What I would do is approach it incrementally: use the USB-RS232 cable to connect the PC (Windows or Linux) to the DLTECH RS232 side (DB9?) and the DLtech RS485 side to the PLCNEXT, and see if you can send any characters (e.g. the query string for the scale, or even just "ABC") from the PLCNEXT and read it on the PC. E.g.

% python

>>> import serial

>>> ser=serial.Serial('/dev/ttyUSB1')

>>> while True: b=ser.read(1); print(('{0:02x} {0:03d}'.format(ord(b.decode(encoding='8859'))),b,))

​

Then you can swap around the pinouts, wiring, baud rate, data bits, stop bits, parity, etc., until it works.




...

thanks for reminding me i need to send Q\r\n to this scale to get the weight back. i totally forgot about that.

its been a while since i did any serial comm with scales

 

[drbitboy]

Btw, those images don't display any more. I suggest uploading them (use the advanced interface for making a new post, and look for the paper clip icon to upload files).

 

[drbitboy]

I would guess you need summat like Figure 3 in the data sheet, available under [Downloads] here., and the figure in the DLtech manual here, so

• DT-9xxx [1 T/R+] is wired to AXL [1 RxD+,TxD+],
• DT-9xxx [2 T/R-] is wired to AXL [3 RxD-,TxD-]
• You might* need termination resistors (120Ω)
  • AXL [6 R+] to AXL [0 T/R+]
  • AXL [7 R-] to AXL [2 T/R-]

* I have gotten away without termination, but that was usually point-to-point on the bench; I found serial comms to be fairly forgiving in a testing environment; once I ginned up a DB gender change using paper clips.

 

[jbliss15]

well i got it communicating at least sending data, it never fills the receive buffer

 

[drbitboy]

...it never fills the receive buffer

Do you mean you never see anything sent back from the scale to the PLC?

 

[jbliss15]

yeah it never fills the buffer before i try to read it.

nothing is ever there.

i need to send Q\r\n to the scale, and it will return the weight.

when i edit the var senddata[0] = 81, [1] = 13, [2] = 10 into the bytes that are supposed to be sent.

when i look at the output of the code module. its sending:

output[0] is bouncing back and forth between 70 and 30
[1] = 00
[2] = 03
[3] = 81
[4] = 13
[5] = 10

in plcnext engineer the values show as 16#81, 16#13, 16#10 etc...

i don't think im sending the right bytes to get a reading back

but i've also tried the scale in streaming mode where it should constantly be sending a value back. but nothing happens

 

[drbitboy]

Can you get it to send data back to the PC (Linux /dev/ttyUSBn or Windows COMn)?


What are those first two bytes (00 and 03)? Are they being sent to the scale? Is that the length of the reset of the string (Q\r\n)? I don't think that should be sent.

 

[jbliss15]

Can you get it to send data back to the PC (Linux /dev/ttyUSBn or Windows COMn)?


What are those first two bytes (00 and 03)? Are they being sent to the scale? Is that the length of the reset of the string (Q\r\n)? I don't think that should be sent.

Yes I've used this scale before on other projects with a virtual com port, works really easy

I don't know why it'd sending those two bytes before what I want sent. The module that facilitates the communication is from Phoenix Contact and I can't look at the code

I asked the guy from Phoenix Contact I was working with but he hasn't responded yet

 

[drbitboy]

Do you have another DLtech DT-9xxx converter? Because the scale is essentially a server, but because it is RS232 it is designed to be a point-to-point device. However, on the RS-485 network side of the DT-9xxx you can have multiple nodes. So if you have an extra DT-9xxx converter, you could put the PC on that network and have it send the Q\r\n string, and then the scale would respond and the PLC would see the scale's response. The only problem would be getting the PLC to ignore the Q\r\n string. Or instead of the Q\r\n you could have the PC send the "start to stream command" and then the PLC would see a continuous stream of data.

This is only an idea for bench testing. The right fix is to get the PLC to not put the two [00 03] bytes on the wire. I suspect the PLC is sending the entire string object, not just the string, and the string object comprises two items: a 16-bit integer length of the string ([00 03]), and the three characters of string data themselves (Q\r\n).

 

[jbliss15]

Makes sense. You're a smart man thx