[LVTN] Plasmionique Modbus Master

[Tom Bress]

Hello, Porter.  I'm new to Modbus and I'm trying to use the Plasmionique Master library to communicate with a 2-wire RS485 device over a USB port.  Do I need to have a 2-wire USB-to-485 converter, or is there a way in the Plasmionique library to configure the Modbus communication as 2-wire? 

Background: I'm trying to communicate with a Mellen furnace Love controller.  I can communicate with it using the manufacturer's software, but whenever I try to use the Modbus Comm Tester in the Plasmionique library I keep getting timeout error (-1073807339).  I'm pretty sure I've got the baud rate, parity, stop bits, and flow control configured correctly.  The Open Port function on the Comm Tester seems to work, but whenever I try to read coils or holding registers I get the timeout.  Mellen tech support suggests it is because the controller is a 2-wire RS-485 device.  I'm using a Tripp-Lite USB-to-485 adaptor cable, their tech support says the cable should support either 2-wire or 4-wire communication.  So now I'm wondering if 2-wire/4-wire needs to be configured somehow in the Plasmionique library.  Thanks.

[Porter]

When you say Love Controller, do you mean a Dwyer "Love" Temperature Controller? They definitely work with this library.

For configuring the USB-RS485 adapter, I have never used labview to specify 2-wire or 4-wire mode. That is usually done via hardware (dip-switches or jumpers) or the driver (device manager). I have never used the Tripp-Lite adapter though. I typically use USB-Serial converters from Moxa or Sealevel Systems. They have proven to work very will with labview.

If you can provide the model number or user manual of the Love controller, maybe I can give you some example commands to try.

[Tom Bress]

Yes, it is a Dwyer Love Temperature Controller, the manual can be found here: http://www.dwyer-inst.com/pdf_files/e_90_bpc.pdf

I can communicate with the device using the Dwyer software, which also tells me which parity, stop bits, etc. to use.  But when I try the Plasmionique Serial Comm Tester I get the timeout error.  I can open a port, but cannot read the coils or holding registers.

[Porter]

Be sure to double check the ASCII/RTU mode setting.

Make sure that you are specifying the starting address in hex format. The PV value is supposed to be at holding register 0x1000.

You could also try increasing the timeout value to 1000 or 2000ms (instead of the default 300ms).

A screenshot of the dwyer communication setup and the Plasmionique Modbus Comm Tester setup would be useful.

 

[PaoloB]

On 5/24/2016 at 7:36 PM, Porter said:

New version uploaded (V1.0.4). Now supports function codes with responses of unpredictable length in RTU mode (other modes already supported this). In RTU mode, if the RTU_DataBytes is set to less than zero, RX_ADU.vi expects that, in the response, the byte after function code is the number of data bytes. However, if the function code is 43, Modbus encapsulated interface transport message format is assumed. For now, only MEI type 14 is properly supported. Other MEI types rely on a timeout of 200 ms to determine the end of message.

Hi,
first of all, thank you for this great library.
I am working with a device that requires extensive use of the encapsulated interface transport (ETI), specifically MEI 13.
Your quoted reply seems to indicate that, even thought it is not fully supported, it is possible to use the library to implement ETI. Could you point me in the direction on how to do it?

Many thanks,

Paolo

[Porter]

Hello Paolo,

Since you will be using Modbus RTU (over serial port) you would probably want to modify the "RX MEI Data.vi" in the MB_ADU_RTU class to have some logic to determine the end of the response message. Otherwise the default behavior is to wait 200ms and assume that the entire message has been received during that time. If you are OK with the 200ms wait time, then you don't need to modify anything here.

Next you would want to call the "Querry.vi" from MB_Master_Serial class with function code set to 43, and the first data byte set to 13.

Note that if you do modify "RX MEI Data.vi" you can use the RTU_DataBytes parameter to tell it how many bytes to expect to receive if you are able to know this before calling Querry.

[PaoloB]

Hi Porter,

Thanks for the prompt reply. Yesterday I managed to get it to work to some extent implementing a call to Querry as you described.

I think I might also need to modify "MB_ADU_RTU/RX ADU.vi" so that it does not throw an error. At the moment I get 403482 (CRC mismatch). But it could well be that I have missed something in the transaction. More debugging today...

Thanks again.

EDIT:
Nevermind, I was specifying the wrong number of DataBytes. As soon as I set the correct one, the function works as expected.

Edited May 19, 2021 by PaoloB
UPDATE INFO

[Yair]

Hi Porter, we have run into an issue with an EXE getting completely stuck and traced it to the VISA read (or write or both, can't remember) being configured to the async mode. This is in LV 2015 with VISA 15 (and I believe it was also tested with VISA 18.5, which was the latest supported version).

Would it be possible to add a boolean property to the class to allow making the R/W calls in sync mode? Should be as simple as adding a case structure with a second copy of the node.

[Porter]

That's the first time I've heard of such a problem. I'm reluctant to implement this because from experience, synchronous R/W usually causes more problems that it solves. Would you be willing to privately share the code with me? What kind of serial port are you using?

Can you try using a FTDI-based USB-Serial converter to see if you get the same behavior?

Other USB-serial converters that perform well with VISA are:
https://www.sealevel.com/product/2105r-usb-to-1-port-rs-232-db9-serial-interface-adapter/
https://www.moxa.com/en/products/industrial-edge-connectivity/usb-to-serial-converters-usb-hubs/usb-to-serial-converters/uport-1100-series/uport-1150

 

[Yair]

We're checking with the client to see if they can check with different hardware. They did say they are using the same converters in other places with no issues. I'm not sure which device and chipset it is.

This does happen in the two places we have used this code (and converters) so far. In both cases, the code runs actors (one for each unit), and has an additional layer of locking for the bus on top of the one used in your code. One of the PCs only communicates with a single unit, so it only has a single actor. I'm not sure if sharing the code would help, but maybe we can do that if you feel it might be relevant.

To be more clear as to what the actual issue is: The communication starts normally (it cycles through different Modbus commands as ~2-20 Hz) and after some time (my understanding was that often it was after only a few hundred cycles), the actor gets stuck, while the rest of the program keeps running and the UI is responsive. By adding some debugging indicators we have seen that it gets stuck at the read or write primitives and when adding the option to work synchronously, we have confirmed that this causes the freeze not to happen.

This is the first time we used the Plasmionique toolkit. Before that we used the old NI modbus code, which is set to sync and where this didn't happen, but that has its own host of issues.

Obviously, the actual problem isn't in your code, but somewhere in the serial stack (LV/VISA/driver). I'm not sure what the actual problems with sync would be, so I can't comment on that. The help says it locks the thread until the call is done and that this will impact performance if there are more than ~4 devices. Since the systems I have to work with at the moment have at most 2 RS485 buses, meaning no more than 2 devices in parallel, that's not something I can currently test.

[Yair]

Turns out this was only happening in a single computer, or at least that's what I'm told. The other one uses Modbus TCP for the more intensive comm, so I don't know if they would have noticed it there as easily.

Anyway, after some grumbling, the client did replace the converter and said this resolved the issue, so I guess I will cancel the request. While I haven't seen the problems with sync myself (have been using the old NI Modbus code since the time it wasn't old and there it is set to sync), I don't think I can justify the request without a concrete use case.

[Porter]

Glad to hear that a new converter did the trick. I can remember having an issue like that a long time ago and it was due to incompatible hardware.

The main reason why I don't like the synchronous mode is because it allows only one serial read at a time, across the entire system. So for a system with multiple serial ports, you can only poll them one at a time. I recall being very confused when using the old NI Modbus code and watching the status LEDs on our multi-port USB-Serial converter light up sequentially. It had a very detrimental impact on the performance of the system.

Edited August 4, 2021 by Porter

[DavidLee97]

Porter,

I am trying to communicate with a device at 300 baud, but I keep getting a Slave ID Mismatch error.  I have verified that the slave ID is correct (ID=1).  Here is an image of the proof-of-concept code that I've tried (LabVIEW 2020):

Edited February 8, 2022 by DavidLee97

[Porter]

300 baud. That is slow!

This error is generated by the slave ID check that happens after the first 2 response bytes have been received.

Byte 0: SlaveID
Byte 1: Function Code

If the slave ID doesn't match the slave ID of the request, then you have a slave ID mismatch. Likely the data is somehow corrupt.

Are you sure that your stop bit and parity bit are set correctly?

You can also check the two received bytes using a property node like this:

Be sure to set the string indicator to hex display.

[DavidLee97]

I have verified that the stop bit and parity are set correctly.

The system consists of a USB to RS232 cable connected to an isolater/converter to connect to the Device Under Test.  Once side of the isolater/converter is powered by the DUT, the other is powered by the RTS and DTR lines.  This last part is presumed, but appears to be verifiable.  I used a scope on the RTS and DTR lines while sending the command using the old NI MODBUS library.  I observed the RTS and DTR lines remain ASSERTED during the entire transmission (master send and slave response).  When using the Plasmionique library, I observe the RTS and DTR lines assert and clear during the transmission.  Is there a way to keep these lines asserted during the entire transmission?

[Porter]

What model of USB to RS232 cable are you using?

Maybe this could work?

Maybe the RTS and DTR are cleared during the Flush IO buffer that is called just before serial transmission. This is the first time I would have seen this behavior though.

[DavidLee97]

The attached image is the same with or without the modification.  This was taken using a Tripp-Lite U209-000-R USB to Serial converter.  Signal names are:  0=RXD, 1=TXD, 2=DTR, 3=DSR, 4=RTS, 5=CTS.  I have shorted RTS/CTS and DTR/DSR.

 

[DavidLee97]

I also observe the same image using a Trendnet TU-S9 USB to Serial converter.

 

[DavidLee97]

I placed a breakpoint after the Init and before the Read.  I was able to verify that the RTS/CTS and DTR/DSR lines are asserted.  They appear to be unasserted at some point during the Read operation.

Also, when running this same proof-of-concept at 9600 baud, I noticed that the RTS/CTS and DTR/DSR lines remain asserted for the duration of the message (master send and slave response).  It is only when I try using it at 300 baud that I run into this issue.

I am using LabVIEW 2020 and Plasmionique 1.3.5.

[Porter]

In "TX ADU.vi" of the "MB_ADU_RTU.lvclass" try setting the mask of the VISA Flush to "Flush Receive Buffer (No I/O)"

If that doesn't change anything, then try replacing the VISA Flush with this:

 

Please let me know if that changes anything.

 

[DavidLee97]

Thank you for the suggestions.  I have tried both of them and still no luck.

I'm looking at my signal converter right now, and I'm seeing some echo on the RX line from the command transmitted to the slave.  The converter I'm using is supposed to mute the RX line while the master transmits, but it's obviously not working.  I'm working on the hardware solution to this issue now.

What I still don't understand is that the original NI MODBUS VIs appear to ignore the echo and capture the slave response without an issue.  Anything else, including modpoll and modscan command line interfaces, all seem to key on the echo as part of the slave response.

Here is the NI MODBUS proof-of-concept.  This has worked for me at 300 baud every time, even with the echo characters.