LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

beep delay

Solved!
Go to solution

Hi all!

I have this simple subVI that gets a desired set of (X,Y) coordinates, the actual X,Y coordinates of an object, and a tolerance. The subVI is supposed to beep (using beep.vi) if the object is within the tolerance zone.
I use this subVI in a loop which constantly gets the actual coordinates of the object, so I expect to hear a beep every time the object passes close enough to the desired location, or continuous beeping sounds if the object stands in place inside the tolerance zone.
The thing is that I would only ocassionaly get a delayed beep when the object makes a pass at the spot, and if it gets into the tolerance zone but stays there, the subVI won't beep at all (until the loop is stoped).
I added an LED to go along with the beep (to make sure everything else in the code is alright), and it works just perfect.

 

Any ideas what I'm doing wrong?

Download All
0 Kudos
Message 1 of 10
(4,146 Views)

Hi shayelk,

 

could you attach your VI in LV2011?

 

The distance is calculated more easily using complex numbers:
check.png

Note: this will check for a circular area around your target point, whereas your routine checks for a rectangular area due to checking both x and y distances…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 10
(4,135 Views)

I don't see anything wrong with the VI you attached so the next logical place to look is at how you're calling the subVI.  Your description ("continuous beeping") suggests you're calling it as fast as possible. Is there any "throttling" in the calling loop?  In other words, is there something in the calling loop (like a wait function) that prevents the subVI from being called at a very high rate?  What happend if you wire constants (contrived to cause a beep) to the subVI inputs?

 

I don't knwo the details inside the "beep" function but it acts like it is a non-blocking function, which is to say that LV can go on to other processes while the "beep" code is being executed. It feels like maybe the beep is being called frequently enough that it can't execute before the next "request to beep" comes in.  Try putting a 5ms wait function inside the case structure next to the beep VI and let us know if that affects the symptoms you're reporting.

Message 3 of 10
(4,129 Views)
Solution
Accepted by topic author shayelk

I could not see your VI but try adding delay to your loop (execution). If not possible, use a flag to check whether to beep or not and put beeping in other while loop and add delay to that loop.

 

something like snippet.

 

Beep.png

 

 

With Regards

Miraz
Kudos is better option to thank somebody on this forum
------------------------------------------------------------------------------
Message 4 of 10
(4,114 Views)

Thanks everybody for your input!

GerdW:

A 2011 version is attached. I really liked the way you calculated the distance. I only use this specific VI for debuging purposes, but I'll be sure to use your way whenever I need something like that in the future, thanks!

 

Zwired1:

The loop runs at about 100Hz (as it waits for input from an outside program that runs at that frequency). when I wire constants in, the VI will not beep until I stop the loop (then it will beep once and quit).

Adding an additional delay doesn't seem to help. 


Miraz:

I tried adding a delay (5-10ms) but that didn't seem to help. I will try the flag option as soon as I can and report back. 

 

 

0 Kudos
Message 5 of 10
(4,071 Views)

Hit it with a big hammer.  Try a 1000ms wait inside the case with the beep function.  I'm guessing you'll get a beep every second.  Keep cutting the time in half until you start to see (hear) oddities. 

 

At 100Hz, you're calling the beep function every 10ms.  If the (presumably non-blocking) beep code takes 100ms to run the 5-10ms wait we suggested earlier is not sufficient. 

Message 6 of 10
(4,054 Views)

That might be a problem, as it is crusial to run that loop as fast as possible. I will try the flag solution that was suggested here, as it's not supposed to delay the main loop at all (if I understand it currectly).
Thanks for the idea though, I'll try it out just to see if the problem is indeed the non blocking quality of the beep vi

0 Kudos
Message 7 of 10
(4,048 Views)

Hi shayelk,

 

it's not supposed to delay the main loop at all

Use parallel loops to avoid delays in the main loop!

 

Only beep on rising edge of your "boolean" signal…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 8 of 10
(4,044 Views)

I can appreciate that you want the calling loop to run as fast as possible.  The "big hammer" suggestion is only for troubleshooting purposes.  Once we prove that our suspicionas are correct there are a variety of ways to call the beep in an independent process and keep it from being called too often.  You can have your cake (fast rate) and eat it too (beep).

Message 9 of 10
(4,041 Views)

thanks Miraz!
the parallel loop idea worked perfectly once I figured the right delay.
it was also a chance for me to learn how to use notifiers (to stop both loops with one stop button) so thats awesome to.


0 Kudos
Message 10 of 10
(3,967 Views)