LabVIEW
LabVIEW serial port programming using the WinAPI and CreateFile() and CloseHandle()? Yes or no?
Solved!
@3d0g wrote:
What's the real reason I want help with my code? What kind of a question is that? I'm here. I have an issue. In the past I've been told to post my code lest I (or others have heard it) can't be helped. (Frankly, I find this forum more helpful than NI. Did I say that out loud?) I have now posted my code. There is a problem with it, and I still have yet to get it debugged. That's the reason I created this thread. If you want to get deeply philosophical about it, I exist. Frankly, I'm trying to learn and I need to learn and I don't learn by being sent away to go read something or download things. I learn by getting those more experienced than I to show me my error, how I went wrong. Now please help me by examining my code.
Incidentally, if I find my error, I will be sure to post it, here, in this thread.
The "kind of question" you refer to above is the kind of question that gets asked when someone wants to do something in a strange and non-standard way and their benefactor(s) are hoping that, by understanding the reason behind the strange request, they can help them to an alternative solution.
Are you saying that you want to connect to a COM port with a known "COM" address? You can just use a string control with the name "COM123" to the "VISA resource name" and it'll connect.
@3d0g wrote:
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.
Yeah this is wrong. It can use ASRL but doesn't have to. It uses COM port numbers too. I've used VISA for more than a decade and have used the ASRL format in maybe two instances. I always just use "COM9" or whatever as my VISA resource name.
Also I will echo the rest of the people here... you're being REALLY combative for people trying to help you for free. The fact that we're on page 3 and we're still trying to figure out what you're trying to do indicates you haven't posed a clear question.
At first: I don't know which communication parameters you want to use. It looks like 7 data bits, 1 stop bit, no parity and no handshake and no termination character.
The FileWrite() is wrong - your code write the pointer address plus some more bytes. Change lpBuffer to Numeric, Unsigned Pointer-sized integer, pass Value
With this modification, the vi transmits the correct string:
BTW: Your code uses synchronious communication, which is in most cases not the best option.
negative 😞
The issue being debugged is threefold.
1. Why is fOutCtsFlow B1 and B2 needing to be $02 $07, respectively, such that I get success from ret_set_comm_state? (Those are bytes 1 and 2 of the DWORD.)
2. Why does it take two shots to get even a decent looking RXBuffer?
3. Why can't it be the correct RXBuffer contents as opposed to just decent looking?
Clearly my code is botched somewhere.
Also, to address the comm state for you.
What you have there is a choice between what it got (in the get comm state, state) and what you want it to be (in the set comm state, state.) Now, I have to explain, getting it to what you see there in the default values you see was not the easiest road. Basically, I ended frustratingly just dumping LabVIEW and firing up the LabWindows/CVI. I wrote what I wanted in C, got it working (didn't take too long, frankly,) and then used those verbose results to fine tune that set and get comm state part into operation. Once it was in operation, then I felt I was getting some where.
Look out to the far right, and you'll see the number of bits is 8, parity is none, stop bits is none. Look to the far left and you'll see $80 25 00 00, little endian for 9600 baud.
It wasn't so much about exactly what I wanted. It was about how I could take what it gave me, which it rewrote just fine, which proved my code was likely sound, and then finesse it into the config I needed, enough that it was useful. (My C code's output was the key.)
Seriously, thank you for reading my code, Martin! ...and that THIS IS A TEST was a nice touch, 🙂
