Timing of using intensity graph

[RWong]

What I am trying to do is to display a set of data on the intensity graph and at the same time, make a flash light in a period of 250ms.

Now, the problem is when using the intensity graph, it give out a time delay at the start of the program which make the light cannot flash regularly.

I know I can reduce the number of data ploted on the intensity graph, but is there any other way to solve this problem??

Please help, I really struggled on this for several days already.

[odiseo123]

Hi. Could you save it for LV2010?

Without having look at your code you may use an event structure. Set the timeout event for triggering every 250ms and handle the flashlight there. Create an event (with an "accept" button or with the data change of the intensity chart) to handle the chart update.

Also the timed loop is quite useful for executing sequences periodically. Set the period to 250ms, in the first secuence handle the flashlight and in the second sequence the chart update. The remaning time to complete a period will be idle. The structure has a boolean output that allows you to check that the period time is not being exceeding.

Again, this is without looking at your code. Please downgrade the saving version so that I could help you more.

Regards

[RWong]

Thank you so much !!

I am going to give it a try, but here is the 2010 version.

[RWong]

I did try both methods, but they seem don't work. Maybe my description are not enough.

What I want is both function can act simultaneously, but using time loop have to stop updating the intensity graph to flash the light.

And I also try the event loop. I don't know if I use it correctly, but I can't even plot the intensity graph.

Thanks again!!

[johnsold]

Here is a somewhat cleaner version.  The LED blinking is erratic due to the time it takes to update the intensity graphs and other things.  Updating displays at 1000 times per second is rather meaningless.

Lynn

[odiseo123]

Hi again.

What do you mean by acting simultaneously? I think you are trying to do something in a more complex fashion than what your application really need. I have never seen somebody using parallel processing to update two indicators. Moreover as pointed by johnsold updating a chart so frequently is rather inefficient.

Please tell us a little bit more about your application. Maybe there is a simpler workaround to achieve the effect you want.

Regards,

[RWong]

Hi.

Sorry if I confused you. The one I posted is just a example made by myself to show what I want to do.

Actually my application contain the folowing step

1, Read form a sound card in every 250ms where the sample rate have to be set in 22050 per second.

2, Display the data to a intensity graph. As in every 250ms a new set of data come, the intensity graph should be updated in every 250ms.

3, Output a trigger pulse in every 250ms at the same time. This was represented by a flash light in the VI I posted.

The first step was achieved.

Thank you for both of you again!

[odiseo123]

Hi RWong.

Well to update the frame 4 times in a second seems more reasonable that the former update rate of 1ms.

Personally the pulse I would not process it through software. When using software additional delays have to be considered for the signal.

What hardware are you using to sample the sound signal? If you are using a NI Daq card, you could generate trigger pulses at a specified frequency (4Hz for instance). This would translate the time critical operation from the PC (where antivirus and other windows processes may be prioritized first than your VI) to the NI Card which is specifically tailored for those tasks.

Another comment, being very strict with the definition of words, the concepts of "at the same time" or "real time" are illusions. There is always a delay. The key idea is that the delay is so small in comparison to the application cycle time that it appears to be executing immediately or "at the same time".

In this order of ideas, the delay may not be as critical as the so called jitter (this is, that how inconstant is the delay). This is true for applications like streaming of audio/video: you do not mind to wait a little bit at the beginning of the movie, but you get quite annoyed when it has to buffer constantly in the middle of the action.

Review your application specifications and get an idea of how immediate is really your "at the same time" requirement.

Regards,

[johnsold]

You got good advice from odiseo123.

Four updates per second is a very different situation than many hundreds.

The synchronizaton will be an issue. Since the sound card is handled directly by the OS and the data handed off to LV, you have very little control over or knowledge of the latencies or delays. You might be better foo gneerating the trigger pulses in some hardware and monitoring those pulses through the sound card.  For example if the sound card can record in stereo (2 channels) but you only need one for your experiment, feed a sample of the trigger pulses to the other channel of the sound card.

Then the sound card data is synchronized within one sample period to your trigger pulses.

Lynn

[RWong]

Thank you odiseo123 and johnsold!!!

Both of you really gave a good sugestion for me and I am going to try these out.

Thanks again!!!