Issue with Modbus Communication in LabVIEW via USB Converter

[Bonapg]

Hello,

I’m currently working on a project where I use a Modbus converter connected to my computer’s USB port to control a motor's VFD. I'm using the Modbus library in LabVIEW to handle communication with the device.

The issue I'm facing is that LabVIEW is unable to communicate with the device. Although the converter is recognized by Windows, I can only establish communication after rebooting the computer. Once rebooted, the connection works as expected.

Has anyone experienced something similar? I’d really appreciate any hints or suggestions on how to solve or work around this issue.

[RTSLVU]

---

@Bonapg wrote:

The issue I'm facing is that LabVIEW is unable to communicate with the device. Although the converter is recognized by Windows, I can only establish communication after rebooting the computer. Once rebooted, the connection works as expected.

---

Hmmm... This could be a couple things. When you say "unable to communicate" do you get an error like a Timeout error or VISA Resource valid but unable to open resource error?

[Kyle97330]

When you say "A modbus converter", do you really mean a USB to serial adapter?  In nearly all cases, MODBUS is run over serial or Ethernet ports.  It seems unlikely that you have a special device that simply allows USB to MODBUS directly, and is more likely just a serial port emulator on USB.

If that's the case, a lot of those don't have the best drivers ever made, or the best quality control, and are often counterfeit.  Especially anything using a Prolific chipset, which are most of the cheap ones and about 80% of the market.

One of the more common symptoms of a bad serial to USB converter is that they don't properly "let go" when an application stops using them, but they do on a reboot.

It could also be that whatever you are using to connect that isn't LabVIEW doesn't close its connection to the device internally properly.  You haven't given a lot of details on this device, though.

[rolfk]

Definitely would first suspect the serial (probably RS-422 or RS-485) to USB controller. They are often manufactured with buggy chips that claim to be something they are not and barely manage to send some data over the line, some of the time. You can get lucky with the cheap ones, but generally here too applies: "You get what you pay for"

[ZYOng]

I would recommend testing with another Modbus application like QModMaster to rule out if it is a software issue.

[SlippinJimmy85]

Hello,

---

@Bonapg  ha scritto:

The issue I'm facing is that LabVIEW is unable to communicate with the device. Although the converter is recognized by Windows, I can only establish communication after rebooting the computer. Once rebooted, the connection works as expected.

---

If I am not mistaken, your ModBus communication works fine. The problem is that, when you connect the USB converter, you have to reboot the PC before it works, right?

It seems to be a PC problem, not a LabVIEW problem. Try using another application (for example Modbus Poll). If you still have to reboot the PC to make the communication work, the issue isn't related to LabVIEW.

Vice versa, if the third-party application works fine without the reboot, let us know.

[RTSLVU]

Okay I have seen weird behavior like this years ago with USB-serial (virtual com port) adaptors that have a counterfeit Prolific chipset. Newer Prolific drivers could sense these counterfeit chipsets and will just randomly stop communicating, no error is displayed and a reboot fixes it.

Older versions of the Prolific chipset driver will work fine since they don't check the authenticity of the chipset.

There were counterfeit FTDI chipset too but I don't recall what the FTDI driver does when it encounters one. Anyway we have moved to only using or buying these devices with FTDI chipsets when possible.

You don't mention what USB-Serial device you are using but last time I did anything with Modbus the devices used RS-485. I have had good luck with this Advantech USB-RS485 adaptor.

[rolfk]

---

@RTSLVU wrote:

There were counterfeit FTDI chipset too but I don't recall what the FTDI driver does when it encounters one. Anyway we have moved to only using or buying these devices with FTDI chipsets when possible.

---

The initial FTDI drivers that started detecting counterfeit chips were actively attempting to brick the chip. That got them however a massive backlash in public, although there were arguments that it hadn't been intentional but an "accident". The later drivers still supposedly try to detect counterfeit chips and simply give a non-specific error code when attempting to open such a device.

The open source Linux driver doesn't have such measures but I suppose that market is pretty small anyways.