Data Acquisition Idea Exchange

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!

Hello

I don't know if there is already an "idea exchange" about this, it could be usefull that USB devices or adapter support USB 3.0.

A device isn't recognized through an USB 3.0 port.

Thanks !

Vincent O.

I have an application in which I have to digitize a pulse across a shunt resistor.  The common mode voltage can be up around 60VDC.  The digitizing cards I was able to find cannot perform a differential measurement without digitizing both sides of the resistor and then subtracting.  This method causes a lot of error due to the needed voltage ranges.  I have been able to digitize some of these pulses with the PXI-4072 DMM with great success.  However, I can control when those pulses occur and setup trigger lines as needed.  Other pulses I need to digitize will occur whenever the UUT decides to put it out.  What is really needed is a way to trigger the DMM on a measured voltage level.  Just for reference, Agilent's PXI DMMs can do this.  It seems such a shame I haven't found a way to do this with NI's DMM.  As a final thought, some pretrigger data would be needed to properly capture the pulse.  Though, pretrigger data would be nice in any hardware triggered acquisition.

When using TDMS on cRIO systems, there are a couple of considerations that doesn't normally play in too much when storing data as TDMS files and they are:

* The current version of the file system used on cRIO controllers degrades significantly in performance if -any- folder on the cRIO contains more than ~100 files. (work-around> more elaborate folder structures, but a lot of this structuring would be only to work around this shortcoming of the (old) version of the file system 

* The drives are SSD with limited life-length and wear-leveling etc. Writing and re-writing these index files add un-necessary overhead and wear on the disks

* They use up space which is (very) limited on some cRIO's (even if not much). (people may be quick to point out that you can add a thumb-drive, but down-sides to that is the thumbdrives (as far as I know) needs to be FAT. Compared to storing on the cRIO file system which is atomic and fail-safe where you pretty much don't have to worry about sudden power outages and interruptions mid-write.. on a thumb drive you would have all these issues that could worst case corrupt your whole thumb drive.)

I propose to add a boolean (default to false) on the TDMS Open called "supress writing tdms index to disk" or some smart name along those lines. What this would do is still allow for the tmds index to be created, but it will remain in memory only and never be written to disk. When the TDMS Close is called, the memory is released and the tdms file is written to disk without the index file. If the same file is opened again, extra time would be needed since the index file would be re-created (again in memory only if boolean indicates this), but I think for the most part this overhead would be more than acceptable.

I'm not sure how "simple" modifying the TDMS open and close functions would be, but I do know that there are many cases where this flag would make sense. 

I am trying to use labview to make a stress strain curve for an experiment I am running. However my use of lab view is highly limited. I have a load cell that inputs voltage using a transducer techniques DPM3 to send the voltage signal and I have a laser extensometer that inputs voltages also. My question is about the graph and what is the best way to put the strain input n the x axis and the load input on the y axis.