LabVIEW FPGA Idea Exchange

About LabVIEW FPGA Idea Exchange

Have a LabVIEW FPGA Idea?

  1. Does your idea apply to LabVIEW in general? Get the best feedback by posting it on the original LabVIEW Idea Exchange.
  2. Browse by label or search in the LabVIEW FPGA Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  3. If your idea has not been submitted click New Idea to submit a product idea to the LabVIEW FPGA Idea Exchange. Be sure to submit a separate post for each idea.
  4. Watch as the community gives your idea kudos and adds their input.
  5. As NI R&D considers the idea, they will change the idea status.
  6. Give kudos to other ideas that you would like to see in a future version of LabVIEW FPGA!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

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

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.

 

Annotation 2019-08-14 111042.png

5 Comments
Member
Status changed to: New

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

Rahul B.
Member

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:

subvi.png

 

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

Rahul B.
Member
Status changed to: Already Implemented

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

Rahul B.
Member

NXG subVI.png

Rahul B.
Member

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