LabVIEW
corrupted serial data when reading
Here's a quick example of what I mean. It is far from complete or fully functioning for what you need. It is an example. You will have to format your data however you want before writing it to file.
@Ranjeet_Singh wrote:
hi @Dennis_Knutson,
May be my words are wrong, what i mean to say is here attached, As i mentioned earlier if the device is sending the data continously in the interval of sec then this can be done. delay is useful when there is some master slave type of communcation, then closing & opening will work perfectly. And you need delay eventhough termination character is there. Depends what is your application job. If you read the data serially inside the while loop with no delay & read VISA believe me sooner or later this will cause problem.
No. You don't want to keep opening an closing the serial port! All you do when you do that is waste resources and put things in funky modes. Open/setup once during program bootup, read as much as you want repeatedly in main loop, close once during program shutdown.
@Dennis_Knutson wrote:
The image proves what I said. LabVIEW is a dataflow language so the close will only happen when the loop stops - exactly what should be done.
Fixed delays are often a lazy way to program. They also can result in buffer over runs as well since you do not read fast enough. Believe me, written carefully and with an understanding of the instrument, you don't need them.
True enough. I can think of only ONE instance (out of countless times) when a careful understanding of the communication needs of the equipment was achieved, that I could NOT eliminate hard-coded waits - and that was a power supply that was so dumb, the programming instructions specifically said "The average command processing time of the ZUP Series is 15mSec. It is not recommended to send strings of commands to the ZUP power supply without considering the processing time." In other words, hard-code a wait of at least 15 ms in between commands.
