Additional NI Software Idea Exchange

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.  

Ship VBAI or VDM with the OCR B standard file the way that VBAI ships with OCR A.

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 :

1. 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.
2. 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.
3. 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.
4. 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
5. 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.
6. Once I define it, you draw it. This would need to iterative and the drawing would need to be editable.
7. Signals that branch would need to be able to do that with each leg being selectable or the entire tree shown as one.
8. 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.
9. 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.
10. 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.).