Unsupported nodes inside for loop within SCTL should result in a broken VI

[EricLM]

While for loops inside SCTLs offer limited functionality, placing an unsupported element inside the for loop does not result in broken code. Instead, one has to wait until the second stage of generating intermediate files to discover that the element is not supported. Code like the example below should show a broken run arrow if it is not supported.

[National_Burritos]

Thanks Eric! I agree that is not ideal, we will look into it for the next LabVIEW FPGA release! Not sure if we will be able to add the fix in the next release or not, but thank you for reporting it.

Best,

Rahul

[National_Burritos]

Hey Eric,

Some comments - this is intended behavior based on how this was designed. This may not be the best design decision, so it is something we are looking at in NXG. But I at least wanted to explain why this is the way it is...

The biggest challenge is if we have the code snippet below (from your screenshot) in a subVI:

If we only look at this in a VI, there shouldn't be an error. However, in a subVI inside a SCTL (a potentially common use-case) that becomes an issue. Based on our current backend, it is very challenging to be able to determine at edit-time whether a VI is used inside a SCTL or not. And it is also possible that this VI is used both in/out of the SCTL.

Again, I totally agree with your feedback - it probably makes development way more inefficient. And it is something we will look into for NXG. I am not sure if it will be something we fix in the short-term, but I am happy to hear further thoughts!

Cheers,

Rahul

[National_Burritos]

Hey Eric,

See the picture below. This actually is how NXG works already! For the single-cycle programming, we made it a separate file type in NXG (called Clock Driven Logic or CDL). Having a separate file type allows us to be smart about what is not supported, and hence calling something like the below out as a edit-time error becomes a lot easier.

Thanks for the feedback!

Cheers,

Rahul

[National_Burritos]

[EricLM]

Hi Rahul,

Thanks for all the feedback. I appreciate the complexity of doing this in LV and as I do more of this I get to know the incompatible nodes, but don't always catch them at dev time, so it can be frustrating to discover them at compile time.

I hope to be able to take advantage of the improvements in NXG in the near future, but we still us LV for the vast majority of our projects.

Thanks

Eric

[cbutcher]

Could this be reopened given that NXG is now even more not the same as "Already Implemented"?

[Terry_ALE]

NXG is no more.

[Christina_R]

Moving status to New since NXG has been discontinued and the problem still exists in LabVIEW.