High speed independent event loops?

[Mystogan]

Hi Norbert,

I've asked, but we dont have any other controller here except these 2 PXIe 8370 in 2 chassis. Might be this 8370 is the bad guy here?

Regards,

Yan.

[Ben]

---

@Mark_Yedinak wrote:

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).

---

A "register for event node" wired to TWO or more event structures will miss events in one or the other structure. Use one register for each event structure.

"Filter Events" will be serviced in the order they were dilvered registered so it the dismiss is issued by the first structure, the second will never see it.

I have never seen anything that appered to be missed events where either of the two above rules were observed.

Just trying to help,

Ben

[Mark_Yedinak]

---

@Ben wrote:

---

@Mark_Yedinak wrote:

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).

---

A "register for event node" wired to TWO or more event structures will miss events in one or the other structure. Use one register for each event structure.

"Filter Events" will be serviced in the order they were dilvered registered so it the dismiss is issued by the first structure, the second will never see it.

I have never seen anything that appered to be missed events where either of the two above rules were observed.

Just trying to help,

Ben

---

Each event structre did have it's own event registration. When I stated shared events I mean that two event structures had an event case for the same event, such as my user event for Exit. However, each loop registered for this event independently. These were not filtered events either.

[Kyle_A.]

If I may offer some insight on the issue with streaming 40MHz on the 5105, I decided to take a look at the issue a little deeper and I believe I have at least an understanding as to why you are stuck at 30MHz.  The 5105 max sample rate is 60MHz, and the clock is Divide by N, so by selecting any rate over 30MHz, it actually coerces under the hood to 60MHz and forces you to stream 120MB/s across the backplane.  You can check this by reading back the sample clock property node of niScope after you set the sample clock rate with the VI.

From here, you still have the issue that your system cannot reach the 120MB/s streaming rate.  Either the MXI link is not fast enough, or you are hitting a theoretical maximum on the backplane (PXI usually stops around ~110ishMB/s unfortunately).  This means you may be restricted to the onboard memory as your only source if you choose to stay with the internal clock.

An alternative workaround is to bring in an external 40MHz clock and use that, which keeps your data across the backplane at a reasonable 80MS/s and achieve the minimum requirements for your application.  You can use a Digital output device (like HSDIO) or an external square wave frequency generator.  

I hope this allows you to move forward with this application, best of luck!

[Mystogan]

Hi Kyle, thanks for responding.

---

@Kyle A. wrote:

If I may offer some insight on the issue with streaming 40MHz on the 5105, I decided to take a look at the issue a little deeper and I believe I have at least an understanding as to why you are stuck at 30MHz.  The 5105 max sample rate is 60MHz, and the clock is Divide by N, so by selecting any rate over 30MHz, it actually coerces under the hood to 60MHz and forces you to stream 120MB/s across the backplane.  You can check this by reading back the sample clock property node of niScope after you set the sample clock rate with the VI.

*How do I do this? is there something like "actual sample clock"-property node? 

**I've checked clock property node of 5105, and I found this. Which one is it?

 

From here, you still have the issue that your system cannot reach the 120MB/s streaming rate.  Either the MXI link is not fast enough, or you are hitting a theoretical maximum on the backplane (PXI usually stops around ~110ishMB/s unfortunately).  This means you may be restricted to the onboard memory as your only source if you choose to stay with the internal clock.

An alternative workaround is to bring in an external 40MHz clock and use that, which keeps your data across the backplane at a reasonable 80MS/s and achieve the minimum requirements for your application.  You can use a Digital output device (like HSDIO) or an external square wave frequency generator.  

*I've generated my Digital Signals using HSDIO; using sample clock 40MHz then generating 2 dynamic signals with frequency 10MHz (they should be generated with 1/2 period or 1/4 period difference). I found the way to generate them from this forum, and I'm sure Kyle was there helping me to get the wanted signals. 

**The question now, should I connect my digital clock (40MHz) from HSDIO directly into PFI 1 in 5105 and use it for my sampling frequency (using 5105 with external sample clock example)?

***OR this is where I should bring to use the Timing Module card (PXIe 6674T), that I dont use until now?

I hope this allows you to move forward with this application, best of luck!

---

Regards,

Yan.

[Mystogan]

Hi Kyle, thanks for your informative comments.

Now I found another example from NI, with this program I could fetch and save my signals using PXI 5105 into TDMS with 40MHz sampling rate.

http://zone.ni.com/devzone/cda/epd/p/id/5273

But, why would I get different scales in my Amplitude. Using my edited Fetch Forever (with max speed only 30MS/s), I could get my desired Amplitude shown in my TDMS File viewer (sinusoidal, -1Volt ~ +1Volt, using Fetch WDT). *Somehow I couldnt use Fetch Forever with  external Clk.*

But using this pogram, I got this while using niScope Fetch WDT (not sinusoidal, -1Volt ~ +1Volt)

and I got this while using niScope Fetch I16 (sinusoidal, not -1Volt ~ +1Volt)

 

Anyone know what do I miss here? *sorry I dont think I need to open new thread for asking this, right?*

Regards,

Yan.

[Norbert_B]

Yan,

the queue is of type "2D array of I32". So your waveform (containing doubles as values) will get coerced. Since your amplitude is +- 1V, you will coerce to -1, 0 or 1.

Reading I32 will result in unscaled values. You have to scale them correctly if you want to see "voltages".

Norbert 

[Ben]

I do not have time to dive into all of the details but I can offer some ideas.

1) Does the acquistion have to run for more time than the on-board memory can hold?

2) using an external clocked acquisition can drive two boards one trigger on rising edge the other on falling. Put the dat back togethe after wards.

3) Using multiple machine with syncronized external clocks can push things farter.

4) Try to schedule you abuse of the bus. Don't try to save and acquire at the same time.

5) SCRAMNet and other reflective memory lets you tie together multiple machines with wicked fast interactions. Collect on multiple mahcines and do the saving on another.

6) The longest part of saving files is allocaing the disk space. Pre-write the file and then over-write then truncate.

Ben

[Kyle_A.]

Hi Yan,

In regards to your reply to my post, the property is Actual Sample Rate under the Horizontal list in the niScope Property node.  Also, you can choose a variety of ways to send a 40MHz clock to your scope, the 6674T could send a 40MHz high stability signal across the backplane to your scope very easily, or you could route CLK OUT from your HSDIO board to PFI 1 (or respective clock in) on the scope.  Either way, looks like you may have gotten it.

[Norbert_B]

I also want to add something to clear up the confusion regarding the MAX testpanel.

Even though the testpanel states "continuous" acquisition, it actually isn't 'continuous'. It should rather be called: infinite multi-record acquisition. The records do have gaps in between, so the data you have to transfer (even with 60MHz sampling rate) will not be 120MB/s.

If your system is capable of transferring 80-100MB/s, it is possibel that MAX testpanel works, while a real streaming application (as your LV example) does not work anymore.

Norbert