Experimental Physics and
Industrial Control System

Thanks Mark. We only have 3 or 4 of the older XPS-C8 (which I think were upgraded to the Q8 motherboard), and these weren’t heavily used for step scanning. We have a new XPS-Q8 and XPS-D6 which is a heavy step scan application (and in addition a heavily loaded server where the IOC is running).

 

I’ll suggest to the team to try using XPSEnableMovingMode to see if that helps.

 

Cheers,

Matt

 

 

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

 

 

 

 

 

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