Many times, I find myself wanting to compare different I/O traces side-by-side, but I can only have one instance of I/O Trace in memory and hense can only view one capture at a time. Would it be possible to view two different captures within one instance of I/O Trace? I believe a lot of people would appreciate either a split screen option or the ability to open another instance of the I/O Trace application in memory.
Please change the NI uninstaller program in Windows to be resizable. You have a tiny list box to list all the MANY little applications that NI installs. It's so small, though, that I have to constantly scroll to read the names. Vertical scrolling only would be tolerable. It's the horizontal scrolling, too, that is most annoying.
Posted this in Data Acquisition Ideas as well, but it seems like it would be implemented with something like MAX, so...
When dealing with various remotely deployed cRIO hardware configurations, it may be impossible to keep a sample configuration of every type of system we ever sell. Unfortunately, if upgrades or revisions are made to the base code in our system, remotely deploying to our customers becomes impossible unless we have their exact configuration on-hand for the programmers to compile. Remote connection to the hardware for this type of operation is also not typically possible.
To be able to simulate or emulate a full cRIO system (processor & hardware modules), then compile the RT code for deployment on that system as if it is physically connected to our development system would be ideal. This would allow images to be created, which can be sent to customers for local deployment at their facility. Dramatic decrease in "hardware library" requirements on the development end, reduction in "on-site upgrade" service trip costs to the customers. Plus, easier for OEMs like me to justify the move away from PLC types of hardware and towards cRIO, once you take away some of the potentially nightmarish continued support and update issues involved with basing systems on cRIO platforms.
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.
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.
I recently handled a service request (SR# 1698819) in which a customer was confused why TestStand was not listed in License Manager (LM) when his admin had generated a disconnected license. For him, all that was showing up in his LM was the following screen shot:
I explained that the Developer Suite with Industrial Monitoring and Automated Test (Disconnected License) includes a disconnected license for TestStand.
The product suggestion I'm making involves being able to expand disconnected suites by clicking a plus button to the left of the suite for example to view all of the software that's available to the client. This will avoid future confusion on the customer's end and reduce support call volume.
Send the VLA log automatically as notification to the VLM administrator.
The VLM log can send the logfile automatically to NI, however this is not an option when the server is not connected to the internet. In this case, emails can be send to the administrator. It would be great if the VLA log will be attached to the email, so that the administrator can forward this to NI.
Currently, Switch Executive virtual devices can only be imported and exported through Switch Executive itself. It would be really nice if instead Switch Executive virtual devices were handled through the MAX configuration import and export wizards. This would simplify test system deployment, particularly since the MAX configuration import wizard can be easily automated through deployment installers. Importing of Switch Executive devices can currently be automated, but you have to create an executable using the Switch Executive Configuration API and then call that executable using a batch file called by your deployment installer. It would be so much simpler and more consistent if the MAX configuration wizards supported Switch Executive in addition to other products such as DAQmx and VISA.
After running a compilation, the Functional Safety Editor produces several files, including the actual bin file for uploading to the 935x module, plus a compilation report and other compilation results. The FSE manual recommends reviewing these output files for correctness.
Problem is there's no quick way to open these files for review. So I think it'd be useful to provide a button to open File Explorer to the folder containing the files produced by the compilation.
LabVIEW has a nice feature allowing an arrow to be drawn from a comment and attached to a block diagram element. This makes commenting specific parts of code much more precise. The Functional Safety Editor lacks this feature (and is inefficient to comment in general). When adding verbose comments to the diagram, it can be unclear which comment belongs to which state or transition.
The proposed idea is to add the same comment/arrow functionality from LabVIEW to the FSE, so comments can be attached to a transition, state, compound state, etc.
Comments can be added to the diagram in the Functional Safety Editor, but only when dragged from the palette. It's second nature in LabVIEW to simply double-click a blank area of the block diagram and begin typing to add a comment, so the lack of this feature in the FSE is really jarring.
This idea is to enable double-clicking an empty area of the diagram to automatically insert a comment, without the need to drag it in from the palette.
The Functional Safety Editor lacks a pan tool for navigating the diagram view. The only option is to use the scrollbars + mousewheel.
This proposal is to add a pan tool, activated by a keyboard+mouse shortcut. This could be Ctrl+Shift+Click (like LabVIEW) or Space+Click (like NXG). This would make navigating the diagrams of larger safety programs much quicker.
LabVIEW provides access to a list of recently opened Projects and Files, which is handy for quickly resuming where you left off. The Functional Safety Editor lacks this feature. Combined with the default file dialog issue, it makes reopening user programs a time consuming exercise.
The idea is to add a Recent User Programs menu item to the File menu, listing the last 10 or so user programs (just like LabVIEW).
(Labelled this as System Configuration API, but the FSE is its own product)
Currently the Functional Safety Editor file dialog always defaults to the path %userprofile%\Documents\LabVIEW Projects\Functional Safety Programs when opening or saving user programs. This is regardless of where the user program was opened from, or where the program was last saved to. This is unlike LabVIEW, where it will always remember the last used directory and use that as the starting path for file saving/loading.
The default file dialog path for the FSE can at least be changed in %localappdata%\National Instruments\Functional Safety State Machine Editor 6.0\Preferences.xml (under the key NationalInstruments.Shell.ApplicationFeatureSetDefaultDialogDirectory) to a more sensible default path (the root of your preferred version control system). Even so, it is still tedious needing to change folder paths to a given project for every save or load operation.
A better UX would be to remember the last used file path, and use that as the starting path for any file open or save dialogs. Much less clicking and navigating required.
(Labelled this as System Configuration API, but the FSE is its own product)
For a reason I don't know, NI Softmotion team remove the function "write position setpoint" to all 951x axis. I'm using four (4) 9514 axis right now that all need to use this function at sometime in my code.
This function is really useful when design a motion tracking system and also for PID tuning to check step response.
I can't upgrade to LabVIEW 2018 for this reason without non-desired work-around.
Please work on reenabling this fonction on all 951x axis.
as my volume license manager is not able to handle more than ~850 registered computers, I need the creation date or register date of a computer to run a proper inventory every month (no usage AND present also last month -> deletion of computer).
I need this function urgently to have a stable service and license allocation.
Systemlink seems unaware of software changes deployed to a Managed System outside of the SystemLink Systems Manager. If I install a software package using Systems Manager to an RT client, then install something else on the same client directly from LabView, Systems Manager will continue to show the original package as the Installed Software. Ideally the SystemLink client on the RT target should recognize the difference and report to Systems Manager that an unknown package is installed. Additionally, Systems Manager should have a Reinstall option on its installed software tab. The current procedure is to uninstall the currently installed version, then install it from the Available software tab.