USB to RS-232 Adapter/Old Version of LabVIEW Issue

[Mike576]

Hi, I work for a lab that operates multiple autoclaves. Each autoclave has a dedicated Windows XP PC running LabVIEW 6.1 connected via male-to-female serial cable from a COM port to a FieldPoint FP-1000 network module. One of these PC's failed, so we replaced it with a new Windows 11 Pro PC.

This new PC has no COM port, so we are attempting to use a DTech USB to RS232 adapter (Model: DT-KJ5011-2M, FT232RL/ZT213 FTDI chipset). The newest drivers are installed, the virtual COM port appears in Device Manager (COM1, with no other COM ports present), and the settings match that of the FP-1000 (9600bps, 8 data bits, no parity, 1 stop bit). The FP-1000's network access light never comes on.

After searching these forums, my understanding is that the virtual COM port must appear in MAX in order to be utilized. The version of MAX currently installed will not run, so I installed the newest version. The new version runs but does not show the serial adapter under "Devices and Interfaces".

I also saw that Project Explorer was necessary for LabVIEW to be able to use a virtual COM port, but was not introduced until version 8.

I understand that LabVIEW 6.1 is extremely dated, and no longer supported, but it has worked without issue for a very long time, so there was never a need to upgrade.

Before I spend any more time trying to figure this out, I thought I would ask if a working combination of Win11, USB virtual COM, LabVIEW 6.1, and FP-1000 is even possible. Any help, guidance, or advice would be greatly appreciated. Thank you.

[santo_13]

Win11 and LV6.1 may not work. The best you can do is try to clone the other working WinXP machine image into the new computer, but that may also not work because those latest processors and chipsets are never heard of during WinXP days.

[Mike576]

Thank you for your reply Santhosh. Just to be clear, we did get LabVIEW 6.1 running on the new Win11 PC, and our main VI frontend loads, but we cannot proceed from there due to a lack of communication between the USB serial adapter's virtual COM port and the FP-1000.

I guess the main question is whether or not it is possible for a USB virtual COM port to communicate with a device via LabVIEW 6.1?

[rolfk]

Well, LabVIEW is not the problem usually. LabVIEW itself does only use the standard Windows 32 API and Microsoft went in the past to extreme lengths to guarantee that the old APIs kept working even if Microsoft had to build in hacks that try to detect known applications from accessing certain APIs and then behaving bug for bug compatible in those cases even if the newer versions of the API were improved in the meantime.

So LabVIEW 6.1 starting up on Windows 11 is not very exceptional, and displaying its front panel more or less properly (there can be sometimes visual glitches) neither. However accessing hardware is an entirely different chapter.

Older versions of NI-VISA definitely will not work very well on the latest and greatest Win11 system. So you need a fairly recent NI-VISA version. And while the NI-VISA API has remained very stable over the years, NI-VISA from 2000 was still a fairly early version of NI-VISA and there was some change in the API in those times that the latest NI-VISA won't necessarily support, specifically about discovering devices, as this has always been a bit of a tricky part in NI-VISA in the beginning days. So it is very possible that LabVIEW 6.1 won't be able to see devices that NI-VISA 2025Q1 actually can see. You are after all trying to match software from 2002 with a driver from 2025. That's a long stretch to work and one NI never has tested and never will guarantee to work.

From your description so far it is hard to troubleshoot anything. A COM1 being available in the Windows device manager says nothing that it would be your DTech device. I have a COM3 available on my notebook without any adapter plugged in and not serial port available. It is supposedly a virtual COM port inside the chipset for Intels Active Management Technology and trying to access it from LabVIEW through NI-VISA gives strange errors, since the driver supposedly does not support everything that NI-VISA considers a required feature of any serial port. Even if it is your device, you would first have to test it in a Terminal program to be actually functional, then in NI-MAX try to see it and if that works, try to use the Interactive Command Utility to talk to the device and then after all this, you can try to use it in your LabVIEW version.

[Mike576]

Rolf, thank you for the reply. Everything you said makes sense. Here is some additional information.

USB to serial adapter used:

-DTech USB to RS232 adapter (Model: DT-KJ5011-2M, FT232RL/ZT213 FTDI chipset), driver version: 2.12.36.4

I uninstalled and reinstalled the drivers.

Device Manager COM information:
-Port name: USB Serial Port (COM1), Device type: Ports (COM & LPT), Manufacturer: FTDI, Location: on USB Serial Converter, Device status: "This device is working properly.", Device Instance path: FTDIBUS\VID_0403+PID_6001+B001U9M5A\0000

-USB Serial Converter, Manufacturer: FTDI, "Load VCP" is enabled, Power Management: "Allow the computer to turn off this device to save power" is not only disabled, but option is greyed out as well; "Allow this device to bring the computer out of standby" is enabled.

I used Simple Serial Terminal to test connection to adapter. The device instance path matches what Device Manager reports, as stated above. Commands are successfully sent to the COM1 port. Also, a green LED lights up with every command sent to indicate data received/sent. I was also able to echo the COM1 port in a command window.

I noticed that Device Manager shows correct COM settings (9600,none,8,1), but checking the settings in a command window with the "mode" command reported different settings (1200,none,7,1). I corrected the settings through the command window, but still could not connect to the FP-1000.

MAX continues to not recognize the USB to serial adapter.

Does the USB serial adapter have to be connected to the device you want it to communicate with in order for MAX to recognize it? In other words, if the USB serial adapter is plugged into the PC via the USB type-A connector, but the RS232 connector of the adapter is not plugged into anything, should MAX still be able to recognize it under "Devices and Interfaces" in MAX? Knowing the answer to this will help with further troubleshooting.

Does an adapter exist that operates close enough to an actual physical COM port thus negating the requirement of MAX needing to recognize it in order to work with LabVIEW?

Is it worthwhile buying varying types of adapters with different chipsets and build qualities in the hopes one will work?

I would really appreciate any additional incite from you or anyone else reading this. Thanks for your time.

-Mike

[rolfk]

To answer some of your questions:

- MAX can't really detect what device is connected on the RS-232 side. RS-232 as a joke stands for "Resolder pin 2 to 3 and 3 to 2" and that and the electrical interface is the only real thing standardized in this standard. How a device talks, if it ever listens and if it requires a handshake or rather a courteous bow is all up to the device developer and MAX simply can't even start to try to guess which of the many billion variants might be successful.

So the fact that you haven't connected your device to the serial port should not make a difference, actually it might even prevent the serial converter from working properly if the device is damaged or otherwise borked.

- The different COM settings might be a possible indication for some inconsistencies. Each application handles that slightly different and not all query the current settings before assuming some defaults of their own. But yes it might be that one of the setup calls to query these settings is somehow not properly working, and your command line window then falls back to stone age defaults from DOS times while MAX simply throws its arms in the air and says: What it can't even answer that question? That device is damaged or otherwise bad. I won't try to talk more with it!

MAX is relatively sensitive to device drivers not answering basic setup function calls, that it considers mandatory for proper operation.

- It seems you debugged quite a bit and quite thoroughly too, congratulations! The driver version seems to be the latest. Considering all that it would indeed seem that is time to try other hardware. It would seem unlikely that the problem is counterfeit chips in your adapter as the FTDI driver generally refuses to work with such hardware altogether if it detects such a chip, not just when you try to access it from NI-MAX.

So I would try to source another FTDI hardware and another one, which is not FTDI and installing its driver too. First see if the other FTDI device will work, which would be kind of surprising, and then the non-FTDI. Non FTDI could be from Prolific, although Prolific can be a rather spotty experience. Sometimes it simply works, sometimes it is with no might of the universe possible to get it to work in certain systems or sometimes even at all.

I and others here have pretty good experiences with Moxa devices. These are usually connected through ethernet, and setting them up properly can be a little work, but once they are properly installed they just keep working. They are not cheap, but unless you are a student whose time costs nothing (except that you should at some point hand in your report about your experiment rather than how you tried to get a serial port working 😁) two hours tinkering with your current device would have paid for it easily.