probe causes error

[dsavir]

Hi,

I have a while loop that reads data from hardware and sends it (via queue) to a processing loop. In parallel, but much slower, the processing loop averages and displays the data. Because I had some problems, I probed the error wire in the read loop. When adding a probe, I have read errors caused by data overflow, i.e. the read loop is not emptying the hardware buffers fast enough. How much does the probe slow down the read loop? If I can't use probes or highlights (as that slows down the loop even more, obviously) how can I debug this code?

Thanks,

Danielle

[P@Anand]

I don't think your probe is causing this issue. How fast you are reading from the hardware and Are you not getting the error when you are not using a probe?. Try posting a snippet of your code for a better understanding.

[dsavir]

Attached the snippet as requested.

All the initialize etc. happens before the loop. In the loop, I read untill there is data in the buffer (inner loop) send the data to the display loop (in the subvi) and read again until done (until the boolean is TRUE). I tried to probe the error in the inner loop.

To begin with, we had some hardware problems. In order to debug and correct, I used probes. However, today I noticed that when I use the probe, I get an error relatively quickly. Sometimes the code runs well for a long time with the probe and casues no errors at all. 

Now I'm mainly confused 😞

Thanks,

Danielle

[smercurio_fc]

I am also confused. Because I see no parallel loop. I see a loop inside another loop. That's not a parallel loop.

A probe would not be causing your error. Your error is being caused for the exact reason stated in the error: you are not reading the data fast enough.

[dsavir]

Hi,

there is a misunderstanding. I didn't post the parallel display loop, only the read loop. The subvi there sends the data to the display loop which is a pallel loop and is not shown.

The question was whether the probe could slow down the read loop so that it would not read the data fast enough.

Thanks,

Danielle

[P@Anand]

No Probe will not create any delay in data transfer or loop iteration. The worst thing can happen is if the loop is running at a very high rate then there are chances for the probe not getting updated.

[dsavir]

Hi,

Then why are there more errors with the probe than without?

Thanks,

Danielle

[P@Anand]

Are you sure that when you are not using the probe you do not have any error? I guess it should be happening by other means. What is the error message you are getting? Just keep ann indicator for the error source and keep the probe ( as you said it should through error) then post the error source.

[dsavir]

Hi,

The error source is the read from hardware VI.

There are errors also without the probe, but there are more errors with the probe.

As you said that I am not reading the data from the hardware fast enough, is there a way I can reliably do so? Without a probe it fails roughly once every 10 measurements. Is there a way I can prioritize the read loop over everything else? I already added a delay to the display loop, but if I make the delay too big the display takes too long to update.

Any suggestions?

[C-Dav]

Danielle,

I noticed you mentioned you were sending the data to your parallel loop via a queue, but I don't see where you intialized the queue and enqueued elements.  It's entirely possible that after you've read the data from the buffer and are sending that data to the display loop via SubVI, the data is building up and an error is being thrown.  As far as why your probe would be exacerbating this bahavior, that seems odd.

What version of LabVIEW are you working with?

Regards,