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

[3d0g]

This thread results from a search that yielded four results in the forum (LabVIEW community.)

It seemed reasonable and not a waste of time to at least ask, as it runs alongside another question I ask as I do things with LabVIEW.

It has been said to me that anything that can be done in C can be done in LabVIEW, as LabVIEW is rooted in C.

...as is the WinAPI...

Now some may ask, why in the world would you ever want to use Windows to handle serial communication when LabVIEW has so many VISA-based functions just waiting there to be used?  MAX has its aliases and it's so easy!  Why use CreateFile() and such?!

Here's the scenario:

A USB serial device has just been attached to the system, from out of the blue.

Windows has enumerated it and has produced COM147.

Now what?

Using C, it's no big deal.  Open the port, define the setup, use the port, and then close it when you're done.

How about LabVIEW?

Is it just as easy?

Asked another way, should I use LabVIEW or C (ok fine, C++ too) to solve this?

If your answer is LabVIEW, then please explain.  (Don't just post a link and say "here read this."  No, actually explain at least a little bit how it'll work.) 

This is the decision I am making, and yes, I'll appreciate your input.

(thought of a better title. not sure if I actually replaced the title or not, though.)   

[3d0g]

make that CreateFileA()

oops!

[3d0g]

I have a philosophy (algorithm?) I follow:

You are welcome to laugh at me, mock me, and even call me stupid, but if you do, then you'd better have my answers.

[rolfk]

---

@3d0g wrote:

I have a philosophy (algorithm?) I follow:

You are welcome to laugh at me, mock me, and even call me stupid, but if you do, then you'd better have my answers

---

I find this kind of provocative stance fairly counter productive. You have a problem and want help with it and repeatedly dismiss or overlook suggestions and recommendations or outrightly misrepresent them. Try to be more constructive and carefully read the posts you react on. it will benefit your cause.

[billko]

I don't understand the question.  Just use the right tool for the job.  If the rest of the code - and I assume the top level code is going to do more than open and close a serial port - is written in C, it is only natural to to your serial code in C as well.  Same case for LabVIEW.  If my answer didn't make sense, I apologize, because the question didn't make sense to me, either.

[*3d0g]

roflk, I've read this forum for a long time, and I can't tell you how many times a person has asked a question only to be... In the end the person's question isn't answered. Much is said but the actual question that was asked isn't answered.  I don't like that.  That's where I was coming from with what I said; I sought to prevent that with my posted question to the forum.

continuing

I'm thinking your answer to my question of yes or no for using the winapi for serial communications is no, but I don't know where you're coming from, and I want to hear about it, relative to the scenario I gave, the issue to be resolved. My assumption is you've dealt with the scenario, from your experience with LabVIEW. 

[*3d0g]

rolfk: My apologies for messing up your handle, again. rolf k rolf k I'll get it.

billco: Thank you for clarifying you didn't understand my question.  My question is this.  Given the scenario I gave, as an experienced LabVIEW programmer, what would you do?  I'm not as experienced as you.  Perhaps you can see COM147 and say, "no problem!  I know how to work with that!"  But I can't, not in LabVIEW, and that's what the question I posted is about.  Are you saying, "no problem!"?  I hope so.  It'll reduce the complexity if you can. If not, then complexity it will be.

Do you understand the question, now?

[LLindenbauer]

It looks like the question is "How can I find out which COM-Port my device is attached to?"

To which the answer would be: "Can you tell us more about your setup, requirements, and if you are able to change them?"

The simplest solution is surely to just connect to the only device that is there. If there are more devices, it quickly becomes a problem to be better solved on the design level, rather than with code.

This question comes up about once per month in the forum and it has been solved for a wide variety of setups and requirements. From you mentioning the port assignment registry entries, it seems you have done the research already. Which prompts the question: Why are you doing this? If it is out of academic curiosity, please just state so - you will get better answers that way.

[rolfk]

I asked you if you have tried VISA Find Resources.

That VISA Find Resources should do a re-enumeration of resources on your machine. It is the main reason why it is so slow. You simply said you didn't try and dismissed it.

[*3d0g]

I'm disappointed. I figured I could return later and find out from someone more knowledgeable how to use LabVIEW and VISA to communicate with a serial port brought in on the fly, a serial port, USB-based, which Windows had enumerated and was ready to go.

It has been my experience that ASRLn != COMn. What I'm saying is I have personally experienced MAX showing an ASRL number that did not agree with the COM port number. Therefore, I cannot trust the ASRL number is the COM number.

However, if there is a way to (I'll use the word) tackle this scenario I'm presenting, I certainly would like to hear about it. I know I can do it in C, as I did it yesterday. Likewise, I'm well on my way in translating my working C to working LabVIEW (it's 80% done); only I am using the winapi (CLFNs w/kernel32.dll) to do it, not VISA. Others seem to be saying it'd be easier done using VISA. But what I know of VISA, which I admit is not a whole lot, is it uses ASRL to identify serial devices AND those numbers do not always align with Windows' numbers, for starters.

Oh well, maybe there'll be answers when I get back. 😞