Unable to achieve the desired timing Resolution with FPGA

[Rohit0729]

Hi all,

I am trying to generate a digital on/off signal (i.e. a step function) which will turn On/Off my devices (Camera and others). I am using the following hardware :

cRIO-9012
FPGA Target (RIO0, cRIO-9102)

The on-board FPGA clock is 40 MHz so I should have a timing resolution of 25 ns (which would be fantastic for me). But when I check the rise time of the step function in either On/Off it is about 2 ms (which is horrible).

I was using nested flat sequences (one outer Flat sequence with many of its frames having Flat sequences with 5 or more frames). Someone suggested the delay might be due to nesting. So I tested just one flat sequence with 3 frames:

First Frame : Give an on signal.

Second Frame : Wait for 2 us or less.

Third Frame : Give an off signal.

But still with such a simple program, I get the rise time of about 2 ms (no improvement at all !). I actually get nothing with 2 us delay, I have to make it 400 us or more, to see a 2 ms rise time. For smaller delays (like 1 us which I actually need) the program gives nothing.

Also using the same I/O node multiple times causes time delays. But I am using it only twice (with a say 2 us delay in between its On and Off).

I am using LabVIEW 8.5.1.

A Snapshot of the VI is attached. Thanks for Help!

[James_McN]

The way you describe this sounds like a hardware issue rather than an FPGA issue.

When you say rise time, do you mean rather than getting a square edge voltage change you get a slower ramp? Can you share a screenshot/measurement of this? Also what module are you using?

Using the same IO in multiple places may cause conflicting signals which will cause problems but do you see these even with a single on/off frame?

[Rohit0729]

Yes, You correctly figured out meaning of rise time. I want a square edge but I get a slower ramp.

I tried making a single on/off frame measurement. But still the same timing. The measurement image is attached.

[James_McN]

So this would appear to be a hardware issue then I would guess.

What module are you using in the compactRIO? What is it driving? If it is an externally powered module (e.g. 9472 or 9474) what is the power supply rating?

The reason I ask is it could be that the load/capacitance is too high for the module and power supply but this will depend on the electrical setup.

[Rohit0729]

I am using NI 9403 Digital IO module in compactRIO. For now, I am just checking timings with an oscilloscope so it is not driving anything yet.

The entire compactRIO is normally connected to the AC mains via its adapter.

[James_McN]

The specs look good then - 7us update times and doesn't give a requirement for a min load to operate well but I would check two things:

1. These are bidirectional outputs so make sure you are configuring them for output (sounds like you are to get that much but double check): http://zone.ni.com/reference/en-XX/help/373197J-01/criodevicehelp/9403_configuring_the_line_directio...
2. Can you apply a small load to see if it is the same in a loaded state? Something like 5k-50k? (Anything above 78 Ohm should work)

[Terry_ALE]

The interface between the FPGA and the C Series modules is the limiting factor here.

See the cRIO Developer's Guide http://www.ni.com/pdf/products/us/fullcriodevguide.pdf page number 115

SPI Bus Communication The Serial Peripheral Interface bus, or SPI, is a standard 4-wire communication protocol set up for master/slave, fullduplex (two-way simultaneous) communication. The bus clock rates typically range from 1 MHz to 70 MHz. The SPI clock rate that CompactRIO hardware uses to communicate with C Series modules varies but usually operates around 10 MHz. The common architecture of SPI bus modules contains a complex programmable logic device (CPLD) that, on the module side, controls the timing to and data collection from the ADC/DAC chips. On the chassis side, the CPLD communicates via SPI bus back to the FPGA. Based on the specific module used and slot location, the LabVIEW API knows how and where to communicate to the individual CPLD on the module. This is why new module support is added in new versions of LabVIEW.

[James_McN]

Hi Terry,

Certainly, this module runs on the SPI bus but it shouldn't limit it as far as this, it will limit to a 7us update but once the signal is received I think you should get a solid rise time.

[deceased]

I would first add a resistor to the output in case there is a capicitance in the output that is slowing the rise time.

[Rohit0729]

Sorry for such a late response!

Thanks to everyone who helped! I have resolved the issue. I think it was some hardware issue with the triggering of the oscilloscope. Now the rise time is 8 ns.

Thanks for providing such detailed info. I like these forums a lot. I will mark Kudos to all replies as they increased my knowledge.

But one question:

What is meaning of update time 7 us? I have seen on the oscilloscope that if I produce a switch on signal, I can produce the switch off signal on the same channel no sooner than about 7 us. Is than what is this 7 us time scale?

Also suppose one channel produces a signal (on/off). Can a different channel produce its signal sooner than 7 us (only limited by the FPGA 25 ns resolution) from the time first channel produced its signal? Will I have to implement some clever algorithm to do this? I will also test this on the oscilloscope but want to know if its possible and how?