This file contains some links and some videos for OFB usage in Libre/Open office graphic programming, code generation for C(++) and test

[title="BandpassFilter_FBgl_srcC-en"

FBcl means 'Function Block Connection Language' which is the textual description of the graphic. The idea comes from ~2018.

OFB means 'Object oriented Function Block graphic'.

Graphical programming of function blocks has been common practice for decades. The automation control, for example Simatic-S7 or Codesys, use it with its "FBD" language (Function Block Diagrams). Another representative is Simulink © Mathworks. There are some more similar tools for that. But for these Function Block programming solutions ObjectOrientation is missing. It is also non-conform to UML. The OFB closes this missing relation with some enhancements in concept, using of Aggregations (UML like), and also a event control system for execution.

What is the approach? Drawing the software with graphic and code generation in C/++ (maybe later also in Rust, or in Java) so that the functionality is seen and understandable by everybody with physic knowlege, obviously, no code lines. But the code lines are generated and follows guaranteed the graphic. Graphical software development does not save effort (money) for development. It improves the documentation! That’s the benefit. The basis for the graphics should be an available, proven tool (without basic costs, usable by anyone at any time). LibreOffice was chosen for this purpose. It is well-known and easy to use for this approach of graphics. The translation is an algorithm written in Java, which reads the graphic data and have capabilities for Code generation.

1. Resources, hints for download and work

Of course the current version needs to be improved, and some small things are seen immediately. But if it is not offered in a definitive time, it is never offered. Procrastination is usual not the best idea.

You can write feedbacks and questions to info (at) vishia.org

Note: Some descriptions here are related to the newer, expected version of the OFB_Presentation, but are also valid as consideration for the just given version 2025-07-25.

1.1. download zip and install the tools

Some examples and the load_tools are contained in the following zip file:

  • https://vishia.org/fbg/deploy/OFB_presentation-2025-07-25.zip: Last version,
    SHA-256 check sum: 5b654b77a82fb22077740f1ff5ce2dcd5beee5c022fb23dce372721214687d9f
    MD5 check sum: 22cd4faf96765a6af308e8bd499343d8

  • Download and extract the zip file to any proper directory on your PC. Then all files are stored under OFB_presentation in your destination directory. The directory tree under OFB_presentation have a designated structure which is presented in Hints Handling load, file tree and detailed explained in ../../SwEng/html/srcFileTree.html

  • Install the tools. The tools are simple jar files running under Java in version 8 or higher. Installing the tools should be done under MS-Windows with execution of the batch file:

    OFB_presentation/src/load_tools/+checkAndLoadTools.bat

    This batch file calls as Java process a loader (MiniSys.jar) from the given internet location on this web page with a given and compared check sum (MD5) contained in the file tools.bom beside.

  • After installing your find the tools as jar files in the directory

    OFB_presentation/tools

1.2. Just have a short look into the examples

The zip file contains some examples, which are also shown in the videos below. You find the LibreOffice draw files in certain directories:

  • OFB_presentation/src/MyExampleComponent/odg/MyExample.odg : This is a very simple basically example showing the principle of using the graphic.

  • OFB_presentation/src/BasicTest/odg/BasicTest.odg : some examples showing basic capabilities used as test.

  • OFB_presentation/src/ExmplBandpassFilter/odg/OrthBandpassFilter.odg : elaborately example for a module as filter for 50 Hz grid frequency detection

  • OFB_presentation/src/ExmplPositionCtrlPID/odg/ExmplPositionCtrlPID.odg : an example showing the capability of working with non deterministic data types.

  • OFB_presentation/src/Templates_OFB/odg/LibCtrl_emC.odg : 'Library' file with definition of modules as FBtype which are contained in

  • OFB_presentation/src/src_emC/cpp/emC : some sources in C and C++ language which comes from the emC-concept (../../emc/index.html) used in the examples.

  • OFB_presentation/src/Templates_OFB/odg/OFB_DiagramTemplate.odg : Graphic file as template with the styles and shapes

The different directories below src are the Component's directories. A Component is one part with all its Graphic files, control files, generated target source and report files.

Note: ignore the batch files on root of OFB_presentation. There are for internal organisation only.

1.3. Documentation

Note: Use two-page view if you have a larger monitor (1980 x 1020 or more). The documentation is page-oriented. The odd page should be on right side ('book view'), but because usual the Browser-pdf view don’t support the book view an empty left page is introduced for that.

What is the approach

  • Graphical programming for embedded control is not the way to save money (this is not true also by using other tools), it is the way to get a good correct and understandable documentation for the software.

  • That’s whay it is important to generate target code for the embedded controller from the graphic.

  • Usual Function Block Diagrams are used for such approaches, this is also done here.

  • But the UML (Unified Modelling Language) plays an important role for software architecture and also software understandment. That’s why a way is searchted, and found, to combine capabilities of UML with Function Block graphic. It is possible that this opens a proper way to go to a joining of UML with Function Block graphic. For that it is named OFB Object oriented Function Block graphic.

  • One of the important idea is: Use the capability from the Free Open Source tool LibreOffice draw to draw the graphic. And in fact, all necessities are supported.

  • The here offered tool is the translator from a LibreOffice draw file (*.odg) to the target code yet in C/++ language.

  • There are a lot of details, possibilities of the graphic, handling, translation parameters etc. explained in the docu.

1.4. test, translate one component from graphic into target code

If you want to test what’s happen while translation, before or after reading the docu, go with any File Explorer to one directory of the examples, (a component), and then to

OFB_Presentation/src/ExmplPositionCtrlPID/makeScripts/genSrc_odg.bat

Start this batch or on Linux the adequate genSrc_odg.sh script. This reads the graphic, translates the content and writes the result to

OFB_Presentation/build/ExmplPositionCtrlPID/

If this works, the tools are proper installed.

But wait a moment, what is build:

General, sources are stored in OFB_Presentation/src, results, including the generated target (second-) sources should not be merged with the first intrinsic sources. That’s why the destination for all translating is OFB_Presentation/build.

More exact, the scripts uses an environment variable BUILDD which is preset to ..\..\build as relative path from the component’s directory.

For practical approaches, this build directory can often be a symbolic link which refers either to a RAM disk or to a destination in a network, on another computer, where immediately the generated target secondary sources can be used in a target project. Details explanations see chapter on end of this site: Write results to build, optimising access to the hard disk, RAMdisk and symbolic links

To redirect the build directory to another destination symbolic links can be used, which are JUNCTIONs in Windows. To organise that, often used batch or shell scripts are arranged beside src and build:

OFB_presentation/+mklink_build_TMP.bat
OFB_presentation/+mklink_build_RAMD.sh

More variants of that files can be stored also in the OFB_Presentation/src/Organize_OFB/…​ directory.

1.5. Compare newly generated sources with the versions before

Are the sources proper generated after changes in the graphic? Which is changed in the sources? Is somewhat by accident destroyed in the graphic, a dangling connection, a removed pins or such?

That are important questions. If you write source code, usual a source repository (git) is used to monitor all changes. If per accident a part of software is bad, it can be fast detected by comparison of the source with the version before.

In graphic programming, faulty changes per accident are more probable and maybe worse to detect.

That’s why a textual different view of the generated sources (and also some report files) can help to see the truth what’s happen.

A secondary consideration: The generated target sources should not be seen as black box (as some other graphic tools imply). The hard work to manage embedded software are the real text sources. Graphical programming first helps to understand the code. Source code generation is not primary done to hide the sources, or to save time and money for code writing, it is done to guarantee that the graphic and the sources are identically. Which is usual not true if the graphic is only drawn as documentation afterwards.

Hence, you should look into the sources, knwo the source code principles etc.

Thats why a "diff view" is recommended or necessary.

There are some different diff tools available. Here using Winmerge is preferred. https://winmerge.org/. It is very proper for the approach. Use the winmerge-2.16.50-exe.zip to download. It is a 32-bit Windows version as 'portable' or just 'copy deployment'. It runs also under Linux using wine. It is recommended to install Winmerge not in the Program Files folder, that is for Windows stuff, use instead in extra C:\Programs folder for your own additional tools.

To call the Winmerge or also another diff tool, the following bat or sh in the scripts are used:

OFB_Presentation/src/Organize_OFB/fdiff.bat
OFB_Presentation/src/Organize_OFB/fdiff.sh

After installing Winmerge you need to adapt this script(s). The default choice for the Winmerge path there is:

C:\Programs\WinMerge\WinMergeU.exe

If Winmerge is installed and this file is correct, then after code generation Winmerge is started to compare the folders:

.../build/<?COMPONENT?>/gensrc  <==>   .../src/<?COMPONENT?>/cpp/gensrc

With simple textual comparison, decision that the new generated sources are correct and copy with quick push over using <Alt-arrow right> you can fast synchronise this files. Have it compared, store the last used version.

What is the meaning of all these generated files - look in the documentation.

1.6. Compile the examples for a Windows-Environment and run/test it

There are some Visual Studion projects given, also some CodeBlocks project to compile and run the examples under Windows.

Because of recommended separation of sources and generated Object files, the Visual Studio files should run under

OFB_presentation/IDE/<?COMPONENT?>/MSC

There are copied with the

OFB_presentation/src/<?COMPONENT?>/+spawn_IDE_MSC.bat

The relative paths to the sources in the Visual Studio Project are related to the OFB_presentation/IDE/…​ location of the project and to the OFB_presentation/IDE/…​ location for the sources.

To see how does the compiled target code on PC works, a small graphic output (Java program) is contained under OFB_Presentation/src/…​/curveView The control file for this curveview is also a result of the code generation.

But to run all, you may need a little bit to be familiar with all.

1.7. testAll, translate all examples from graphic to C code

To start a test whether all graphic files can be translated, do it, translate all the graphical source files by execution of

OFB_presentation/src/TestAll/makeScripts/testAll.bat

1.8. Linux?

There is no reason that this tools cannot used under Linux. Only the scripts should be prepared. LibreOffice runs, Java runs, Linux has some possibilities for IDEs (Integrated Development Environment) to compile the generated stuff.

The next zip file will be have Linux scripts.

1.9. older zip files to download

Hint: Use the newer file to test whether all features are ok, use the older one as fall back if you know that in the older version a detail has worked, to compare with the new one.

1.10. source repositories, Gitlab

New created on 2025-March-27: Git repository on Gitlab. (The repository itself is grown since 2019):

1.11. Javadoc for sources

Javadoc html of the converting tool

2. Preparing the new version 2025-10..12

The new version should anyway be completed with the state machine capability, working on.

But also quests of handling a system with more modules are in focus.

2.1. Aggregation using in OFB diagrams

Exmpl AggrDataClasses
Figure 1. AggregatedData

This video (13 min) shows how aggregations are used.

3. The version 2025-07-25:

The new version comes in comparison to the April version with a lot of new features. As the versions in 2024, the April version may seen only as start. This version is now suitable for professional use.

3.1. Changes since 2025-April

Some important news are:

  • The access to data with operations and return values are now supported. The older versions were oriented, as usual also in ordinary C programming, only to (public) data. Working with operations and hence encapsulate data are a proper decision. inline operations also in C language does not enforce additional calculation time on machine level. Also usage of reference variables for return values is possible. What is not clarified: Return of a reference is intrinsically an association in UML thinking, and should be handled in exact that way. Function block graphics do not deal with references, only with data flow. But usage of references is usual in C/++ programming. This should be basically proper clarified for the Object Oriented Function Block (OFB) concept.

  • In opposite to this feature, also public access to structured data works, sometimes necessary for embedded applications. Inner variables well structured can be declared as outputs to immediately access from outside.

  • Defining and usage of module input and output pins is improved (as result of the changes above).

  • Usage of non determined types are supported. This is sometimes necessary if a library module is written first independent of usage in a float or int environment. The graphic is the same. The usage and code generation decides about the numeric, with unchanged graphic.

  • The fix point arithmetic is improved and tested, with automatic conversion from and to float with dedicated given 'number of fractional bits'. Also using saturation arithmetic is supported. It is not yet tested elaborately in embedded hardware, but the system for that is established.

  • The concept of predefined FBlocks and the alias are improved. The name of a struct in C language is determined only on code generation, not already in the graphic diagrams. The mapping is done with an extra text file (-cfg:), see video below. Used names in the graphic diagrams are more independent of target implementation stuff.

  • logs and comments are improved to see how and why the code is generated in the given result.

  • The translation from the graphic to target code can now be started also from LibreOffice in the toolbar, using a macro in LibreOffice, which calls the used batch file (or todo: shell script for Linux). See video below. Also executing the target code build process and start execution can be done in this kind, but is not done yet. This would be a faster way from the graphic to execution results.

All in all, some tests on living examples are done, a lot of fine tuning was done. A list of details of changes can be seen in the version history: https://gitlab.com/jzhartmut/srcJava_vishiaFBcl. Of course the documentation is improved step by step.

3.2. Videos showing the new features and working with OFB

There are some videos showing the new features and showing how working with OFB. The video is linked by clicking on the image on the right. It is an mp4 file hosted on my website.

3.2.1. Working with alias and determine the struct names in target code

Alias and Headerfiles
Figure 2. Alias_and_Headerfiles

This video (18 min) shows how alias designations are used and how the header files are determined from the graphic content.

It includes also the explanation how the graphic definition of FBlocks is related to the given (legacy) target code.

3.2.2. Module output possibilities, return by value, value reference variables, operation access

OutputRetRefOper
Figure 3. Module output possibilities

This video (26 min) shows possibilities of the outputs of the module as also as called function blocks also written in target language.

Operation access is the recommended style for encapsulated Object oriented programming. But beside this, for embedded C, as usual, also the public access also to structured data is supportet.

The video discusses also the possibility to use pointer access. But this is a question of associations (UML thinking), and some questions are open regarding code style, public access, const access. Associations are not yet ready to use handled in the version 2025-07, should be added in the next time. Then this video is still valid, and a second video using associations will be offered in parallel.

3.2.3. PID control - with different numeric data types

PIDctrlN
Figure 4. Explain PID ctrl with numeric DTypes

This video (21 min) shows the example ''Position control with PID'' which is implemented with float, int32 and int16 arithmetic. It shows more details about controlling effects, especially the D-Part in PID controlling, than details of the OFB concept. But may be interesting as application example.

SelectNumericTypePIDctrlPos
Figure 5. How select the numeric DTypes

This second video (11 min) for the same diagrams now shows, how the numeric data types are selected in code generation and from the given (legacy) core C codes.

3.2.4. Integer and saturation arithmetic, using fractional bits

IntegerArithmSaturation
Figure 6. IntegerArithmSaturation

This video (26 min) shows how integer artithmetic with dedicated number of fractional bits is used beside float arithmetic, with automatic conversion between, and especially how saturation for integer arithmetic is possible and works. Hint: The video has some technical hanging effects especially on end. It should be replaced by a new version.

3.2.5. How insert an icon and macro in LibreOffice draw for the translation

Macro OFBwr
Figure 7. Macro_OFBwr

This video (8 min) shows how to insert a macro in the LibreOffice toolbar to fast start the OFB translation from LibreOffice (after saving the file).

The translation itself is controlled by a batch file (TODO offer also a shell script for linux) from the stored file.odg content. The macro does the same as start the batch file from outside. But it is faster to handle.

3.2.6. Fix a problem with hanging socket on CurveView

SocketHangingProblem
Figure 8. SocketHangingProblem

Not all is perfect. The current version of the CurveViewApplication has the problem that sometimes (rarely) it is not correct closed, and the used socket remains open. This problem should be fixed in the CurveViewAppl, which is only used here as helper. But it is not fixed yet in the moment. If it occurs, "a new boot is good", booting the PC helps. But to fix the problem also only the hanging process can be killed, using the TaskManager (of Windows). This video (8 min) shows the problem, and show how to find the blocked socket in the ResourceMonitor on Windows and kill the process. The process-ID is written to the socket in the Resource Monitor. But it is unfortunately not written in the standard view of the task manager, only in the "Details" view on the task manager.

4. Presentation on Linux-Day in Augsburg, Germany

My presentation in German language has shown the OFB-Converter only as example how to use indirect styles in documentation and graphic. The topic there was LibreOffice, not the OFB-Converter. But nevertheless the presentation may show some hints on usage also for the OFB topic:

https://www.luga.de/static/LIT-2025/talks/nutzung_von_styles_in_libreoffice_draw_zur_semantischen_kennzeichnung_von_elementen/

https://youtu.be/CfxPV5skklM The presentation itself, German.

5. Version 2025-04-02:

Hint: The videos below are also valid for the current version, only small changes in implementation are different. The approach and system is not generally changed.

Many details are improved in the last year, in the work is also current in progress. But new versions has run also in the past with changed versions. The base is stable.

My own main focus should now be on improving the comprehensibility of the sources (programmed in Java) All tagged or downloadable versions are (and should be in the future) tested and fulfill the examples shown. The second effort should go into the documentation. The state machines are not yet available, but are in progress. Follow the videos. They show what is available.

../deploy/OFB_presentation-2025-04-02.zip

5.1. Unpack zip file, use code generation

OFB presentation 2025 04 02
Figure 9. OFB_presentation-2025-04-02.zip

This video right side on the image shows how to unpack and start test with the new zip file from 2025-april-02. It is a short presentation, 6min with ~43 MByte

5.2. Detail explaination with example BandpassFilter

ExmplBandpassFilter
Figure 10. OFB_presentation-2025-04-02.zip

This video (in German language) right side on the image is an introduction to the new zip file from 2025-april-02. It is a longer presentation, 1h10min. The resolution is reduced (to save a little bit our world), it uses only ~200 MByte space on the server and for traffic.

6. Older content from ~2024

Older zip file to download:

The following videos are the old ones, still valid exclusive small details. They will be replaced step by step by videos with the newer versions if necessary.

A documentation can be viewed or downloaded, see start of this page.

Older and not complete documentation:

6.1. First example from 2024, goal of graphic in Libre/Open office

CopyTplFirstModule
Figure 11. CopyTplFirstModule

This first video (12 min) shows how to copy and use the template in LibreOffice for a first simple own UFBgl-diagram. It shows the general approach drawing UFBgl diagrams.

UFBgl 2 CodeGenerationFirst
Figure 12. UFBgl-2-CodeGenerationFirst

This second video (16 min) shows the code generation for this first example,

6.2. Comprehensive example: Bandpass Filter for 50 Hz electrical grid

BandpassFilter FBgl srcC en
Figure 13. BandpassFilter_FBgl_srcC-en

This video (8 min) explains a more comprehensive module or graphical model. It is the first video for that example and shows the approach how to deal really with graphical modelling.

BandpassFilter Test Scope en
Figure 14. BandpassFilter_Test_Scope-en

This video (13 min) shows how test results are output in a curve view, and how the functionality can be designed, tested and improved in the graphic module, with help of execution the generated code.

CodeGeneration Scope en
Figure 15. CodeGeneration_Scope-en

In this video (10 min) it is shown how the code generation for this specific scope program is done, with preparing of an ethernet telegram to the scope "Curve View" application, inclusively generation of the configuration of the code generation script

6.3. Details about running mode

UFBgl 3 VisitDebugTheCode
Figure 16. UFBgl-3-VisitDebugTheCode

In this third video (6 min) it is shown in single step in the generated code how the initialization works. It is also the concept of emC for the phases constructor, initialization and run.

UFBgl 4.AggregationInCtor
Figure 17. UFBgl-4.AggregationInCtor

This video (8 min) enhances the example in the video above with the possibility to assign the aggregation between the classes in the constructor instead in the init…​() routine. Both is possible.

Also the possibility of vice-versa aggregations are explained. But not full completely. The topic is, vise-versa aggregations in the constructor are not possible if allocated memory is used. Because the other instance does not exists if it is necessary for referencing in the constructor. That’s why aggregations can also be assigned in the init, after construction of all instances. This topic should be explained in an extra video, yet todo

7. Hints Handling load, file tree

Also handling with "load tools"

Hint for the file tree in the examples: The generally approaches for the file tree are described in ../../SwEng/html/srcFileTree.html.

It means here:

Working_tree_where_zip_is_unpacked
 +-tools           This is created after src/load_tools
 +-IDE             This is created after executing a +spawn_IDE_....bat
 |  +-Example_Component
 |     +-CB        for Codeblocks projects to execute and test
 |     +-MSC       for Visual Studio projects to execute and test
 +-src             The sources, only this directory is contained in the zip
    +-load_toos    To load the translation tools for UFBgl from vishia page
    +-src_emC      Version of used sources from emC (embedded multiplatform C/++)
    +-Templates_odg contains the odg template file, and makescripts to create onw stuff
    +-Example_Component
    |  +-IDE...        The IDE files to spawn it.
    |  +-+spawn_IDE_....bat click it to spawn
    |  +-odg           Here is the odg file for this example
    |  +-cpp           Some C/++ files
    |  |  +-genSrc     This are the destination for generated C/++-Files
    |  +-cmpGen        This directory contains the versions from older generations, to compare
    |  +-curveView     Files for the CurveView toool
    |  +-makeScripts   Files to translate the module.
    +-ExmplBandpass    It is such an example
       +-IDE
       +-odg           ... etc.

7.1. Where to store generated sources, JUNCTIONs or symbolic linked directories

There is a decision where to create the folder for the generated sources. I see three possibilities which advantages and disadvantages:

  • a) Do not create this JUNCTIONs or linked folders, write the sources immediately in …​\<EXAMPLE>\cpp\genSrc.

    Disadvantage: It is immediately a part of the sources in the src/tree though it is generated. Any new generation writes on SSD or the hard disk.

  • b) Write the generated sources outside the source tree to OFB_Presentation\build\<EXAMPLE>\cpp\genSrc Advantage: The generated sources are outside of the primary sources. This will be done in fact because a symbolic link or JUNCTION in MS-Windows is created from ⇒ to

    OFB_Presentation\build => %TMP%\OFB_presentation\

    and hence the sources are seen also there.
    Disadvantage: Taking the sources from …​/build/…​ in a IDE project is a little bit more confusing. It is better, sources are beside together. (Is it a disadvantage).

  • c) Write the generated sources to …​/build/…​ but without symbolic links or JUNCTIONs:

    Hm, symbolic links are a proper possibility well known in UNIX from the 1970th
    (ln -s /path/to/dst linkname), should be well known in Linux,
    and introduced in the Windows-world first with Windows-Vista ~2008, but only for the NTFS file system.
    But for some people they may be confusing.

Have experience and fun.

8. Write results to build, optimising access to the hard disk, RAMdisk and symbolic links

General, sources are stored in OFB_Presentation/src, results, also the generated target (second-) sources should not be merged with the first intrinsic sources. That’s why the destination for all translating is OFB_Presentation/build.

More exact, the scripts uses an environment variable BUILDD which is preset to ..\..\build as relative path from the component’s directory.

For practical approaches, this build directory can often be a symbolic link which refers either to a RAM disk or to a destination in a network, on another computer, where immediately the generated secondary target secondary sources

This is not a topic of the OFB approach and tools, but it is recommended (also here) to think above:

RAM disk

If you have a lot of temporary files, writing all these on your hard disk needs a little bit time, even if only milli- or microseconds per file. But the more important problem is: Frequently writing on hard disk puts strain on it, more for SSD as for magnetic disks. On the other side, RAM is usual enough in your system. If you have 16 GByte RAM, and you spend only 1..2 GByte as RAM disk, it is enough for all temporaries. The translation is faster and your Hard disk is spared. This is true for the generated target source files, as also especially for Object, Map and executable which are usual used only for a short test. Of course proven files should then be copied to a permanent storage.

Symbolic links (Unix, Linux) or JUNCTION in MS-Windows

To work with the RAM disk, and also using relative paths recommended, symbolic links helps to work. Symbolic Links are familiar in UNIX since beginning (1970th). In DOS till Windows XP there are not available. Only beginning with Windosw-7 for the NTFS file system so named JUNCTIONS are usable with similar capabilities as symbolic links in UNIX. This symbolic links allows to write the generated sources in a build directory beside and separated from the sources in src. But the files can be really stored on the RAM disk, or on another proper location, also in the network. I use partially the RAM disk of another PC to store the files, because the other PC is used to compile the target project. This does not save time, because the files should be transferred via Ethernet to the RAM disk, But is spares the hard disk.

In an adequate way the yet currently generated target source files can be used in a project for target software generation which can be located not only on another main directory path on the same computer, but also on another computer connected in the network. Symbolic links or JUNCTION on MS-Windows in combination with substituted network drives can be used to interact between the sources.

For the examples the destination of target code generation is always the

OFB_Presentation/build/<COMPONENT>/genSrc

The build directory is symbolic lined to the temporary directory:

%TMP%\OFB_presentation\build\<COMPONENT>\genSrc

It means the generated sources are stored in the temp folder of your computer. It is temporary, can be deleted again after the session. I use (recommended) a RAM disk for the whole MS-Windows temporary stuff, that works. The computer is faster and the SSD is spared. But in some scripts after making any JUNCTION a pause is programmed, you need to "press any key to continue"

If JUNCTION on MS-Windows does not work because you have not an NTFS file system, then the build directory is created where it is located on the hard disk, or for example on an USB-stick which is even not NTFS-formatted. It works anytime.

As you see, some small problems are in the source, especially ExmplWaveAvg is not yet ready. But the videos are made with this version.