making a timeout event last longer?

[balaclava]

Just had a quick question about how to make each iteration of a timeout execute a little longer without stalling out the rest of the program.  Basically I'm collecting and processing data through a DAQmx input (voltage signal), and my program is mainly centered around the timeout case of an event structure.  The event structure is inside a while loop, and data collection and analysis (graphing, etc.) occurs during the timeout event.  I need to have the timeout event execute as often as possible (i.e., no lag- I set the timer on the event structure to 0) to ensure that the delay between data collections is negligible (we're trying to calculate position data based on how fast we're going and how many datapoints we've taken).
 
So in short, I need to make a timeout event have no lag in between executions, but each timeout event needs to take 100 ms per execution.  It's taking 95 ms per execution.  What's the best way to add 5 ms to the event's execution time?
 
I'm willing to clarify whatever questions that need to be answered.  Thanks in advance.

[MikeS81]

Hi balaclava,
you should use a parallel process for you data acquisition. See the shipped Producer/Consumer architecture.
 
Hope it helps.
Mike

[balaclava]

I'm sorry...I don't understand what you mean.  Could you clarify what architecture you're talking about, and how exactly the parallel process (which I thought was inherently being used anyway) that you're talking about would help me?
Thanks in advance.

[MikeS81]

Hi balaclava,
i mean the Producer/Consume design pattern. You have to while loops there. One for your events with the event structure and one for your data acquisition. If you use a parallel process you can measure you signals while press a button, or other thinks.
Mike

[balaclava]

Would that ensure that the data collection/processing takes 100 ms every time it executes?  Sorry if this seems like a stupid question, but since we're calculating positional data based on time, speed, and number of datapoints it's essential that we get it up from 95 ms to 100.
 
Thanks again!

[MikeS81]

Hi balaclava,
you don´t work with windows, do you? :smileywink:
Mike

[smercurio_fc]

The <a href="http://zone.ni.com/devzone/cda/tut/p/id/3023" target="_blank">Producer-Consumer</a> architecture. It is impossible to guarantee timing on a non-Real-Time operating system. This gets asked all the time.

[balaclava]

Thanks for the link smercurio, now I get what you're talking about.&nbsp; Sorry about the repetitive question.
&nbsp;
Not really sure how exactly to implement that in the program I'm using though.&nbsp; Basically I've been adding on to Aerotech's HMI VI in 8.5.1...unfortunately where I work we're cheap and only have the Base development system (8.5.1)- not sure if that matters in this case.&nbsp; <a href="http://www.aerotech.com/soloist/software.cfm" target="_blank">http://www.aerotech.com/soloist/software.cfm</a>&nbsp;will get you to a brief description of the VI...it's on the right side of the page.&nbsp; I don't have permission from the boss to post up the modded version of the VI (I'll ask later today if you want it), but I could post up the unmodified version if you all want me to (and if I won't violate TOS or any laws by doing so).&nbsp; You won't be able to run it since it has a massive library of subVIs, but I'm pretty sure the block diagram will stay intact.
&nbsp;
Oh yeah, we use Windows XP on our computers.
&nbsp;
Sorry if it seems like I'm not listening to you guys- just out of curiosity how bad can the timing errors be on non-real time systems?&nbsp; Did anyone ever get an error margin for it?

[smercurio_fc]

I'm not sure on how you're able to use the event structure if you say that you have the Base edition since the Base edition doesn't include the event structure. That aside, the little picture and brief (quite applicable word in this case) description simply tell me that you have a pretty interface (sarcasm aside) :smileywink:. In any event, the producer-consumer architecture can be used in a variety of ways. One typical means is for the producer loop to handle your UI. The individual event cases shouldn't perform anything that takes a long time. Its intent is to place actions on a queue for the consumer loop to take care of, so that the producer can quickly return to respond to events. The consumer loop is where you do the work. You can actually have more than one consumer loop. Thus, you can have a consumer loop that performs the UI operations, and the other consumer loop is doing your data collection. There is no error margin that one can give for the timing since it's dependent on way too many factors. You can do a few things in software:- You can have a minimum. For instance, you can get the tick count before you start the acquisition, and get it after you've got the data. If the difference is less than your 100 msec, then wait the difference. If it's more, don't wait.
- You could use a timed loop based on a DAQ clock. Not sure if this is available in the Base edition. This isn't the same as a real-time loop, though, but it's as close as you're going to get.
- Change the way you perform your data acquisition so that you get your samples at the timing you need. Basically do a buffered acquisition if your DAQ card has that capability. The DAQ card collects data at your desired rate, and the software pulls it from the buffer. As long as your buffer is large enough and you can keep up you should be able to do this.

[balaclava]

Yeah, as far as I can tell I can put stuff in the event structure at different cases, but I can't add or remove cases.&nbsp; I guess I'll post up the unmodfied version right now- I'd like to see where I can implement the consumer loops- maybe make an entire other while loop and just put all the data acquisition and analysis stuff in there?&nbsp; Let me know if I'm gonna have TOS issues by posting it up- though I suspect there shouldn't be any since you can't actually run it.
&nbsp;
Basically that version lets you move a platform around...I'm only really using the Move tab on the front panel.&nbsp; But like I said, right now I have all of the data acquisition/graphing/analysis in the Timeout case.
&nbsp;
So if you don't mind, could you take a look at it and see if my idea is feasible?&nbsp; Thanks in advance.


HMI.vi:
http://forums.ni.com/attachments/ni/170/347571/1/HMI.vi

[smercurio_fc]

Well, I don't know how long each of you individual operations take so I can't tell you whether it's OK to leave the code as is in the event structure or to put it into a consumer loop. You're the best judge of that. Just take into consideration my previous comment. As for the data acquisition I think you should try to separate it out into its own loop. Side-comments: - I noticed that some of your buttons have spaces a the beginning of the labels.
- Your description for "Initialize" says to press just once, but I didn't see anything in the code that would prevent someone from pressing it again. You may want to disable the button after you've done the initialization.
- The case structures you have for some of each button event are not necessary. Your mechanical action for your buttons are "Latch When Released", so by definition they will always be true when that event fires.
- I don't quite understand why the mechanical action for "Move" is "Switch Until Released".

[balaclava]

Thanks for the quick response.
&nbsp;
Like I said, the version that I posted up was written entirely by Aerotech, not me.&nbsp; At any rate, I'll try to separate out the data acquisition from the main loop.&nbsp; And I'll get on changing those buttons- didn't even notice their formatting was off.&nbsp; I'll post again if I'm still having trouble.