read serial without polling

[isaoz]

Hello Dennis,

You are  absolutely right, the while loop around the VISA events is not needed. It was just an artifact of a previous VI iteration. But since no timer VIs were in it, its contribution to the speed loss was negligible. I did move the VISA enable and disable event VIs outside the while loop, and that made the difference. I sort of questioned that myself, but somehow the instructions seemed to advise enabling and disabling on every iteration. Now, I have one more problem. In time the data is arriving increasingly delayed. You can see I have even reduced the buffers and queues to as low as 2 bytes in an attempt to force the data to get lost than pile up if necessary. But it made no difference. Any ideas what is going on? I have also tested it without the code that tests for queue overflow, error -1073807315. That was added so the VI continues working even if the queue overflows. I have also tested it in both synchronous and async mode. I have attached the last version. The flush buffer VIs were also tested lined before the VISA event enable with no change in performance. Data delay gets into minutes and I also see intermittent interruptions of data flow. 

[Dennis_Knutson]

Without the actual hardware, it's hard for me say what might be going wrong. Frankly, I usually just use the VISA Bytes at Serial Port without the VISA Event and if I know the instrument is terminating the data, I'll just use a VISA Read with a high number for for the expected byte count. The VISA Bytes at Serial Port is just extra overhead if the data has a termination character at the end.

[isaoz]

The hardware is a simple microcontroller hardware I put together for testing. It writes a 3 digit #, CR  and LF every preset period. For the latest test, I increased the period from 5ms to 10ms. So It sends a number at about 100Hz.

I tested your suggested VI. LF termination character and 7 bytes to read. It is simple, it works and no latency. And SURPRISINGLY the CPU usage does not change noticably when I run the VI. The very reason I was interested the in the VISA event VIs. Thanks a lot for your help so far, but I have more questions for you.

1) How can I verify that the data is indeed arriving at 100Hz? The MS timer difference scheme does not seem to work well. I am getting a lot of zeros with flashes of unrecognizable numbers. Is the OS capturing a bunch of data and dumping them at once? I would like to have some means of knowing all data is being captured and displayed in a timely manner.

2) Forgive me for beating a dead horse, but any idea what the source of the huge data latency was in the previous patch? I have come across this problem before and I would like to understand the mechanism of the serial device. I was not using VISA events in past when this happened.

[O_Proulx]

Hello Aro,

1- Can you post a screenshot of the values you are getting from the mS timer difference scheme?  It seems you are using the VI's correctly and this is the way you could measure the rate from LV.  Please note that these will only give you a 1mS resolution.  You will only be able to measure that your data is coming in terms of milliseconds.  If you increase the rate of the data from your micro-controller, you may not be able to accurately measure it on a Windows machine.

2- I do not know exactly what is cause the delay, but you will need to close the handle from the event if you wait on an event.  You can refer to this knowledgebase article for more information.  This may also explain why the wait on event is inside the loop.   However, as you mentionned, this may be taking you back in the wrong direction if your system is now up and running.

Have a great day.

[isaoz]

Hi O. Proulx,

Sure, I have attached a couple of screen shots along with the VI. BTW, I added the case structure around the MS timer in an attempt to filter the many zeros from most iterations of the while loop. I have of course tried it without the case structure at first. Most iterations display as in niScCap1 with some flashes of the niScCap2 type. As a work around temporarily, I have made another VI that takes the average of the last 8 values and I am getting a number close to 10 with some flikers showing numbers around ten. I also tried to attach an avi movie but I discovered there is a 3 attachment limit, anyway the capture must have changed something as the zeros did not show as often in the movie.

Regarding the knowledge base article, the VI is slightly different from the one you gave me earlier so I will test it to see if it makes a difference. But it does make the point that the 'wait on event' must be closed in each iteration, which I think is the cause for the slow down to only every 100ms.

[MilanV]

Hallo,

VI_ATTR_ASRL_AVAIL_NUM flag can be used in order to determine the amount of data in the input serial asynch. COM buffer, but what about determining number of bytes in output buffer ? Is there any VISA function which query number of bytes in output buffer ?

BR,

Milan.

[Eric_K]

Milan,

With a question like this, the best approach would be to make a new thread for your new question, which I can see that you have done on this duplicate post.  Once you have done that, there is no need to post on 9 other threads to ask the same question.  Please see the duplicate post for the answer that SFK has given.

Thanks,

Eric K

[MilanV]

Sorry Erick,

I am new on this forum so I did not now the rules. I did not send on 9 threads 🙂 but I got the point...

Sorry again and regards,

Milan.

[Eric_K]

Milan,

I am sorry if I overstated in the number, I just saw that you had 9 recent posts that seemed to be very closely related. In any case, Welcome to our Forums!!   I think (and hope) that you will find our forum to be very active, and that you will receive responses to almost any (hopefully all) new threads.

Thanks for being flexible, and again, Welcome!! I hope you will find our forums to be a valuable resource for any of your questions.

Eric K