LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Endless loop when trying to use Value (Signaling) Property Node

Solved!
Go to solution

Hello,

 

I'm trying to get my code to take a picture of my graphs every time a certain value is exceeded. My code works beautifully.... except that it doesn't stop taking pictures and I can't seem to figure out why.

 

Does anyone have any ideas as to what is causing my event structure to continuously loop?

code.PNG

 

 

Download All
0 Kudos
Message 1 of 8
(3,287 Views)

This is not the right way to do this!  You are using Value-signaling to get the Graph scaler to run (once) whenever some events in your sampling loop are true -- an artificial way to communicate between the A/D DAQ loop and the Graph Scale Controls loop.

 

I don't know how fast your DAQ loop runs, but I notice that your V Drop event takes at least 10 seconds.  Let's say that your DAQ loop runs once/second for a minute, and that half the time, V Drop is signaled.  So after a minute, you will have enqueued 30 x 10 second V Drop Events, so the loop will take 5 minutes to finish.  Is this what you want?

 

I'm guessing not.  You may want to re-think your logic, what you really want to do, and when you want to do it.

 

Bob Schor

Message 2 of 8
(3,278 Views)

Bob,

 

That's a good point! And it explains why it appears to be an endless loop. Unfortunately I'm using a DAQ (recommended by NI) that has a minimum sampling rate of ~1600 samples/sec. Perhaps if I increase my loop size to a few seconds or two, my problem will be solved.

 

I'll check the buffer of the daq to make sure i don't exceed its limit... & let you know if that solves the problem.

 

Thanks!

0 Kudos
Message 3 of 8
(3,270 Views)
Solution
Accepted by topic author cpip

No, that's not the solution -- the solution is don't use a queue (which "remembers"), but possibly a Notifier (which only remembers the last value.  Make yourself a separate loop that "does what you want when you tell it to do so" and feed it the Wait on Notification -- until you Notify it (in your DAQ loop), it will consume no CPU time, but when you say "OK, do something", it will do it (once).  It only "remembers" the "latest" signal.

 

Bob Schor

Message 4 of 8
(3,263 Views)

Thanks for the advice! I've only had bad luck with notifiers so I'll likely use a channel writer instead.

 

Now.. just for the sake of understanding: Ultimately I get that what you're recommending might be better practice, but won't the notifier/channel writer be updated just as often as the event structure does in my existing code? Especially because I have to set the same threshold in order to notify. If my set threshold is exceeded, the code will continue to notify until the voltage has returned back to its normal state. The event structure is also in a separate loop so it does not necessarily use more resources nor does it slow down my DAQ reading loop... what do you think?

0 Kudos
Message 5 of 8
(3,246 Views)

Some other points:

  • In your subVI, you can leave the input to "format date/time string" unwired and it will default to the current time. No need to get the time first.
  • You can of course keep using the value signaling event, but then you need to remove that 10 second wait. Never delay events! In the producer you would need to limit writing to the signaling property, e.g. if the threshold is crossed for the first time and then every 10 seconds until the signal drops in range again. You should also limit the event queue to "1" entry.
  • You can leave the stop button latch action and eliminate all the local variables of it. Place a TRUE diagram constant in the stop event to stop the event loop.
Message 6 of 8
(3,239 Views)

Altenbach,

Thanks for the pointers. They make a lot of sense.

I didn't figure out how to set a threshold in the producer with the 10 second wait without slowing down the producer loop. I also couldn't figure out how to set a threshold that only has a single entry... SO I ended up using a lossy channel writer... Yes, my producer is constantly sending T/F to the consumer, but the code responds very quickly & doesn't seem to hang.

 

Here's a screenshot of the simplified code just in case you or anyone else wants to see it as a reference.

 

 

lossy channel writer.PNG

0 Kudos
Message 7 of 8
(3,081 Views)

What's the point of the sequence structure?

What determines the loop rates?

0 Kudos
Message 8 of 8
(3,076 Views)