LabWindows/CVI Idea Exchange

In CVI 2013 the array display has changed (for the worse, in my opinion).

There are two minor inconveniences and one acute shortage I would like to see improved (hopefully prior to CVI2020 )

First, the right click context menu: If I want to see values of a numerical array, it offers a 'Graphical Array View' but no 'Array View', so one first has to chose 'View Variable Value' and then 'Array Display' - maybe one could save one step and already provide the 'Array Display' in the first case...?

Second, the new Array View table still is very slow, not extremely slow as prior to SP1 but still very slow...

Most importantly, at present it is impossible to debug large arrays, large meaning arrays with more than 10000 elements. The current implementation requires to select a slice of data - but this makes it impossible to check or compare say array indices 5, 10005, and 20005...

Of course I agree that there is no need to simultaneously see more than 10000 data values - but why not have a table with say 100 rows that can be turned over, e.g. displaying either elements 1-100, 101-200, ... this way one could access and inspect all array values...

View All (3)

If the thread that FileSelectPopup (and similar) is accessed is multithreaded, wacky things happen. The programmer can fix this by creating a new thread that is itself not multithreaded and pass information back to the current threrad. It would be helpful if the current functions were designed to default to create such a thread, return the value(s), and garbage collect removing the programmer from the loop.

In the case of MultiFileSelectPopup, it is not clear to me what would be the best practice given the unknown number of results. I guess one could assume a limit for the number of results that may change as the Windows API does.

Other possible solutions can include an added parameter (variable switch) or with a whole new function. I could see the default case as an effective solution for legacy code that is partially refactored for multithreaded performance.

It was a nice surprise when CVI provided clang as an external optimizing compiler. In the meantime, however, the initial clang version 1.0 has been significantly improved and now is at version 3.0 - but not for CVI users...

I would suggest that NI provides a current Windows binary of the compiler for everyone with a legal copy of CVI2010 or later. As the release cycles of CVI are quite long it would be convenient to obtain, on a biannual interval, interim updates of clang.

Spoiler

On a side note, this also would provide some motivation to keep/renew the SSP. Right now I consider it disappointing if the equivalent of several hundred Euros is a patch of CVI only. Other major companies such as Autodesk or Microsoft provide patches free of charge...

View All (1)

As of CVI2013 data tooltips and variable view do some kind of automatic rounding but based on 15 digits only... This prevents tracking numeric / rounding issues. Unfortunately, no possibility exists to show the full precision of doubles... Phrased more drastically one you cannot use CVI to debug numeric issues...

So I suggest to urgently add

as a minimum version the possibility to show true numbers, not rounded numbers, allowing true debugging
as a more general version the possibility to adjust the precision of displayed numeric values

View All (3)

As discussed here earlier I am using tooltips that show 'dynamic' information, e.g. the permitted data range of the respective control, available user actions..., These frequently depend on several other controls and parameters.

Right now, all other affected controls etc. need to call a function to re-build the tooltip text, and to more than 90% this is wasted effort because the tooltip text is changed again before it may get displayed...

Thus I would like to suggest a 'dimmer callback', similar to the menu dimmer callback. This 'tooltip dimmer callback' should be called just before the tooltip is going to be displayed, allowing to build/update the tooltip text only when needed.

Thanks

View All (2)

One thing, I'm comming accross with very often is, that the drawing updates of Table controls are very slowly, Sometimes, they bring the system to hanging, whithout increasing the processor load, and User Interface events (e.g. Commit events) are not recognized quick enough (up to 30 s delay, depends also on other events, e.g. Timer, HW events etc.).

On most of my projects, I was changing the Table controls to Tree controls, which are much more quicker in drawing updates. But sometimes, I need the Table features (e.g. Ring cells, picture cells etc.), so I'm not able to change the Table into a Tree.

According my expierience, Table controls should be updated every 2 s and Tree controls are able to be updated every 200 ms or faster without waiting for User Interface Events.

You should make Table controls nearly as quick as Tree controls...

Thanks

I apologize if this has already been addressed but this was determined as a issue years ago and forced us to implement a workaround.

We use PloXY for large data sets (up to 16 MB has become pretty standard lately). To address lag years ago, we pared the data to be viewed to 4000 data points in background code and send that to PlotXY. However, when the user zooms - which is always, you must then go back to the original data to find the new best 4K data points prior to plotting the new data. The code usually works well but there are instances where it can shutdown unexpectedly - not often enough to fight through friutfully though.

As for an truly automated perhaps a more logical course of action is to retrieve the panel size and use that for the data sizing. Regardless, it would be nice to use the CVI built in function and then subsequent zooming etc could be possible via standard functions.

My 2000 dollar worth, run of the mill desktop PC has 4 teraflop of brute computation power hiding in 4 GPUs. None of which is accessible for my programs I develop in Labwindows.

Shame!

With the release of the new OpenCL it is possible to generate a "platform independent" GPU computing library. That would place Labwindows on the same or better footing than Labview that already has some GPU computing support.

The advantages are obvious: huge gain in data processing speed, real-time application with streaming data, pattern-recognition (video) applications, image processing, data-parallel tasks in (technical) modeling arena.

I am playing with some optimization algorithms (genetic algorithms, evolutionary algorithms) that benefit and show amazing gains since they are ideal for data-parallel applications! Currently working on the specs for a new type of controller that would optimize several parameters to figure out the state of the tissue culture (expanding, producing, overgrowing, etc.) to maximize productivity and to calculate the optimal settings using evolutionary algorithms... Any complex process control could take advantage of this kind of applications -currently not available- because of computational limitations. Had a previous optimization task that would have taken 150,000 years to complete using a brute force algorithm on a "monofilament" CPU-based application. Converted it to a genetic algorithm and it gives me a good enough solution in 3-4 days on the same standard PC. Now, with GPU, that problem could be solved in fifteen minutes while expanding the evolutionary depth and finding better solutions using even more complex fitness functions.

Ask yourself what do you want: tinkering with the conveniences of the IDE that already does the job well enough; or open the door to new landscapes that could be conquered by using the simple elegance and effectiveness of LabWindows and the power of GPUs?

View All (4)

View All (2)

Comparison between floating point numbers is best done using FP_Compare() - see CVI help for details.

Often you need to choose the maximum (or the minimum) of the two floating point numbers, and the most common approach is:

if (a > b) {

choose a

} else {

choose b

}

If you use FP_Compare instead of ">" you'll notice that FP_Compare is much slower than ">" (because it involves calculation of the ratio between the two numbers). This is extremely evident if you have to choose the maximum of several couples of numbers.

I think that the maximum (or the minimum) between two floating point numbers could be found in a more effective way, comparing the exponents of IEEE representation (for example), and calculate the ratio only if the exponents are equal.

For this reason I suggest two new functions FP_Max() and FP_Min() that would much more performant than the easy approach.