Set RS485 to 2-wire mode on cFP-2220

[B-man]

Attached is my hardware wiring setup. I believe this is correct after reading Serial Quick reference guide. I am not getting any register readings using the MB serial Master Query.vi. Does anyone have a Modbus 2-wire example vi that communicates with a 2 wire device? Thanks for any help.

B-man

[Wayne.C]

B-Man,

Left click the broken arrow like you would to run the vi.  LV should tell you why the arrow is broken.

Back to fixing your original problem:

1-What instrument are you trying to communicate with?

2-What MODBUS settings does the manual for that instrument call out?  ASCII vs RTU etc

[B-man]

I have a single AquaSensor Data Stick with a 2-wire Modbus RS485 protocol that measures ORP value in water. The Modbus protocol default communication parameters are:

Slave Adress:1

Baudrate: 19.2 kbps

Data Bits: 8

Parity: Odd

My goal is get the sensor's value from it's register map at register number 43001 (see attachment). I hope that is possible to just read from register's adress. Do you know if I can or do I have to send a string command? So far I have been using the Modbus library vi to read register address. I think I need to get vi into 2-wire mode.

[RavensFan]

You'll want to use command code 3 Read Holding Registers, Set the start address to 3000 and qty to 1.

To set the property node for 2 wire.  You may just want to make your own copy of MB Init (rename and save to your own location) if you use that since it already has the settings for Serial port property nodes in there, and add the property node for 2 wire there.

To answer an earlier question, if you have unwired property nodes, you can unexpand by dragging from the bottom up.  Or you can right click and say Remove Element.  Of course you can't have any wires (even broken ones) goin into it.

[Wayne.C]

B-man,

Very important to verify that serial settings are correct.  8 data bits infers MODBUS RTU mode.  MODBUS can also operate in ASCII mode.  Any mention of RTU mode in docs?  Can you post a copy of the docs for the AquaSensor?

 As called out in the MODBUS spcec, settings for RTU Mode:

1 start bit

8 data bits

1 bit for even/odd parity

1 stop bit if parity used; 2 bits if no parity

[B-man]

Hi All,

I appreciate you guys help. Attached is my vi and aquasensor modbus communication manual.

I was able to read data but it's more than I expected with a much of numbers. I read register 3000 with quantity 1 but ouput was bunch of numbers and not the number value I wanted. I think it's a timing issue. Or I starting to feel that I must send a ASCII command to get the value instead of reading registers?

[RavensFan]

Did you set the property node for 2 wire?  I don't see that property node set in you MB Init VI or anywhere else.  As I said before, I hadn't seen the property node before, so I don't know exactly what it does.  One issue is that with 2-wire mode, you could be seeing an echo back of the command that  you sent out since the receive wires are directly connected to the transmit wires.

Perhaps you could post an example of the bad data you are getting as well as the number you are expecting to get.  (Run the VI once, Edit menu Make current values default.  Save then post.)

By the way, there is no need to create hidden controls on your FP to provide the cluster for your bundle by name nodes.  Just change the hidden controls to a constant on the block diagram.

The manual says it uses Modbus RTU, so there is no reason to send an ASCII command.

[B-man]

Opps, I was messing arround with the property node, must have deleted the constant for wire mode. See attachement again. It's in the MB Init under "instr" last node "serial settings: wire mode. Besides the com+, com-, and ground wires, do you know if I need to connect V+ (voltage) wire to the 10pin RS485 jack to make the signal differential, maybe? If so, which pin would it be? The serial quick reference guide does not specify. Currently I have it connected to pin 1 (a "no connect" pin).

[Mads]

Ravens Fan, the attached picture shows the wire mode property.

PS. Notice that I've filtered out error -1073807330 in this case because I use the same initialization on the other serial ports as well and then you gett hat error because they are RS232 ports....but if you ignore it you can use the same code for both.

[Mads]

No, actually it should work fine with just A(-) and B(+) wired...

You have a lot of things going on in your system so I would try to simplify it to debug the problem.

To ensure that you indeed have the wiring correctly I would attach a computer in the other end of the RS485 and start HyperTerminal on it...then I would write and run a VI on the controller that just writes hello to the port every second...if you read that correctly from the laptop then the wiring is OK. Now - I would use the computer to talk to the sensor - if you download a modbus master simulator you can firstly verify that you are indeed able to communicate with the sensor on modbus. If modbus communication is possible I would then run the modbus VIs on the computer to verify that the LV code in fact is able to communicate with the sensor as well. Once all this is verified I would run the LV modbus code on the controller. The next step depends on at which step of this procedure things go wrong...If e.g. it goes wrong at the last step I would replace the sensor with a PC running a modbus slave simulator or at least a serial port software that can display the hex characters it receives..I would then check if the commands received by the PC are indeed what they should be. As you assumingly do not know the details of modbus you could always send the commands received and/or replies to this forum and it will probably tell us what is going on.

The above procedure would be a bit difficult if you do not have a computer with RS485...if that is the case I would first show on this forum what data you received when talking to the sensor...perhaps we can understand what it indicates. There is also always the option of making yourself an RS485 to RS232 converter...for test purposes it can be done fairly easy.