Hi Matt,
We have 17 Newport XPS units on the beamlines at APS sector 13. They are a mix of XPS-C8, XPS-Q8, and XPS-D8. I suspect the issue you are describe affects all models.
I have never heard reports of the problem you describe. It would most likely be discovered when doing a data collection step scan, where it is important for the motor to actually arrive at its destination before collecting the counters.
Just looked at the startup scripts for our XPS units, and 5 of the 17 call XPSEnableMovingMode in their startup script. Those 5 are the units that are most commonly running
step scans. For other units we are typically just doing positioning, not scanning, or we are running trajectory scans, not step scans.
Mark
From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of
Pearson, Matthew via Tech-talk
Sent: Friday, November 18, 2022 10:49 AM
To: tech-talk at aps.anl.gov
Subject: possible race condition in Newport XPS-Q8
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