LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

top priority of timeout in event structure.

Solved!
Go to solution

I have several cases including timeout in event structures.

The timeout fires regularly the important tick of starting measurement but other case (e.g. mouse move) handles the analysis of data.

When I move the mouse, I found the timeout is not working in constant interval due to the enqueue of mouse moving continuously.

(Actually, timeout is located in front panel (FP) and mouse move in child window: two parallel while loops.)

 

How can I set the top priority of timeout case whatever mouse move calculates something?

or can I change the response rate of mouse move to lower the real-time burden of CPU from child window (for example, 1 event fire per 500 ms) ?

 

labmaster.

0 Kudos
Message 1 of 12
(425 Views)

Can you share your vi so that we can get a clear picture of how you want the program to run?

 

From what I understand, you want the timeout to run continuously with intervals despite any actions/input from the user.

Is that correct?

0 Kudos
Message 2 of 12
(402 Views)

As long as other events fire, the timeout event will obviously never happen.

If you want something to happen at regular intervals, use a parallel loop.

Another option would be to keep the timeout in a shift register and shorten it accordingly whenever other events happen. (Long ago I made an example, so try searching for it. It still assumes that there are typically no events queued up. Make sure to limit the event queue to one for all rapidfire events (slides vale change, cursor move, mouse etc.)

Message 3 of 12
(398 Views)

Maybe you can also refer to this discussion forum link to help you with it too

https://forums.ni.com/t5/LabVIEW/How-to-run-a-particular-case-continuously-in-event-based-state/td-p...

0 Kudos
Message 4 of 12
(393 Views)
Solution
Accepted by topic author labmaster

I was talking about this post:

 

 

altenbach_0-1582145633110.png

As I said, the definition of a timeout even is that if will happen X milliseonds after the last event fired. It is only regular if nothing else ever happens. (see also)

0 Kudos
Message 5 of 12
(390 Views)

Thank you much for the comments.

 

Actually, my situation is too complicate to state here.

However, I used event structures and several parallel loops in mainVI and subVI.

When I move the mouse (or cursor) event continously! over intensity plot, overall performance was slower and it affect to timeout loop (timer).

For example, every 1 sec timer was not working in independent application while the cursor was moving on the plot.

(I suspect windows resourse but I cannot be understood.)

 

I changed my code that timeout event send the message to find a pixel information but the update was slowered for continuous mouse moving.

 

labmaster.

 

0 Kudos
Message 6 of 12
(316 Views)

@labmaster wrote:

 

However, I used event structures and several parallel loops in mainVI and subVI.

When I move the mouse (or cursor) event continously! over intensity plot, overall performance was slower and it affect to timeout loop (timer).

 


You need to make sure that the mouse and cursor move event cases:

 

  1. Don't do excessive data processing
  2. Have the event queue size set to =1 and don't lock the panel (picture).
  3. Don't use the timeout event for something that should happen at regular intervals.

 

altenbach_0-1653579952881.png

 

 

0 Kudos
Message 7 of 12
(302 Views)

I don't think you understand the Timeout case.

 

Timeout fires an event x milliseconds after the last event, not every x milliseconds.

 

If you want something to fire every x milliseconds regardless of other events, you'll need to trigger it that way.

 

Instead of a timeout, use a User Event, and create a second parallel timing loop to trigger the user event every x milliseconds. Or use the suggestions earlier to dynamically change your timeouts.

 

The issue is not Windows resources. The issue is that your timeout starts to wait for 1 second (or whatever you've set it to), then 1/2 a second later you move the mouse over the plot, triggering a Mouse Move event. That restarts the timeout timer to another full 1 second. If you move the mouse again 1/2 second later, it resets yet again. As long as the mouse is moving you will never see the timeout case fire.

 

Also, you can limit the number of Mouse Move events that queue up to prevent it from slowing down, but that still won't fix your timeout issue.




Heads up! NI is moving LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 8 of 12
(298 Views)

@labmaster wrote:

I changed my code that timeout event send the message to find a pixel information but the update was slowered for continuous mouse moving.

 


That sentence makes no sense at all! Please explain with a few more sentences.

0 Kudos
Message 9 of 12
(288 Views)

@altenbach wrote:

@labmaster wrote:

I changed my code that timeout event send the message to find a pixel information but the update was slowered for continuous mouse moving.

 


That sentence makes no sense at all! Please explain with a few more sentences.


Uploading your code would also be useful.

0 Kudos
Message 10 of 12
(276 Views)