Experimental Physics and
Industrial Control System

"Szalata, Zenon M." <[email protected]> · Tue, 15 Sep 2009 16:13:24 -0700

Hi Ben,
I gave it some thought and it is not clear to me how to make this into a general purpose support module.  It could be made into a skeleton module, which a user could take and flash it out to make it useful.
Take a look at the three attached file, which is all I have in my "proof of principle" soft IOC.

In the IOC for which I need this, these three files are becoming much more complex.  Simply said, the IOC first builds a data base of all defined magnets and associated hardware.  This is done from a setup file in C routines.  When this is done, then the mbbo records are initialized by calling routines which retrieve data from the magnets data base.  The IOC actually controls the Power Supplies which feed power to the magnets and which are controlled and monitored via a set of CAMAC modules.  So, the whole system is a rather complicated mess. 

Zen

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Benjamin Franksen
Sent: Tuesday, September 15, 2009 1:39 PM
To: [email protected]
Subject: Re: MBBO Record Initialization (and a proposal)

On Dienstag, 15. September 2009, Szalata, Zenon M. wrote:
> I have successfully implemented initializing dynamically menu strings 
> (in mbbo record) by creating a device support C module for a 
> fictitious device.  This gives me access to the mbboRecord structure 
> at IOC init time.  I have chosen INST_IO as link type since its 
> structure is the simplest of all. Now, the mbbo record is needed only 
> as a menu of choices, where the numeric value of the selected item is 
> used in genSub routine.  The mbbo record never does any IO. In my 
> xxxx.dbd file I have the following:
>
>  device( mbbo, INST_IO,devMbboSoftMag, "softMag")
>
> The thing is that I was looking for an even simpler solution, but what 
> I did works.

Could your solution be turned into a general purpose support module, published for download? Then the next one facing a similar task /will/ have a simple (or at least simpler) solution available. I have, of course, no idea whether this is feasible, as you didn't state how the strings are determined dynamically (for instance from which data). One way to configure such a generic device support could be to specify the name of a subroutine that gets called during initialization, gets the record instance as argument, and is responsible for setting the string values (and maybe also other items such as state severities and raw values).

This may be related to your problem or not, but I have often wished for something like "application level menu definitions". The main problem is that the existing dbd level menu definitions can only be used statically in record type definitions for fields of type DBF_MENU, but not for DBF_ENUM fields, i.e. not to provide the enum strings for (mb)bo/i records. If there were a way to allow this, e.g. by adding some extra field to these record types and appropriate support code, then similar records could (re-)use the same string definitions. More importantly, the generated C-language definitions could be used in sequencer programs, making interaction between these programs and the database a lot less brittle. Things would be almost perfect if one could, in addition, specify menu definitions in the *db* file, so that they can be easier maintained in lockstep with db and sequencer programs.

Cheers
Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System