Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

rs485 device through rs232 port?

I know this is an issue that has been re-hashed over and over, and I still can't get it to work.  I am relatively new to this so will convey what I understand at this point.

I have a temperature controller which is 2-wire (literally there is no ground terminal) RS-485 (which means half-duplex).  It is set to 9600 baud (fixed), 8 data bits (fixed), 1 stop bit (fixed), even parity, MODBUS RTU (fixed). I have a rs232 to rs485 converter that does not automatically control the flow, so I need to account for this in my software.  I have it configured as a DCE (since it is a go between the PC and the temp controller which are both DTE).  ALso I have it set to T-RTS/R-RTS, so that i can look for the RTS signal. 

On the rs485 end it has a 4 terminal block, being the T+, T-, R+, R-.  I have the T+ and R+, wired together and attached to the (+) terminal of the temp controller, likewise the 2 negative wires are connected to the (-) terminal.  This is how the manufacturer of the device says it should be setup, and seems to make sense to me based on what I understand.

Rs232 is full-duplex, meaning that transmit and receive can occur at the same time, since they are on different lines this makes sense.  But sinec the 2-wire rs485 is combining the (+) and (-) of the transmit and receive, this would certainly cause collisions.

The rs232 end has a db-25. Then there is the cable going to the rs232 serial port on COM1 of my PC.  Pins 2,3,4,5,6,7,8,20,22 are wired as is standard. I've got a rs232 tester in-line cause I like to see blinking lights :>)>

My VI first closes the VISA port, then initializes it using the NI MODBUS library, set as I have laid out above.  I have tried it with FLOWCONTROL=none, and also =RTS/CTS.

n both cases, immediately after init, my tester shows TD and RD are HI, and all other are LO.  When the VISA port is closed, all are HI except CD.

With FLOWCONTROL=RTS/CTS: if I have serial property nodes to set the RTS signal in between the writes and reads then I get the VISA error -1073807302 (BFFF003A), which leads me to think that I can not combine the 2 approaches.  Is this the case?  When flow control is set on the init property node does it conflict with trying to do it manually?

when I take those nodes out, and I attempt a write, nothing is read in from the buffer.

With FLOWCONTROL=none with the RTS signal nodes in, it does not matter which is set to asserted or unasserted, I receive nothing from the read buffer.  What is the terminology "asserted" and "unasserted"?  why do they trun both RTS and CTS, HI or LO at the same time?  Do I need the RTS to be HI or LO when I send a command from the computer, and when I am trying to read from the temp controller?  (it seems to me that is should be HI then LO)

when I take the nodes out I also receive nothing in the input buffer.

I've attempted to set the converter to T-on/R-on, and with this I do receive something in the read buffer, but all it is is the exact copy of what I sent.  It does not conform to the message structure that the temp controller manual says to expect from the MODBUS response.  It has the device address, the function code, the register address, the number of words, and the CRC.  It always seems that it is truncating the actual data, or the setup is acting like nothing but a lookback sending my an exact copy of what I send it.  i.e \01\03\03\E8\00\02D{  (or in hex 0103 03E8 0002 447B)  is returned when I query read 2 words starting at holding register 3E8 on device 1. I

 hope this is clear what I've done and what I am attempting.
thanks in advance
James
0 Kudos
Message 1 of 13
(6,636 Views)

Hi James,

If I understand your (long) story correctly you have tied the T and R wires of the RS485 together making it a 2 wire RS-485. This means that the converter should support this. Otherwise you will get the data you sent back at the receiver.

If the converter does not support automatic 2 wire mode you can try a workarround. Start the receive loop with the number of bytes sent and the number of bytes to receive. Or, just for the test, wait a few seconds and then receive all data and see what comes in.

0 Kudos
Message 2 of 13
(6,613 Views)
Ok let me ask this a different way then...

When do I raise RTS? When do I lower it?  The LabVIEW terminology is "asserted" and "unasserted", which is HI or LO?

Both the PC and the temperature controller are DTE, and they both send and receive data.  In between is the converter, the DCE, and things are going both ways through it.  So from whose persective are TD/RD and RTS/CTS defined?

no apologies for the length of my story, i'm simply trying to be complete.

thanks
James
0 Kudos
Message 3 of 13
(6,584 Views)
Hi,
 
No apology needed for the length of your story, others ask more then you do in one sentence. I think your way is better.  Smiley Happy
 
I don't switching hand shake signal will help. This does not disables the receiver. 20-30 years ago handshake was necessary because devices were to slow to handle all the data at high speeds. Today it is sometime used to indicate if a DTE is ready.
 
Normally "asserted" means active and has no straight relation to the real hardware level.
 
 
I think to get further the best way is to try to receive the number of sent bytes + the number of expected bytes to receive. Then you know for sure what the problem is.
You can also try this with Hyper terminal. Then you can try it with just a few characters.
0 Kudos
Message 4 of 13
(6,582 Views)

James,

Can you post the manufacturer and model # of the 485 to 232 adapter you are using?

0 Kudos
Message 5 of 13
(6,577 Views)
rs232 to rs485 converter:  ATEN ic-485s
temperature controller:  Fuji electric PXR4
0 Kudos
Message 6 of 13
(6,575 Views)

James,

To answer one of your earlier questions.  If you set FLOW CONTROL=RTS/CTS in your vi, then you do not need to manually assert the control lines using the property nodes.  Handshaking will be handled automatically by the COM port hardware.

Suggest that you put switches 7 & 8 in the OFF position.  This will allow the adapter to autodetect the direction.

 

0 Kudos
Message 7 of 13
(6,569 Views)
To clarify:

when you say switches 7 & 8....

do you mean sending signals to the 232 port?  and do you mean lines 7 & 8 on a 9-pin (RTS and CTS)?  or do you mean the lines 7 & 8 on the 25-pin (GND and DCD)?

the converter that I have has no dip switches visible.  are there some inside which I'll have to take it apart to get at?

or do you mean my temperature controller?  which again has no dip switches visible and nothing in the documentation I have?

and when you say adapter...
i assume you mean the converter?

the ATEN ic-485s documentation tells me that it can not do auto-detect.


james
0 Kudos
Message 8 of 13
(6,560 Views)

Sorry,

It turned out that the manual I found was for the IC485ai.  Sounds like the auto mode was added in the later model.  Auto mode is great because the converter can automatically control the half-duplex.

Can you post the manual for the IC485s.  It does not seem to be available online.

0 Kudos
Message 9 of 13
(6,543 Views)

OK,

I finally found a copy of the manual on the net.  It sounds like you already did the loop back test when you tried the R-ON/T-ON and it passed because you got back what you sent.  That would seem to indicate that you have the right cable and that you were correct in selecting the DCE configuration. 

I'm guessing that you have already done all this, but I'll say it anyway.  Double check all your com settings both in your vi and in the FUJI device.  Make sure that the FUJI device is configured with the right address.

If all this is correct and it still does not work, try reversing the 485 lines at the FUJI controller.

0 Kudos
Message 10 of 13
(6,538 Views)