Multiple exOS datamodel handled with the same Linux app

Ask Questions
1

Hello Community,

I have a customer that wants to split up his growing application in several datamodels, AS task and shared memory partition. But he wants also to keep only one linux app to achieve that.

He saw the possibility to add a second datamodel instance like here:
image
I far as I know (so not so far), the datamodel basically generated with VS code plugin, create linux + AR files from .typ file. Is it feasible to create the second datamodel from VSCode and then merge the linux part?

Sorry if the question sounds basic, but I’m quite new to this topic

Best regards

RĂ©mi

2

Hi RĂ©mi!

Sorry for the late answer. Vacation times.

Yes thats absolutely possible. I have not tested the VSCode plugin with several datamodels, and so additional features that you might need once the package has been created, like “update exOS package” might not work as intended. I will see if I get time in the coming weeks to give you a more elaborate answer on that.

From an AS perspective and exOS runtime perspective combining more than one datamodel into a package is possible.

I would merge everything into one exOS package, meaning you would then have two entries for generating / comiling the headerfiles for the two different types you are using.

For example, lets say you have a WaterTank.typ structure and a Threads.typ structure.

In this case you would start with creating a WaterTank package and a Threads package with the vscode plugin. You then move the AR library Threads and the Threads_0 program into the WaterTank package, copy the exos_threads.h and exos_threads.c into the WaterTank Linux folder, and merge the c/c++/javascript code into the watertank Linux program.

You then also need to merge the settings inside the exospkg file, like

<ComponentPackage Version="1.1.0" ErrorHandling="Component" StartupTimeout="0">
    <File FileName="Linux\exos-comp-watertank-1.0.0.deb" ChangeEvent="Reinstall"/>
    <Service Type="Runtime" Command="/home/user/watertank" WorkingDirectory="/home/user"/>
	<Service Type="Install" Command="dpkg -i exos-comp-watertank-1.0.0.deb"/>
    <Service Type="Remove" Command="dpkg --purge exos-comp-watertank"/>
	<DatamodelInstance Name="WaterTank_0" SharedMemorySize="123000"/>
	<Build>
		<GenerateDatamodel FileName="WaterTank\WaterTank.typ" TypeName="WaterTank">
			<SG4 Include="WaterTank.h"/>
			<Output Path="Linux"/>
			<Output Path="WaterTank"/>
		</GenerateDatamodel>
		<GenerateDatamodel FileName="Threads\Threads.typ" TypeName="Threads" >
			<SG4 Include="Threads.h"/>
            <Output Path="Linux"/>
            <Output Path="Threads"/>
        </GenerateDatamodel>

This will let the AS compiler know to create exos_threads.c and exos_threads.h in the Linux folder and the AR Threads library whenever the Threads.typ changes.

As long as you are using C or you handle C++ wrappers yourself and have no use of having the VSCode extension to recreate wrapper code (like for python or javascript), you should be fine.

Otherwise I will need to see how it handles “update exOS Package” when having more than one datamodel. This feature is based on the exospkg entries

    <!-- ComponentGenerator info - do not change! -->
    <ComponentGenerator Class="ExosComponentC" Version="2.0.1">
        <Option Name="templateLinux" Value="c-api"/>
        <Option Name="exportLinux" Value="exchange"/>
        <Option Name="templateAR" Value="c-api"/>
        <Option Name="typeName" Value="Exchange"/>
        <Option Name="typeFile" Value="Exchange\Exchange.typ"/>
        <Option Name="SG4Includes" Value="Exchange.h"/>
    </ComponentGenerator>

which are assumed to exist only once per package. Once again, its only an issue if you are using python / javascript, or you are dependent on the vscode extension to create C++ wrapper objects for you (and you don’t want to do that yourself).

That limitation is visible on line 353 onwards here exOS-ComponentExtension/src/components/exoscomponent.js at master · br-automation-com/exOS-ComponentExtension · GitHub

SUGGESTION

Another possibility could also be to continue having one single datamodel, and split up the structures you are communicating into different sub structures. from a performance perspective, there are no benefits of splitting up the structures. You can have several AS tasks / library instances accessing the same datamodel, and with that update/publish one part of the structure in one AS task, and update/publish/receive changes in another one, while still having one Linux program. This is a use case that is tested, and local changes (like a change of a sub structure in one AS task) will be reflected on the other task. This is surely a more simple way of solving it, if it still fits to your use-case. Please see the chapter regarding datamodels where you are using user-aliases to distinguish between the different AR tasks here:

B&R Online Help (br-automation.com)

3 Likes