Experimental Physics and
Industrial Control System

Hi,

 

Some new thoughts about this issue. This new corner case, and the earlier one that we discussed in this thread both happen in the same IOC and we cannot reproduce the behavior anywhere else.

The IOC contains a lot of custom code and I now tend to think that the reason for these oddities is to be found in how this particular IOC is implemented.

 

I still would be happy to hear if there are any ideas where to start looking, but this does not look like an issue in the EPICS core, as I suspected for a while.

 

Timo

 

Hi,

 

Getting back to this old thread from May.

I mentioned a “corner case” in our meeting yesterday. We have stumbled on that again, I think.

We saw a case where pvmonitor and camonitor show different values for the same record – unless we explicitly point pvmonitor to the VAL field.

 

This matches with Andrew’s explanation below. I assume that waveform is one more of the “unusual” types?

 

Timo

 

Hi Timo,

 

@Andrew: I can't explain how your VAL field went from 0 to 1 above, I think you must have done a put to it (to trigger processing?). There should be no difference between what camonitor and pvmonitor actually show since they both use the same monitor mechanism; if you think you are seeing a difference, please run both camonitor and pvmonitor simultaneously and repeat what you were doing to demonstrate.

 

 

And in the simple example: indeed, there was a put into the sequence record (by me).

I was running camonitor and pvmonitor simultaneously but as there are no monitors on VAL change (even if the value actually changes), running them in parallel does not show a lot.

I think I just got confused by seeing the timestamp at put time on the other and timestamp at completion on the other side.

Ahh, yes puts to a record's VAL field will not (normally) result in a monitor being posted. The original assumption there was that when the record's process() routine is called it will update and post a monitor on the VAL field anyway, and we wouldn't want there to be 2 monitor events resulting from that put. Thus the code in dbAccess that normally posts a monitor after updating a field value will skip that for the VAL field (as long as it is marked pp(TRUE) and thus will trigger record processing).

The sequence record is one of the unusual types where that original assumption was wrong, and that's another reason why I think my suggested behavior change is worth doing.

- Andrew

-- 

Complexity is free, it's Simplicity that takes work.