Leaderboard

OK. Here are some of my FOR (nots) using MAX. MAX is never installed it just bloats the installation and if it crashes, will take your whole measurement system down and you will get the telephone call not NI. MAX already has an interface which doesn't fit with either our or our customers "corporate" style requirements for software (logos etc) And having a GUI is normally easier for a customer to navigate and that's the last thing we want since they are neither trained or qualified to do these operations and we cannot poke-yoke it. MAX includes the ability to handle Scales of different types (linear, non-linear etc...) - but this cannot be updated from integrated databases and other 3rd party storage. Communicating with MAX is really easy using the Task-based API (through PNs etc...) because MAX sits in top of DAQmx so what we are really doing is configuring DAQmx. (So far) Clients seem to like using MAX - do they have an alternative? Its easy to back up your configuration and port it over to another PC etc. as it is with any other file based storage except text based files you can track in SVN. And some more.... Have to support more 3rd party software for which there is no source and have no opportunity to add defensive code for known issues Requires a MAX installation to do trivial changes as opposed to software available on most office machines (such as Excel, notepad etc). Does not have the ability to easily switch measurement types, scaling etc to do multiple measurements with the same hardware. MAX requires firewall access (I think) and this can be an issue with some anally retentive IT departments that decide to push their policies on your system.. As mentioned before above. Cannot integrate 3rd party storage such as SQL, Access, SQLLite, databases (mentioned again because it is a biggie). Or indeed automated outputs from other definitions (like specs) MAX assumes you have a mouse and keyboard. Its very difficult to use with touch-screens operated by gorillas with hands like feet.. But I think our customers are probably a bit different. They don't want to "play". they just want it to work!. And work 7 days a week, 24hrs a day. We even go to great lengths to replace the "Explorer" shell and start-up logo so operators aren't aware that its even windows. Our system is quite sophisticated now though. It can configure hardware on different platforms using various databases, text files, specification documents etc and it can be invoked at any time to reconfigure for different tests if there are different batches/parts. Its probably the single most re-used piece of code across projects (apart form perhaps the Force Directory vi... I tend to view MAX in a similar vein to express VIs. But that's not to say I never use it.

I use DAQmx quite a lot in my day to day work. The only way you can get to the 16bit data from the acquisition device is to use the Analog>Unscaled option on the DAQmx Read vi. When you read the waveform datatype, the unscaled data it converted to DBL values by the DAQmx driver using a polynomial evaluation. You can get the polynomial coefficients for converting to voltage from the driver by using a DAQmx Property Node: DAQmx Channel>>AI.DevScalingCoeff. What you would want to do then, is to set up your read as unscaled, use the unscaled data for your TDMS file, and convert to volts, or whatever scaling at that point. Stay away from the Raw read options. The Unscaled will still return your data in a 2D array of [channels x samples]. Raw returns a 1D array that you have to parse manually. One other note: don't assume the nominal voltage ranges on your device are acceptable for rescaling. Just because you have a 16bit ADC with +-10V range, it doesn't mean you can use 20 / 2^16 as your dV. The actual output from the device probably goes from -10.214 to + 10.173. This will make your data very messy. Always use the device scaling coefficients from the driver. I use a polynomial composition to combine my unscaled to voltage conversion and my voltage to engineering units conversion. This reduces my CPU load quite a bit. If you are using a custom scale in MAX, I don't know how that works, so you may not see a difference. Another thing I do it build my tasks programatically from config files (you could use xml). I have found that for situations where people are changing acquisition settings frequently, MAX can be a pain. Also, you can't (as far as I know) dynamically retarget a MAX task to new hardware so that you can run multiple instances of it. Another good thing about not using MAX is that you can control what configuration settings your users do and don't have access to. You don't have to give them AC/DC coupling options if they are only reading DC levels, for example. One nice thing about MAX is, well, um, oh, it already has custom scaling options. Though they can be a little cumbersome. I usually avoid MAX as much as I can since its portability is practically nonexistent and the interface is straight out of the early 90s.

Or this one, here on LAVA