Showing results for 
Search instead for 
Did you mean: 

Incompatibility with Moxa?

In several cases we have had problems with LabVIEW (7-7.1.1, have not tested in LV8) and serial cards from Moxa. The ports work fine with other software, it is just LabVIEW that either fails to initialize the port or fails to get anything through the ports. We have seen a similar problem with USB to serial solutions from Prolific. It makes no difference whether we use VISA or the old serial functions.

Has anyone else struggled with these cards/USB units and if so have you found a solution?

It is off course simple to say that it is not LabVIEW's fault but the cards and accompanying drivers, however the fact that so much other software runs fine with them puts us in a weak position.
Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
0 Kudos
Message 1 of 6
One of the problems that I have seen many people run into is that not all serial drivers are created the same. LabVIEW and NI-VISA make the assumptions that the serial driver and serial hardware will support all of the functionality and behavior of a normal Windows built-in port. This of course includes lots of advanced functionality for allocating buffers, flushing buffers, and controlling handshaking lines.

Even for the most basic LV serial examples, NI-VISA will use a whole host of these advanced serial port function calls to configure the port. In addition, NI-VISA has very strict error checking to ensure that every function that is used returns correctly.

Problems occur when you try to use a piece of serial hardware, in most cases USB to Serial converters, that only provides a sub-set of the functionality found in a built-in port using the Windows driver. For example most of the inexpensive USB-232 devices don't support calls like flush, and by default NI-VISA calls flush after every write. If the serial driver returns an error or hangs during the flush this will of course cause your LV application to hang or error out.

The reason you don't see these kinds of problems with applications like HyperTerminal, is that most other applications don't bother to mess with the buffers or any of the other advanced Windows serial function calls. In addition, some applications like HyperTerminal don't do any error checking.

To figure out exactly what is going on you can run a port monitor utility like the one from HDD ( that will allow you to see what serial functions are being used and the status. I typically recommend running the same application on a built-in port and then on the port that is having the problems. Set HDD log to a file for each run and the compare the results.

This should give you an idea of which serial function call is the offending one and in some cases you can design your VISA application to work around that function call or you can contact the vendor of your serial controller and see if they can give you an explanation on why they differ or give you a new driver that corrects the problem.

I hope this helps out.

Message 2 of 6



I'm having issues with a Moxa 5230 serial device server similar to what you describe.  This device is configured, pingable, etc, and using a terminal emulator I have exchanged data between my customer's touchscreen WinXP panel-mounted PC and a laptop (even with a Keyspan USB-serial adapter inline).  I am attempting to communicate with a Yokogawa DA100 data acquisition unit.  This device came with software called DAQ32, and the touchscreen can communicate with the DA100 via DAQ32 serially and through Keyspan, but not through the Moxa.  I installed port monitor software to see what is happening while DAQ32 establishes contact via a known good configuration as well.  I have a Labview program that utilizes DARWIN drivers available from NI and Yokogawa, and with a serial connection I can send and receive data through this VI.  MAX's VISA interface is able to at least return error codes from the Yokogawa. 

When I open MAX with the Moxa inline, I see the virtual COM port created by the Moxa and am able to open a VISA session, but cannot even get an error return from the DA100.

All serial cables have been custom soldered, so I have checked, doublechecked and ohmed out the cable in use in the non-working configuration.

One other strange thing I've noticed, even under a working configuration, is that the baud rate I see when I probe the VISA session wire does not match Windows setting, MAX setting, dip switch on the DA100 setting or the value being written to it by the DARWIN Initialize VI used in my VI.  But it works, so maybe I should count my blessings.

Any help would be greatly appreciated.  I have been grinding away at this comms issue for a solid week, with overtime, and I think I might go crazy or move into the woods and go off the grid.



0 Kudos
Message 3 of 6


@JoshuaP wrote:
For example most of the inexpensive USB-232 devices don't support calls like flush, and by default NI-VISA calls flush after every write. If the serial driver returns an error or hangs during the flush this will of course cause your LV application to hang or error out.


I've run into this problem with MOXA converters in the past.  Ended up switching to a less "reknowned" supplier.



0 Kudos
Message 4 of 6

Yokogawa makes an ethernet communication module I could use instead of the RS-232.  But, my company is only using the DA100 and the Moxa to match an existing unit by a different OEM.  Of course, that original unit didn't have a touchscreen running LabVIEW (pretty much the only extra they are getting out of us.)  So I think I need to go as deep and as dark as it takes to get this to work.  Can anyone give any more council?  Maybe I'm so lost in the murky depths of serial commands that I've forgotten something really simple.

Maybe Rolf could help me... 🙂



0 Kudos
Message 5 of 6

Well, it's taken up so much time now that my boss went to the customer with the issue, and the Moxa is out of the picture now.  Off of comms issues, and on to programming 🙂

0 Kudos
Message 6 of 6