Experimental Physics and
Industrial Control System

"Konrad, Martin" <[email protected]> · Thu, 29 Aug 2013 17:57:42 +0000

Hi Tim,
> Can you make that PV cycle again to 0 and then back to 1, and see if
> the 0-1 transition is noticed by soft device support?  One
> possibility is that the transition that should have sent DMOV to 1
> occurred too quickly, so that soft device support never noticed the
> PV being in the 0 state.
You're right: If I do a

caput test:doneMoving_ 0; caput test:doneMoving_ 1

the soft motors go back to DMOV=1. So it probably doesn't get the short 0.

I ran some tests and can confirm that the soft motors get stuck with 
DMOV=0 if there is no need for the hard motors to move the motors (at 
least with a much higher probability). I tried setting DLY to 10 hoping 
that this would increase the pulse length to 10 seconds but it didn't 
help: The soft motors still got stuck :-(

> This is particularly likely to happen on Linux, which has a
> relatively sluggish task switch compared to vxWorks.  (Soft device
> support just puts a CA monitor on the PV to which DINP links.)
I'm not aware of the details of the CA implementation but I thought the 
idea of a subscription is that you don't miss any changes while you're 
subscribed... So is this a Channel Access limitation or can this happen 
inside the motor record? Is there some other way to get DMOV into DINP? 
I'm pretty much following the example from the Motor Record 
documentation here.

Thanks for your help,

Martin

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System