several years ago I wrote an instrument control package for a set of specialized lab equipment controlled from a Linux PC via GPIB (NI PCI card). The need to frequently update the kernel driver turned out to be an issue for the daily work, so we switched over to a GPIB-ENET/100, which at that time came with a lightweight 32bit interface library libgpibenet.so with very little system dependency - so it was portable between different linux systems.
Recently, I was trying to upgrade the package to a more recent 64-bit linux variant, using up-to-date drivers from NI. Unfortunately, the current offering requires me to install some 30 rpm packages including kernel drivers (causing extra problems when the kernel requires signed modules). My GPIB application now crashes in nipalau.so if kernel modules are missing - which I don't need anyway! - or some startup scripts have not been executed. Even worse: the latest packages have sadly dropped support for the GPIB-ENET/100, probably due to too much maintenance overhead, and the GPIB-ENET/1000 is now the only available package that does not required kernel support.
However, purchasing a GPIB-ENET/1000 as an upgrade is no option if I cannot get rid of the runtime-dependencies on unneeded software.
Currently, my only choices are using an outdated linux system with the full package NI package version 2017, or an even older system with the original 32bit driver library.
Question: would it be possible to provide a 64bit-variant of the original GPIB-ENET Linux package to gain full advantage of the very low system requirements? I could even live without the fancy graphical configuration tools...
R&D community across the globe is moving toward FAIR Data Principles. More and more funding agencies are requiring that data created by and used for research need to be Findable, Accessible, Interoperable and Reusable (FAIR). NI already has made great strides towards metadata-rich data, such as industry-standard open source TDM/TDMS formats.
The next logical step is to help NI customers to comply with FAIR Data Principles requirements. The best way to support NI customers will be the development of TDM/TDMS API for major public data repositories, such as Harvard's dataverse.org etc.
We can currently write data to Ethercat slaves using WriteFoEData and the Industrial Communications for Ethercat driver 20.0. However we cannot read data using FoE. I would like Ni to add this capability.
When adding a Licensing server especially from FlexLM there is no confirmation message that a valid server has been added. This would be nice to avoid confusion of users connecting to this type of licensing Server.
NI License Manager is a really good tool to check in a visual way in which products are licensed and connecting to the Server License.
However, in case you need to request access from NI License Manager to the server through the "Manage" button on the Network License tab, you need to go specifically to each machine physically or set up a remote third party tool to request the access with that button.
Therefore, it will be a great solution to create certain options for the NI License Manager and set up some Master License Managers to make these requests from a few selected computers. Adding value to the security of the server as it will not be accessed very often.
Add option to Project Explorer->Tools->Options->Workspace for UI Manager and Workspace:
Close on Undeploy [to automatically close one or both when project is undeployed]
Open on Deploy [select whether to open or not on deployment - after Calibration is complete, I do not use Workspace again and would prefer that it would not open on future deployments. I can open it manually from the Project Explorer window, if necessary.
When migrating to a new server with an updated license File I loaded a large backup files from a server with a 1000+Computer based licenses. The process of loading the back up took around 1 hour, which got me unsure if the process of restoring the backup was going correctly or not. It doesn't has a loading progression bar to see how much time left is needed for the backup to finish, or even just a progression bar of the percentage left. In the end the process was successful, but very stressing... I think having a progression bar would be an excellent feature to have.
customers need for directly importing the NI Veristand log files into third-party tools (as Vector CANanalyzer) and we found the following contrains:
- TDMS are very effective and open, but not directly manageable by other tools
- txt and cvs are potentially more suitable, but NI Veristand 2019 does not allow adding a native Time Channel, that's fundamental. I saw that System Time and Absolute Time are potential channels to add to a log, but there are no options to format the timestamp and to allow some kind of flexibility
- adding customizable time channels to txt and csv log options in NI Veristand (the limitation is still the files size bacause of ascii, but the multiple files option could help)
- whatever improvement are in the NI VS roamap logging?
- what about MDF4 support? It would be vey useful and well accepted: I recall it was in the roadmap evaluation but no news so far. In case, what MDF: signal and/or message format(s), BTW?
Currently error messages are quite vague - they say what failed, but don't say where. It might be fine in LabVIEW development, where error pops up in the exact location on the block diagram, but it's not well suited for Veristand, where all we have is the error message. Take this as an example:
I'm trying since 2 days to figure out which property is invalid - I have 4 CAN channels and 2 LIN channels in the SDF... If there was an information about the channel/value that causes the error, it'd be far easier to sort the problem out.
Aside from the fact that most of the errors are just pulled up from device drivers which makes them vague and not at all related to the actual VeriStand function happens (so part 1 of this feature request is an overhaul of our error reporting in VeriStand), it would be great if it actually logged these or gave you the option to save to a file. This means that you can then send this to NI Support for assistance or at the very least, document issues.
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)
VeriStand looks in specific directories for plugins. This makes source code control and configuration management difficult for our ADG customers. If Veristand.ini allowed customers to provide paths (plural) to VeriStand plugins, then the plugin destination directory could be under SCC/CM and isolated from COTS plugins. For example: