Data Acquisition Idea Exchange

For each device, MAX will use an unique device number.

This is no problem with fixed measurement equipments.

With USB devices this may become a problem.

On a school, a student will work with different combinations of computer and device.

If the student wants to use his program with a different device, he will get an error.

Even if the device is the same type, but has a different serial number.

To solve it, the student needs to open all DAQ routines and to alter the device number.

Or he needs to change the DAQ assistant routine into a VI and change the constant device number by a routine as shown in DAQmx device to use.vi.

This same problem occurs when using NI-IMAQdx devices.

Solution:

Make it possible to select a device by type instead of a device by number.

I recently had a customer create a global virtual channel in Measurement and Automation Explorer (MAX).  They then set the maximum and minimum values for the input range of their signal. 

My customer wanted to access the +2 and -2 values entered above and display them in LabVIEW.  However, the property nodes for global virtual channels only accesses the limits of the board.  For example, the customer's board may only be able to handle voltages between +/- 10 Volts.  No matter which property node we chose... all that was returned was the +/- 10 Volt range.  Could we please give customers access to this information?

Problem:

1. Many applications need multiple DAQ chassis synced across 100s of meters. Ethernet is not used due to its indeterminism.
2. While NI's TimeSync uses special hardware (&1588), it seems like NI could build into the Ethernet drivers a way to do time syncing without any other hardware modules (cDAQ, cRIO, PXIe, etc.). The customized NI-Ethernet would do the master-slave timing for you. It would be built into the platform. The key may be to use the lower boundary of histogram distribution in the statistics of loop time. Not using an average loop time, but use the bounded minimum as a special loop time statistic. See the image at the bottom.
3. Ethernet time to send a message and receive an answer is not deterministic. But, if all the Ethernet chassis are on a dedicated subnet with no other traffic, then there should be some deterministic MINIMUM time for one chassis to send a packet to another chassis.

Possible solution. Configuration: Suppose you had 5 Ethernet cDAQ 8 slot chassis. Start off by making a simple configuration work first, then extrapolate to more complicating network configurations. Therefore make all the chassis on the same subnet and maybe a dedicated subnet. Each cDAQ is 100s of feet from the other. You want to sample data at 1000 samples per second on all chassis and either lock all the sample clocks, or adjust the clocks on the fly, or know how much the sample clocks differ and adjust the times after the data is transferred.

1. LabVIEW tells each slave chassis that it is to be a slave to a particular master cDAQ chassis (gives the IP address and MAC address).
2. LabVIEW tells one of the cDAQ chassis to be the master and it gives the IP address (and MAC address) of all the slaves to that master.
3. The local Ethernet driver on the chassis then handles all further syncing without any more intervention from LabVIEW. Avoids Windows’ lack of determinism.
4. The master chassis sends an Ethernet packet to each slave (one at a time, not broadcast). The slave's Ethernet driver stores the small packet (with a time stamp of when received) and immediately sends a response packet that includes an index to the packet received (and the timestamp when the slave received it). The master stores the response packet and immediately sends a response to the slave response. This last message back to the slave may not be necessary.
5. The local Ethernet driver for each cDAQ has stored all 1000 loop times and their associated timestamps.
6. Now each master slave combination has a timestamp of the other's clock with a time offset due to the Ethernet delay. But this Ethernet delay is not a constant (it is indeterminate). If it were constant, then syncing would be easy. BUT
7. One characteristic of the loop time should be determinant (very repeatable). On a local subnet the minimum loop time should be very consistent. After these loop messages and time stamps are sent 1000 times, the minimum time should be very repeatable. Example: Suppose we only want 10 us timing (one tenth of a sample period). After sending 1000 time stamped looped messages, we find that the minimum loop time falls between 875us and 885 us. We have 127 loop times that fall into this minimum range (like the bottom “bucket” in a histogram plot). If we were to plot the time distribution, we would notice an obvious WALL at the minimum times. We would not have a Gaussian distribution. This 2^nd peak in the distribution at the minimum would be another good indication that this lower value is determinant.
8. Now the master and slave chassis communicate to make sure they have the same minimum loop times on the same message packet loops. The ones that agree are the ones used to determine the timestamp differences between the master and the slaves. The master then sends to each slave the offsets to use to get the clocks synchronized to one tenth of a sample time.

This continues to go on (in the background) to detect clock drift. Obviously after the data acquisition starts the network traffic will increase, and that will cause the number of minimum packet loop times to be less than 127 out of 1000. But we should be able to determine a minimum number of minimums that will give reliable results, especially since we know beforehand the amount of traffic we will be adding to the network once the data acquisition starts. We may find out that an Ethernet bus utilization of less than 25% will give reliable results. Reliable because we consistently get loop times that are never less than some minimum value (within 10 us).

Remember, a histogram of the loop times should show a second peak at this minimum loop time. This 2^nd peak is an indication of whether this idea will work or not. The “tightness” of this 2^nd peak is an indication of the accuracy of the timestamp that is possible. This 2^nd peak should have a much smaller standard deviation (or even a WALL at the minimum - see image). Since this standard deviation is so much smaller than the overall average of the loop time, then it is a far better value to use to sync the cDAQ chassis. If it is “tight” enough, then maybe additional time syncing can be done (more accuracy, timed to sample clocks, triggers, etc.).

Example, now that the clock are synced to within 10 us, the software initiated start trigger could be sent as a start time, not as a start trigger. In other words, the master cDAQ Ethernet driver would get a start trigger from LabVIEW and send all the slaves a packet telling them to start sampling at a specific time (computed as 75 milliseconds from now).

I mentioned parts of this idea to Chris when I called in today for support (1613269) on the cDAQ Ethernet and LabVIEW 2010 TimeSync. Chris indicated that this idea is not being done on any of your hardware platforms yet. By the way, Chris was very knowledgeable and I am impressed (as usual) with your level of support and talent of your team members.

The DAQ Assistant was presumably created to simplify data acquisition.  The idea seems to be to put all of the needed pieces in one place, so that all the low level 'traditional' DAQ vi functions are not needed.

Consider the following simple vi:

This could be as simple as one analog input channel.

The program will compile into an .exe and work just fine, as long as you don't use one of the features of the DAQ Assistant:  Custom scales.

Custom scales are not stored with the VI or project, but in a system file that does not automatically get included in an .exe build.  The .exe will work fine on the original PC that built it, but it will not work when the .exe is loaded on a different PC.

There is a method that allow the user to port the custom scales to another PC, but it is not automatic.

http://digital.ni.com/public.nsf/allkb/12288DEB3C6A185B862572A70043C353

The fundamental problem is that the DAQ Assistant is intended to make life simple and give you everything you need to make a program.  Custom scales are included in the DAQ Assistant so that the programmer does not need to manually create scaling in their vi.  But what good does that do if they are not included in the .exe build, and there is no obvious clue that this requires extra work or what that work is?

The build .exe process needs to be upgraded to automatically include custom scales and possibly other MAX settings that are essential to the operation of a compiled program.  It does not matter if the build process ciphers and includes only the specific scales or setting used by the particular program / vi, or if it just takes all the settings. 

These are critical pieces to make the final compiled program run on another machine.  The user should not have to somehow know that these pieces are separate but need to be included, and have to take extra steps to go out and select them in order for them to be used in the build.  That is totally counter intuitive to the simplicity intended by the DAQ Assistant.

Background question here:

http://forums.ni.com/t5/Multifunction-DAQ/Channel-Calibration-information/m-p/1295908

Channel calibration in MAX is too limited to be very useful. According to NI AE, from MAX you can only create a table for calibration, not a polynomial fit. I assume intermediate values are linearly interpolated, but that wasn't specified. Programmatic calibration to enable polynomial cal as described in the above listed topic makes traceability problematic. 

I propose that the channel calibration capabilities in MAX be amended to allow the user to select calibration mapping, either TABLE or POLYNOMIAL FIT. 

OF course, the user should be able to select the polynomial order, and the R-value should be clearly indicated.

All of these properties should be included in any report generated from MAX.