cRIO 9035 with finished late

[JyunHua]

Hello, guys

This is my first post, if there is anything wrong, please let me know. 

I use cRIO 9035 to control my motor system with 9263 and design a timing loop with 1ms sampling time as the main structure to send the command to my driver. All Vi codes are run on the FPGA.

When I send short commands (about 15 seconds), everything works well. However, the longer command causes the timing loop finished late. For example, send command for 30 seconds and it works well before 25 seconds and starts to have finished late until to the end. 

After several testing, I can bypass this situation by "Run continuously". That is, send 30-second long command will have finished late at the first round and the same command works well at following rounds until I click the abort execution button. 

Anyone can tell me what happens and how to solve it?

Thank you

[AlysaOng]

Hi,

I think it is because it is not enough time for the structure to process the commands. Maybe you can try to increase the time of the timing loop.

[MaxJoseph]

Hi,

The FPGA should run with very precise timing, but only if you use Single Cycle Timed Loops (SCTLs). Using anything else will result in fast, but not necessarily precise timing. While loops can be used on FPGAs, but will take a number of ticks depending on the number of operations in their longest chain. The downside of SCTLs is that they must be able to execute in a single tick, so you are limited in the length of your longest chain. Pipelining becomes useful here.

It sounds like only the first run is late but subsequent runs occur on time.

Do you pass instructions to the FPGA at run-time? The delay could be caused by the time it takes for the host PC to upload the command to the FPGA.

Please post some example code for us to comment on.

[JyunHua]

I know the running time is short, but my algorithm is designed under 1k Hz.

Increasing time period doesn't work for me.

Following is my structure

Running the code on FPGA

Standard control system for two motors

The gif shows my problems.

The first round has delay and works well in the second round.

(look the "Delay" block at the bottom)

[MaxJoseph]

I presume you are doing some sort of feedback control system. The code you have shown looks like it is running on the cRIO RT. It is reading front panel controls to determine motor positions, doing calculations and then writing new commands to front panel controls. Does the FPGA rely on these front panel writes to know what to do next? The delay could be caused by the time it takes the RT to start or any jitter that is in the system. If the front panel values are old then the FPGA will not do anything.

Are you relying on the timed loop to keep your RT and FPGA in time? Synchronising the FPGA and the RT is difficult! Make the system asynchronous if possible. Send commands to the FPGA and let the FPGA work out what to do with them.

Consider putting the feedback/response code down onto the FPGA. The RT can then just monitor the current position using the front panel controls.

[JyunHua]

hi max, thanks for your quick replies.

In my project, I use the front panel to design position before timing loop start. 

While the loop running, it only reads the existed array data, sends out encoder data and does some calculation in subvi.

So, these processes cause the problems?

I do rely on the timing loop to keep my FPGA in the precise period.

Is it a wrong design?

And how can I change to the asynchronous system?

thank you.

[MaxJoseph]

Hi, no problem; I am happy to help 🙂

If your FPGA is waiting for commands from another (less deterministic) system before the FPGA acts then your FPGA will wait if the other system has jitter. This is probably causing your delays.

That said, you could increase the priority of your RT timed loop to improve performance, which might help you achieve your immediate goal by avoiding jitter. Try this and let me know if it helps.

But there is a more fundamental design issue: You should try and put the logic that controls motor position onto the FPGA. Avoid situations where the FPGA has to wait for the RT.

Then you can issue general commands to the FPGA: (These are in no particular order!)

• Go to a position and b speed
• Do a sine wave with c amplitude and d frequency for e time
• Stop everything
• Return to home position
• Set home position

The FPGA will read and interpret these commands and decide the motion required itself. Consider safety and have an interupt line to perform an emergency stop rapidly if required.

It might help to show the logic that controls your motion, sometimes you need to rework it since the FPGA does not work quite the same as other microprocessors. That said, there are a lot of express vi's available for LabVIEW FPGA to do things like PID control.

[JyunHua]

HI, max

After trying to figure out your suggestion and doing some testings for a week,

I make some conclusion for it. 

First, my main code runs on the HOST, and an I/O code runs on FPGA. At each time period, one command is sent from HOST to FPGA then the I/O processing works consequently. The encoder data are sent form FPGA to HOST at the same time. THIS IS BAD, right?

Now, what should I do is eliminate the "sending" processing and work ALL controls on the FPGA. That is, put the timed loop on FPGA but HOST. The scenario is like

• run the HOST code and decide the commands
• send to FPGA for once and wait
• Trigger by FPGA for finishing
• read the data I want
• stop

Do I misunderstand anything?

[MaxJoseph]

Hi JyunHua,

You are correct. Your FPGA should be able to operate independantly, as much possible. The Host is the interface which the user uses to send the FPGA commands. These commands should contain all the information required to perform the action.

For instance, you could use a cluster front panel control to send a message to the FPGA. The message is a cluster that contains a command enum and a data variant. The FPGA receives the cluster, reads the enum and uses a case structure to read unwrap the variant. An example is: Message cluster where Command='draw circle', Data=(centre=x,y, radius=r, speed=j). The FPGA then can then know exactly what to do to complete the action without any further commands from the Host. The FPGA can also continually send information to the Host via a FIFO to update the Host on the current position.

The FPGA will operate much faster than the RT. Use the FPGA Wait function to ensure timing and movement rate are appropriate.

For safety, the FPGA should always be monitoring another control, or interupt, for an emergency shutdown command. If the FPGA receives this command then the current action is stopped and any make safe processes that must occur are carried out.

PS The Message=CommandEnum/DataVariant design is very similar to the Queued Message Handler template. If you are already familiar with this then you will already understand what I am describing. If you are not, then take a look at that template that is provided with LabVIEW and take note of the message type definition that is used to define the queue data type.

PPS Using a single cluster front panel control write ensures that the FPGA has all the information is needs to complete the action before it starts, do not use multiple control writes, this will result in race conditions unless you put the command as the last write.

Finally, I have never actually implemented this design, my systems are fundamentally different (always on, continuous monitoring). I am very interested to hear how you progress and I also welcome the advice of other forum members.

[JyunHua]

Hi

I have re-designed the FPGA and RT structure.

BUT, I face some calculation problem. Because my algorithm is quite complicated, the FPGA can no do this and I can not just send command once.

I put the controller (a feedback loop designed under 1k Hz) to the FPGA and run loop with 1k Hz. At RT part, running a timed loop with 1K Hz, too. Send the desired command in every time slot.

It can work well, but the performance decreased.

I think it is a synchronization problem.

Is the analysis correct? 

Use FIFO to resolve it or any other suggestion?