Data Acquisition Idea Exchange

Community Browser
About Data Acquisition Idea Exchange

Have an idea for new DAQ hardware or DAQ software features?

  1. Browse by label or search in the Data Acquisition Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see implemented!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

Since NI already has the hardware interface devloped to USB and the PCI bus and its variants, why not leverage on that and create a line of hardware dongles that are compatible with MAX, LabVIEW and LabWindows IDE's. The volume may be low but it would be an integrated solution for ease of hardware/software interaction. Each dongle would have a unique serial number that the programmer's application  can check and verify before allowing software operation.

 

-AK2DM

  • Deployments

The title pretty much says it all. I would like the ability to either configure a full hardware compliment as simulated devices then switch them over to real devices when the hardware arrives or go from real devices to simulated devices without the need to add new, discrete simulated devices to MAX.

 

This would make for much easier offline development and ultimate deployment to real hardware.

NI provides some 100-Pin-DAQ devices, e.g. one for INDUSTRIAL DIGITAL IO

http://sine.ni.com/nips/cds/view/p/lang/en/nid/13577

 

But why doesn't you offer also a basic connector block for a reasonable price, especially for industrial applictations, where it is common to wire (DIO) signals through DIN rail mounted terminal blocks?

 

This connector block should have the following features:

 

- DIN rail mountable

- simple wire connection, best with spring terminals

- 100 Pin-cable connection

      (http://sine.ni.com/nips/cds/view/p/lang/en/nid/13600)

- relatively small for installation in a switch cabinet

- no signal conditioning, just clamps

- much cheaper than then currently available SCB-100 block

 

Please see also this related idea:

http://forums.ni.com/t5/Data-Acquisition-Idea-Exchange/Terminal-Block-layouts/idi-p/2160542

 

Regards

A-T-R

 

0 Kudos

I've been told that in order to change module settings, you have to connect a development machine to the network has has the cRIO hardware. Most systems I build have a deployed application and are located somewhere else (i.e. no connected to my machine). It'd be nice if the cRIO module setting could be ported to the cRIO unit without having to connect a development machine and hit "connect" in the project.

 

For example, I had a cRIO unit in my office and set it up for a project. They installed it, wired it, and tested it. A few months later we needed to add a NI 9213 (16 ch Thermocouple module). It defaults to type J and degree Celcius. In order to switch it to type K, I had to bring my desktop out to the unit, connect to the network, and redeploy the cRIO. I called support twice and was told this is the only way to deploy the module settings. If i'm wrong, someone please correct me.

 

 

I'm thinking it could be another type of application builder or something you could add to an existing application.

 

 

0 Kudos

Not sure if this is the ideal place for this suggestion (maybe MAX suggestions?), but here goes...

 

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.