I am now trying to upscale the CEF platform for a Project from a Configuration only platform to a Complete SW frame with configuration and interation mixed, in which I have a Tree of various Nodes, and where some nodes are related to an Engine.
The Engines are responsible for showing actual live data in the Node specific GUI. or allowing live manipulation of IO.
- Opening or closing a configuration or adding a Node should then also allow each Node to starup or close something.
- By allowing the user to adding Engines / Modules in the tree various simulators for instance can be added in runtime
What have I come across until now :
- There is in the Close Case an CloseNodes.vi that is used to close all memory references, but when I use the Open configuration the CloseNodes.vi is not used for closing the previous configuration. This inconsistent behaviour.
- I am missing a Node call for when the Node is no longer required and I can do a Destruct action ( stop engines etc. ). This should be triggers in the New Configuration for the Old Nodes / Deleting of a Node and Application Close.
- I will upgrade this for my version so that it calls a Node Destructor that can be node specific.
You can find some of those functions in the configurator editor for the Tag Bus Framework. That editor is built on top of the CEF and more functions already implemented. If a node containing tags is destroyed, it will clean the tags. Still i will look into this.
I added them to the Issue tracker in github:
For getting the TagBUs framework:
Obviously i'm missing an important point. How is the configuration stored in a xml supposed to be loaded on a RT Target? Is there an example for that?
Hi nope.ch, the xml configuration can be opened the same way that you are opening it in the configuration editor, and then you can pass it to your runtime code. You can use the same Vis to convert it back into an object or a LabVIEW structure in your real-time code.
If your real-time code is already expecting a specific file format you can modify CEF to create the file that way.
If you use the Hierarchical repo it already has a configuration object you can use to store and pass the information into the system. A good example of how this work can be found in the Distributed Control and Automation Framework (DCAF, previously known as TBDF). In there the CEF is used to create, and then the engine loads the information and use this configuration.
I'm using the Hierarchical repo and already took a look at the Editor and even the TBDF. There are still various questions. In my project to open the configuration, which classes do i have to add or create in order to access the configuration? How does the inheritance look like? Which VIs from the CEF API am i supposed to use?
I've already tried multiple combinations of VIs but never know if i'm on the right way. My attempts looks something like this:
Shown below is the top level vi of my project. The yellow Class is createt by myself and inherits from the hierarchical repo class. It's privat data is empty and it also contains no methods.
I'm really struggling with this one for a few days, maybe I didn't get the framework.
I've made a very simple example, just to test it and saving and loading back gives wrong results.
Can anybody look in the attached archive and see whta's wrong?
The error is in the from repo of the instrument class. In here you are using the Index to get the value for the variant but you have no values in the variant. You can use the index directly. Also if you are not concerned about the format of the file using the Hierarchical Repo, has already implemented the repo and from repo and to repo for the classes.
To read the configuration on a cRIO, the repo needs to be initialized like in the picture below.
Since LabVIEW deploys all files needed (as far as i know) in the debugging mode only to de RAM, how can i specify a path? In a executable (rtexe) this might work with the "always included" option but is there a solution for the debugging mode?
I could transfer the classes to the cRIO with FTP manually but that's the last thing i wanna do. How is this problem addressed in other projects? In my opinion the CEF is mainly for embedded systems like the cRIO and therefore there has to be a better solution.
Thanks in advance
Actually the power lies in the Classes Folder next to your .exe
It allows you to upload new classes, or updated versions after the .exe has been uploaded to the target or PC application. Even when you run from debugging mode, it will search for this folder in a specific place. However for a cRIO the folder structure can differ from Linux to Pharlab platform.
For development, have a dummy VI in your application that holds your "Objects "in Casestructure with a False Control ( no constant ). It is loaded but never executed.
The Classed are loaded first from memory, then from file.
for the Build : Make sure to create a classes folder, setup in your Build to include your current version and that it uploads the current classes folder to that folder.
I don't see why the CEF is mainly for embdedded systems ? All platforms have software, on which settings need to be loaded at one time.CEF
Thanks for your answer. If you don't mind can you explain me the dummy VI a little bit more?
A short test by myself was negative. Does the use of the dummy VI make the initialize repository, as shown in my previous post, obsolete? If i still need to upload the classes previously and specify the path i don't see the meaning of the dummy VI. Also i'm not sure if i implemented the dummy VI correctly. I added constants (also tried controls) of all Classes from the CEF in the casestructure.
Thanks for patience