|
|
|
Back
Midas
Rome
Roody
Rootana
|
| Midas DAQ System |
Not logged in |
 |
|
|
 19 May 2014, Razvan Stefan Gornea, Forum, Weird problem on new installation
|
 22 May 2014, Razvan Stefan Gornea, Forum, Weird problem on new installation
| |
27 May 2014, Razvan Stefan Gornea, Forum, Weird problem on new installation
| |
06 Nov 2014, Stefan Ritt, Forum, Weird problem on new installation
|
|
|
Message ID: 1037
Entry time: 06 Nov 2014
In reply to: 1001
|
| Author: |
Stefan Ritt |
| Topic: |
Forum |
| Subject: |
Weird problem on new installation |
|
|
| Razvan Stefan Gornea wrote: | In my case I have the following structure in ODB right before the framework calls frontend_init():
/Equipment/CAEN_V1740 [CLOSE]
/Equipment/CAEN_V1740/Variables [CLOSE]
/Equipment/CAEN_V1740/Common [OPEN]
/Equipment/CAEN_V1740/Statistics [OPEN]
/Equipmemt/CANE_V1740/Settings [CLOSE]
|
Sorry my late reply, but I could only find today to have a look at this.
It is absolutely ok to have the Common and Statistics subtrees in the ODB open. So if anybody modifies anything in the Common tree for example, the frontend gets notified directly via the hot link mechanism. Having a subtree "open" however means that the structure of that tree may not be changed, since it's directly mapped onto a fixed C structure. If you create a subtree via the db_create_record() function, you modify the structure of that tree, and thus it may not be open by other clients.
Your problem can be fixed if you create the /Equipment/CAEN_V1740/Settings tree (which is not open), instead the full /Equipment/CAEN_V1740 tree, which contains the open Common and Statistics subtrees.
Best regards,
Stefan |