Jump to content

[LVTN] Plasmionique Modbus Master

Recommended Posts

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.


Link to comment
  • 1 year later...
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.

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,


Link to comment

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.

Link to comment

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.

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

Edited by PaoloB
Link to comment
  • 2 months later...

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.

Link to comment

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:


Link to comment

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.

Link to comment

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.

Link to comment

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 by Porter
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By BeeEyeBye
      I'm trying to read six input registers from a remote device but the software I put together doesn't seem to do much; no errors but no read-backs either.  I'm a beginner, so the answer is probably simple.  The remote device input registers start at 200 hex.  The device uses TCP and the IP address is correct.  My computer communicates well with the remote device through QmodMaster.  Any help you could give would be appreciated.  Thanks, Mike.
      Modbus Read 01.pdf So far 01.vi
    • By govindsankarmr
      I am looking for a paid or free course online for LabVIEW instrument control that covers topic like  communication protocols, RS232. GPIB etc. Can anyone suggest a good one. Thank You.
    • By Porter
      This package contains the Plasmionique Modbus Master library for LabVIEW.
      It supports RTU, ASCII and TCP modes with the following function codes:
      0x01 - Read Coils
      0x02 - Read Discrete Inputs
      0x03 - Read Holding Registers
      0x04 - Read Input Registers
      0x05 - Write Single Coil
      0x06 - Write Single Register
      0x07 - Read Exception Status
      0x0F - Write Multiple Coils
      0x10 - Write Multiple Registers
      0x16 - Mask Write Register
      0x17 - Read/Write Multiple Registers
      0x2B/0x0E - Read Device Identification
      Other features include:
      - Sharing a COM port across multiple Modbus sessions using VISA locks (10 second timeout).
      - Sharing a Modbus session across multiple communication loops.
      - TCP transaction ID handling to ensure that requests and responses are matched up correctly in case responses are received out of order.
      - Modbus Comm Tester, available through the "Tools->Plasmionique" menu, for testing communication with a slave device without writing any code. 
      - Detailed help document available through the "Help->Plasmionique" menu.
      Examples are included in "<LabVIEW>\examples\Plasmionique\MB Master\":
      MB_Master Comm Tester.vi: Demonstrates usage of API to open/close connection and communicate with a Modbus slave device. MB_Master Multiple Sessions.vi: Demonstrates usage of API to open concurrent Modbus sessions. MB_Master Simple Serial.vi: Demonstrates polling of a single input register over serial line. Download a copy of the user guide here: MB_Master - User Guide.pdf
      Note that Version 1.3.4 of this library has been certified compatible with LabVIEW and has been released on the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/214230
      The most recent version of this library will always be released on LAVA first before going through NI's certification process.
      ***This project is now available on GitHub: https://github.com/rfporter/Modbus-Master
    • By Porter
      NI Labs Modbus API is now on GitHub!
      Password protection of VIs has been removed.
    • By szewczak
      I wanted to cross post metux's discovery here asap, and have a separate discussion.
      Metux's original post:
      The recent Linux driver package introduces a CRITICAL security vulnerability:
      It adds additional yum/zypper repos, but explicitly disabling package signing and using unencrypted HTTP transport. That way, it's pretty trivial to completely takeover the affected systems, by injecting malicious packages.
      CERT and BSI are already notified.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.