asynFloat64 never finishes processing in IOCTestFramework

[AdrianPotter]

This issue occurs with motorExtensions at commit 692e494.

• Get the commit of motorExtensions above
• Run the oscillatingCollimator tests in the IOC test framework
• Note that the tests fail

The tests above fail because the values for the set PVs are never pushed to the subsequent records. On inspection, the PACT field of PVs such as ANGLE:SP never return to 0. The workaround we used was to convert these to "Soft Channel"s in simulation mode at run time. Notably this causes exceptions to be output during the run of the collimator tests, although it does not cause a failure.

We tried setting the PVs in question into simulation mode with a suitable simulation output location but it did not improve the behaviour.

Another curious behaviour is that, after converting the records to Soft Channels, forward linking from ANGLE:SP to DIST:PART:SP still didn't work within the IOC Test Framework; the tests failed indicating the required values hadn't been forwarding. However, doing a caput from the command line worked fine and trigerred passing the value.

John nor I could explain away this behaviour. A working fix was eventually implemented for the oscillating collimator #2535 but we would like to understand why this occurred

[FreddieAkeroyd]

Other than taking a bit of time to build, might be interesting to see if this occurs with base 3.14

[DominicOram]

I have also seen this issue on asynInt records. It also appears that the value of SIML is not propagated to SIMM on these records.

[FreddieAkeroyd]

If device initialisation fails, PACT is often left at 1 by convention http://www.aps.anl.gov/epics/tech-talk/2014/msg00951.php

[FreddieAkeroyd]

Did you get an error from asyn about being unable to initialise the device? e.g. I can reporoduce the behaviour when I see

TE:NDW1548:SIMPLE:TEST devAsynFloat64::initCommon connectDevice failed

on ioc startup

[FreddieAkeroyd]

I wonder if using the asyn echo driver when starting in recsim would work? It may be that all you need for record initialisation to work is a driver connection that has initialised ok, of course any commands sent to this will not work properly but then we will be in recsim so it might not happen

[DominicOram]

Tested using an echo driver on Galil, didn't seem to work but that could be down to interactions with the motor simulation stuff?

[FreddieAkeroyd]

I think this is all a feature of how the Galil is started when in simulation mode and can be fixed - see #3064