LabVIEW
want to use visa read only when bits are at the port
Solved!
@mcduff wrote:
I'll try to answer the questions for my use cases, your mileage may vary:
Why would a standard producer/consumer design pattern not work better here?
Not sure by what you mean here. Is the producer the VISA write and the consumer VISA read? As far as I know, Serial communication cannot be duplexed, ie, you cannot send and receive messages at the same time. The two loops would need synchronization, and have to handle the case for no response from the command.
Then VISA Read just waits around until it sees the termination character (or a timeout, of course). It's also more reliable because it knows when to stop reading (the term char). But I know there are cases when you want to poll.
This is true for most cases. However, consider the case of binary data coming over the serial port, eg, data from an oscilloscope. In this case the binary data may have a termination character in part of its stream. So you may truncate the data unexpectedly. Also, I have had many cases where the instrument response is a multiline string where the termination character is a newline or carriage return, in these cases the data is truncated incorrectly. Admittedly, these are edge cases and not typical cases. So you are correct in your assumptions.
For my use, I like to use the GeneralSerialIO vi I attached earlier. I use it for the following reasons: I do not need to worry about edge cases, it has a read built in, so if there is a message I can retrieve it, but I can use the same vi to set some configuration that does not generate a response. Lastly, I like to use it as a "Stand-alone" vi to test commands that I send to the serial port.
Cheers,
mcduff
Yes, I am aware about binary reads and termination characters. And that's one of the reasons I know of that you have to simply keep reading bytes at port. I am glad that your approach to replying is to assume nothing about the person you are replying to when you know nothing of their skill level, though. I tend to do the same thing, actually.
I've also run into multi-line replies, but it was always that I knew how many lines were coming back, so I would read them sequentially. However, that method would definitely NOT work if you didn't know how many lines you were going to receive.
From what I saw of his picture, it really looked like he just wanted to read data and then act on it, and so I thought maybe he might want to separate the data gathering from the data processing. As it turned out, it was much more complicated than that.
I don't have LV loaded on this machine, but when I get back to work, I'll go download those VIs and see how you do things. I'm sure I can pick up some good pointers. I'm the last person to think I know everything - or even a majority of things - about LabVIEW and how it works.
@matt198717 wrote:
You brought that up because the example i posted had a section for analyzing the data, and you think i should just be using a general producer consumer? I think ill implemant that as well.
That really depends on how much processing you are doing. In the application I have been working on that has this situation, I parse the string to get the various parameters inside of the data message in my read loop and then use an User Event to send that data to whoever needs it.
I will also add that any file I/O typically should be done in a consumer loop since file I/O tends to be slow and can hold up other parts of your program if not done in parallel.
Thats pretty much exactly what i will be doing. I will be parsing the data, logging probably a small portion of it and then performing an action based on the data.
Thanks everybody for all your help. This has been a great thread.
