05-27-2015 11:11 AM
Yep. But your reply was before you saw mine one minute earlier. I'm not trying to read as fast as possible, but at a user-defined, controlled rate.
Cheers!
05-27-2015 11:13 AM
Anyway, I hope Soffi, the OP, reads this and it helps resolve his problem!
05-27-2015 11:21 AM
@Edjsch wrote:
My system is for a "request / reply" protocol, not like HyperTerminal which basically listens for anything being received, requested or not. (Although I have modes in my application where it just listens, but that's a special case.)
Actually, my VI does use the termination character. Because of the delay after the "reading request string" ("String to Write", usually a "?\r") and the fast, known, response time of the instruments I interface with, by the time I start reading the buffer already has data in it. For short replies such as reading a value (about 12 bytes) at high baud rates (usually 115200), the LF has already been received by the time the read occurs, and the read function returns immediately.
I do get your point that I don't strictly need Bytes at Port, but that was in the original examples from NI, and I saw no reason to not use it. Furthermore, some of my commands will retrieve a large, unknown amount of data, so what constant should I wire to Byte Count? What I do is keep looping as long as I'm receiving data.
You are doing a standard "query" - which is exactly what Dennis' method is made for. Follow the directions he specified and you'll be fine. As he mentioned, use something adequate to capture the largest chunk of data. I usually use something ridiculous like 500. I'm pretty sure I read somewhere that the memory isn't actually preallocated so you can use a large number like that with impunity.
But now we're getting into a pet peeve of mine which is why NI hasn't updated their ancient serial i/o examples to include how to properly execute a query using the termination character. I think we can avoid a few terabytes of forum posts if they did.
05-27-2015 11:23 AM
@Edjsch wrote:
Anyway, I hope Soffi, the OP, reads this and it helps resolve his problem!
LOL why did I think you were the OP? Yiiikes...
05-27-2015 12:51 PM
05-27-2015 12:54 PM
Dennis,
Actually, my real application uses a Wait Until Next ms Multiple vi, which takes into account the delay (wait). That way I get accurate timing. But your point is well taken.
Ed
05-27-2015 01:11 PM
Billko,
Some of the instruments I interface with can sent 10,000 readings (from its memory), which is more than 100,000 bytes, so 500 wouldn't work. I suppose I could wire a +inf, but connecting the Bytes at Port to the byte count input works just fine. I loop until Bytes at Port = 0. With your method I'd have to wait for the timeout, which is usually at least a second. The default is 10 for the VISA config vi, which is unacceptable. While looping (with a 3 ms wait to insure there will always be data in the Rx buffer, which I've set to 32K so it doesn't overflow - but yes this is application dependent) I use a feedback node to concatenate the newly received LF-terminated string with the previous, and send that to a string indicator (which is essentially a terminal window as in HyperTerminal) or can be put into a table.
There is usually more than one "right" way to do things. It depends on the application.
Ed
05-27-2015 03:23 PM - edited 05-27-2015 03:29 PM
I take back what I said about 500 not working. It would, as long as a termination character was received within that number, which it would. But I'd still wire Bytes a Port == 0 to the Stop button of the While loop. Otherwise, you'd need code to handle the timeout error.
I display a dialog box if no response is recieved from the instrument, so I never can get the timeout error. But I do have a Simple Error Handler and Clear Errors vi in series with the Error cluster at the right side of the While loop, not implemented in my example.
05-27-2015 04:38 PM
@Edjsch wrote:
I take back what I said about 500 not working. It would, as long as a termination character was received within that number, which it would. But I'd still wire Bytes a Port == 0 to the Stop button of the While loop. Otherwise, you'd need code to handle the timeout error.
I display a dialog box if no response is recieved from the instrument, so I never can get the timeout error. But I do have a Simple Error Handler and Clear Errors vi in series with the Error cluster at the right side of the While loop, not implemented in my example.
So in this example it's supposed to read until you tell the instrument to stop taking readings? It would probably be better to morph this into a state machine where you tell the equipment when to stop and tidy everything up (in the exit state).
05-27-2015 04:42 PM
My example vi takes readings if the Write & Read boolean is True. That would be used in an application to start and stop reading the instrument.
In my posts about downloading 10,000 readings from the instrument's memory, a command instructs the instrument to output all of its memory. When it is complete, no more bytes are received at the port, so the While loop terminates.