03-25-2014 12:45 PM
@pgaastra wrote:
Hi Norbert_B,
You say: dequeue and timed loops don't have a "perfect match".
Are you saying this because there is some sinister underlying incompatibility or that I cannot rely on something arriving in the queue before the timed loop is complete.
[..]
I tell you so because you are using two different sources in order to time your loop execution:
Having two sources for timing execution is a bad idea, esp. as the timed loop executes the content in a single thread.......
Norbert
03-25-2014 01:34 PM
I am using the queues to channel stuff into the VI but there was never supposed to be a wait for something to be in the queue long enough to affect the loop timing.
03-26-2014 07:31 PM
@pgaastra wrote:
I am using the queues to channel stuff into the VI but there was never supposed to be a wait for something to be in the queue long enough to affect the loop timing.
Then use local variables. ( seriously they do have a proper use--- this is one) Once you delve into the synchronization palette you establish "data availability" timing (Is that a word?) and break dataflow. "Data Availability" is a paradigm that can have "Exceptional conditions" (such as started late?) What to do if ... is built into Timed Loops but sync functions can only tell you if they "Timed Out" or not.
Hence, My objections to your attempt to mix the paradigms. I did not wish to offend but.... I really needed to draw out what you were missing to help. I hope I have helped.
there was never supposed to be a wait for something
is a key piece of information and points me to a likely reason you chose to mix models. There is nothing to help you if some "Wait" creeps into the project from either your mods, the next LabVIEW developers mods or a change to an external resource. Its much better to avoid the problem by using established patterns.
Did that help?
03-26-2014 09:17 PM
Thanks Jeff,
I was not offended. I worried I had offended you. I agree that what I have coded is faught with danger. I managed to get it to work as I have it with the queues. Yes it is a nightmare and I was dreading having to rewrite the whole lot.
My problem with local variables is that I have stuff in different VIs.
You say to use established patterns. I would love to find some large LabVIEW applications to see how people with brains do stuff. Unfortunately I tend to write code which complicates things.
The whole reason for me getting the timing fixed was to get points on a graph at 1 second intervals so that the scale could be time. I know if I had changed to waveform graph (instead of chart) and I used time stamps as my x coordinate and I my queues would not have been in danger of messing things up. I know that will make you cringe. It makes me cringe too.
Thanks for your post.
03-26-2014 10:05 PM
Had you been posting longer you might know that my signature line used to consist of a quote from St. Julian (of Norbert google it... someday.. its not important to the task at hand)
Local variables are local. only the vi they are in can access them (Yes they can be abused)
Global variables can be accessed by whatever context they are in (There are intelligent questions and do look up WORM Global before asking)
In others ways it..... makes ME think..
OK so you are "New" to LabVIEW.
In some ways that tickles the "Teaching Gene" I have ---
in some ways that I have seen children make poor judgments it makes me want to point out that "Sometimes you need to make (Code) mistakes too learn. " This was a great example.......
Now, I've probably been more critical of your posts in this thread than of any other OPs posts in any thread I remember. OK, I appologize- but keeep posting! Really who "Looses" I hope I have asked you to think.