FORUM CTRLX AUTOMATION
ctrlX World Partner Apps for ctrlX AUTOMATION
Dear Community User! We have started the migration process.
This community is now in READ ONLY mode.
Read more: Important
information on the platform change.
3 weeks ago - last edited 3 weeks ago
We would like to learn more about the methods you would recommend for exchanging data between apps. What are the advantages and disadvantages of the different approaches?
3 weeks ago - last edited 3 weeks ago
What kind of data are you exchanging between the applications?
This is going to be a problem with any storage media. The frequent read/write operations generate mechanical wear on the hardware. If you want to go this route, I'd recommend a removable media device.
The best approach here would be using removable storage media and the corresponding plug as shown above. It may also be possible to use the home interface but this plug does not auto-connect. A request to development would need to be made to possibly implement auto-connect for this plug.
This would be my recommended solution, especially if the data is of a consistent format and simple types. There are not examples in other languages for shared memory. What language were you planning to use?
2 weeks ago
Hi @Sgilk, thank you for the explanation
Your questions in blue
What kind of data are you exchanging between the applications?
The best approach here would be using removable storage media and the corresponding plug as shown above.
This would be my recommended solution, especially if the data is of a consistent format and simple types. There are not examples in other languages for shared memory. What language were you planning to use?
I also read about an option to use RAM-Disk on Ubuntu systems, is that a feasible approach on a ctrlX Hardware? I assume its challenging create a RAM-DISK and then mounting it to two snaps.
The benefits of a RAM-Disk for us:
- We could continue writing files
- Very fast read and write operations
- Can sustain countless reads and writes
2 weeks ago
HI @Sgilk,
we looked into the datalayer shared memory example.
A few questions:
In the sample the two apps are running in the same snap. It is necessary for us that the data provider is a own snap and the data consumer is a seperate app. Is there a configuration in the snapcraft.yaml necessary that both apps can access the shared memory?
The MEM_SIZE of the shared memory is set to 100 Bytes, we increased it to fit our 60Mb requirements, the app is not starting after this and we receive an error: DL_OUT_OF_MEMORY
How much memory is available for the shared memory?
Is it possible to do a shared memory implementation without the datalayer?
a week ago
There shouldn't be any special snapcraft.yaml configuration required to share memory between applications. It should be the same as the sample.
I am not finding a documented limit on shared memory. Maybe @nickH could comment?
The shared memory functionality is provided through the datalayer service. I don't think we can support it otherwise.
Now that I understand more of the application, I think the removable media file sharing approach would be more suitable. This way you don't need to parse/encode your files as compatible types for the memory range.
a week ago
Thank you,
we increased the MEM_SIZE in the example app main_owner
(line 16), would be interesting to know the threshold.
Would be also intersting to know if shared memory without datalayer is possible.
Removable media via the sd card slot or the usb-c interface, correct?
I read in a data sheet that all ctrlX CORE have a usb 2.0 interface.
Which read/write speed can we expect for a ctrlX CORE x7?
Is it possible to auto connect on removable media with two different snaps?
a week ago
Yes, you can use USB-C 2.0 or uSD.
The removable media and storage extension interfaces are both auto-connecting.
a week ago
As an addition, apps can also exchange data via Unix sockets directly. The same mechanism is used internally in the ctrlX OS at several points.
a week ago
Do we have any documentation on this? I see the information on using the existing unix sockets (ie. licensing-service), and binding a webserver to a unix socket within a single application, but what about data exchange between apps?
Thursday
@Sgilk you found the correct documentation. The sockets used are examples how our system (consisting of apps) is exchanging data with other installed apps.
Also simply using an content interface in one app where the other app can connect to is possible. Just like our solution management is sharing the hosting folders for the active configuration and all apps can access this folder and its data.