Experimental Physics and
Industrial Control System

<[email protected]> · Wed, 3 Nov 2010 09:17:35 +0000

Yes, I agree with Till. Any mechanism which requires the client to
buffer a number of monitors for each subscription and then compare
timestamps is too difficult for the average client. What happens if you
get two events with the same timestamp?

We use this, for example, to recover the state of a system after a
ca_put_callback. I actually think it works virtually all the time
(primarily because VxWorks seems to be better than Solaris or Linux). I
am happy for the mechanism to break if the event queue overflows, but I
would like a client's event queue on the server to be a single
time-ordered FIFO queue, rather than a collection of queue's. However,
the details are probably a bit of a devil.

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Till Straumann
Sent: 02 November 2010 23:54
To: [email protected]
Subject: Re: monitors received out of order

That's an idea but requires a lot of bookkeeping by the application
for supporting something that could be of broader interest.

I could imagine EPICS' subscription mechanism being enhanced with
a feature that lets you subscribe to a set of PVs and then
be notified when all members of the set have updated.

FWIW
-- Till

On 11/02/2010 04:39 PM, Ben Franksen wrote:
> On Dienstag, 2. November 2010, [email protected] wrote:
>> I am not sure what to do about it now, but I definitely have a
>> frequent requirement to get a coherent set of data from a server. Up
>> till now, I have monitored everything and then taken a snapshot
>> whenever I got a monitor from the last item in a processing chain
>> (which I have ensured always updates whenever the chain processes).
>> This has seemed to work with VxWorks servers. I would like to still
>> be able to achieve the same effect. How else can I do this?
>
> I think there is one reliable way that should work, although I have
not
> tested it. Please correct me if I am making wrong assumptions.
>
> The idea is that all the records in your set use TSEL to point to
> the 'start' record of your processing 'queue'. If the records in your
> set are linked via FLNK, they now should all exactly agree on their
> timestamp for one processing run. Then, in your client, you can group
> events according to timestamp, i.e. you first wait for an event with a
> new timestamp, remember it, and then wait until all the other slots in
> your set have been filled by subsequent events with the same
timestamp.
>
> If your event groups are not clearly separated in time, i.e. different
> event groups may overlap, you can add a small queue (2 or 3 elements)
> of PV sets to be filled. Then the event handler can put values into
the
> right bucket (queue element) according to timestamp.
>
> Cheers
> Ben

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System