LabVIEW Idea Exchange

In Diagram Disable Structure, if there is an option provides "Selector Terminal" that could help to control programmatically. This could be optional selection in RCM (Right Context Menu).

Connecting Enable/Disable as Constant/Control to Case Structure would not do all purpose as the functionally of Diagram Disable Structure Enable/Disable individual does.

Diagram Disable Structure have unique behaviour if this Selector Terminal is given as optional that will add even more vale to the same.

As programmer myself felt that why do this be controllable, because while developing big codes we use to much of diagram disable structure , when we are suppose to change to Enable or Disable, I has to search for around my code. If this has controllable option that help to do my work even more efficient specially while testing code. 

I am submitting this request based on a recent suggestion from a customer.

After doing a peak detect, the customer wants to find full width at half maximum(FWHM) of those peaks. 

However, in order to calculate FWHM, information of quadratic fit used to find the peaks is needed. However, we cannot get the equation from Peak Detector.vi. This means, the user needs to do an additional quadratic fit, and then calcualte FWHM after that.

It would be very nice if we can get FWHM from the Peak Detector.vi.

The Report Generation Toolkit provides functions to set various Format aspects of Excel "areas", and Excel Graphs, but doesn't provide the complementary "Get" functions to return the current values.  For example, I wrote a LabVIEW function that will set the Font Color of a row of a WorkSheet to Red (using Excel Set Cell Font), but if I want to find the row with the Red font, there is no "Excel Get Cell Font" that can return the property to me.  Of course, I could cobble something together using ActiveX calls, perhaps, but these are poorly documented, and since NI is already doing the "heavy lifting" to provide the Set functions, it would seem "relatively simple" for them to also add the corresponding Get functions, as well.

Bob Schor  (using Excel as a "controller" for some experiments controlled by a LabVIEW Real-Time system)

We have cloud computing, virtual Machines, CPU virtualization etc. - There are numerous ways of achieving parallel and distributed computing, available at different architectural levels. The inherent parallel nature of the LabVIEW graphical programming means we can often achieve parallel computing without thinking.  

-But in cases where the programmer actually needs to make a decision we now have the Loop Iteration Parallelism option.
If an action is to repeated multiple times and the execution of each run takes longer than the overhead of communicating the input data, execution code and/or output data across to multiple targets, parallelization can reduce the total execution time, and/or reduce the load on each target. Now, in some cases the execution time can justify parallelization even across slow communication channels. 

What if we expanded the user-friendly loop iteration parallelization mechanism to also support remote processors?

• On the targets we want to offer as execution hosts we will need to install a host service. This service might offer us the choice of offering all, or just a subset of the available cores.  Perhaps even decide this based on the current load on the target, or time of day(!). The targets can be of different platforms as long as the code is possible to recompile for it.

So how would this look like to the programmer? Well, we simply extend the for loop parallelization function dialog to something like this:

• The loops should also allow this setup to be changed at run-time. You could have a general VI to define the default targets and establish a link to them, and each for loop could have input terminals to specify the parallelism options to be used at the time of execution.
  
  
• Another fun consequence of this functionality would be that you can really distribute *any* part of you code across multiple targets simply by wrapping it in a 1-iteration only loop.
  

With this functionality in place getting 10 machines to work on a heavy problem instead of just one would really be as simple as drawing a for loop...