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, 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.
Before I start, I want to make clear that I am fully aware that my suggestion is probably linked to some crazy amount of work.... That being out of the way:
I often have to switch between LV Versions and have on more than one occasion run into the rpoblem that different versions of LV work with MUTUALLY EXCLUSIVE sets of drivers. This means that I cannot (_for example) have LabVIEW 7.1 and 2011 on the same machine if I need to be coding GPIB functionality over VISA because there is no single VISA version which supports both 7.1 and 2011 (image below).
Of course these days we just fire up a VM with the appropriate drivers but for much hardware (Like PCI or Serial or GPIB) this doesn't work out too well.
Why can't we have some version selection ability for hardware drivers. Why can't I have VISA 4.0 and 5.1.1 installed in parallel and then make a selection of which version to use in my project definition? I know that ehse drivers probably share some files on the OS level so it clearly won't work for existing driver packages but for future developmend it would be utterly magnificent to be able to define which version of a hardware driver (Or even LV Toolkit like Vision) should be used ina project.
Wouldn't it be simpler to wire your DAQ systems if there was a way to print the tasks? This is exactly what I'm proposing - a 'Print' function from the menu to print the channel order for a specific task that would also contain the system configuration. See below:
Would create a file that looks similar to this:
I'm not saying that this is the end-all-be-all, but some way to print the channels contained in a task would simplify my life.
For security reasons, many customers using Volume License Manager to administer licenses to client machines do not authorize users to download and install anything from the web. Therefore, if a critical patch is released, the client machines are unable to download this unless it is distributed by the administrator. It would be useful for the VLM administrator to be able to configure the Update Service such that all Users can run the Update Service but the service has been configured to point to an internal network share rather than an internet location outside the firewall. This way, the administrator could make critical updates and patches available for the client machines and the clients can be notified and install them.
Currently licenses use the sort key word within a server's license file to specify the priorotized check out of similar software products ( a preference to check out DIAdem professional over DIAdem Advanced for example when a user has permissions for both). With concurrent licenses, right clicking on a software product from a client's License Manager application and selecting the Do not Allow License Request from the context menu as shown below will also bring about this functionality.
Without a set preference, sometimes two licenses are checked out, and this is a known issue:
DIAdem is double-checked out from VLA when several versions are licensed
Do Not Allow License Request for Concurrent License
Sort Keyword Within a Server's License File
My suggestion is that we create a way within VLM to modify the server's *.lic file (by changing sort key word's value) to reflect software check out priority. Currently this change can be made by manually modifying the sort value in the server's *.lic file. This works since the server's license doesn't need to be resigned after said modification. However, it would be nice if this change could be made through the VLM user interface and the *.lic file would be modified behind the scenes.
As I understand it now, with VLM, groups were introduced.
I could create a group of Developers that has two members and I could create a group of New Hires with 8 members. Then I could issue permissions to the ten licenses of LabVIEW that I purchased to each group.
When I add the LabVIEW licenses to the Developers Group I notice that only 2 of the 10 licenses are used for the members of the Developer group. Then I add the remaining licenses to the New Hires group.
The problem that I see with groups now is connected to what happens when more people are hired at the company.
If two more people are hired at the company, and all of the new hires are using LabVIEW licenses, then the Developers will see a message that all of the LabVIEW Licenses are checked out.
Could R&D make a way to lock the number of concurrent licenses in a group? For example, if we could lock the 2 concurrent licenses issued to the Developer group, then in the previous scenario when all ten of the new hires attempted to open and use LabVIEW, two of the licenses would be reserved for the Developers and the last two New Hire members to attempt to open LabVIEW would get a message that all licenses had been checked out.
I think this could be a very useful addition to the current functionality of VLM and that it could benefit many companies who utilize it! Feel free to post, comment, or kudo. Thanks!
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.
Why don't we integrate PuTTY or some version of it into MAX? "Console out" is powerful troubleshooting tool for all NI RT targets and more because it tranfers vital information such as errors and IP address information regardless of whether you can find the device in MAX. It's especially useful for devices that don't have hardware dipswitches. It's a great tool, but is useless without a program like PuTTY. Hence, my suggestion remain to integrate PuTTY or some form of it into MAX.
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.
This is a very small issue, albeit an annoying one:
When using <F2> to call a rename dialog in MAX, it would be very intuitive to have the focus on the name field, since this is ultimately the field of interest for the user.
Currently, the dialog has no focussed field and pressing <TAB> does not even move focus except to the <Abort> field.
So now, I do not only have to change from keyboard to mouse, but also, I have to mark the entire name in the field to change the name. As I tend to give meaningful names to my channels, this makes for a good many time-consuming "mouse/keyboard/move/click and back" journeys
If the <TAB> key would at least move focus, this would be equally helpful.
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.
For several years NI marketing has used the term Graphical System Design to refer to LabVIEW and its suite of addons and supporting software. This is fine as it goes, but when I first heard the term I pictured something entirely different in my mind and I would like to suggest that as a product of its own.
When I hear Graphical system design, I picture something like VeriStand on the software side and a similar configuration based utility on the hardware side. It is the hardware tool that is missing and needs to be created. I would love to have a tool that could :
Let you define the hardware you are testing/controlling (the device). It has switches, analog inputs, analog outputs, frequencies, GPIB commands, CAN messages, TCPIP messages, etc.
This set of definitions would be in one place and would then be used to help you define the system that you will need to build in order to test/control that set of defined hardware.
A wizard would lead you to the proper hardware or choice of hardware that would work to test/control the defined signals. This needs to be modifiable by the user of the wizard, but should point to as good of an NI solution as it can and then allow options.
The wizard would then also help you develop the hardware interconnects of the system, for instance:
DAQ channel goes to a particular pin of a particular card or module
the pin goes to the NI cable
the NI cable goes to an NI breakout box connector
the NI breakout box connector goes to a terminal block
the NI breakout box terminal goes to device cable
device cable goes to device connector
device connector goes to device signal
It would also need to be able to add connections since you may have more breakout boxes or interconnecting cables in the system. These would all need to be in the signal chain.
Once I define it, you draw it. This would need to iterative and the drawing would need to be editable.
Signals that branch would need to be able to do that with each leg being selectable or the entire tree shown as one.
It would need to be divisible by signal (rows) and by connection (column) so that you can easily trace a signal throughout the system or conversely, see all of the signals in a particular connector.
It would be nice to view as individual signal wires, as connectors, as cables, as breakout boxes or other boxes, as systems, etc. This would be different levels of 'zoom' of the system.
It would need to play well with the Requirements Gateway. You will want to connect signals to specs, perhaps in several ways.
We typically do most of this already with separate tools that do not work well for job - Visio or PowerPoint for the initial system block diagram, AutoCAD Electrical or Mentor's Capital Harness for the wiring diagrams, Excel spreadsheets for the wiring interconnection - and nothing to pull it all together.
Putting it all into a single tool could be a good way to sell more hardware since you get to recommend the correct hardware for the definition. And you could even build the NI portion (for a fee). It may wind up being plug and play when the developer gets it.
Future add-ones or developments could include the ability to stub out VeriStand configurations based on the developed system. The ability to define and trace expected signals (such as DC levels or even complex waveforms). Or the ability to define signals as either electrical or the physical units that they may represent (pressure, distance, etc.).
For integration and station troubleshooting the Sessions, Aliases, Tasks et al would be organized by Project, Application or deployment in MAX and fault identification has all the "tools" any repair tech could want to isolate a failure.