LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Flat Sequence Structure inside Timed Loop and Order of Execution

Solved!
Go to solution

I have some problems trying to implement a flat sequence structure when using a timed loop on a cRio target VI

I've tried both with and without the while loop around the flat sequence structure, and I've also tried replacing the 'Non-Deterministic Loop' with a timed loop

The problem is that the program seems to run only once, then get stuck somewhere

I'm trying to write a program that does the following as fast as possible:
1. Read the input Pos_MC on the FPGA
2. Send the value of Pos_MC to the target VI (on cRio CPU)
3. Calculate an output value based on Pos_MC with a PID block ('PID output')
4. Send 'PID output' back to the FPGA
5. Write 'PID output' to the analog output 'MOOG'

Additionally, I want the program to send the measured value 'Pos_MC' to a host VI for data logging

To ensure that the PID output is calculated and sent to the FPGA as fast as possible, I've placed a flat sequence structure to make sure this happens before sending the output to the non-deterministic loop for data logging

Also, I want the digital input 'Stop' to be able to stop the deterministic loop (the timed loop)

I'm reading a lot more inputs than this and using multiple PID's and outputs, but I've rewritten the code for only one input and output to make it easier to illustrate

Screenshot of the code is shown in 'target code.png' and 'fpga code.png'

The VI's themselves are attached in the next post (can't attach more than 3 files)

 

Question 1:
Any advice on how to get this running? Thanks!

 

Question 2:
Also is my understanding correct in that, using this structure, every 0.9ms (fpga loop time) the following happens:
1. The input ('Pos_MOOG') is read on the fpga
2. The PID output is calculated on the cRio with some computational delay (for example 0.1ms)
3. The PID output is then written to the analog output 'MOOG' at around 0.1-0.2ms
4. The FPGA program then waits until 0.9ms has passed and repeats the process

As opposed to the following happening whenever a loop execution is startet on the FPGA:

1. The FPGA reads the input and writes to the output (the PID output from the previous loop execution)

2. Then the input is sent to the cRio, a PID output is calculated and sent to the FPGA

3. This new PID output is held until the next loop execution starts

Thanks!

Download All
0 Kudos
Message 1 of 10
(4,000 Views)

FPGA and Target VI's attached here

Download All
0 Kudos
Message 2 of 10
(3,991 Views)

Question 2:

Also is my understanding correct in that, using this structure, every 0.9ms (fpga loop time) the following happens:
1. The input ('Pos_MOOG') is read on the fpga
2. The PID output is calculated on the cRio with some computational delay (for example 0.1ms)
3. The PID output is then written to the analog output 'MOOG' at around 0.1-0.2ms
4. The FPGA program then waits until 0.9ms has passed and repeats the process

As opposed to the following happening whenever a loop execution is startet on the FPGA:

1. The FPGA reads the input and writes to the output (the PID output from the previous loop execution)

2. Then the input is sent to the cRio, a PID output is calculated and sent to the FPGA

3. This new PID output is held until the next loop execution starts

Thanks!


You will have scenario #2.  All of the read and write for the RT/FPGA communications on the FPGA side will happen at the same time.

 

The simple solution to all of your problems would be to just put the PID control in the FPGA.  That would eliminate most of your timing issues and greatly simplify the communications between the FPGA and RT.

 

Also, you should not have a While Loop inside of a Timed Loop.  You are just losing any timing capability when you do that.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 3 of 10
(3,947 Views)

The actual controller would consist of two different controllers in a case structure, and some logic to determine which one to use and other modification. Would it still be a viable option to do this on the fpga?

 

Also, is there any way to get the flat sequence structure to work inside the timed loop then?

 

Thanks!

0 Kudos
Message 4 of 10
(3,930 Views)

@phg wrote:

The actual controller would consist of two different controllers in a case structure, and some logic to determine which one to use and other modification. Would it still be a viable option to do this on the fpga?


Case structures work just fine inside of an FPGA.  I see no problem with that.

 

 


@phg wrote:

Also, is there any way to get the flat sequence structure to work inside the timed loop then?


Your problem is not the sequence structure.  Your problem is the dividing up of processes and trying to communicate in the time of a single sample.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 10
(3,902 Views)

Thanks, I like the suggestion

 

On a more general basis though, what if I have code as shown in 'codesegment.png' on the rt target;

- I read from an input from the FPGA

- Calculate an output through a PID

- Send the output to the FPGA

 

Will the following scenarios will happen?

 

Scenario 1

1. 'Pos_MOOG' is read

2. 'PID Output x' is calculated based on 'Pos_MOOG'

3. The 'PID output' is sent to the FPGA

4. The FPGA outputs 'PID output' the next time the FPGA VI executes

 

Scenario 2

1. 'Pos_MOOG' is read, but the 'PID Output' from the PREVIOUS iteration is written instantly to the FPGA

2. A new PID output is calculated, but doesn't get sent to the FPGA until the next loop iteration

 

If I've understood the basic of how data flow works in LabVIEW, then scenario 1 should occur, but please correct me if I'm wrong

 

Thanks!

 

0 Kudos
Message 6 of 10
(3,881 Views)

If you understand the basis of Data Flow, you can't select either scenario.  Scenario 1 is "almost" correct.  The PID function can't run until all of its inputs are "satisfied", and nothing appears on its outputs until it finishes.  Now, who knows what is on the output -- it depends on what PID does.  But this output is sent to the FPGA (the Moog Write).

 

The problem is Step 4.  You ask if the FPGA outputs PID Output the next time it executes.  That depends -- since I don't know if there is any dependency between the FPGA code and the code you show here, I can't tell if it executes before you do Step 3 (in which case Scenario 2 is correct) or after Step 3 (in which case Scenario 1 is correct).  You chose to only show us a very tiny piece of your VI (and it's a Picture, darn it), so we can't tell if there is other sequencing, nor suggest how you could make it one way or the other.

 

Bob Schor

Message 7 of 10
(3,849 Views)

I would say Scenario 2 is the most likely.  Your FPGA writes and reads the front panel controls at the same time and then outputs what it was told.  Your RT reads a value from the FPGA front panel, does a calculation, and then writes to the FPGA front panel.  Assuming the two loops are at about the same rate, the hardware output will happen on the next iteration of the FPGA loop, when the new value is read from the FPGA front panel control.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 8 of 10
(3,834 Views)

Sorry, I should have written that:

- The FPGA code is the code shown in the first posted screesnhot

- And the fpga VI is the VI attached in the 2nd post

 

Thanks for the input guys, any advice as to how I could achieve the functionality in Scenario 1?

 

Thanks

0 Kudos
Message 9 of 10
(3,806 Views)
Solution
Accepted by ghp_1

phg wrote:

Thanks for the input guys, any advice as to how I could achieve the functionality in Scenario 1?


I still say the best route is to just put all of the control logic in the FPGA.

 

Other alternatives include 1) using DMA FIFOs to sedn the data back and forth or 2) use interrupts so that the FPGA code cannot read the output level until the RT sets it.

 

DMA FIFOs are typically very limited, so I would not use them in this situation since I belive you said this code needs to be done for many outputs.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 10 of 10
(3,757 Views)