DASYLab and FlexPro
29 August 2007
Reviewed by Felix Grant
Data analysis traditionally follows data collection – save data in a file, then open it for analysis. These days, analysis frequently starts while collection is still going on, but generally in a phased way: collection places data into a store, and analysis takes it from that store. Sometimes, however, as efficiency and time criticality become more important in a growing number of fields, it can be desirable or even necessary to conduct the two in tandem. In these situations, incoming data is used to update the ongoing, continually recalculated analyses which in turn will often inform decision making about observed processes – maybe fine tuning the control parameters for an industrial procedure, for example. Over the past couple of months I’ve been running a test installation of DASYLab 9 and FlexPro 7 on three live studies where such linkage is a real benefit. The key is a module called, straightforwardly enough, 'Saving FlexPro Data' – hereafter, SFD for short – which, once installed, appears within DASYLab release 5 or later.
As DASYLab receives data from sensors, SFD employs Component Object Model and Distributed Component Object Model (COM/DCOM) methods to save them directly into a FlexPro database. This can be done in various ways, controlled by the user though with automatic defaults, according to the priorities of the study concerned.
The fastest throughput is achieved by having DASYLab transfer data into a database locked against FlexPro access; if the target is closed at initiation, this is the default behaviour. This may seem to negate the whole point of the module, but there are circumstances where it is appropriate: one of my test projects, for instance, produced furious bursts of data lasting little more than a second, followed by gaps of several minutes. Control routines which sense the end of such a burst can close collection, unlock the database, initiate an analysis, then restart collection.
Slower, but more than fast enough for most purposes and much more flexible, are the two server modes (local and remote) in which FlexPro has read access to the file simultaneously with DASYLab's write access. The difference between the two lies in whether or not the FlexPro instance receiving the data is on the same system as the DASYLab delivering it. I tried only the local variant in live use, since my test projects were all closed field studies run from a single machine, but the remote option worked well in contrived lab bench tests through wireless LAN although setting it up is more of a fiddle. In these modes, the database is initially open in FlexPro and the data inflow is visible from within the workspace.
The ways in which data transfer is handled can be controlled in various ways. Up to sixteen incoming channels can be handled, and the data within them treated as either series (most economic of system and storage resources) or data sets (more explicit). A continuous data flow (single measurement) can be replaced by segmented readings (multi-measurement) shaped to specific circumstances which gives, in practice, a sliding scale of options balancing the advantages of server mode against those of the locked file method.
A lot of control during collection is available through the use of system variables (with or without placeholders) and DDE commands, and each channel can have its own settings, allowing quite sophisticated capture/analysis regimes to be set up without having to learn too much about the mechanics of how they work.
If you are installing FlexPro on a system with preexisting DASYLab setup, SFD is suggested as part of the process; if not, the module has to be installed separately. Either way, it then works very well thereafter – and, after initial set up work has been put in, transparently.