COM port access

[patrickokeeffe]

I've been using version 18.1 and see strange behavior related to serial ports. Immediately after creating a new serial port with the correct port parameters, I see no traffic on that port. However, once I open the port configuration screen and press Save to close, traffic immediately appears. Nothing actually needs to be modified on the configuration screen, it just needs to be opened and closed. 

This behavior was observed when setting up three different serial devices, and it's reproducible for me too:

1. Open Comm Monitor for port in question (COM7 in this case, assume there is already traffic flowing)
2. Right-click and choose Configure... 
3. Do nothing and press Save to close the window
4. Observe traffic has stopped
5. Right-click and choose Configure... 
6. Do nothing and press Save to close the window
7. Observe traffic flowing again
8. Repeat again and again

 

I saved a copy of the control document in both states:

* with traffic flowing: `compostpile-msmts.ctl`
* with traffic stalled: `compostpile-msmts(stalled).ctl`

 

Here is my full environment:

* DAQFactory 18.1, Base Release, build 2347
* Windows 10 Enterprise running as administrative user
* COM 1-6 are physical ports not in use
* COM7 is an Airmar brand RS485-usb serial adapter
    * port settings: 4800/8n1, 1000ms timeout, no flow control
    * sends several NMEA0183 compliant streams
* other 2 COM ports are virtual comport drivers linked to an nport 5610-8-DT serial port server

compostpile-msmts.ctl

compostpile-msmts(stalled).ctl

[AzeoTech]

Opening the configuration screen and clicking save reinitializes the port, which apparently is what your port requires.  I've seen this occasionally with USB->Serial converters.  You can achieve the same thing in script by simply doing:

device.myDevice.initComm()

and with that you can easily right a little script that reinitializes the port whenever it doesn't see any data for some time period, say, a few seconds.

 

[patrickokeeffe]

Thanks for the suggestion. I'm actually seeing this several different serial ports:

* With my USB-RS485 converter, it's 100% reproducible
* Using NPort virtual com port drivers, the issue occurs roughly 1 in 3 times I click-through the configuration screen
* still TBD: whether or not this issue occurs in relation to a physical RS232 port

What I don't understand is why the initialization routine would de-initialize a port (what it seems is happening in this situation).

[AzeoTech]

Unless you can reproduce on a physical port the issue is in the USB driver.  Pretty much all those virtual com port drivers use the same core code so have the same issues.  DAQFactory uses simple core Windows functions for communicating on the serial port.  There isn't much to it as Windows itself takes care of everything.  But virtual com ports are really just a trick (hack really) and so aren't particularly reliable.  DAQFactory can't bypass them, so we are completely at the mercy of the quirks in the virtual driver. 

I've been saying for many, many years that people should avoid USB -> serial devices and use Ethernet->Serial if they want true reliability.  This is because DAQFactory can connect to the Ethernet->Serial device directly using Windows sockets and not be reliant on some 3rd party driver.  Alternatively, though more expensive, is to purchase an industrial computer with native serial ports.

There are also other issues with using USB in general in systems that require high reliability, which I can go on and on about, mostly related to the fact that one device can easily crash all the devices on the USB bus.   USB is convenient, and for many applications, a failure isn't a problem so we support devices like the LabJack U3 that is USB only.  But I would never use a U3 or any other USB device in a case where its failure would cause major issues.  I would instead use a LabJack UE9 or T7 which is Ethernet based, or some other Ethernet based device. 

Likewise, USB->Serial is cheap and convenient, but it isn't reliable, especially if you just buy a random converter from an unknown vendor, but in many cases it doesn't matter.  And often you can script around it, such as in your case.  But you are going to get weird things happen like what you are seeing.

Note: Over the years we have found that the serial converters from SeaLevel tend to be much more reliable than the generic ones from the generic web, so if you have to use a USB to serial converter, buy one from them.

[patrickokeeffe]

Quote

I've been saying for many, many years that people should avoid USB -> serial devices and use Ethernet->Serial if they want true reliability.

This is an old thread, but it's worth pointing out an NPort virtual com port is an Ethernet->Serial connection. If you meant creating a TCP (Ethernet) port instead of an RS232/422/428 (Serial) port inside DAQFactory, that could have been expressed more clearly. 

[AzeoTech]

I haven't heard of NPort so just assumed it was for your USB->Serial converter.  If you are using an Ethernet -> serial converter you should use one like the ones from SeaLevel that offer a Raw port connection and thus do not require a local driver.  With the NPort you are still at the mercy of the 3rd party virtual comm port driver and whatever limitations it may have.  By using a the raw port, DAQFactory is connecting via its own internal Ethernet driver directly to the converter and then on to the device.  In this case you are only relying on DAQFactory's Ethernet driver and the software inside the converter device.