Simple Time Delay in FPGA (cRIO 9073)

[hegb_85]

Hello,

I'm trying to implement a simple time delay in the cRIO 9073 running under FPGA Interface.

To test this delay i have a simple state machine with 3 states. The first is "idle" and is waiting for a button to be pushed. "delay" waits for a delay and "timeout" that waits for the same button to be pushed to start over again. I'm attaching the 3 states.

 

 

The "timer loop" is configured to count ms.

The problems that i'm having is that:

If i run the program connected to the cRIO the delay state runs ok, but it takes too long to timeout, i mean, it doesn't take 200ms to timeout. I thought this was because of the communication between cRIO and the PC via TCP but i'm not sure about that. This can be solved if a put a count of aprox 10 and i get a delay of 2secs (that's what i need).

The other problem is that if I deploy this compiled program to the cRIO and set it as Startup Program, when the cRIO gets to the delay state it never finish its execution and there's no way to complete the complete state machine so I can do anything with it.

I tried to do a RT VI to run this but the same behavior is seen. Can anyone help with this? I have been trying this for about 2 days without a real solution for this.

Regards

[Troy]

So I will ask the obvious question off the top.  Are you sure the Reset Button is going false?  The execution of the timeout and idle state would happen so quickly that if the reset button is stuck true it will look like the app is stuck in delay mode.

[hegb_85]

Troy,

Yes i'm sure that the reset button goes to false because I have another VI where no button needs to be pushed in order to the delay to run and the same behavior is seen.

[Troy]

OK.  Thought we best get the obvious out of the way.  I don't really see anything else obvious.

I don't know if it will fix your problem but have you tried using SCTL as opposed to the base while loop?  SCTL seems to be LabView FPGA preferred method and I have used in the past with timing critical functions and never had an issue.  Since it executes in a single clock cycle you would need to adjust your delay to match the clock speed of the FPGA (40MHz on the R-series boards I used, not sure if its the same for cRIO). 

You can also used a timed loop with a derived clock.  I haven't done this yet in practice but have seen the ability to do so. 

[Ruhmann]

The single cycle loop should not be needed here.  (FYI, cRIO uses a 40 MHz base clock just like R Series.)  Are you sure that the FPGA VI is actually running and that the host isn't reseting or aborting the FPGA VI?  Can you double check the loop timer and make sure it is set to mS?  Are you monitoring the "Elapsed ms" and "t" indicators to make sure they are acting as you expect?

[hegb_85]

Thanks for the responses

I did a couple modifs to the state machine.

The new delay states looks like this:

And I'm sure that both counters are set to ms.

With this 2 modifs the count (2000) it corresponds to 2secs, but again if the I deploy to it to the cRIO it never gets out of the delay state.

[Ruhmann]

Your original algorithm was fine for an FPGA VI.  It really looks like you just aren't getting the VI to run properly.  How are you getting the FPGA VI to download and run?  Do you have a host VI that uses the FPGA interface nodes?  Are you downloading the compiled FPGA VI to the flash?  Or, are you simply pressing the run button on the FPGA VI?

[hegb_85]

Ruhmann,

When i simply click the Run Arrow the delay works fine.  But when I download the bitfile to the flash memory the delay doesn't work. It just never get out of there.

I'm not getting to work this delay.

Now, as workaround I did a VI on the RT Interface (the one that uses FPGA Nodes) that calls the delay.vi and it works fine. This is temporary until a find a solution for this.

[Ruhmann]

I have a couple ideas as to what your problem could be.  Is your FPGA VI set to run when loaded?  You can check this by right-clicking on the FPGA target in your project and selecting properties.  On the dialog that pops up, select "general" on the left side and on the right side you should see a check box labelled "Run when loaded to FPGA".  This must be checked before you compile your VI.  If it is not checked, check the box and recompile your FPGA VI.  This should fix your problem.  Also remember that the FPGA is only loaded from the flash when you power up or reset the system, however you configured it using the "RIO Device Setup" utility.

If that's not the issue, I have another idea.  You may have a startup RT application on your system that is running and downloading something else to the FPGA as your system boots up.  To check this, there should be a switch on your cRIO controller labelled "NO APP".  Turn this switch on and then reset your controller (or whatever you do to get the FPGA to load from flash).  This time, any RT VI deployed to the controller will not run since the switch is on.

If that's also not the problem, there's something much more complicated going on.  Try to right-click on each of the controls and indicators on the front panel of you FPGA VI and make sure that the Advanced>>Synchronous Display option is not checked.  If that's checked, I believe the control/indicator nodes on the block diagram block until they are read/written from the host.

[Lars.B]

Hi,

at my opinion, I would recommend to use a SCTL and a simple selfwritten counter of the ticks (means: with shift register and +1 at every cycle) for simple delay actions on FPGA. 

Why that? Because only then (with SCTL) you have the great benefit of FPGA and an absolute deterministic in timing behaviour.

And how to count? Well, if you have a basic frequency of 40 MHz... then you have to count 40 ticks for every µs. Or 40e6 ticks for 1s. etc.pp. That's all.

Every cycle in a SCTL needs one tick. That is the magic of the SCTL. A normal while loop... needs more. That's all one can say without testing - and that's the big disadvantage of other loops unlike SCTL on FPGA.

Greets,

Lars 

Message Edited by Lars.B on 08-28-2009 09:23 AM