LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

problems with precise timing and (timed) sequcenes and loops

Hey,

I developed a VI to send 16 finite pulse of 23ms duration and different frequencies. The time between the start of a pulse and the start of the next pulse is always 248ms. The only exception is the time between the start of the 8th and the start of the 9th pulse, which is 5299ms. I display the pulses at a chart to see if the timing is allright. I send these pulses to a device with a transducer which replies if the timing of the pulses is correct.

My environment:
  • LV 8.2
  • PC pentium4 3.2Ghz
  • window xp sp2

1. solution 'send.vi'

I developed a first solution with a normal for loop and a wait VI which works if you don't toggle  between the window of the VI and other windows(matlab,...) during the sending of pulses.  BUT, it never works the first time after directly starting the VI, even if the timing of pulses looks allright.(You should be able to send the sequence of 16th pulses as often as you want and I use a while loop for that). For example, usually the duration of the first run is smaller than the time of the expected duration. The next runs are usually 13ms longer which seems to be ok for the device with the transducer; at least it replies correctly.

2. solution sent_time.vi

In my second solution I use the timed loop and timed sequence structure, but with the timed loops it NEVER works. Even if the timing looks allright on the chart it simply doesn't work which means the device with the transducer is not replying. In addition the timing is not more precise compared to my first solution. The duration of the the sequence of the 16th pulses is also various.

I appended both VIs, so you can have a look.

I have a couple of questions:

  1. why isn"t  my second solution(timed structure and loop) more precise than the first one?
  2.  How can I achieve precise timing(using linux? buying RT module? are there any other solutions?
  3. why is my first solution working for any run execpt the first one? and how can it be that  the loop is ready before the expected time?(I really don't get this!)
  4.  how can I make sure that the VI is not disturbed by windows or the user during the sending of pulses?

I hope you guys have an idea.

Thanx a lot,
Martin



Download All
0 Kudos
Message 1 of 10
(5,386 Views)

Hi Martin,

1.  Maybe I am mistaken, but the first solution (send.vi) is actually the solution with the timed loop in it.  Though the timed loop appears to be more precise, in LabVIEW running on a Windows machine, this is not necessarily the case.  Just because you are using a timed loop does not mean that Windows will not have a process that can preempt that loop.

2.  Using LabVIEW Real-Time on a Real-Time system (not running Windows), you will be able to achieve more deterministic behavior.

3.  From your code, I cannot see why the first run does not execute as expected.  The run can complete before the expected time for various reason.  If you are saying that it isn't executing as expected, this could be a reason for it to calculate the incorrect expected end time.

4.  There is no way to make sure that the VI is not disturbed by Windows or the user during the sending of pulses?  That is why it is recommend that LabVIEW Real-Time be used for deterministic applications.

Best of luck on your application, and please let me know if you have further questions.

Regards,

Regards,
Ching P.
DAQ and Academic Hardware R&D
National Instruments
0 Kudos
Message 2 of 10
(5,349 Views)
Hey Ching,

thank you very much for your help.

Let me ask my question in a more precise way:

1) The first solution send.vi contains a TIMED SEQUENCE and a NORMAL loop, not a timed loop. In contrast, the second solution sent_timed.vi  contains a timed sequence as well as a TIMED LOOP. So, the second solution should be super precise, but it isn`t. I understand that windows is a problem for precise timing in general. But why works the first solution with a normal loop better then the second solution with a timed loop???

2)What combination of operating system and LV RT module can you recommend? Linux and RT? (the application should be able to run on a normal laptop.)

3) The first run of my first solution send.vi never works. I most cases I can see on the graph(and hear) that the timing of the second pulse is not allright.(the pulse is to early) Maybe this helps to find the reason why just the first run is not working.


Thanks again for your help,
Martin


0 Kudos
Message 3 of 10
(5,314 Views)
Martin,

1)  It appears as though you are mis-using the timed sequence structure in these VIs.  I wasn't able to see any evidence of you setting start or deadline times for any of the frames.  Thus your timed sequence structure is currently behaving like a regular sequence structure but with the increased overhead of being a timed structure.  A good place to start for information on what each part of the time sequence structure does would be the LabVIEW help (specifically I would first navigate to VI and Function Reference»Structures»Timed Structures).

Looking at your timed loops you also appear to have a deadline set that is shorter than the regular period time -- 15 ms compared to 248 ms.   This will generate a "Finished Late" flag on every loop iteration which I don't think is something you intended.


2)  The LabVIEW RT module comes with it's own real time operating system called Phar Lap ETS.  As with most real time operating systems ETS does not have a user interface.  User interface events such as keypresses and mouse movements generate interrupts which must be serviced by the processor.  This unpredictable workload generates jitter which is unacceptable in a real time environment.  Consequently Linux is not a real time operating system.  You would normally have two computers in a real time setup.  One would be your development machine with Windows, LabVIEW and the RT module installed.  The other would be dedicated to running your real time code and would have Phar Lap ETS and the LabVIEW RT engine installed on it.  If you would like some more information about LabVIEW Real Time I would recommend starting at the Real Time Software section of ni.com.


3)  I ran your code and wasn't able to figure out what was going wrong.  Is this not what the output should look like?



Regards,

Simon H
Applications Engineer
National Instruments
http://www.ni.com/support/

Message Edited by Simon H on 03-20-2007 08:02 PM

0 Kudos
Message 4 of 10
(5,283 Views)
Hey Simon,

thank you very much for diagnosting my code.

1)  in my first solution send.vi I used the timed sequence because I thought that the code gets a higher priority and is more real time style. but now I understand that I mis-use the timed sequence.

In my second solution sent_time.vi I use timed loops. The deadline of a timed loop is not relevant for my job. In previous time before I figured out the non relevance for my job I played with the deadline and the 15ms is a left over of that playing. anyway, it shouldn't influence the vi.

I was thinking about to use the time-out of the timed loop. I tried it, but the result was not better. Maybe windows is the problem?
(In addition the device with the transducer never replied to the pulses generated by that vi with the time out in the timed loop. )



2) thank you for the information about the LV RT module. I think I should get it. Is it sufficient to use a normal flat sequence and a normal iteration loop when I run the vi with the RT module?

3)The result should look like that the last pulse ends at 8.790s and not at 8.804s. And the graph shows that the second pulse is earlier than all the other pulses. unfortunately you cannot see that on this plot. (but when the graph is showing the first 8 pulses, you can see that.)

Thank you very much,
Martin


0 Kudos
Message 5 of 10
(5,258 Views)
Martin,

I think you are going to hard pressed to achieve the kind of accuracy you need with your current setup.  Not only are you using Windows but I doubt that the sound VIs were designed with precise timing in mind.  You might also want to investigate data acquisition cards to see if there is something with hardware timing that may fit your needs.

Just out of interest I cleaned up your code a lot while I was investigating -- I figured I should post it here rather than simply delete it.  You don't really need a timed loop or a sequence structure for what you want to do.

Regards,

Simon

Message Edited by Simon H on 03-22-2007 08:40 PM

Message Edited by Simon H on 03-22-2007 08:42 PM

0 Kudos
Message 6 of 10
(5,214 Views)
Hi Simon,

thank you very much for cleaning up my code. (I used the timed sequence structure to do the configuration of the sound card BEFORE sending the pulses to improve timing.)

Anyway, I will try it with a real time system and/or data aquisition cards.

Thank you,
Martin
0 Kudos
Message 7 of 10
(4,904 Views)

Martin:

Please post what you find when you try your code on a real time system.

Regards,

Rudi N.

0 Kudos
Message 8 of 10
(4,872 Views)
Hi Rudi,

I will post my "real time" results. But this might take some time.(need to get software and so on)

Martin
0 Kudos
Message 9 of 10
(4,862 Views)
I'd think RT would be serious overkill in this case. All you need is a buffered output -- unless I read your requirements wrong.
 
RT is required when you need to respond in RT... To input, or output, with precise timing, all you need is a buffer. The problem is that you're trying to get more performance than software timed will give, for hardware timed, this is easy. Get a multifuntion card with a couple of analog output channels, write 0-volts or 5-volts to it and will look TTL, or, get a buffered digital output card. I see loads of MIO cards with a couple of AO channels around where I work, so that solution pops into my brain first.
 
Randy
0 Kudos
Message 10 of 10
(4,857 Views)