pt by pt to array

[carloman]

Hello,

I have put together an attempt that  works.

Are there better ways to achieve this result, rather than passing the array to the other while loop via a property node ?

Seems like queues & notifiers would be overkill for this application ?

I dont really need the ptbypt waveform graph.... its just there as a source of the property node, so that I can then pass data for further processing and display on the 3rd graph.

Thanks for any comments on these basics.

carloman.

[RavensFan]

No.  You would be much better off using a queue to pass the data rather than hacking something through property nodes.

You might think it is overkill, but you will find that as soon as you start trying to add more features to your program, you'll find your program won't be able to keep up, and you'll come across a host of problems you never would have expected.

1.  Property nodes would be much slower in passing data than queues or notifiers.

2.  Race conditions.  Search the forums for those terms and read up.

Queues are not difficult to use.  It may mean dropping a couple more nodes on the block diagram than you would with property nodes now.  But it will save you a huge amount of time later on when you aren't wasting time trying to debug your application problems that were caused by the improper use of the property nodes.

[carloman]

Thanks for the advice. I will implement the change and post my new attempt.

Queues seem easy enough to implement for my simple situation. I just figured they would be slower. (no reason...just my impression).

So I take it from forum posts, that property nodes should generally only be used for affecting a UI control/indicator on the front panel.? Is this a fair comment ?

[RavensFan]

Queues would definitely be faster.  Also, they can decouple one loop from another.  For instance, if you are writing data to a file within the loop that does the data acquisition, you are at the mercy of how fast the OS can handle the file writing.  If something slows it down (virus scan, other programs accessing hard drive, ....) it slows down your whole program, possibly to the point you'd miss data from the acquisition.  Put it in another loop, the acquisition can continue unimpeded, the data is built up in a queue until the consumer loop has a chance to catch up.  (Of course if the consumer loop is always running slower, it would never catch up and the queue would fill up until you had out of memory problems.)

Yes, it is fair statement to try to reserve the use of property nodes for where they are required for modifying the appearance of front panel controls/indicators.

[carloman]

Thanks again for your advice.

Here I have modified my example to transfer a "snapshot" of the waveform every 1000 pts via a queue.

It transfers from the fast loop to the slow loop, which awaits the data.

However I ran into some problems when I tried an example transferring from a slow loop to a fast loop (which needs to run at full speed). The fast loop got held up waiting for the data (from teh slow loop) out of the queue.

Is there some way around this, rather than just setting a dequeue timeout to 1 ms...which also wasted too much time for my application.

Perhaps I need to add a test for data to be present, else ignore ? Like polling a data ready flag  in hardware ?

Regards.

[RavensFan]

You can set the timeout on the dequeue function in the "fast loop" to be 0 msec.  So it will return any data in the queue immediately, or return nothing immediately with the Timeout? flag set to True.

My question for you is what is going on in the "fast loop" that the loop needs to run fast even if you haven't sent any data to it?  What do you want to do when the loop hasn't received any data from the queue in that 0-1 msec?

[carloman]

OK..didnt realise that...so it will return data or move on immediately. That should work well.

My slow loop handles user interaction with the SFP...changing parameters etc, and the fast loop is running simulations with pt by pt signals, drawing on screen etc. I have about 80 values/data signals I needed to move about the place.

Getting rid of property nodes has been helpful in eliminating slow moving code, and also in forcing me to work with clusters of data signals etc. Hence why I needed queues to be able to transfer data from one loop to another.

Thanks for your help and hopefully my experience with moving on from property nodes for data transfer may be useful to others.

Regards,

carloman