Quo vadis NI DIAdem?
Today, 30 years ago, was my first working day at GfS mbH in Aachen and also the first day I came into contact with the DIAdem software. Since then, my entire professional life has been closely linked to this product, which has been part of the NI ecosystem for more than 25 years. Over the years, I have worked continuously with DIAdem, trained users in the use of the software, and occasionally influenced its further development.
To this day, I am enthusiastic about the idea of combining all the functions necessary for test automation and data analysis in one (!) product and structuring them in a task-oriented manner. And I am also convinced that for most users, the right approach is not to have to program the required functionality, but to be able to simply configure it.
What strikes me in my daily work, but especially in the training courses I hold on behalf of both NI and müller+krahmer, is a development bottleneck in many areas of the program. The complete switch to the 64-bit platform was often cited as the reason for this. I cannot say whether it was really necessary from a technical point of view (in LabVIEW, we continue to work exclusively with the 32-bit version), but I have no doubt that changes are needed in many areas. Some of the points that immediately come to mind are:
- The NAVIGATOR module allows to handle a wide variety of data formats. However, it is difficult to understand why the automatic generation of DataPlugIns, which form the interface to almost any file type, does not produce adaptable program code.
- The representation of the TDM data model in the DIAdem data portal provides a comprehensive overview of the information contained in the data. However, it is simply impossible to explain why the global information of all files except the first one is lost when loading multiple files.
- Why the VIEW and REPORT modules for graphical representation are separate is a question that almost every DIAdem novice asks, especially since each module has functions that are sorely missed in the other.
- The ANALYSIS module offers everything you need for your daily work in the field of mathematics and has recently been expanded to include extremely helpful functions such as event search. However, if AI is the future of data analysis, which often fails today due to practical usability issues, then DIAdem needs AI integration that allows for easy application to the data—without programming and complex installation of additional software.
- Despite decades of neglect, the DAC and VISUAL modules still allow numerous simple measurement, control, and visualization tasks to be solved and continue to be used by many users. This is precisely where DIAdem could make the biggest leap forward. A truly intuitive and, above all, direct integration of NI hardware, including access to real-time platforms, combined with access to current fieldbus protocols, would instantly expand the range of applications. Modern and flexible visualization could even be of interest to PLC users who are put off by the cumbersome operation of, for example, TwinCAT HMI. Since NI also has a graphical development environment in LabVIEW, it is worth considering whether the DAC module should not be offered with text-based programming, such as Structured Text, which is established in the PLC world and standardized in IEC 61131-3 – and, of course, real-time capable. Finally, it would be worth examining whether DIAdem DAC, with consistent further development, could replace the often short-lived developments for easy-to-use measurement software at NI, such as SignalExpress and FlexLogger.
- The DIAdem SCRIPT module not only allows the automation of typical processes, but also, in conjunction with a very flexible dialog editor, the creation of complete applications with individual interfaces. However, experience from training courses shows that object-oriented programming is too complicated for many users. The typical DIAdem user is not a programmer and finds the concepts previously pursued in DIAdem easier to understand. But even they could be helped quite easily by summarizing the confusing object structure from the outset.
Despite all the points of criticism, I and we at müller+krahmer are convinced of the basic DIAdem concept. We at müller+krahmer use DIAdem for a wide variety of customer applications. We have compensated for many shortcomings with our own extensions (such as bus interfaces, real-time extensions, DataPlugIns for loading and saving data, or functions for dynamic visualization in script-based user dialogs), but we are convinced that such functions are relevant for all DIAdem users and belong in the standard feature set.
To secure the future of NI DIAdem, it is therefore not enough for the roadmap for further development to contain only a few marginal items for each new version. Product management is called upon to develop a genuine vision for the future, and the leap will probably have to be as big as the change 30 years ago from the text-based DIA/DAGO under DOS to the graphical DIAdem under Windows.
CONTACT:
Holger Mueller
Email: mueller@mueller-krahmer.de
Mobile: +49 160 / 287 7294

müller+krahmer GmbH