infinitenothing Posted November 9, 2016 Report Share Posted November 9, 2016 Is this a good way to stop a calculation midstream if you get a new input? Quote Link to comment
hooovahh Posted November 9, 2016 Report Share Posted November 9, 2016 The sequence structure you have shown there is likely a whole lot of stuff right? Is it a single subVI that takes a long time to return? If so pass the queue reference into it and check there. Then in your subVI use a state machine architecture that periodically checks to see the size of the queue. A more clunky solution could also be to call the Calculate subVI as an asynchronous process, and then abort it if your queue gets an element. Quote Link to comment
hooovahh Posted November 9, 2016 Report Share Posted November 9, 2016 Okay here is an example of the abort technique. Attached is a VI that will perform an Add every time a button is pressed, but the add takes 2 seconds to operate. If you click Add within the 2 seconds, it aborts the current add, and then process the new add that was requested. Keep in mind aborting a VI like this can have bad consequences depending on what is happening. You shouldn't just abort a VI that is dealing with references. You should go through a cleanup process. Of course you could just pass references already opened in to this VI and I think things would still be fine. Abort Test.zip Quote Link to comment
infinitenothing Posted November 9, 2016 Author Report Share Posted November 9, 2016 In my example I was trying to show that the for loop (which could be made a subVI) took a long time but the individual iterations of the for loop were relatively fast. I was more curious about what other people have done because I almost never use the queue status VI. The "abort" option does sound clunky. There wouldn't be a way for the SubVI to perform post cleanup operations Quote Link to comment
hooovahh Posted November 9, 2016 Report Share Posted November 9, 2016 Oh now it's clear. I thought you had the for loop in there processing multiple items for some reason. In that case I'd say that's a perfectly fine way to check for an abort condition, and then stop if a new request comes in. The abort example really only seemed like a good idea in an example like the one I posted. Where maybe you were doing some image processing to display to the user, which might take a long time, where a purely computational operation could be aborted without any concern. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.