LabVIEW serial port programming using the WinAPI and CreateFile() and CloseHandle()?

[*3d0g]

By the way, detecting the new port is not the problem at all.  I know exactly what COM port I want.  It matters not how many viable ports are there but where devices are not. I know the exact new out-of-the-blue running and ready port, thanks to the registry as was said, prior. This is the time for LabVIEW w/VISA to shine, but it doesn't look very shiny, to me right now. That's what this thread/my post is all about -- I came here pursuing an algorithm. Please cause LabVIEW w/VISA to shine for me. Thank you. 

[Kevin_Price]

True, the ASRL# and the COM# don't always agree.

But LabVIEW's VISA functions can accept either notation.  So at the risk of gravely oversimplifying this whole discussion, have you even *tried* using VISA in LabVIEW to open your port using the "COM#" syntax?  I almost always use that notation myself.

On the other hand, I don't think I've ever seen a serial port get enumerated with a 3-digit number, maybe you're bumping into some limitation I've never encountered.

-Kevin P

[Martin_Henz]

---

@Kevin_Price wrote:

have you even *tried* using VISA in LabVIEW to open your port using the "COM#" syntax?  I almost always use that notation myself.

---

VISA "COMx" is an alias for "ARSLx::INSTR". The situation becomes difficult, if the "ARSLx::INSTR" dows not match to COMx of the operating system.

To be more concrete:

The standard assignment: ARSL5::INSTR is equal to COM5 of the operating system (=system name) and the default VISA alias is also COM5.

But in some cases (I personally never saw this in the past 10 years or so)

The ASRL5::INSTR is equal to COM12 of the operating system and the VISA alias is also COM5.

Such a situation makes it very difficult to get the correct VISA resource name for the systems port COM12.

[*3d0g]

Exactly!

I deal with three digit COM numbers, routinely.

Now the situation is out-of-the-blue enumeration of such. But like I said, I have the C, now, I also, now, have most of the LabVIEW done, but what I'd really like is to at least hear about the LabVIEW+VISA algorithm, from veterans here. It would appear to me, even though I don't know it, that it'll be much more complicated than the above mentioned were I to use it.

Thank you to you new posters out there, for supporting my thread/post/subject/issue. (Relatively speaking, to rolfk for instance, I'm new here, and I don't know the terminology you (plural) use.  I call it a thread.)

[rolfk]

---

@*3d0g wrote:

I deal with three digit COM numbers, routinely.

---

That's because Windows has a somewhat strange way of enumerating new Plug&Pray hardware. It uses the PCI and USB bus and device number on which the device is connected and its serial number to determine if it is a known device or not. If any of these things is different it will consider it a new unknown device and assign a new never before used device ID (in the case of a serial port this is a COM port number). You can argue that this is pretty useless especially if you have a unique serial number anyway, but in the case of USB devices many manufacturers prefer to avoid creating new serial numbers anyways as that is one extra step during the final product test step, requires some database management connection for the generation of unique serial numbers and of course causes the test to take a few seconds longer. Why bother with that problem? It works anyhow without a unique ID!!! Sort of!

The average customer prefers to have a device that costs half a dollar less than such a feature.

[rolfk]

One way to get rid of those excessive COMM port numbers

https://www.digi.com/support/knowledge-base/removing-unused-com-ports-from-windows

[*3d0g]

In C yes.

In LabVIEW, not yet. Something isn't right. If you get a chance, please give it a look. Thanks!

Therefore: (this is 2014 version)

[*3d0g]

I'd bet I botched the memory management. Please fix. 🙂

Thank you!

[GerdW]

Hi *3d0g,

I recommend to place all those controls/indicators into a typedef'd cluster, maybe some sub-clusters related to the items on those tab pages.

Then handle that cluster in a shift register!

I'm getting angry when there is a "handle" local being predefined with some arbitrary U64 value…

[rolfk]

---

@*3d0g wrote:

I'd bet I botched the memory management.

---

That bet is a very safe one! But it's a learning experience. 😁