EXTENSION TOOLKIT FOR DASYLAB 2016 AND 2022 DETAILS

[SGerhards]

For DASYLab Release 2016 (DASYLab 14) the interface between the main program and the DLLs with the modules went through significant modifications/enhancements. As a result DLLs created with the extension toolkit in an earlier release (< 14) are not compatible with DASYLab 14. They will not load intentionally – vice versa DLLs created with Extension Toolkit 14 will not load in DASYLab 13 and earlier. This document lists and describes the modifications of the interface and is an addendum to the original documentation. Look for hints for the necessary steps.

For DASYLab Release 2022 (DASYLab 16) the interface between the main program and the DLLs with the modules went through slightly reductions/modifications/enhancements. As a result, DLLs created with the extension toolkit in an earlier release (< 16) are not compatible with DASYLab 2022 and need to recompile with the recent toolkit. Only a few simple changes are necessary (less than 2 minutes per module).

List of changes

In the next small sections we list the changes in the toolkit and provide hints, what actions are needed to migrate your source code to the next version of the toolkit and DASYLab.

Toolkit Version: 1 -> 2 for DASYLAB 2016 and 2 -> 3 for DASYLAB 2022

By changing the internal Toolkit version (i.e. the supported toolkit version in DASYLab) we make sure, that DASYLab 14 or 2022 can only load DLLs created with toolkit version 2 or 3 and – vice versa – older DASYLab releases can only load DLLs created with older releases of the toolkit. This is intentionally because a lot of the data structures changed – most of them transparent to you as the developer of the DLL. The example modules reflect the necessary changes.

Necessary actions for migration:                  none

DLAB_Float: FLOAT -> Double (only DASYLab 2016 – no Further changes for 2022)

DLAB_FLOAT was changed from 4 byte single to 8 byte double to improve the accuracy of computation results and minimize errors generated by accumulation of computing errors. On the other hand this modification will roughly double the necessary amount of memory for DASYLab flowcharts at runtime for DASYLab 2016 (there are plans for DASYLab “15” to take care of this possible issue in optimization of the internal memory management, if this is a “real” and not a theoretic issue). Beside better accuracy the user gains a better handling of any counted value (hardware ore internal counter) – in 32bit DLAB_FLOAT any integer will start to loose digits (counts every 2nd, 3rd 4th, … value) after a while. This happens now much later (6-7 digits of precision vs 15-16 digits of precision).

Necessary actions for migration:                  Delete all explicit type conversions, which are not really necessary. Search for all occurrences of “float” and improve, if necessary.

Max. BlockSize (only DASYLab 2016 – no Further changes for 2022)

In „DATA_BLOCK_HEADER“  the member „wBlocksize“ was renamed to „uiBlockSize“ and its data format was enlarged from WORD to UINT. Block sizes can be larger than 32768 Samples now.

In „FIFO_HEADER“ the member „wBlockSize“ was renamed to „uiBlockSize“ – data format was already „UINT“.

Necessary actions for migration:     Rename the variables in your code and make sure your modules work with block sizes larger than 32768. The maximum block size for DASYLab 2016 is 2 in the power of 20 (1 MSample). For test purposes use the data window module – it can produce block sizes larger than 32768.

Sysinfo -> Serialopt (only DASYLab 2016 – no Further changes for 2022)

The structure „Sysinfo“ was responsible for authentication of DLLs regarding flags in the serial number. Since most of the work is done in the main program at startup time, you probably don’t need to care. However - it is renamed to “SerialOpt” and gained some more flags.

Necessary actions for migration:     none

Removed deprecated Functions) - (only DASYLab 2016 – no Further changes for 2022)

"ShowPipeStatus" and "AdvancePipeStatus" were removed, since DASYLab handles the animation of the data flow internally. „SetFontSmallProc“ was removed, since deprecated from Windows 32 on. „CenterDialog“ was removed, since handled in DASYLab internally. Some function declarations (that were never exported to this interface) for bitmap handling were removed.

Necessary actions for migration:     Delete function calls in your code

Slightly changed Structures / Functions (only DASYLab 2016 – no Further changes for 2022)

• Internal structures „MODUL“, „MODULKLASSE“ and „FENSTERPARAMETER“ enhanced.
• New constants for event actions „ACTION_PARAM_TYPE_xxx“.
• New constants  for time base IDs (need to be mutually exclusive for all time sources in the system)
• Removed hook function (Windows 16 bit remainder) in „ModalChooseFontDisableSize“.
• „ToolTipTyp“ has a string length of 512 chars now.
• „CheckWindowsPosition“ is exported by DASYLab now.
• New global variable „chDefSharedUserDir“ that provides the path tot he base directory for DASYLab document files. In this location the DASYLab.INI is located (since DASYLab 10).

Necessary actions for migration:                     none – but use, if applicable

New Module Message for Data Source Modules – including DLL driver modules) (only DASYLab 2016 – no Further changes for 2022)

DASYLab 2016 stores only the used time bases into the worksheet per default (you can change that to store all time sources in the system as it was before in the global settings dialog box). For this purpose it needs to ask every module, which time base ID it uses. The default function returns 0 (so no time base is used) what is appropriate for all data processing modules. Nothing to do for you.

But all data source modules (slider, switch, generator, hardware input modules, hardware output modules) need to return the time base ID, they are bind to (or they are synchronized to). If you do not answer to that message, the block size and the sample rate of your time base do not make it into the work sheet. Example is in Generat.c in this toolkit.

Hint: The time bases DASYLab and Driver are always stored into the flowchart – so nothing to do for old fashioned Driver toolkit drivers.

Necessary actions for migration:     Add handling of message DMM_GET_TIMEBASE_ID

Example from Generat.c

case DMM_GET_TIMEBASE_ID:
   return ((MODULE_GENERATOR *)ThisModule->ModuleParameters)->uiTimeBase;

New Module Message for ALL Modules to support SmartMux (only DASYLab 2022)

Similar to the data flow (while processing), DASYLab carries the structure information of the modules from left to right through the flowchart (with adjustments – depending on the function of the module). The smart multiplexing feature works different – it does not copy the information about channel name and unit directly to the receiver; instead, it provides a link to the information (internally a tree) and needs to investigate the “left” module while dissolving that link. Therefore, it sends a DCM_GET_CHANNEL_NAME message to that module.

Remark: When you’re amazed about the very similar DMM_GET_CHANNEL_NAME message – a long time ago we could have given that a better name – DCM_COPY_CHANNEL_NAME_ON_USER_FLAG would represent the functionality better. Feel free to replace DMM_GET_CHANNEL_NAME with DCM_COPY_CHANNEL_NAME_ON_USER_FLAG or leave it as it is. We changed the examples for clarity, but it has no other effect.

Necessary actions for migration:     Add handling of message DMM_GET_TIMEBASE_ID

Example from Generat.c

case DCM_GET_CHANNEL_NAME:
   return (long)((MODULE_GENERATOR*)ThisModule->ModuleParameters)->szChannelName[wParam];

 

General instructions for the migration:

• Let Visual C do as much work as possible - use warning level 4.
• Avoid explicit type conversions (if possible) - if the compiler doesn't know what you want without it, it could be a trouble spot.
• For questions or help or suggestions please use this forum.