Experimental Physics and
Industrial Control System

[email protected] (Bill Brown) · Tue, 6 Dec 94 09:08:56 PST

WARNING - This message is too long and this stuff may be too LBL/ALS specific
for many members of this list.  Or not.  Your milage may vary.

> From: lewis (Steve Lewis)
> To: [email protected]
> Subject: Re: pvget to an _output_ record
> 
> Bill--you haven't told them the best part--that there is the other
> hidden race condition where either EPICS has loaded the upload queue
> for a new AC and it hasn't been reflected in the CMM memory yet.

(Or even that the semaphores that protect this queue are "non-atomic."
Seems like a "non-atomic" semaphore guarding a queue is kind of like
a "non"semaphore" at the edge conditions, but I digress.)

Yes.  Well.  Actually I was trying to avoid that issue, or at least not
mention it publicly, lest I be thought of as too much of a damned fool
by those outlanders who do not understand that race conditions have been
declared to be a non-problem by the "Great Architect of the Historic
Control System."  Which is another way to say, "That which cannot be
cured must be endured."  Or something like that.
> 
> I agree with Dalesio that you might need a new record type; we could 
> also think about a very carefully crafted *asynchronous* device support
> to handle at least the above condition.  This might have to be combined
> with a complex new record that senses DMM writes.

(Shudder!!)
> 
> Whe don't you have a brainstorming session with you, Robb, me, maybe
> Carl Lionberger at LBL.

This is a good idea.  Anybody want to suggest a time/place?

> 			   Then we could have a repeat at Tucson
> (which is only about 5 working weeks away) to pick up any pointers
> from Dalesio, Kraimer, Hill, and a few others (like Winans).

I hadn't asked to go to the Tuscon meeting, altho I am certainly open to
the idea.  I'll have to talk to Joyce about it.  And of course, a fix is
wanted last week.  I better hurry.
> 
> This is like a motor with an encoder which can be turned by external
> means...and the shaft has a *lot* of windup.

Yup. Sort of.

[email protected] (Bob Dalesio) said (among other things!):

> I think you need a special record.
> It would monitor the Multibus memory either as part of periodic record
> processing or a device driver callback. This would update EPICS controllers
> with
> the value that was set through the other Multibus interface.
> You would need to put in an option for actions to take when an EPICS request is
> made in the middle of a Multibus change:
> Throw away new output if Multibus memory changed outside EPICS
> Override the Multibus value with the new EPICS value
> Look at both and pick the largest/smallest changes

My original thought was to have a task that sort of climbed down (up?) a
chain of CMM-type output records and put the "real values" from the CMM
into the pv entries.  This seems a rather risky way of doing business,
altho I suspect that if it runs at a lower priority than CA it should
avoid any race conditions more serious than those which already exist
in our system.  I've thought of using a similar task to initiate record
processing for input records, based on the way the input bits are handled
in the vmic2534 support (which I coppied from sombody elses' driver support
for another board).

Since the CMM apparently cannot issue interrupts to the ioc without
major changes to the CMM code which is 1) very timing-sensitive and
2) in eprom and for which we may no longer have devlopment tools,
this task has to be strictly a polling task.  And we (I) currently don't
have any feel for Multibus-I backplane-loading.  Which worries me.

Note that setting outputs in the "historical system" does not directly
affect the value of the variable stored in CMM memory, but involves sending
the new value via a message to the ILC, which in due time updates the value
in the CMM memory structure.

It may be that this type of behavior might be useful in other situations
(as opposed to the kludge that we're dealing with) so it might be worth
while going up into record suppport to provide the mechanism that I hoped
was there.  But I suspect that in order to do it cleanly there would be
enough global changes that it should be part of a major upgrade.  At the
very least it would add an entry ot the DSET list (I think it would be
done this way) which would point to the "read the output value" device
support function.  Hmmm - maybe it wouldn't be that bad - gotta look at
how record support works.

My own gut feeling on this is that adding this functionality to the CMM
interface is yet another stab at making a silk purse out of a sows ear.
Our time and efforts might be better spent making epics talk directly to
links of ILCs via the commercial vme/sbx interface of the type that we
bought.  The software design is at least a "3-beer" problem, and my guess
is that the implimentation is a number of "2-or-3-beer" problems, but I
think the resulting solution will be quite a bit more robust.

It is, however, probably more of a political issue than a technical
problem, so I will proceed to see what can be done in a "quick and dirty
yet as robust as possible way."

Disclaimer:  Any opinions are my own and have	    |
    nothing to do with the official policy or the   |  -bill
    management of L.B.L, who probably couldn't      |   [email protected]
    care less about employees who play with trains. |   Berkeley, CA

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System