Experimental Physics and
Industrial Control System

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

void collectSample={

    processLink=[3] {

        {pvname = “incA”;      parallel=true;  wait=true},

        {pvname = “incB”;      parallel=false; wait=true},

        {pvname = “getSample”; parallel=false; wait=true}

    }

}

void collectSample={

    processLink=[3] {

        {pvname = “incA”;      wait=no},

        {pvname = “incB”;      wait=completion},

        {pvname = “getSample”; wait=completion}

    }

}

void collectSample={

    processLink=[3] {

        {pvname = “incA”;      wait=no},

        {pvname = “incB”;      wait=2.5},

        {pvname = “getSample”; wait=completion}

    }

}

Ralph Lange wrote:

Marty Kraimer wrote:

o line 6/12: Logical: line 12 says incB processed in
parallel with incA, while parallel has been set to "false"
in line 6.

This is correct. incA has parallel true which means it is OK to start

something else. In this case it neans incB.

incB has paralley false which means dont do anthing else until incB

completes.

Hm. I understand the mechanism, but I find the syntax, semantics or

terms not very comprehensive, if not even misleading.

Your semantics slide says:

Parallel – If yes then this link can be processed in parallel with

other links

But looking at your example:

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

I agree that parallel is confusing.

I can see that incB has parallel set to false, but will indeed be

processed in parallel (with incA).

In other words, using this syntax setting parallel to false will stop

the /next/ link from being processed in parallel, not this link. I

fear users will keep making mistakes forever because they don't

remember if setting parallel changes this or the next link's behaviour.

What about changing the syntax a bit, so that your example reads:

void collectSample={
processLink=[3] {
{pvname = “incA”; wait=no},
{pvname = “incB”; wait=completion},
{pvname = “getSample”; wait=completion}
}
}

See below. The "slight" syntax change does require some changes

I would find this a lot more obvious - does it collide with the use of

the wait keyword in non-process links? Not necessarily, I think.

Well, one could even go one step further and include some

functionality of the seq record by allowing numbers:

void collectSample={
processLink=[3] {
{pvname = “incA”; wait=no},
{pvname = “incB”; wait=2.5},
{pvname = “getSample”; wait=completion}
}
}

This would lead to MAJOR problems. What is the type for wait? But see below

which would fire off incA, incB, and then getSample after waiting for

2.5 seconds, regardless of incB's process state, finally wait for

getSample to complete.

What do you think?

http://www.aps.anl.gov/epics/wiki/index.php/V4_DB_RecordCommon
defines MonitorLink, InputLink, OutputLink, ProcessLink.

Lets just look at ProcessLink since InputLink and OutputLink are similar

since they all have a field parallel

struct(ProcessLink) {
field(pvname,string) { link}
field(parallel,bool)
field(wait,bool)
}

Perhaps this should be changed to

menu(LinkWait) {
choice(linkWaitNo,"no")
choice(linkWaitYes,"yes")
choice(linkWaitBlock,"block")
}

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

Then

void collectSample={
processLink=[3] {
{pvname = “incA”; wait=yes,timeout=2.5},
{pvname = “incB”; wait=block,timeout=2.5},
{pvname = “getSample”; wait=block,timeout=5.0}
}
}

Thoughts?

Marty

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System