crio 9074 cpu use

[baratajoao1@hotmail.com]

Hi,

I am using a Crio 9074 with AI,AO and DI boards. The software architecture is organized as folows: 1) the FPGA vis acquire the data 2) the real time vi has a controller running in a high priority timed loop and a lower priority timed loop sends the data by TCP/IP to a host PC;3) the host PC vi receives and stores the data. The Crio is running in FPGA mode and the communication between FPGA and real time is based on indicator readings.

When running the real time high priority vi at 100Hz everything is OK although the Crio CPU load is nearly 90%; when running at 1kHz the system gets blocked - the CPU charge is 100%. 

 In the NI documentation it is clearly stated that 1kHz execution rates are expectable, so how can one justify this behaviour? Is there any apparent mistake?

Thank you in advance for your help,

João Barata

[Wayne.C]

How are you passing data between the high and low priority loops on the RT target?

[James_McN]

Hi,

Can you post any of your code?  This is more than possible on a 9074 without CPU usage that high.  There maybe something in your code that can be altered to reduce this.

Regards,

[barata]

Hi, data between time critical and communication loop in the RT Crio vi is done using a RT FIFO.

Thank you for your help.

Joao Barata

[James_McN]

Hi,

I had a thought on this.  Are you running in interactive mode i.e. are you opening the front panel of your RT VI and hitting run.  If so, in addition to your code the cRIO has to transfer all of that data back to the host which always increases quite significantly the CPU usage especially if you have charts or graphs on there.  I have seen people save 50% CPU by cutting down on graphs and charts.  Try running as an RTexe or simplify your front panel to the bare essentials.

Regards, 

[baratajoao1@hotmail.com]

Dear James,

Thank you for your support. Yes, I do have to hit on run each vi (FPGA,RT,and Host PC) each time I run the project. I have already reduced the number of indicators in the FPGA and RT vi’s to a minimum and furthermore I hid them in the front panels. This has indeed reduced the amount of CPU charge but still wasn’t sufficient. I’m guessing this isn’t a code problem because when I run the RT vi without any code inside the timed whiles (1Khz time critical while, 10 Hz communications low priority timed while) the CPU charge is already at 99/100% charge. Anyway, tomorrow at the office I will send you the RT vi so that any mistakes may be noticed.

Regarding the RT executables, can you please point me out some references on their use?

Thank you once again for your help,

João Barata

Porto, Portugal

[baratajoao1@hotmail.com]

Hi James,

Please find attached the real time code vi. Thank you once again for your help.

Best regards,

João Barata

Porto, Portugal

[James_McN]

Hi João,

Thanks for posting the VI.  I cannot see anything fundamentally wrong in the code but wondered how long does your code take to run (I can see you have been measuring it)? If this is close to the loop period it may be that you need to make the code more efficient or increase the loop period.

You should not need to run the FPGA seperate to the RT anyway.  The RT code will start it running itself.  To build the executable see the instructions at https://www.ni.com/docs/en-US/bundle/labview-real-time-module/page/creating-stand-alone-real-time-ap....

Regards, 

[baratajoao1@hotmail.com]

Hi James,

I think that definitely the 9074 cpu isn't quick enough. I have tried to run the code I sent you in a 9022 Crio: while with the Crio 9074 cpu charge is at 99/100%, in the 9022 Crio the CPU charge is at 50%!

This is nevertheless quite strange, I might add, since the code I sent you only enables acquisition and transmission of data to the PC.

Perhaps future documentation of NI should clarify what type of applications does effectively run at 1KHz (for each Crio)!

Thanks once again for your help.

Best regards,

João Barata,

Porto, Portugal

[StephenB]

I can't see your subVIs as they are not attached, but I did notice one bad thing.

Your cpu usage could be suffering because of the inappropriate use of the RT FIFO read in your bottom loop. You are using the read, but not passing in a preallocated array... so every time the read is called, it has to allocate memory... which is bad for performance and can cause priority inversion between your two loops as the LV memory manager is a shared resource. Aka... while the lower priority loop is allocating memory, the higher priority loop can't preempt it if it also has to allocate memory.

See the caution in the RT FIFO Read help:

You can do something like this instead:

Or in your case since you have a 2d array:

Also, you're reversing the array... which probably isn't good for performance either. Have the reciever of the TCP data reverse the array so your RT code doesn't have to.

Also, I see you're writing your own TCP protocol. You might want to look into one thats already been developed called the Simple TCP/IP Messaging (STM) Component. It takes care of all the array size stuff and you can set it up to have better data type support handling. It has a C example as well so it works cross platform. If you are just going from LabVIEW to LabVIEW though, check out the new Network Streams... they handle all of the connection management, data typing and sizing for you... realllllly simple.