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

[3d0g]

However, I do still want to know what that #1 bug is about, if you know. (fOutxCtsFlow)

[3d0g]

You got it, Martin!  I just added the last part, and it works! Many thanks.

So what can I do for you? How many points can I give you? How does it all work?

[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!"

Well, now that the issue's been resolved, I'll return to this briefly.  When I think "typedef" I also think "another file."  Also, I think "another file that if missing causes the vi not to work and the user to be upset."  Also, I think "an extra file a user could c&p in erroneously."  But it all can be summarized to "an extra unnecessary tag-along file." Here the vi stands and (thanks to Martin) runs alone.  Now I realize I just caused all of LabVIEW to cringe from spewing such typedef sacrilege; nevertheless, that's how I see it.

Then, shift registers... They have their place.  Clusters in shift registers is reasonable.  ...if I don't mind horizontal lines running across all my states in my state machine.  Once again, I'm going to burn in the fires of LabVIEW, but I actually like local variables. Then again, I come from a background of 10 PRINT "HELLO WORLD"<CR>20 GOTO 10<CR>RUN<CR>:-)

In the end, the vi is exactly what it says it is, nothing more nothing less. It's a "simple_com_cx.vi"  If you listen to that that reads: (it's a) simple COM (port) communications vi. I'm not going for LabVIEW awards. I wanted a simple vi that I could understand and follow step by step into operation. ...and couldn't care less how lost VISA would've been -- I don't have to worry about making VISA happy, now -- I have to worry about making Windows happy.       

[Martin_Henz]

---

@3d0g wrote:

However, I do still want to know what that #1 bug is about, if you know. (fOutxCtsFlow)

---

I assume you missed, that fBinary to fDummy is a single 32 bit unsigned integer. Most of the values are only 1 bit wide. fDtrControl and fRtsControl are two bits and fDummy2 are the 17 remaining bits.

Your encoding and decoding of the DCB structure is wrong. You use 4 bytes for each of these bitfields.

[*3d0g]

Hmm...

Let me look into that, more. Thank you. Very interesting! I'm very happy to have met you, Martin.

[rolfk]

---

@Martin_Henz wrote:

BTW: Your code uses synchronious communication, which is in most cases not the best option. 

---

While you are technically correct, you do not want to propose to use the LPOVERLAPPED parameter from LabVIEW! Asynchronous programming is even in pure C quite a pain for anyone who is not an advanced C programmer and the Windows API method of it offers two possibilities, either callbacks or event objects.  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.

But its still a pitta especially if you want to support both 32-bit and 64-bit.

One more of many reason to seriously question the decision to want to go the Windows API route in spite of any good advice.

[*3d0g]

"One more of many reason to seriously question the decision to want to go the Windows API route"

I hear you, rolfk. Believe me. I hear you.

[*3d0g]

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.

[*3d0g]

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.

[*3d0g]

This has become a good thread, to me, and I thank you all for supporting it with your valuable insight.