LabWindows/CVI Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

As discussed here, distributing the code of

 

#include <ansi_c.h>
int main ( int argc, char *argv [] )

{
    printf ( "%s", "Hello world" );

 

generated in CVI2013 results in a distribution kit of 74 MB minimum...  Using the NI default settings results in 219 MB...

 

Yes, I do have TB drives, but I dislike bloated software.

The integration of some SCC software is officially supported in CVI (see this KB).

Unfortunately GIT is not officially supported, but its popularity has been increasing very much.

LabVIEW has a specific User Group in the community (Git User Group) and I think CVI should support the same integration

 

NI is not a C/C++ Editor-Debugger company.  And, it will never be able to invest the man power needed to get there.  NIs strengths are its Instrument UIs, its libraries, and it's visual application UI pieces.  The LabWindows/CVI tool looks and feels like tools from the mid 90's (ie.  like an old Borland C editor, but even less featured).  It lacks the toolset found in VisualStudios, NetBeans, and Eclipse.  And, it will always be behind.

 

The Verigy93k tester was like this several years ago.  They wrote their own C/C++ editor, and it was at a mid 80's level.  When a team was asked to rewrite the UI and bring it up to date, they made a novel choice (they recognized that they were not a UI platform / editor company), and they moved their product under Eclipse.  Teradyne Flex did something similar a year or two later moving under Excel and Visual Studio.  The thing is this, both companies realized that they could make more money focusing on their real strength.  They added libraries and apis to work in the platforms framework, and changed/adapted the platform framework to work for them.  ie. Teradynes Flex test tool does not say "Excel/Visual Studio", it says it is a Teradyne product based on MS Excel and VS.  And, they have adapted the platform to their needs adding on the extra Windows/UIs/... to meet their needs.  Same with the Verigy 93K.

 

In Teradynes case, they went back to the drawing board.  So, we will ignore this (even with their success).  In Verigys case, all their existing APIs worked in the new platform, and the user didn't need to change anything when they upgraded.  But, suddenly the Editor and Debugger were up to date, with latest greatest features.  It was a huge change overnight.

 

LabWindows really should make a shift to Eclipse.  Keep your old legacy stuff at first, but working under Eclipse.  Add in "Views" and "Tools" to supplement what Eclipse doesn't give you for free.  And, remove unwanted or confusing plugins from the eclipse base.  (This is what advantest did.)  Leave in features that make Eclipse great, like error view, and the ability to have several "perspectives".  And really focus the man power into making a product that will blow the others out of the water.  NI has what it takes to make great Instrument editing/debugging windows in Eclipse.  But, NI doesn't have the 1,000's of people and millions of man hours required to make an Editor/Debugger that will compare to the Eclipses/VisualStudios of the world.  As a business they should focus on what will make them a differentiator, and reuse what is accepted and common.

 

Anyway.  My 2 cents on how you could really improve LabWindows in a few short months.  (Note: Verigy spent all of 9 months and 9 engineers on their C/C++ integration into eclipse...  I know... I was there at the time.)  If you took the LabWindows team, and a year or two...  Imagine how much better of a job you could do.

The CVI Full Development System supports Microsoft's Software Development Kit.

I'd like to suggest to update this support to Windows 10 SDK.

LabWindows/CVI lags behind the more recent developments in its programming language, C. At present, it only partially supports the C99 standard, not to mention the improved Unicode support of the current standard, C11.

Since odds are that Unicode finally will be supported in a future version of LabWindows/CVI, this might be a good opportunity to also ask for support of the current standard of CVI's programming language, C11, allowing the use of UTF encoded strings and also including updated libraries (e.g., supporting complex or long long) and debugging tools (data tooltips and variable view supporting complex numbers, for example). It also would help to improve C/C++ compatibility for programs that use complex floating-point values.

 

I really would appreciate it if the LabWindows/CVI project will show some strong signs of development and accompany us for the next 30 years, too.

I add this new idea based on the info on this thread.

I know that this idea is almost the same, but the basic reason is quite different.

 

I think that C++ offers much more flexibility for the development and it is a much more powerful approach for the future.

Now CVI uses CLANG/LLVM compiler, that is a C/C++ compiler.

But, as written by Luis from NI

Supporting C++ entails far more than just the compiler. For example: the standard C++ library (including templates, etc...), the APIs of all the standard CVI libraries, the source editor (auto-indentation, coloring, etc...), code-generation from the various wizards, memory runtime checking, debugging, etc... so, even though the compiler does support it, for all of CVI to support C++ is still an extremely large undertaking that has to be weighed against other, competing work that's going into CVI.

 

 

Customer who has used CVI for years and likes it was looking a Mstudio for the reason that a lot of his new engineers can't or don't do the regular C programming.  He likes Mstudio as an idea but, with the extra cost of adding MS Visual Studio and dealing with a they support/We support issues of having two SW pkg from 2 different companies gives him pause about purchasing.  He stated he likes CVI because if there is an issue (even if rare) he know that NI will help to figure it out. I let him know I'd provide the feedback.

At present, autoscaling works with respect to the full provided data set, i.e. if all data are shown on the graph.

 

If say the X axis is set to manual scaling such that only a subset of all data is plotted, autoscaling of the Y axis still considers all data even if they are not shown, see the discussion here.

 

Hence it is suggested to provide an additional auto scaling mode which considers only the data actually visible on the graph, say VAL_AUTOSCALE_VISIBLE_DATA, complementing the current VAL_AUTOSCALE which actually is a VAL_AUTOSCALE_ALL_DATA

In earlier versions of CVI source files needing compilation were marked in a different color, unfortunately this feature has been removed in CVI2013. The suggestion is to re-introduce this feature...

 

Benefits:

Changing an include file immediately shows affected source files

It's always clear how time-consuming it is pushing the RUN button, i.e. if there are files *and how many) to be compiled first

Following this idea already implemented, it could be good to add up/down keys to rows and columns selectors.

 

At present, if the table is in hot or normal mode you can click on a cell in the table preview in the Quick Edit window to select the corresponding row/column: going to editing them is made easy this way. However, if the table is in indicator mode you cannot click on the cella to select row and column. The same applies if you want to reach a column/row out of visible area of the table: the only solution to that is to double click on the column or row selector and type in the number you want. Not easy  nor fast, and prone to errors. Much better to click on a button and increment / decrement the active column index

 

I'm thinking to something like that:

TableRowColSelectors.png

Please conisider supporting multi-touch screen gestures in a similar manner to the mouse events.  Windows 7 Mulittouch capabilities are a good place to start. http://msdn.microsoft.com/en-us/magazine/ee336016.aspx

 

The GUI of the future will most certainly be touch screens, and users expect to be able to use gestures such as pinch, fling, spread, rotate, etc.

 

 

 

 

I want to be able to do the following:

 

  1. Right-click on a control on my user interface and select “Add Event Case to Control Callback” (if a callback function already exists)
  2. CVI brings up a dialog similar to what you see at Code>>Preferences>>Default Events to select an event for that control
  3. Check the box for one or more events for that control, click OK, then
  4. Have CVI find the existing control callback function and add a case to the switch statement for each event I checked

If you haven’t written any code in the callback already, you can just change the default events and re-generate (replace) the control callback.

 

However, if you have already written code for one event case, the only way I can find to add an event case is to do it manually. I go to Code>>Preferences>>Default Events or use the Operate tool to look for the constant name of the event that I am interested in, then I go back to my code and manually type out “case EVENT_CONSTANT_NAME: break;” with the name of the event and hope I remember it correctly and spell it right.

 

CVI is all about minimizing user errors and reducing development time by, you know, not making you type things out yourself, so I think this functionality would be a useful addition.

If you have, say, three controls called MAX_1, MAX_2, MAX_3 arranged vertically. If I select them all, copy and paste, the new controls appear as MAX_4, MAX_5 and MAX_6 but in the wrong order to what you would expect.

i.e.

MAX_1

MAX_2

MAX_3

 

becomes

 

MAX_1

MAX_2

MAX_3

MAX_6

MAX_5

MAX_4 

 

A similar issue occurs with assigning a group of controls to a control array, they always seem to be in the wrong order, usually reversed.

OPC UA has become much more popular in the last few years.

I did some tests trying to integrate open62541 library in CVI 2015 and 2017.

 

I think that CVI should provide this library as an add-on.

Moreover NI engineers can put their effort tryingo to develop the library itself (rather than rewriting a library from scratch).

It appears that cvi.exe can run into serious memory problems for larger projects due to a memory-hungry generation of source code browse information.

The solutions suggested (* don't generate browse information for larger projects or * don't use larger projects) are not too helpful. In my opinion, a much better solution would be to provide cvi.exe as a 64 bit application.

Because a crashing CVI is a serious limitation I hope this wish will make it soon.

Thanks...

Since now CVI relies on CLANG, it would be great to have a tool for static code analysis.

Some software are available for C code (see here), but I think CVI can use Clang Static Analyzer (if it is good enough - I've never tried it).

My CVI application started to generate linker errors immediately after I upgraded from CVI 2012 to CVI 2013. A number of other people have reported exactly the same problem, with the linker unable to resolve symbols found in IMAQdx or nivision.

 

This means that the final release of the new version of CVI cannot have been tested when using the image acquisition or image processing add-ons.

 

I suggest that, in future, new versions of all tools are subjected to automatic regression tests against the examples distributed by National Instruments before release. Because it obviously doesn't happen now.

Hi,

 

sometimes vertical buttons or toggle buttons fit better to the rest of the UI than the standard horizontal buttons. In such cases I would like to have the possibility to have the button text aligned vertically. Hopefully the attached figure can explain my wish...

 

vb.jpg

I recognized it's not possible any more to view a constant while debugging since CVI 2015.

Example: #define CONSTANT1      1

For example if I have a constant defined, I can then right click “view variable value”.

Normally CVI then shows me the value.

 

Since CVI 2015 this doesn’t work anymore. I also tried with CVI 2017.

In our code we use many structs where the fields are defined by a constant.

Now when the debugger can’t view the constant any more it also won’t view the value of the struct.

Example: #define CONSTANT1      1

Int struct[10];

struct[CONSTANT1]  = 5;

 

This is the main reason why I didn't upgrade from CVI 2010 to 2015.

In the last few years JSON came out as new format for data objects consisting of attribute-value pairs, largely replacing XML.

LabVIEW has functions to handle JSON data, and LabVIEW Community has been developing a JSON Toolkit.

In the CVI board of the forum this is the only result for a "JSON" search (at the present).

 

I suggest to integrate into CVI a JSON library (for example JANNSON).

I think this is better than develop a proprietary library.