Magic Diagram Disable Structure?

[james_baker]

I have noticed something very strange with my cRIO RT code ... the attached speed_test.vi essentially calles the functional global RT_Rod_Data.vi many times to decimate a 1D array into a 2D array.  The script will be taking data from a DMA FIFO from FPGA ready for processing on RT.  (The 9th element is being converted to U32 as it contains some test results)

Using LabVIEW 2012 (f2 patch) with a cRIO 9082.

I compiled, deployed and restarted cRIO and observed an average 270 us loop time.

If I recomile this using the RT_Rod_Data_with_disable.vi, compile deploy and restart cRIO I observe an average 130 us time.

The script is correctly reformatting the array in both cases (I have checked output data is present and formatted correctly) but adding a diagram disable structure makes my script more than twice as fast !

As far as I can see not only does this diagram disable appear to have no functional purpose but should be stripped from the compiled code anyway.

Has anyone else seen this phenomenon or could perhaps explain why it should make a difference?

James.

Amfax Ltd.

[Eden_S]

Hi James,

This is indeed very strange behaviour! I have not heard of this issue before.

Does this happen consistently or have you only tried it with one compile each? I cannot think of a reason why adding any structure to code would speed it up rather than slow it down. However, our compiler does work on an algorithm that means the code written to the FPGA is different with every compile. This is why sometimes we see a compile failing the first time but working the second even if nothing has changed.

Perhaps when compiled with the diagram disable structure it routed things more efficiently and hence was faster than when without.

I also noticed that there is no timing in the loop. Have you tried adding some timing to force execution time and seeing if that makes a difference in the behaviour? Thanks,

[Alex.T]

I can't see his code, but it sounds like he's talking about software running on the RTOS rather than that on the FPGA.

A 130us difference on an FPGA would result in 5200 extra clock cycles to execute a region of code, if it's using the base clock. Usually when routing gate configurations, the router affects the propagation delay time between gates and therefore impacts on the maximum clock speed you can use before risking metastability, and not the number of clocks.

If you're waiting on a specific number of elements on the RT, then there's a chance that your software may wait for different lengths of time depending on how data is added to the DMA FIFO on the FPGA. If it's done conditionally, that might explain why the code may iterate at different speeds at different times.

[JCC_(SK)]

Hi Eden

James created LabVIEW RT code with was "recompiled" few times and always with same result.

Attached code doesn't use FPGA code (and communication with FPGA).

Best Regards

 Peter

[AG@Amfax]

Hi Alex,

The results we based on the benchmark tests of the algorithim and therefore were not dependant on the data from the DMA FIFO, the error would seem to suggest there is a fundemental problem with the code deployed to the device. Perhaps Eden you could raise a CAR on this issue and let us know what the response is from the RD team, either way it would be good to hear back from the AE team more frequently than once per week.  

[Eden_S]

Hi Guys,

I apologise for the delayed response. Basically, before I file the CAR I need to ensure that the issue is reproducable.

Could you provide a little more concise information on how the code was tested? I am going to set-up a RT device here and run a similar, smaller version of the code that James sent across to see if I can see the same behaviour.

Many thanks,

[AG@Amfax]

Hi Eden,

Have you looked at the code posted? A basic performance benchmark test was carried out, if you are struggling to read the code as implemented in the speed test vi I would happily explain it to you or you could ask a colleague. Run the following test in a project setup using a cRIO as described in the first post. I have included a zip file with the code and have created a typedef enum to replace the one that is missing. If you have any further questions please feel free to ask.

[Eden_S]

Hi Andy,

I apologise - I looked at the attached code and saw that there were missing components so assumed it was just a section from a larger, main bit of software, that was a bad assumption from me.

Thank you for the .zip, I'll run it now and file the CAR depending on the results. I'll keep you informed via this forum as soon as I hear any feedback.

Many thanks,

[Wilson54910]

Hi Andy, 

I have replicated the issue. 

I have also tried to change the structure to see what effect this has, It appears that all except the While and Timed loop inhibits this behavior.

The next steps will be for me to ask some of the more Knowledgeable people here in the UK and then look at escalating this further.

I will keep you informed of any progress

Thanks,

[james_baker]

Hi Nathan,

thanks for looking into this, some more understanding into what is going on would be very useful, it is not preventing any applications from running but it is the 'undocumented' change in behaviour which is worrying / interesting depending on your outlook!

regards

James