LabWindows/CVI Idea Exchange

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

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

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

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

 

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.

Where does NI stand on this????

NI no longer supports 32 bit OS, but hasn't ported their own toolkit to x64. Since NI is NOT committed to developing (or even maintaining) CVI toolkits, how about open sourcing these so that users and the community can move these forward.

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

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.

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.

I love my CVI, but come on.  How great would it be to be able to debug your project inside VSCode?

Dear NI,

Until lately I worked with CVI 2017. I've decided to move on and I have installed 2019. For years I use NIReport 

to create reports to the customers. To my astonishment, NIReport is no longer supported, meaning a work of years will be thrown away. I have tried other options provided by NI, such as creating a report in word/excel, but neither gave me  satisfactory results

I am developing applications in CVI for 15 years, and had NEVER a problem of backward compatibility. I know other companies  that do not care about their customers, but NI has been never the case.

I hope that NIReport will be back. 

thank you

 

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

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.

 

 

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.

At the moment the maximum panel and control name length is limitted to 32, if you set them programmatically.

 

Because of longer customer system signal names it is not possible to use them directly as control names. If the maximum length could be raised to 64 or to the maximum label length, it would help to avoid to generate new control names and the additional mapping between costumer system signal names and the generated control names in the test environment.

Adding a example code in CVI for CAN FD in CVI is very important for the customers , sending a CAN FD frames in CVI is not as easy as labview , it requires deep knowledge of pointers .

Please include example for sending different payloads like 8, 12, 20, 24, 64.

 

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

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

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

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.

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