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.
I wrote this idea after having spent a lot of time trying to understand a strange connection problem between MAX and NI-cDAQ 9188 ethernet chassis.
As a matter of fact I discovered that MAX uses the proxy settings made inside Internet Explorer (in Tools >> Internet options >> Connections >> LAN settings). If you set a proxy inside IE, MAX uses this proxy trying to connect to a NI cDAQ ethernet chassis.
If you set the same proxy inside Firefox (for example), MAX doesn't use this proxy settings.
For this reason you must tell the customer how to configure the proxy inside IE in order to be sure that MAx is able to connect to the NI cDAQ ethernet chassis. And if the customer has already set the IE proxy as requested for network connection, it could happen that he must change this settings, and this could be a problem.
I suggest that MAX (and other NI software) should have its own proxy settings (has Firefox has) so that it would be possible connecting to cDAQ ethernet chassis even with "strange" settings of IE proxy.
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.
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.
this is an old question, see here, but so far I have not heard about a practical solution. The quest is to find all instruments on a local LAN that are switched ON (and connected to the LAN, of course). Unfortunately, viFindRsrc does not work. Pinging all possible addresses seems not a viable solution due to the required time, either. So it's possible to detect all serial instruments, all instruments connected via GPIB, but until now there is no standalone solution (i.e.without involving NI-MAX) to detect instruments on a local LAN...
Newer instrumentation (such as mass spectrometers..., i.e. no LXI instruments, no NI hardware) usually comes with LAN capabilities (instead of serial or GPIB). While ten years ago I could use viFindRsrc to detect this instrument (then with serial), now I miss a possibility to detect this instrument which is connected to my local LAN.
I have modern hardware but need to configure it manually...this is odd.
There is some software available to detect instruments on a LAN, but I did not want to use an extra program but a simple function call within C (using CVI)...
PS: I am not sure that the idea label System Configuration API is appropriate, but no better label is available...
In the present MAX setting for the RT controller we have the option for setting the password to prevent the changes to the settings but it still has to be extended one more layer. If I have set the permissions and logged in and when I try to restart the system MAX should prompt for the password if I have not logged in the password prompt is not required. This will prevent the access of the RT by the other people if the RT is connected to the common server.
Am not sure whether it has been already proposed but it will be better if we have this option.
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.
Currently, NI Motion does not allow users to set the proportional gain (or any gain) less than one probably due to the fixed point math on the motion control cards. Many systems, especially those using ultra-high resolution encoders as feedback, are unstable with gains greater than one. Also, any system approaching the need to use Kp close to one will be extremely sensitive to the tuning process and will likely be difficult to optimize. An extremely simple solution to this problem is to add the ability to use Input and Output scale factors to the PID loop. Specifically, scaling the error term input to the PID controller for the input scale factor and the commanded output to the D/A or PWM's for the output scale factors. Even the ability to scale by factors of two would solve most issues. If only one scale factor could be implemented the output scale factor would be more useful as the input scale factor will effectively decrease the feedback resolution on a fixed point system. Other modern controllers utilize this strategy.
A quick search of the forums finds several people with this problem.
Customer want to complete as many as functions within Stimulus Profile for their usability and cost. Now we need TestStand for automation, however customer is afraid that adding one more software would increase complexity.
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.