LabVIEW Idea Exchange

LabVIEW currently has functions Format Date/Time String and Scan Value to convert between time stamps and strings.  Unfortunately, these functions do not handle arrays of time stamps and strings.  While this conversion can be handled using a For Loop, a specific function would be cleaner and probably faster.  This functionality is currently available for other numerics and should be extended to time stamps.

I suggest modifying the Format Date/Time String function to handle arrays of time stamps, integers and floating point numbers as well as single values.  An additional function Date/Time Sring to Time Stamp should be created to convert strings and array of strings to time stamps.

NI updater kindly informed me that LabVIEW 2014 SP1 was released (even though I uninstalled it shortly after I tried it last year) and out of curiosity, I took a look at the known issues list.

I learned a few interesting things I did not know about, and also that some problems had been reported as long ago as version 7.1.1. This type of stuff looks like bugs that won't be fixed, ever.

For instance, CAR #48016 states that there is a type casting bug in the Formula Node. It was reported in version 8 and the suggested workaround it to use a MathScript Node instead of a Formula Node (where is the "Replace Formula Node by a MathScript Node" contextual menu item?).

Problem: the MathScript RT Module is required. Even in my Professional Development System, this is not included by default. Does this really count as a workaround?

I read: we don't have the resources to fix that bug, or we don't want to break code that expected that bug.

In any case, this bug with most likely never be fixed.

The bottom line is, we can waste a lot of time as users, rediscovering bugs that have been known for a while and will probably never be fixed. As a user, I would really appreciate a courteous warning from NI that there are known traps and have a complete description handily available with the help file related to the affected function.

My suggestion: add a list of known issues (with link to their description) for all objects, properties, functions. VIs, etc, in the corresponding entry in the Help File.

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...