It is always a pain finding new hardware in NI MAX. You never know the IP Address. It would be great if MAX had the capability to find hardware and configure network settings via ethernet Data-link layer 2. You should be able to identify all NI hardware with your common vendor MAC prefix and communicate network settings. I have seen other companies use this to find and configure their hardware on the network regardless of the ethernet adapter configuration.
The size of the NI-488.2 driver files is quite large. I have an inquiry from a customer about the possibility of having a driver that just contains the driver to be recognised by the computer, without all the compatibility files for programs such as C++, Visual Basic etc.
For certain customers, there is alot of overhead associated with downloading a file the size of the current NI-488.2 driver, when the compatibility for different environments is not always necessary.
The various Compact DAQ digital IO modules available can be either correlated or not.
However, there is no information regarding this in the various device specifications.
The information is required because a correlated device is required to access the chassis counters.
A comparison table for correlated devices does exist on NI.com (see link below) but the user has to search for it. It would be far more useful if it were included in the device documentation and specifications along with a supporting information.
Currently, our NILM license daemon doesn't support the TIMEOUTALL function when used with a FlexNet server. The purpose of the timeout is to cause an application to release its license if idle, which is useful in the case that a user doesn't realize LabVIEW or another NI program is still open on the client machine. The TIMEOUTALL command is a standard FlexNet option.
It would be useful if we provided this function, or provided a similar function in the Volume License Manager server product.
When using the Read/Write Variables to INI File step in VBAI and not selecting the Ethernet option the code that is generated still includes this step and therefore requires the Ethernet IP toolkit to run the code. I suggest that when the box is uncheck then the generated code not require this toolkit becuase the VIs are going unused.
It would be nice to provide a way to get diagnostic information regarding any potential HW issues that may be apparent with the Timing and Sync modules. Currently the only method for getting diagnostic information is through the use of the LEDs (active LED, and Access LED), or through external connections to other measurement equipment. The addition of this feature will better assist troubleshooting defective timing modules.