FPGA Graph handling

[Intaris]

I've developed a small test utility for testing FPGA code on my windows machine before proper FPGA testing and have noticed something I think could be improved.

If I have a graph or any other indicator with DBL default data type within a conditional disable, the compiler still throws an error regarding an unknown state (DBL).  Although the terminal is in the diagram disable, the object seems to remain on the FP (but also in the code being sent to the FPGA compiler).

Can we actually remove the graph (or other culprit control) in the background before starting the actual compile so that I don't need to drop and re-connect every time I want to switch execution systems?

Shane.

[Intaris]

I wanted to further comment on this idea as I have a new use case which may be related:

It seems that FP controls and indicators placed within a disabled case of a conditional disable structure are not removed from the source code early enough in the compilation process.  I would like ideally to be able to tell VISUALLY which FP controls and indicators are active in a given context.

Example:  I have recently written an oscilloscope module as part of our FPGA software which includes multiple triggers and pre-trigger functionality.  I have placed a bunch (around 40) indicators on the FP to allow me to debug what's actually going on while the code is running on the real hardware.  I have placed the entire code for this monitoring (40 indicators and 40 global reads in a for loop) in a conditional disable structure.  On the FP I see NO indication that any given indicator is currently not actually part of the code to be compiled.  I think the visual feedback is an important missing feature.  Such disabled UI elements should then NOT interfere with any given compilation (DBL on FPGA and so on).