LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

High speed independent event loops?

Hi everyone,

 

I've been searching in forum about independent event loops, and got this 2 posts which are very helpful.

 

Event Structure: Multiple Events ??
http://forums.ni.com/t5/LabVIEW/Event-Structure-Multiple-Events/m-p/333521#M171408

Parallel processing
http://forums.ni.com/t5/LabVIEW/parallel-processing/m-p/1260290

 

But I need more information from you guys with more experiences.

I would like to generate signals continuously using NI PXI cards, analog and digital signals (starting together at the same time, snychronized).

And then I would like to acquire signals using another NI PXI card (anytime I want, when I click "ACQUIRE" button).

I could generate and acquire signals using 2 vi's (not joined into 1 vi). 

 

And I now need to put them together into 1 vi.

Can I use these 2 event loops which running parallel to achieve my goal?

I'm generating 40 MHz sample clock and need to acquire with 40MS/s speed, saving into TDMS file, would it be problematic?

I tried to put them together without event structure, but doesn't work.

 

What is the best method to achieve this?

 

Regards,

Yan.


Message 1 of 43
(4,315 Views)

Hi Yan,

 

generally, you can put 2 while loops parallel with each having one event structure.

 

In your case, i don't think you need 2 event structures. For the aquire button you can do that, but it is not necessary for your signal generation.

 

Is it possible that you can upload your VIs?

 

Best regards,

 

Abduelkerim

Sales
NI Germany
0 Kudos
Message 2 of 43
(4,303 Views)

I have run into some strange issues if I have multiple event loops within a single VI. Even though there were very few shared events I got strange behaviour. If you do need to use multiple event structure I recommend that you limit them to one per VI. I had no problems calling multiple subVIs in parallel, each containing an event structure, from a single top level VI.

 

I would also seaprate your task for saving to file from your data collection/generation tasks. File I/O can be a big hit on performance. You may also want to consider using queues in your application as well. You may not need multiple event structures.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 3 of 43
(4,294 Views)

@Mark_Yedinak wrote:

IEven though there were very few shared events I got strange behaviour. If you do need to use multiple event structure I recommend that you limit them to one per VI. I had no problems calling multiple subVIs in parallel, each containing an event structure, from a single top level VI.



Can you define "strange behavior". I've never run into any problems.

0 Kudos
Message 4 of 43
(4,284 Views)

Yan,

 

why do you want to use events at all?

 

I see hardware configuration as the main part of the task, followed by datastreaming (TDMS streaming to RAID?). Both don't require any events if done properly.

OK, events are handy if the UI should be handled gracefully (using producer/consumer), but this is a single source with limited events over time.....

 

Norbert

 

PS: Are AO and AI synchronized? Both have same sampling rate it seems...... 

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 5 of 43
(4,282 Views)

I would randomly miss events. The only way I could get it to work was to place two of the loops (had three parallel loops each with an event structure) into subVIs and call those from the top level. I didn't make any other code changes. When all three loops were in one VI it didn't work (lots of dropped events).



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 6 of 43
(4,279 Views)

Mystogan wrote:

But I need more information from you guys with more experiences.

I would like to generate signals continuously using NI PXI cards, analog and digital signals (starting together at the same time, snychronized).

And then I would like to acquire signals using another NI PXI card (anytime I want, when I click "ACQUIRE" button).

I could generate and acquire signals using 2 vi's (not joined into 1 vi). 

 

And I now need to put them together into 1 vi.

Can I use these 2 event loops which running parallel to achieve my goal?

I'm generating 40 MHz sample clock and need to acquire with 40MS/s speed, saving into TDMS file, would it be problematic?



OK, this is not clear at all. Obviously, the "continuously" part does not need an event structure, because it runs always.

That leave the "acquire" command by the user. Why do you need two VIs for that?

 

What kind of disk hardware do you have?


@Mystogan wrote:

I tried to put them together without event structure, but doesn't work.


In what way doesn't it work without the event structure? Such a statement needs mouch more detail, because there are millions of possible ways to "not work".

 

 

0 Kudos
Message 7 of 43
(4,274 Views)

Hi everyone, thanks alot for responding my post. 🙂

 

Basically, I'm trying to achieve my goal using these 3 examples from NI:

 

Generating Analog Signal:

Continuously Generate Voltage using Internal Sample Clock

(https://decibel.ni.com/content/docs/DOC-11197)

*I've changed my signals into 4 options using case structure, so I can generate Sinus/Ramp/DC/Off.

**as you can see, to run this vi continuously, I need to put Is Task Done in the while loop, and wait for user input to stop it. 

 

Generating Digital Signal:

I have combined 2 channels of dynamic generation and 4 channels of static generations in 1 Task.

*I need to have delay in 1 static generation, so I'm generating this signal with delay using sequence structure and put desired delay.

**sorry I can't upload any pict for this right now; cant find similar example, and somehow I cant install HSDIO driver in my laptop (I'll upload tomorrow from my working PC).  

 

Acquiring Analog Signal and save to TDMS:

basically I'm using niScope EX Fetch Forever combined with write TDMS to do this.

*I think I'll need Producer/Consumer method to fetch and write with 40MHz sample rate, right?

**as you can see, to run this acquisition continuously, I need to put niScope Fecth WDT in the while loop, and wait for user input to save into TDMS or to stop it.

FetchForever.png

 

This is my problem, when I use 2 separate vi's for generation and acquisition, I can start acquiring anytime I click start in acquisition vi (niScope EX Fetch Forever). But when I joined them into 1 vi without event structure, they not running well, when generation task goes into while loop (Is Task Done?), while loop of fetch forever just running 1x then stop (total points fetched not increasing with time). I'm not good with error line connection, I think thats my biggest challenge to make them work in 1 vi.

 

I have normal Harddisk (not SSD). 

 

I've tried to put Analog Generation and Fetch Forever into 1 vi, and this is what I got: 

FetchForeverWithGeneration.png

 

problem is when I try to put in Digital Generation with DELAY (sequence structure) in this, while loop not running. I think my dataflow understanding in Labview is pretty bad.

 

I tried to use event structure today, I think it gives me better result:

- using 1 event to generate Digital signal

- using 1 event to generate Analog signal

- using 1 event to acquire signal

But to start 2 events  (analog&digital generation) at the same time, I still havent found solution 😞

 

Regards,

Yan.

 

0 Kudos
Message 8 of 43
(4,250 Views)

Yan,

 

without looking into the very details of your work, i want to give you some feedback:

 

1.) Normally, NI Scope is acquiring data and writing it using DMA into the virtual memory. If you don't have a decent RAM equipment, this will result in paging (swapping RAM content into page file on HD). Additionally, each data point should be 2 Bytes (16 bit) raw data, scaling is done once you transfer the data from the buffer within the virtual memory into your application using the Read function.

 

So you are running 40MHz on one channel, making up for 80MBytes/s data transfer volume.

PCI bus is running on 133MHz, being capable of transferring around 100-110MB/s of data in average.

Normal harddrives have very different transfer capabilities, search internet (e.g. http://www.tomshardware.com/charts/hdd-charts-2012) for more details. Depending on brand and family, HD have between 40MB/s up to about 160MB/s (writing!). So you see that some HDs wont be able to write 80MB/s (+overhead for file IO) over a long time.

 

Having a normal PCI system, the Scope device alone will narrow down the data transfer capacity left for DO and AO. Depending on the size of the waveform, you possibly still have to pass data between virtual memory and device...

 

So you see, that possibly you have limitations in your system which prevents you to fullfill the requirements at all.

 

2.) Running PCI Express/PXI Express will lift the limitation from 1.) regarding data transferrates on the bus. Still, the HD is possibly a bottleneck. You should think about getting an SSD at least or even better a RAID system.

 

3.) Changing pattern for AO, you have to swap the waveform. Either you have to set the buffer to be "non regenerative" or you will encounter glitches. Do not expect the change to take place immediatly; the change could take up a whole cycle of your waveform.

Working with "is Task Done?" will not enable you to swap pattern, you have to use another example. 

 

4.) Working with events makes the task only more complex. Get rid of the idea to implement events.

 

5.) What is the desired delay for DO? Has it to be 'deterministic'?

Depending on the answers, software delay might not be suitable. You might want to think about using dedicated DIO hardware capable of delaying signal generation depending on the clock cycle. But since you point to HSDIO, you might already have a suitable device, dont you?

 

6.) Again, you haven't answered if AI and DO/AO should be synchronized. If not, i would split up AI (NI Scope) and AO/DO completly (two VIs?).

Even if some synchronization is necessary, splitting up makes sense (synchronization using start trigger/PLL on common clock). No need to paste them all in the same loop.

 

 

These are my most prominent, immediate feedback points. Please let us know if you have additional questions.

 

Norbert 

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 9 of 43
(4,214 Views)

Hi Norbert, thanks alot for such great reply.

 

So, the hardwares I'm using are:

PXIe 1082 Chassis.

PXIe 8370 Controller.

100MHz DIO PXIe 6544 for Digital Signal & Clock Generation and Digital Acquisition.

16 Bit PXI 6733 for Analog Signal Generation.

12 Bit 60MS/s PXI 5105 for Analog Acquisition.

PXI 6674T (I still don't know why do I need this card).

 

I'm doing my study project where I need to generate and acquire Digital & Analog signals using Labview.

After seeing some examples in NI forums, I was thinking, that Producer&Consumer Method (using QUEUE) might help me to acquire with 40MS/s speed without buying SSD (different speed on Fetching&writing TDMS), but I've been experimenting, and keep getting error "The requested data has been overwritten in memory and can therefore no longer be retrieved". I think I keep getting this error for not using high speed Harddisk, right?

 


@Norbert_B wrote:

Yan,

 

without looking into the very details of your work, i want to give you some feedback:

 

1.) Normally, NI Scope is acquiring data and writing it using DMA into the virtual memory. If you don't have a decent RAM equipment, this will result in paging (swapping RAM content into page file on HD). Additionally, each data point should be 2 Bytes (16 bit) raw data, scaling is done once you transfer the data from the buffer within the virtual memory into your application using the Read function.

 

*niScope Fetch WDT using 2 Bytes raw data? I didn't get information of this anywhere.

 

So you are running 40MHz on one channel, making up for 80MBytes/s data transfer volume.

PCI bus is running on 133MHz, being capable of transferring around 100-110MB/s of data in average.

Normal harddrives have very different transfer capabilities, search internet (e.g. http://www.tomshardware.com/charts/hdd-charts-2012) for more details. Depending on brand and family, HD have between 40MB/s up to about 160MB/s (writing!). So you see that some HDs wont be able to write 80MB/s (+overhead for file IO) over a long time.

 

Having a normal PCI system, the Scope device alone will narrow down the data transfer capacity left for DO and AO. Depending on the size of the waveform, you possibly still have to pass data between virtual memory and device...

 

So you see, that possibly you have limitations in your system which prevents you to fullfill the requirements at all.

 

2.) Running PCI Express/PXI Express will lift the limitation from 1.) regarding data transferrates on the bus. Still, the HD is possibly a bottleneck. You should think about getting an SSD at least or even better a RAID system.

 

3.) Changing pattern for AO, you have to swap the waveform. Either you have to set the buffer to be "non regenerative" or you will encounter glitches. Do not expect the change to take place immediatly; the change could take up a whole cycle of your waveform.

Working with "is Task Done?" will not enable you to swap pattern, you have to use another example. 

 

*I need to let the user having freedom to change the waveform only in the beginning (before generating), not while its running, is this still a problem? I'm working with "Is Task Done?" to provide user to stop the generation (when its continuous). I'm trying to make the options continuous/finite as a control, then applying case structure:

- if its continuous, then use "Is Task Done?"

- if its finite, then use "wait until done"

 

4.) Working with events makes the task only more complex. Get rid of the idea to implement events.

 

*Why would it be more complex? I'm using events since I have to make a program which let the user to start generating/acquiring anytime he click on the button on the frontpanel.

 

5.) What is the desired delay for DO? Has it to be 'deterministic'?

Depending on the answers, software delay might not be suitable. You might want to think about using dedicated DIO hardware capable of delaying signal generation depending on the clock cycle. But since you point to HSDIO, you might already have a suitable device, dont you?

 

*I dont think I really understand this part (your red italic comment). But what I'm doing is, user has freedom to delay the (Analog&Digital) signals while generating them.

And the desired delay is user input (user can freely determine what is the delay between the static generation in 1 channel). Thats why I've came up to this idea:

DigitalGeneration.png

 

6.) Again, you haven't answered if AI and DO/AO should be synchronized. If not, i would split up AI (NI Scope) and AO/DO completly (two VIs?).

Even if some synchronization is necessary, splitting up makes sense (synchronization using start trigger/PLL on common clock). No need to paste them all in the same loop.

 

*Yes, I need everything (AO/DO & AI/DI) to be synchronized.

And my task is to have this Generation and Acquisition in 1 vi (its possible, right?), thats why I keep on pushing to use event structure.

 


Best regards,

Yan.

 



0 Kudos
Message 10 of 43
(4,149 Views)