07-11-2017 01:03 PM
cp73 does this solve your problem?
07-13-2017 09:54 AM
Thanks Ryan01. I think you are on to something here with a separate data display loop. One question. With the display loop timing out every 50ms when the acquisition and overlay loops are idle, do you expect the redrawing of the x-y graph to be a significant drain on CPU (I'm guessing not, as the arrays are relatively small)? Thanks again for the input.
07-17-2017 08:02 AM
Yeah, the separate loops are the way to go when concurrently executing functions. I do not expect a 50 ms timeout of a wait for notification to be a significant drain on the CPU. If you don't mind, can you please mark my post with the solution as the solution?
07-17-2017 02:00 PM - edited 07-17-2017 02:05 PM
@Ryan01 wrote:
it took about 12 hours but i think i have a solution. Please see attached.
No, this is way too complicated and inefficient. Way too many loops for such a simple thing.
Note that circles are much more easily done using complex datatype, something an XY graph understands directly (hint!) :D.
(Also, in your original code you have all these case structures. None are needed because latch action booleans are always TRUE (if the default is FALSE) when the event triggers.)
Attached is a simple rewrite of your original code. If you want to do the overlay with a file dialog, this can be done in a separate loop and the result communicated via e.g. a local variable (or signaling value property, triggering the code of the current current "add" event case.). This is a simple thing and should not require gigantic amounts of code.
Improvements could be to ignore the acquire button if the timeout is >0, i.e. use a case to not modify the event case output. But maybe you want to restart with every press of the "acquire" button. You might also want to correct for timing differences that occur when e.g. the "add" button is pressed.
07-17-2017 03:50 PM
Thanks altenbach,
I like the idea of using the complex numbers...that will definitely simplify a part of the code. One reason I had parallel loops for the acquire and the plot is that in the actual code will have more cases in the plot loop than just overlay. In effect I am using a state machine for all of the acquisition tasks (which I have simplified to just plotting a circle in this example) and then passing the acquired data to the plot loop which will have additional cases to modify the plot in addition to adding an overlay. I selected a queue, as I can handle buffering the data while the user selects the file, though, as was previously suggested, I will be using a flush operation instead of dequeue in the final version.
Essentially I was hoping to find a way to have the plot loop sit idle and wait for data to either enter the queue or for the user to interact with the x,y graph (by adding, removing, etc.). The problem is, I can't find a way to "wake" the plot loop when data enters the queue without polling the queue size or just having it timeout after a finite time. All that being said, I think you hit the nail on the head, with a signaling property node. I will play around with that and see if I can implement that in my original code. Thanks again for the input.