Experimental Physics and
Industrial Control System

 

Hi,

 

I don’t really work with these controllers anymore, but I looked into a problem on one of our beamlines yesterday involving a premature callback from a motor record move on one axis on a Newport XPS-Q8 controller, which I don’t recall seeing before.

 

The axis was requested to move using put_callback. The move() function in XPSAxis.cpp seemed to execute ok and the motorStatusDone parameter was set to zero (which was reflected in the motor record MSTA field). Then in the next poll of the controller we must have read the XPS axis group status to be ‘not moving’, because it immediately set motorStatusDone=1 and the callback completed. Then the motor started moving and completed the move normally.

 

So this seems like a race condition in the software on the XPS-Q8. We send a move command and then immediately read the status and it was incorrect. Has anyone seen this before on any flavor of XPS controller?

 

The server where this software is running is unusually heavily loaded, which may have exposed a race condition that has always been there.

 

Anyway, if anyone has seen this, have they tried using the ‘enableMovingMode’ shell function to change the way the ‘move done’ is reported? I suspect that might fix the issue as it waits for a response from the XPS ‘moveSocket_’ to determine ‘move done’, rather than polling the axis group status.

 

Cheers,

Matt