LabVIEW
top priority of timeout in event structure.
Solved!
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.)
I was talking about this post:
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)
@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:
- Don't do excessive data processing
- Have the event queue size set to =1 and don't lock the panel (picture).
- Don't use the timeout event for something that should happen at regular intervals.
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.
@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.
@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.
