Modbus RTU - Problem with 2 stop bits

[Tweezer]

Hello,

iam trying to communicate to Carel controllers and IO modules via Modbus RTU.

The Carel controllers have given network parameters:
Baud Rate: 19200

Data Bits: 8

Stop Bits: 2

Parity: None

Flow Control: None

The IO modules have adjustable parameters. All other configurations are working with the Plasmionique library except for the above named. Like 1 stop bit and odd parity. Even parity even and 1 stop bit is working. So iam assuming that the problem is caused by the second stop bit.

The errorcode is -1073807253: VISA Read in MB Master.lvlib:MB_ADU_RTU.lvclass:RX ADU.vi:4960001->MB Master.lvlib:MB_Master_Serial.lvclass:Querry.vi:3550001->MB Master.lvlib:Read Holding Registers.vi:2420001->MB_Master Comm Tester.vi

I have tried to program an own vi. It works as the Plasmionique Comm Tester for all other parameters except for the above ones.

I also have to mention that the communication with the Carel controllers is working and i have spoken to one of the manufacturer of the IO modules. He said the modules should be fine.

The Carel controllers AND the modules are working with the free program qModMaster.

Does anyone have any idea about what is wrong here?

Thanks for your help.

Albert

[Tweezer]

I have traced the data and following messages are written and received:

With parity: even and 1 stop bit (working):

Write: 0F 03 00 00 00 01 85 24

Read: 0F 03 02 13 BC DD 04

With parity: none and 2 stop bits (not working):

Write: 0F 03 00 00 00 01 85 24

Read: 0F 03 02 13 98 DD 1F

[RavensFan]

Can you attach your VI?

There is a recommendation by Modbus org for how many stop bits are to be used.  That doesn't mean everyone one follows that standard.

I do know that one particular modbus library I often use, the number of stop bits is hard coded in the Modbus Init VI.

I never use that Modbus Init.  All it does is initialize the serial port.  So I use the regular VISA Serial Configure that gives you full access to all the settings.

Just make sure your serial configure matches what the device is using and don't use the NI version of "Initialize" that is in that library.

[Tweezer]

Thank you for your reply.

I have attached a simple VI with the VISA Serial Config u suggested. With this VI i can read the register with parity even and 1 stop bit, but not as i want with parity non and 2 stop bits.

[RavensFan]

Are you still getting that error message you originally mentioned?  I looked up the code and it was for a framing error which makes sense if there is a mismatch between the communication of the serial port and the controller you are talking to.

Are you SURE the the controller is set for 8 data, 2 stop, no parity?  Maybe they say it is, but it is not.

All you need to do is make sure the settings on your PC side match the controller's settings.  Change the controller settings if they allow it.

You might be able to look at the bit stream looking at an oscilloscope, but you'll want one that captures the data and allows you to review it later as it will go by fast and you'll need time to truly analyze the bits and bytes.

[Tweezer]

In the control panel the settings are as mentioned. Also in MAX, but now iam getting error 6101. I dont know what i have changed.

At the moment only one of the IO modules is integrated in the modbus network. I have disconnected all other modules and controllers. Iam (not really) sure the module is set to 8 data bits (standard and cannot be changed), 2 stop bits and no parity. I can change those settings via DIP switches or via a PC interface so the settings should be right.

The controllers settings cannot be changed. That is why i need to have those parameters in the I/O modules. Otherwise i would use the settings which are working.

We have an osci here somewhere. Iam trying to get one.

EDIT: One thing i have seen in the config of the modules: I can change the "Register order". "Order of registers at LONG or FLOAT values <> 0 -HH-HL-LH-LL (default) or ==0 -LH-LL-HH-HL". Maybe this has something to do with my problem?

[RavensFan]

That is a modbus timeout error.  http://digital.ni.com/public.nsf/allkb/628A4CF844B2382A862575D700349D99

Basically, there was no response back in time.  Probably means the outgoing message had a problem and the controller ignored it.

That link does suggest a possible cause as a problem with the serial port.  I wonder if the problem is in your PC's port.  Is it a hard COM port or a USB adapter.  Is it RS-232 or RS-485?  Can you try a different serial port or try on a different PC?

[Tweezer]

Today i have set all parameters again and tried the vi again. Now its the error -1073807253 again.

I tried a different MB library and checked the write/readcode in NI trace. The read buffer looks like that: 0F 03 02 14 37 9F 53 ....7.S . Iam not an expert but the signal looks good expect for the 7.S which should not be there? The error code here is 56 in read ADU packet.

Currently the system looks like that: sensor->I/O module->RS-485->RS-232toRS-485 Converter ->RS-232 cable -> serial port. The cabel of the Modbus is a 20m long LiYCY cable. The RS-232 cable is 2m long. The termination resistor has 120ohm.

I don´t think it is the PC port, because the communication with the Carel controllers is functioning. But i try to get a USB to serial adapter.

By the way thank you for your replies!

[Ben_Manthey]

What brand and model of USB to 485 converter are you using?

Is it this Micro Flex? If it is I've encounter the same problem.

The solution is not obvious. Go in Device Manager, Choose Port Settings from the Properties. Then choose Advanced. Change any item, choose OK. This should reinitialize its internal settings. You can go change the item back to its original setting and then exit the property screen Device Manager. 

All USB to 485 converters suck in their own way, this is (one of) the ways this one sucks. 

[arteitle]

---

@Tweezer wrote:

I tried a different MB library and checked the write/readcode in NI trace. The read buffer looks like that: 0F 03 02 14 37 9F 53 ....7.S . Iam not an expert but the signal looks good expect for the 7.S which should not be there? The error code here is 56 in read ADU packet.

---

Just a note, the "0F 03 02 14 37 9F 53" is the same thing as the "....7.S", just represented differently. The former are the received bytes represented in hexadecimal, the latter are the same bytes interpreted as ASCII characters, with the unprintable characters (everything but the 7 and S) shown as periods.