GP-307 read errors

[dohnarms]

For years now, the GP-307 support in vac would every once in a while stop working for a read, then come back later. In the iocConsole logs, there are messages of bad values read. I've suspected that the asyn support is sending a new command too fast after receiving the message form the last one.

I've run into another instance where the value would never read correctly at all. I added asyn flags to see the output, and the record started working normally. I assume that the slowing down of the processing due to the debug information was enough time between the read and wrinitg the next command.

I think that a GP-307 specific delay of some value needs to be added in the command loop.

[MarkRivers]

Is this on vxWorks? If so the debugging can indeed slow it down printing to the console. If not vxWorks then debugging should not slow it down significantly.

[dohnarms]

It was on vxWorks. I've seen the issue when the vxWorks IOC uses the IP module as well as uses a Moxa on the network. Here's an example from one using a Moxa, where the value sometimes updates:

2021/06/19 18:26:36.582 devVacSen::writeRead 29idb:VS12D pasynOctet->read, status=1, error=164.54.118.12:4001 timeout: S_errno_EWOULDBLOCK
2021/06/19 18:26:36.582 devVacSen::callback 29idb:VS12D Read reply too small/too large =0

This sort of thing went away for that other record when I had the debugging info started.