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

[rolfk]

---

@*3d0g wrote:

I was hoping to get an answer to my "red dot" question (not to you), earlier, but so far nothing. LabVIEW has to make that conversion. As a rule, as of about two years ago, I never let a red dot remain.

---

That rule is usually a good one but if taken as a holy rule that can not ever be violated, it is making your job a hell!

A string is compatible to a VISA resource but it is NOT the same. Hence you get that coercion dot. LabVIEW indeed does some extra work there and that dot indicates that.

As a modification to your rule, red coercion dots are really bad if they happen in array data. They "should" be avoided at all cost (but even that is not always a holy rule, which is why I used "should"). For scalar data it is usually not really a problem although it can indicate that you did something in a way that may be suboptimal and there might be other and better ways to handle things. In this case it is legit and not indicating a problem. Just a hint that LabVIEW indeed does a little more work than just treating that string as a string only from there on.

[BertMcMahan]

If the coercion dot is really rustling your jimmies just use Coerce to Type:

[rolfk]

---

@*3d0g wrote:

And, if you notice, the (small, but monster) error in my code that Martin caught was one of those "adapt to type" gizmos. 😉 That was a troubleshooting (there were half-dozen variations, prior) leftover that I missed. Again, I'm hesitant to even use that thing. I'm trusting LabVIEW to think correctly with using that. I don't like that.

---

You're interpreting the Adapt to Type completely wrong! What it means is that LabVIEW simply passes the parameter in whatever form the datatype is natively represented in LabVIEW. It does not and can not even remotely guesstimate what your DLL might want to have for this parameter.

Basically with Adapt to Type you tell LabVIEW:

Please don't do try to do anything with this parameter, just pass it in whatever format you use internally. I ASOLUTELY know what I'm doing and I will make sure that my DLL knows that too and that it will expect the data you internally use.

Basically that is only ever true if you:

1) Write the DLL specifically to work with LabVIEW data types

2) Preferably create the Call Library Node with this setting and then right click on it and select "Create C code".

3) Use the generate C code file as a starting template for your function prototype, treating the data always as LabVIEW data and using the correct LabVIEW memory manager functions whenever you want to create, resize or deallocate arrays and strings passed in such a way!

In some cases you can turn this around by creating VERY CAREFULLY a cluster in LabVIEW that matches EXACTLY the memory layout of the C structure and then pass this cluster as Adapt to Type. However it is absolutely YOUR responsibility to make sure the LabVIEW cluster matches the C structure layout. LabVIEW has NO way whatsoever to query the DLL for what a parameter needs to correspond to. And the import library wizard is not much more than a wizardry apprentice that tries to guess these things from the header file syntax and might get things right or wrong.

[*3d0g]

You definitely deserve a kudo for that last, but it isn't working, for whatever reason. I'll get it to you when I get a chance.

Also, no update today and it's safe to say no update tomorrow either, as I had a higher priority issue come up, today.  (I juggle many things and this is but one.)

[BertMcMahan]

Just want to say this again because it doesn't seem like you're responding to the multiple people saying this- why are you using the WinAPI, when VISA connects using the "COMxyz" format just fine? It's about a billion times easier than what you're trying to do.

[Martin_Henz]

---

@rolfk wrote:

Use of a callback function is an antipattern with the LabVIEW Call Library Node and the alternative to use an event in that structure is only slightly better although technically feasible if you know what you are doing.

---

Hmm ... I almost agree. My comment about async. communication was more intended to make things a little more challenging for 3d0g 😋

[Martin_Henz]

---

@BertMcMahan wrote:

Just want to say this again because it doesn't seem like you're responding to the multiple people saying this- why are you using the WinAPI, when VISA connects using the "COMxyz" format just fine? It's about a billion times easier than what you're trying to do.

---

As rolfk wrote in another thread, After some years of ugly issues, which is a long time ago, the serial port communication with VISA works very well for 99.9% percent of all cases (I personally see it more at 99.5%). But If anyone has such an issue, there are only two alternatives: starting a DIY project or using my library. 3d0g decided to go the DIY way.

Who hasn't started a DIY project, even though the result is perfect and ready in the shop around the corner?

[billko]

---

@Martin_Henz wrote:

---

@BertMcMahan wrote:

Just want to say this again because it doesn't seem like you're responding to the multiple people saying this- why are you using the WinAPI, when VISA connects using the "COMxyz" format just fine? It's about a billion times easier than what you're trying to do.

---

As rolfk wrote in another thread, After some years of ugly issues, which is a long time ago, the serial port communication with VISA works very well for 99.9% percent of all cases (I personally see it more at 99.5%). But If anyone has such an issue, there are only two alternatives: starting a DIY project or using my library. 3d0g decided to go the DIY way.

Who hasn't started a DIY project, even though the result is perfect and ready in the shop around the corner?

---

But AFAIK, there was no mention of any problem with using VISA to communicate, only a desire to use this convoluted approach.  All requests for information on the problem appeared to be pointedly ignored.

[*3d0g]

I still haven't figured out how one knows where a post is directed, here. So

Bert: Thinking about my need and how I'd handle it, I did some playing with VISA, looking at what was available and how I could do what with what.

I found I couldn't determine a new port from a sea of ports that was a sum of connected and disconnected devices -- perhaps I didn't have that key special option selected which would've worked. I also was able to fool VISA into thinking a USB-RS232 converter was 32-relay card -- it proved to me VISA was totally dependent upon Windows and its memories of what it knew prior as said by Windows. I then dug up some information from NI with respect to handling blind discovery of a new port and after reading it a bit, while in the back of mind knowing for a fact that ASRLn != COMn (boy that was a nice surprise that day back when!), I tired, frankly, and put down the NI doc and went to web seeking alternatives. On the web I found options via Windows. I tested those options, was pleasantly successful, wrote a few decent vis, and then all I needed was the COM interface to work. Martin helped me out tremendously the other day with that simple find he made. Now I can work with a COM port completely independent of VISA. (Granted, it isn't perfect, yet -- haven't had the time, but I will. There is light at the end of the tunnel and it isn't a train.) I guess you could say I don't trust VISA but so far. I can't tell you how many times I've seen VISA crashes -- granted it wasn't my software, but still... If I'm working independent of VISA, that's one less hassle to deal with. Perhaps when I have more LabVIEW experience I'll be more trusting. I trust Windows, because I have to trust Windows. LabVIEW is dependent upon Windows, always. Somehow I'm thinking I should've thrown a paragraph in there somewhere. Oh well.

[rolfk]

---

@Martin_Henz wrote:

Who hasn't started a DIY project, even though the result is perfect and ready in the shop around the corner?

---

It’s called the NIH (Not Invented Here) syndrome. It’s highly contagious among engineers and incurable. 😀

Sometimes an individual spontaneously recovers from it, usually after an exceptionally painful case of head banging connected with massive project budget excesses and delivery time delays.