Additional NI Software Idea Exchange

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

Recently I've been doing some XNet development on embedded RT targets.  Particularly the Linux RT hardware with the embedded UI.  This is a very neat platform and allows for a UI on RT without needing an industrial PC to talk to.  So having support for things like importing a database from a USB drive, or exporting a database would be features I'd hope were supported by XNet but apparently it isn't.

 

I made a post here describing my use case where an engineer would like to come up to a system with a database on a USB drive, and be able to select it and start logging data back to the USB drive.  Then I thought when the data was being logged, the database used could be exported and saved with the raw data.  This way the data being taken could have a copy of the database used for tracability.  There does exist a SQLite database on the RT target but it is not in any form that is useful for importing in XNet.

 

So this idea is to add support for more database manipulation on RT targets, particularly when it comes to importing and exporting database.

It would be nice to have support for XNET LIN Multiplexing to use with VeriStand. 

We have dozens are targets that are deployed to by an automated system depending on test cases being run. However, we have no API (short of building our own system) to retreive what system definition a target is currently running. This would help us improve our test case speed by only deploying when needed, and also improve configuration management and traceability.

Currently the entire realtime sequence must be set to stop execution on fail or not.  It would be better to allow each realtime sequence call the ability to generate an error message on fail and then allow the user to define if the appropriate action would be to notify only and continue, notify and give option to continue or abort, or to abort on fail and notify.   

This attached file is a picture that shows the outcome of current drag and drop UI setup (above the box), and the desired drag and drop UI setup (below the box).

 

As you can see above the box, when I drag and drop each channel that a user could select for a single digital output, the controls are numerics by default.  It would be quite tedious for a user to drag and drop each required channel, and then interpret the channel's function based on its name alone. Below the box, I right clicked a channel from the tree, and then selected a control based on the datatype that makes sense with respect to the channel's function. It makes sense that the controls are numerics by default because in the Set Channel Value.vi (part of Custom Device API library), the only accepted datatype is Double. However, it would be nice to be able to set a channel's datatype in a custom device's configuration VI. Channel, folder, and device properties can be set using a polymorphic VI that supports many data types. I propose that channel values could be handled in a similar way. Then in the VeriStand UI, when a channel is drag and dropped from the system definition tree, it could be recognized as Boolean, ring, numeric, etc...

 

Further desireable functionality would include a custom control which would allow the user to drag a single channel from the system definition tree. The custom control would be composed of multiple programmer-defined controls whose data would be passed to the driver in a cluster since there could be multiple datatypes. Using the attached file as a visual example, the custom control would programatically update its appearance based on the desired output mode (discrete, PWM, or encoder).

OK, I admit that I find keyboards a useful input device. And I like to keep my fingers on the keys instead of switching back and forth to the mouse.

 

This said, I should appreciate when I can use the <tab> key to navigate through dialogs. Such as the scaling dialog in MAX: If I mouse click into unscaled max, I can tab my way through unscaled min - scaled max, scaled min. But -Lord forbid! - not into scaled unit! why not? wouldn't this be the most natural dialog box behaviour? To be able to tab through all fields of interest? Given that LV has a great tool to select and organize tabbing behaviour of user interfaces - why have all MAX dialogs escaped this small improvement ever since (as far as my knowledge goes back to MAX  1.0)

Please give some programmer this half an hour and let him improve this detail.

Thank you

Michael

Hello,
I would like to suggest implementing software tools in which to objectively calcuiate audio/speech quality based on the industry standards (i.e. Perceptual Evaluation of Audio Quality (PEAQ), Telecommunication Objective Speech Quality Assessment (TOSQA) and Perceptual Speech Quality Measure (PSQM))

thank you.

I've been working with LabVIEW for about 3 years, on the same PC.

All the time I've installed all the NI-Updates.

This time the LV 2016 update couldn’t be done, because of lack of memory space on my PC. I’ve deleted a lot of data, but 48 GB (!!!) still weren’t enough.

Then I’ve made an EXCITING DISCOVERY.

In the directory C:\ProgramData\National Instruments\Update Service\Installers there are several older (up to 2013) folders. Overall data volume of these was 131 GB! This is a half of my hard drive!!!

Why didn’t NI-Updater suggested to remove these old data before I have started to remove some MBs of my old documents?!! Is the data really essential for NI-SW? Is there ANY need for this data on my PC?

I’m really embarrassed by this issue. To overload clients PCs with such a trash data is not a good approach!

And regarding LabVIEW-Updates, I think the installer should ask the user if he/she wants to keep the old version of LV instead of always keeping it on PC.

What is the point on keeping the old version of LabVIEW anyway? Once opened with a new version, no VI can be opened with the older one.

Would anyone find it useful to have cloud-based, user-definable calculators with a web services to integrate with NI products?

I love being able to simulate DAQ hardware and write the program before ever connecting the hardware to actual instruments, but the default waveform that is generated from a simulated device is not always a great representation of the expected signal of the actual hardware. Right now I have to program in a way to select between signals from the simulated DAQ device using DAQmx Read or a Simulated Signal express VI. It would be great if the Simulated Signal express VI was built into MAX so that the signal from each simulated DAQ device could be modified from Max. This would simplify the LabVIEW code needed and allow me to easily test the code.

 

Max

Currently it's possible only to assign number of bus from 1 to 100 in MAX (e.g. "CAN1", "CAN2", ... "CAN100").

 

When you are working with test systems with multiple test sockets and each UUT has got many interfaces (e.g. 3xCAN, 4xLIN, 1xFR) it's hard to manage system configuration.

 

1. Right now it looks like this

e.g. :

Socket 0 => CAN1, CAN2, CAN3, LIN1, LIN2, LIN3, LIN4, FR1

Socket 1 => CAN4, CAN5, CAN6, LIN5, LIN6, LIN7, LIN8, FR2

etc....

 

2. You could also assign numbers that first digt equals socket number, second interface number, like "CAN23" = UUT2, CAN bus number 3 :

Socket 0 => CAN1, CAN2, CAN3, LIN1, LIN2, LIN3, LIN4, FR1

Socket 1 => CAN11, CAN12, CAN13, LIN11, LIN12, LIN13, LIN14, FR11

etc...

Looks better, but here you are limited to 10 test sockets since bus numeration is limited to 100.

 

3. With custom aliases it would be much easier to manage multiunit - scalable test systems and reduce debug time. Example :

Socket 0 => Vechicle_CAN_0, Private_CAN_0, Backbone_CAN_0, Ultrasonic_LIN_0, AlarmDetector_LIN_0, Control_LIN_0, InternalLight_LIN_0, Safety_FR_0

Socket 1 => Vechicle_CAN_1, Private_CAN_1, Backbone_CAN_1, Ultrasonic_LIN_1, AlarmDetector_LIN_1, Control_LIN_1, InternalLight_LIN_1, Safety_FR_1

etc...

 

4. Or in more generic way :

Socket 0 => CAN-A-0, CAN-B-0, CAN-C-0, LIN-A-0, LIN-B-0, LIN-C-0, LIN-D-0, FR-A-0

Socket 1 => CAN-A-1, CAN-B-1, CAN-C-1, LIN-A-1, LIN-B-1, LIN-C-1, LIN-D-0, FR-A-1

etc...

Hello! 

 

It would be extremely usefull and would save lots of frustration if the Veristand Sequence Editor (and all of verstiand for that matter) had undo and redo functions. It is surprizing that software of this caliber does not have such a basic function. I posted this in the main veristand forum and wanted to also make sure it made it into the Idea Exchange.

 

Thanks!

Dear NI Community,

 

it would be a good feature, if it'll be possible to see directly in NI License Manager list of licenses, and expiration dates - all at once. If it'll be possilbe to export it, it would be really great, because then you can sort them, check what will expire first, and so on.

 

Because when sometimes we use trial keys for toolkits, activated at different time - it's a mess, because one needs somehow to track when trial license will expire, and when you need to ask for new one / to purchase final license, and so on...

 

Why don't to make it more easier for users then? Smiley Wink

 

Thanks a lot,

Sincerely, kosist90.

It is very helpful if the expired signal of watchdog timer can be routed in the system as PXI Trigger, and so on. Users can use this function easily to increase reliability of their system without creating a Custom Device.

During the test phase, the possiblity to add a a formula or a conditionnal channel instead of just a number, would be really appreciate.

This feature was included in TIV, a competitor software and we really missed it.

 

add formula.png

 

In certain circumstances it would be helpful to see exactly what license file ties to each piece of activated software within NI License Manager. This would be an additional field in the right hand pane of License Manager as shown below.

 

 

License Manager Idea.PNG

The Embeded Data Logger and Waveform Data Logger could have some sort of array (either two 1D array or one 2D array) allowing to create custom parameters to the TDMS file. The array could be defined in the SDF or during operation using a LabVIEW VI to pass data to it.

If your project performs data acquisition of channels as Waveform data type(instead of single point), you can't associate this channel to a Aliases. Since the waveform data type receives a buffer of data, you could choose some common options for that channels, such as max buffer value, mean among others.

Since it does not exist, I had to create an workaround by acquiring data as single point and logged them using embedded data logger, then had to use Diadem to create the waveform channel.

In addition, it would also allow to acquire data in higher rates because the waveform acquisition loop runs ins parallel to the PCL.

This feature would be extrememly handy for those who are using waveform acquisition and logging, and would save me some months of work.

Hallo,

I have detected a small but cumbersome problem witch at the end of the day can grow to a problem with heavy impact related to security updates.

 

In the actual release, the NI Volume License Manager can disable the NI Update Service on the client machines if the Administrator of the Volume License Manager sets the option “Disable NI Update Service on all client machines”.

 

Now, for example, there is a scenario on witch clients get the License for a DIAdem installation from the NI Volume License Server and get the License for a LabVIEW installation from the local License Manager.

 

The problem is, that the user cannot update his LabVIEW application using the NI Update Service because it is blocked by the administrator of the NI Volume License Manager for the DIAdem installations.

 

There should be the possibility to disallow the Updates by Products instead of disallow the whole NI Update Service.

 

With best regards

Franz

Please check the following thread for additional info:

 

http://forums.ni.com/t5/Instrument-Control-GPIB-Serial/Connecting-to-a-TCP-IP-VISA-Resource-Requires-Registration-Why/m-p/3256873#M71564

 

Specifically, the last entry includes a couple of ideas:

he last comment seems to support the observation that having to register the instruments manually in MAX could be done away with. seeing how coding is complex enough as it is, removing this step makes sense because it is manual and redundant.

 

i'd be most grateful is this could be implemented in a future release of NI VISA.

 

and, while at it, could you guys look into implementing VXI11.2? I believe Keysight has had that as part of their VISA implementation for some time now. with VXI11.2 GPIB control over TCPIP is virtually complete. granted, HISLIP might do just that but because it takes time for new hardware to materialize supporting this new flavor of LXI, implementing VXI11.2 might provide value for some time.