Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Thu, 29 Sep 2005 10:40:57 -0500

Did you have a look at my mail?

Most of my concerns are probably still valid.

Sorry to be out-of-sync on this one ...

Ralph

Marty Kraimer wrote:

I am really sorry. I made som major changes to the talk yesterday and

forgot to send a message to core-talk.

I will send it after Im answer this message.

The example now reads:

void collectSample={
processLink=[3] {
{pvname = “incA”; wait=true; block=false},
{pvname= “incB”; wait=true; block = true},
{pvname= “getSample”; wait=true; block=true}
}
}

I will agree that the names wait and block may not be correct. But

what to use?

Every word I think of is already overloaded. Note that the meaning is

wait - really means: When the link completes call a record support

supplied callback. The record will not be allowed to complete

processing until all outstanding callbacks have been called.

block - really means: Dont do any more processing of the record until

all outstanding wait callbacks have been called.

I am open to suggestion for good names.

Forget timout for a second. I am making changes that will allow the

timeout to be specified when a record instance is created. It will

appear in the dataStruct related to the record.

Marty.

P.S. A message to core-talk coming soon. Again sorry I did not send it

yesterday.

Marty Kraimer wrote:

Ralph Lange wrote:

So ... ... ... what about:

menu(LinkWait) {
choice(linkWaitNo,"no")
choice(linkWaitYes,"yes")
choice(linkWaitGroup,"group")
}

struct(ProcessLink) {
field(pvname,string) { link}
field(wait,menu(LinkWait))
field(delay,double64)
}

so that the example is:

void collectSample=processLink=[3] {
{pvname="incA”; wait=group},
{pvname="incB”; wait=group,delay=1.0},
{pvname="getSample”; wait=yes,delay=5.0}
}
}

Is this really better than wait and block?

Don't get me wrong - it actually does mean wait and block. I just

changed the syntax to be more comprehensive:

Your example is functionally equivalent to my example

incA wait=yes incA wait=group
incB wait=block incB wait=group
getSample wait=block getSample wait=yes

but in your case the syntax is assymetrical, so you can't e.g. swap the

incA and incB links. (It would change the grouping of links.)

For my suggestion links that are treated the same also are configured

the same. It is more obvious that incA and incB belong to a group of

links that are waited for in parallel.

Again why have delay as part of every link. Note that with the new

style links they should be waiting until some physical "thing" is

done. Specifying a delay says "I think maybe this will be enough time

for X to complete".

Let the experimenter create a set of records that dont complete until

X really completes.

I was just thinking that extending the general functionality of links in

such way would make the seq record obsolete. But if you don't like it -

just ignore it. My main issue is a more comprehensive "grouping" of

links I mentioned above.

Ralph

Marty Kraimer wrote:

Ralph Lange wrote:

So ... ... ... what about:

menu(LinkWait) {
choice(linkWaitNo,"no")
choice(linkWaitYes,"yes")
choice(linkWaitGroup,"group")
}

struct(ProcessLink) {
field(pvname,string) { link}
field(wait,menu(LinkWait))
field(delay,double64)
}

so that the example is:

void collectSample=processLink=[3] {
{pvname="incA”; wait=group},
{pvname="incB”; wait=group,delay=1.0},
{pvname="getSample”; wait=yes,delay=5.0}
}
}

Is this really better than wait and block?

Don't get me wrong - it actually does mean wait and block. I just
changed the syntax to be more comprehensive:

Your example                 is functionally equivalent to my example

incA wait=yes                incA wait=group
incB wait=block              incB wait=group
getSample wait=block         getSample wait=yes

but in your case the syntax is assymetrical, so you can't e.g. swap the
incA and incB links. (It would change the grouping of links.)
For my suggestion links that are treated the same also are configured
the same. It is more obvious that incA and incB belong to a group of
links that are waited for in parallel.

Again why have delay as part of every link. Note that with the new

style links they should be waiting until some physical "thing" is

done. Specifying a delay says "I think maybe this will be enough time

for X to complete".

Let the experimenter create a set of records that dont complete until

X really completes.

I was just thinking that extending the general functionality of links in
such way would make the seq record obsolete. But if you don't like it -
just ignore it. My main issue is a more comprehensive "grouping" of
links I mentioned above.

Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System