As far as I'm aware there is no current way to export the quadrature conversion clock from an encoder task. It would be great to be able to export that signal to use for other things.
For example, you could use this signal to perform an analog acquisition each time your encoder passed a mark, giving you position vs. signal. This would be useful for something like a roughness tester where you drag a stylus across a sample and get roughness vs. position. Or a pressure sensor reading pressure versus crankshaft angle.
NI Terminal block layout should be designed so that wiring can be done straight from terminal to wire trunking.
For example TBX-68 has 68 wire terminals aligned to inside of the terminal block. This causes that each wire should make tight curve to wire trunking. Another problem with TBX-68 is that wires are heavily overlapped because of the terminal alignment.
Also the cables from terminal block to DAQ device should be aligned to go directly to wire trunking (not straight up).
I recently discovered that the SCXI-1600 is not supported in 64-bit Windows. From what NI has told me, it is possible for the hardware to be supported, but NI has chosen not to create a device driver for it.
I'm a bit perplexed by this position, since I have become accustomed to my NI hardware just working. It's not like NI to just abandon support for a piece of hardware like this -- especially one that is still for sale on their website.
Please vote if you have an SCXI-1600 and might want to use it in a 64-bit OS at some time in the future.
I find myself quite often needing to modify the DaqMX tasks of chassis that aren't currently plugged into my system. I develope on a laptop, and then transfer the compiled programs to other machines. When the other machines are running the code and thus using the hardware I have to export my tasks and chassis, delete the live but unplugged chassis from my machine, then import the tasks and chassis back in generating the simulated chassis. When I'm finished with the task change and code update, to test it I have to export the tasks and chassis, plug in the chassis, and re-import to get a live chassis back.
Can it be made as simple as right clicking on a chassis and selecting 'simulated' from the menu to allow me to configure tasks without the hardware present?
RSI support of the NI 9361 counter module would allow for use in scan-mode within 9144/5 EtherCAT chassis. I have several use cases for this that mostly would benefit from distributed acquisition and end-user-configurable I/O.
It would be great if there is c series CAN interface module which doesn't need an external power supply. This makes it easy to use and saves time to set up because we don't have to find or prepare an additional power source.
As someone who migrated entire product lines from PLCs to cFieldPoint platforms, and now is in the process of migrating further into cRIO platforms, I am finding some cRIO module selection limitations. One big gap I see in the selection is with analog in/out modules. A set of 2-in / 2-out analog modules would be very welcome, offering standardized +/- 10V or 0-20mA ranges. There are a many times in our products that we need to process just a single analog signal, which now with cRIO requires 2 slots be used, with many unused inputs and outputs (which just feels like a waste of money and space).
It would be great if NI offered a simple 4 Counter bus-powered USB device, like a USB-6601, but with the counter capabilities of the new X Series DAQ devices. This would give people who only need to perform counter operations a low-cost alternative to the bus-powered M Series, with double the counters.
Dear NI, please consider a future hardware feature addition:
Add a "Power Up Delay DIP Switch" to the back of the PXI Power Supply Shuttle.
It would allow end users to reliably sequence the powering-up of multi PXI chassis solutions. It could also be handy to sequence any other boot-order sensitive equipment in the rack or subsystem. This would also be a world-voltage solution since this capability already exists in the power shuttle. We are seeing the need for more input-voltage-agnostic solutions. I'm sure you are too.
It might offer time delay choices of 1,2,4,8,16 seconds, etc.
We run into this problem on every multi-chassis integration. We have solved it several ways in the past like: human procedure (error prone), sequencing power strips ($$$ and not world-voltage capable), custom time-delay relays ($$$).
Imagine never having your downstream chassis(s) disappear. Or worse yet, having them show up in MAX, but act strangely because of not enough delay time between boots.
Thanks for reading this, and consider tossing me a Kudos!
Currently there are only two options for acquiring +/-60V input signals:
NI 9221: 8-Channel, ±60V, 12-Bit Analog Input Modules ($582)
NI 9229: 4-Channel, ±60 V, 24-Bit Simultaneous,Channel-to-Channel Isolated Analog Input Modules ($1427)
I would like to see a new module provided that is identical to the NI9205 (32-Channel Single-Ended, 16-Channel Differential, ±200 mV to ±10 V, 16-Bit Analog Input Module, $881) but with an input signal range of ±60 V.
NI supports almost any bus. Why not SSI (synchronous serial interface) ?
Of course, there is always the option to use an R series card and then build an interface. Why not have a low-cost PCI or USB card? Also, perhaps a C-series module, so that we don't have to take up FPGA space?
When a DI change detection task runs, the first sample shows the DI state *after* the first detected change. There's not a clear way to know what the DI state was just *before* the first detected change, i.e. it's *initial* state.
This idea has some overlap with one found here, but this one isn't restricted to usage via DAQmx Events and an Event Structure. Forum discussions that prompted this suggestion can be seen here and here.
The proposal is to provide an addition to the API such that an app programmer can determine both initial state just before the first detected change and final state resulting from each detected change. The present API provides only the latter.
Full state knowledge before and after each change can be used to identify the changed lines. (Similarly, initial state and change knowledge could be used to identify post-change states.)
My preferred approach in the linked discussions is to expose the initial state through a queryable property node. The original poster preferred to have a distinct task type in which initial state would be the first returned sample. A couple good workarounds were proposed in those threads by a contributor from NI, but I continue to think direct API support would be appropriate.