Compiling FPGA code numerous times has different results

[labviewman]

Hey James,

Thanks for taking time to look at my code!  I have 22 years of ex in LabVIEW and would love to help others but I'm always too busy and behind schedule so I can't.  I appreciate you taking the time to help!

1) Added the pipeline anyhow even though speed isn't needed

2) Changed from index an array to individual elements into the measure/calc code

3) The update user variables code can run far slower than the main loop so a slow quotient calculation is acceptable, though, the function is very costly in space on the FPGA. I'm at less than 50% now (started out at 90%+!), so space isn't a problem, it's the darn timing violations, most of which are not tied to my code (at least what can be seen).

4) EtherCAT state has been moved outside of the fast loop...no need to check it so fast since all it does is define the flashing led timing.

Thanks for the sanity check...was hoping there was something stupid.

Will see how the compiles go...

[labviewman]

50% compile success rate (out of only 4 compiles), so, no change for the better.

[Terry_ALE]

How does this compare with the shipping examples for this hardware?

In other words, how much did you add?

How do the compile results of the shipping examples do?  Do they compile all the time?

[Intaris]

Click on the "non-diagram component" in the timing violations window and in the status at the bottom of the window it will show you exactly where in the design the error occurred (the path will be a bit cryptic but usually contains enough information to give a good hint).  This information is incredibly valuable in finding out your first step of action.

[labviewman]

The code is significantly different...no example has a fully loaded EtherCAT chassis like I do, and no code does close to what my code does (measure period of a pulse train, averages the period over a configured time and updates a variable, for all 6 inputs).  About all that is very close to an example is flashing the FPGA LED.

Looks like the fully loaded chassis has much to do with it since FPGA utilization is less with a EtherCAT chassis with only one module (9411), which is 30% vs 53% on a fully loaded chassis.

BTW, if I remember right, compiles are near, if not at 100% with a EtherCAT chassis with one module...tried it today...successful on 8 of 8 attempts

[Terry_ALE]

Should have done it earlier, but I looked up the chassis and it has a Spartan-3 2M FPGA.  This is quite old and I do not know if there are newer EtherCAT chassis.

In the past I remember NI having recommended chassis for certain applications/module combinations (particularly for power analysis).  This is probably good feedback to them cause as your code does not seem to be too complex (relatively).

The question was more to gain some perspective but I cannot give any specifically actionable advice from this.  Did you talk with NI about your issue?

[James_McN]

So the really interesting thing is that the timing violations seem to be happening on the 80MHz clock (noting the target period). This doubles up the idea that this is a problem in the scan engine components (all your code was at 40MHz).

At this point (if you haven't already) I would try opening a ticket with NI support. They may be able to find similar issues and have some concept of anything you can do to impact it.

[Yin_W]

I believe NI 9144 is going to be EOLed in the near future. NI 9145 with bigger FPGA will be a good choice for labviewman's use case.

[labviewman]

I read about the 9145 but unfortunately, we are stuck with legacy hardware and software because NI changed the HTML format or data on firmware above EtherCAT 2.4 such that our dyno control software will not work.  We will soon, sometime in the next year be getting an upgrade to the dyno software but I suspect they (dyno supplier) are still using the older XML format, thus, I'm stuck with LV2012 and 9144's