Re: Recommendations for StreamDevice "architecture" flow

[Ralph Lange via Tech-talk <tech-talk at aps.anl.gov>]

My 2cts:

Technically, these are all valid.

Question is always: What does the protocol look like? What are you trying to achieve? Is the device well-behaved?

In general:

FLNK means: *now*, as in immediately after.

Same SCAN period means: in the same interval, not necessarily in the same order (unless you use the PHAS field).

Your device protocol specifies if you need to keep a specific order or not.

Use parameters:

Many devices have similar commands that only differ in one token. Push that token from the record link to a generic protocol.

Especially when doing %() redirections, it is useful to have the "device" part of the record name as a parameter to use in those redirections.

Another technique I have seen:

Have the individual records scanned by one or multiple soft events, and add an event record for each that is triggering the swarm. Advantage: no fixed linking, but still a single SCAN field that changes the period for many records. (Easy to change scan periods for parts of the interface depending on the situation.)

Also interesting:

For a complex but fixed-order configuration, put the whole configuration into a single protocol. Fetch any configurable values from other passive records using the %() redirection. Initially hard-coded values can later easily be made configurable that way.

In most cases, how the records are triggered is not the most important aspect of your interface, and neither the aspect that needs the most time to implement. StreamDevice drivers are following the 90/10 principle: getting things working and your commands implemented is the fast part. Getting your implementation to be robust (reboot both ends, pull cables at any moment) and having the error handling done right is the part that often gets frustrating.

Cheers,

~Ralph