09-21-2016 07:08 AM
Thinking this might work. Can't check it now because the equipment is running.
09-21-2016 07:41 AM
You must put a delay between the property node and the Visa read function. Without this, the buffer won't have time to receive datas.
09-21-2016 07:48 AM - edited 09-21-2016 07:48 AM
@Michael.C wrote:You must put a delay between the property node and the Visa read function. Without this, the buffer won't have time to receive datas.
No. Not true. Typically you would see a delay between a VISA Write and a Bytes at Port to give time for a response. No need for a delay between Bytes at Port and a VISA Read.
The correct solution to this problem is what Crossrulz stated. DON'T use bytes a port, just use a very large number at the VISA Read and allow the termination character that is present in the message and has been enabled at the Serial Port Configure to do its job.
09-21-2016 09:06 AM
One thing you can do: Monitor the output in raw mode to see if the /03 characters really appear or not.
I add a Q&D monitor vi I once wrote. Configure the rs232, gnore the modem-line settings, run it and look at the data comming in 😉
09-22-2016 03:34 AM
Here is my new corrected code. Seems I made several mistakes’.
It was my intention to concade output from visa and split it into array and loop through elements until number is found.
I think it's working now.
Henrik I didn’t use your code, since I don’t send any data to balance. The balance is constantly sending by itself.
I tried to look at concated output, though.
Often "k" or "ks" is sent. But ONLY when I use labview. When I use my normal terminal test program, not written in LabVIEW I get only number. Weird.
09-22-2016 05:00 AM - edited 09-22-2016 05:01 AM
Few things to note:
1. Since you are using the termination character to get a full message, there is no need for the whole concatination and search mess. When you have a full message, you can extract the value and units out.
2. Are you sure the parity should be "None"? Typically if you are only using 7 data bits, there is a parity used for that last bit in the byte.
3. I just realized that you are doing this whole thing just for 1 measurement. Serial communications work best when you keep the port open and you constantly read the data coming from the instrument. Just use a queue, notifier, user event, global variable, etc to send the read value to another loop who needs it. By opening and closing the port constantly, you can get into some weird synchonization issues.
Which brings up another question: how quickly is the instrument sending the data? Specifically, is there any gap between the messages? I had to interface with an instrument that had no gap between messages and it was a PAIN to get the communications to work correctly, even with a terminal program like putty, due to some of the most bizare synchonization issues you could imagine.
Anyways, here is a greatly simplified snippet for what your code should really look like
09-22-2016 08:10 AM
I’m pretty sure that the parity is none. I tried all other parities.
I will try opening the port in start off the measurements end close it ending measurements.
I also considered that myself.
About the sending speed. Its fast ! Several pr. seconds. Tried to decrease that with no luck. Will try again.
As it is now I need “the whole concatination and search mess. “ as I see it. Often the output is like this “k LF 3102.2 LF”
(LF = linefeed)
Will return, hopefully tomorrow 🙂
09-22-2016 08:12 AM
Obs: forgot your code - Thanks !
Will try it when the instrument is free 🙂
Maybe I don't need the interation then
09-27-2016 09:10 AM
Seams that it’s when opening the port that things go wrong.
Approximately every fourth time.
I receive a “k” or nothing and it will stay like that until the port closes and opens again.
So if the error occurs I wont get any data before having opened and closed again.