Power Electronics Development Center

cancel
Showing results for 
Search instead for 
Did you mean: 

Regarding passing values between two targets

I have two FPGA targets in my project, one is the GPIC (sbRIO9606) and the other is a cRIO-9076. If I need to pass values from the cRIO to the GPIC or vice-versa what would be the best way to do it?

I would appreciate any opinion on this. And a simple example VI would be highly appreciated.

0 Kudos
Message 1 of 17
(9,219 Views)

-->> Basically I intend to use cRIO-9076 to read the NI9467 (C-series GPS module) and pass all the measurement and properties and everything to the GPIC with little to no time loss.

-->>To simply put it I intend to access a C-series Module with the GPIC while the Cseries module is physically connected to the cRIO instead.

0 Kudos
Message 2 of 17
(4,780 Views)

Athapa, what sort of latency/update rate are you OK with? May be you can use Ethernet based communication?

0 Kudos
Message 3 of 17
(4,780 Views)

What's an Ethernet Based Communication? I would prefer minimum time lag.

0 Kudos
Message 4 of 17
(4,780 Views)

Athapa, It all depends on the sort of latency you are looking for. LabviewingToday probably referred to network streams or TCP/IP style communication. To pass data between two targets running LabView RT, network streams seem to be the most convenient option. It allows for nice queue mechanism with error checking, relatively low latency (around 10-100ms depending on the network configuration) and sufficient bandwidth (I've been sending several Mbps without any problems). Another option would be network published shared variables, but I am not sure whether it would be more efficient for you.

If you need very low latency and would like to send less than 10Mbps, you may use one of the high-speed DIO modules for CRIO and connect it to the FPGA IOs on the GPIC. This option would need you to implement some kind of SPI, I2C or UART interface in the FPGA. The CAN on the sbRIO could be used also if you prefer to go for serial communication via GPIC processor.

Given that your interest is to move around some measurement data and GPS location data (which I assume to have less than 10Hz update rate) Network Streams via Ethernet port should be the easiest and most future proof option.

0 Kudos
Message 5 of 17
(4,780 Views)

I agree with Ceslav's suggestion. To learn more about Network Streams and other communication options you might want to have a look at CompactRIO Developer's Guide section 2.

Additionally, if you are just using the cRIO-9076 to expand the I/O, I think you might be able to use an expansion chassis instead, mentioned in section 4 (though I guess Ethernet RIO would be the only option able to interface with GPIC).

0 Kudos
Message 6 of 17
(4,780 Views)

Agreed. Here is a tutorial on LabVIEW network streams:

http://www.ni.com/white-paper/12267/en/

If you are looking for GPIC example code for network streams, the GPIC Reference Design for LabVIEW 2014 examples (DC2AC and DC2DC) both have a network streams user interface between the VxWorks real-time processor on the sbRIO and a host machine graphical user interface (GUI). Around 20 channels of data are streamed from the GPIC to the host GUI, acting like a network oscilloscope for all of the power electronics measurements and FPGA configuration register settings. By default, the sbRIO real-time application is configured to send 10,000 samples at 10,000 samples/second-- thus a 1 second update interval.

However, you could try moving the host GUI application to the cRIO and experiment with lower numbers of samples (representing the amount of data you need to send for your application) at lower rates to determine what latency is achievable. Best performance will be achieved with a private network link between the RT targets and your development computer such as a Ethernet switch not connected to a network. Note also that the network streams transmit loop in the GPIC reference design is set to normal priority on the real-time operating system. Therefore, the amount of jitter from one iteration to the next is completely unbounded.

You can place the while loop in an outer timed loop in order to make it time critical priority. Set the outer timed loop to a latency of 0 and use a loop timer in the inner while loop to provide sleep. You would want to do this for the "Network Stream Waveform Transmit Loop" and "DMA Transfer Waveform Acquisition Loop". Do the same for the network streams interface in the desktop GUI application, and strip out unneeded code.

How to use an outer timed loop to set priority for an individual while loop.png

Why not just use the timed loop to set the loop rate? It is significantly lower performance due to all of the overhead associated with the diagnostics built into the timed loop structure. So I recommend using the timed loop to set the priority only (as shown above) to achieve the best performance.

If you decide you want to go with FPGA-to-FPGA communication for low latency reasons, let me know and I can share some example code for serial UART communication with packet decoding. The GPIC code was developed for 100 kVA power converter applications with the cutting edge new AgileStack converters.

0 Kudos
Message 7 of 17
(4,780 Views)

BMac,

The AgileSwitch Switch Stream technology looks cool. I have a few questions:

  1. Are the gating signal fed through the switchstream interface?
  2. What is the update/sample rate of the analog signals - VDC, INVIABC? I am assuming that the Stack has onboard ADC's.
  3. Are the LVTTL DIO pins utilized for the interface - if so, how noise-immune is the interface?
  4. Is a 'driver' of sorts available for the software interface that allows drag-and-drop interface of the Stack - much like RMC cards? I'm assuming the interface would be through the FPGA?
0 Kudos
Message 8 of 17
(4,780 Views)

Hi Labviewing,

Following in blue are responses:

  1. Are the gating signal fed through the switchstream interface? The gate signals are individual control signals sent through the J1 26 pin connector. They are not sent through the serial interface.
  2. What is the update/sample rate of the analog signals - VDC, INVIABC? I am assuming that the Stack has onboard ADC's.  1 KHz. Yes it has onboard ADC.
  3. Are the LVTTL DIO pins utilized for the interface - if so, how noise-immune is the interface? Our breakout board takes the DIO lines and buffers them as a full differential signal.
  4. Is a 'driver' of sorts available for the software interface that allows drag-and-drop interface of the Stack - much like RMC cards? I'm assuming the interface would be through the FPGA? Will have to defer back to BMAC for a response on this one for now.


The User Manual for the AgileStack can be found here: http://www.agileswitch.com/download.page

Let us know if you have additonal questions...or would like to order one!

0 Kudos
Message 9 of 17
(4,780 Views)

Hi Labviewing.  Sorry. Did not reply directly to your message, but to the original.

0 Kudos
Message 10 of 17
(4,780 Views)