DiAdem Scripting and Automation via LabVIEW code/sub-VIs

[biographie]

I am sure that this is far from a 'new idea'.  I have been using DiAdem 11.1, and have not looked at the new features of 2010 yet.  The new idea...use LabVIEW code to make scripts.  I know LabVIEW very well, that is how I make the TDMS files; but the idea of data analysis or automation comes to a standstill when you tell me I need to learn VB to manipulate or work with the data I just gathered beyond the canned toolsets already in DiAdem.  DiAdem needs to be like Teststand in this regard.  You can use different code types with Teststand, and it works.  And this needs to work in all the different categories of scripting or automation (Navigator, View, Analysis, etc.)  Any software package NI creates should have LabVIEW as the center point, and always require seamless integration of LabVIEW code.  I think that comes down to plain-jane good marketing strategy.

[Brad_Turpin]

Hi biographie,

You're correct, this question has come up every once in a while for many years now.  There are a few existing options you should consider.  For many years now LabVIEW has shipped a "DIAdem Report" express block on the "Express >> Output" palette with which you call DIAdem to create a report.  There is additionally a set of "LabVIEW DIAdem Connectivity VIs" that wrap common individual automation steps in DIAdem with VIs that you can string together in a parent LabVIEW program.  Similarly, there is posted custom step type for TestStand that calls DIAdem to create a report at a certain point you choose in the executing sequence.  All of these approaches program DIAdem from the "outside" using DIAdem's ActiveX interface, so while they're friendly to native LabVIEW or TestStand users, they're not really first-class-citizen approaches, which is what I believe you are asking for and what customers have asked for in years gone by.  One final existing option to consider which is very close to first-class-citizen status is the LVRuntime object available in DIAdem VBScripts.  This gives the DIAdem VBScript the same C-interface calling efficiency that TestStand uses to execute LabVIEW code.  So if you need to do custom analysis or external actions (ftp, email, tcp, etc.) or even just custom dialog creation that you're most comfortable doing in LabVIEW, this is a very nice solution.  Note that for many versions now DIAdem has installed the LabVIEW Runtime engine in order to guarantee that it can execute VIs using the LVRuntime object.

Actually DIAdem is already like TestStand in this regard.  Both TestStand and DIAdem use a scripting approach to sequence a series of programmatic steps-- measurement steps in the case of TestStand and analysis and reporting steps in the case of DIAdem.  The individual steps can be VIs called through the C-interface, DLLs/OCXs, etc. or the native scripting language.  The difference is that TestStand's sequencing script operates mainly as a shell-level backbone for linking the steps and their results, controlling their execution and exporting their results to data base or report files, whereas DIAdem's sequencing script contains literally thousands of commands you often use exclusively to define and execute the analysis and reporting steps.  In a way the difference is that DIAdem is much more than an analysis and reporting sequencer, whereas TestStand is exclusively focused on that measurement sequencing role.

The practical reality is that DIAdem was created prior to LabVIEW's release during an era when text-based programming was the only kind anyone knew about.  DIAdem has sprouted so many commands and variables and even Windows hooks over the last several decades that it would be prohibitively expensive to try to mirror all that functionality with a native LabVIEW API.  What would make a lot of sense, though, would be to find a way to include DIAdem-like report capabilities natively inside LabVIEW.  This is something we're interested in considering-- here's hoping one of these years NI will offer that kind of LabVIEW reporting feature.

As a final note, you can use DIAdem's VBScript Recorder to write VBScript code for you while you execute the steps you want interactively, like the macro recorder in Excel.  That is often enough of a bridge for non-VBScript-programmers to get them to a reasonable automation solution.  Also, feel free to ask for VBScript help on the DIAdem Discussion Forum-- I guarantee you'll get a response from the DIAdem supporters.

Brad Turpin

DIAdem Product Support Engineer
Naitonal Instruments

[jakidd]

I agree with this that there needs to be a better interface between DIAdem and LabView. I call DIAdem from LabView and that works, but there is no easy way to call LabView from DIAdem. I have tried this using an example but the passing of the channel data back and forth didn't work out very well, and was just too complex (for me) to do what I needed to do with a VBScript.

I think what would be very useful is a way to call a LabView vi from DIAdem much like TestStand does without having to do any VB scripting. Pass the data to LabView, let LabView do it's thing, and pass the result data back. DIAdem is a good product, but it does lack some analysis functionality, so you do need to put the hooks in it to run LabView and not just VBScript.

[Brad_Turpin]

Hi jakidd,

The LVRuntime object available in DIAdem VBScripts is a straightforward and efficient programmatic option to call LabVIEW VIs.  If you have large arrays you want to pass back and forth between applications, I'd recommend TDMS File I/O-- it'll be faster than anything else.  The shipping Bessel Function example passes back and forth scaler parameters through the LVRuntime object but passes a TDM(S) file path back and forth for the large data arrays.

If you are not interested in programming DIAdem with VBScript, does that mean that you want to call LabVIEW VIs interactively from the DIAdem user interface-- say in ANALYSIS as a new LabVIEW palette or new icons on existing ANALYSIS palettes?  If so, I agree that the idea is appealling, but the devil is in the details of how the VI interfaces with DIAdem.  With the LVRuntime object, you get to specify those details to suit your needs.  You can already add icons to existing ANALYSIS icons bars or to new ANALYSIS icon bars you define, so that you can call selected VIs interactively from the DIAdem environment.

Would it satisfy your request to create a sort of VI interface wizard which displays those details for you to choose from in a dialog, then creates a new icon in ANALYSIS that remembers those interface details and associates them with the icon?  Something like the current MathScript menu in ANALYSIS?

Brad Turpin

DIAdem Product Support Engineer
National Instruments

[Brad_Turpin]

Hi biographie,

Switching out the VBScript scripting language in DIAdem for a similar scripting language may eventually happen, but switching to a compiler such as LabVIEW would require so much work that it never gets serious consideration from version to version.  Now that there is a shift toward server side processing with the Analysis Server, NI would be much more likely to create a native LabVIEW task option in the Analysis Server, like just happened for Python with the 2018 release.

Brad Turpin

DIAdem Product Support Engineer

National Instruments