Experimental Physics and
Industrial Control System

"Pearson, Matthew R." <[email protected]> · Tue, 17 Sep 2013 14:14:02 -0400

Hi Tim,

If there's no existing support, I'd recommend writing a new model 3 type driver. The amount of boiler plate code is not so much, and it will be easier to maintain in the future. There are a few example in the motor module:

motor mkp$ grep -r "public asynMotorController" *
motorApp/ACRSrc/ACRMotorDriver.h:class ACRController : public asynMotorController {
motorApp/AcsSrc/MCB4BDriver.h:class MCB4BController : public asynMotorController {
motorApp/ImsSrc/ImsMDrivePlusMotorController.h:class ImsMDrivePlusMotorController : public asynMotorController
motorApp/MicosSrc/SMChydraDriver.h:class SMChydraController : public asynMotorController {
motorApp/NewportSrc/AG_CONEX.h:class AG_CONEXController : public asynMotorController {
motorApp/NewportSrc/AG_UC.h:class AG_UCController : public asynMotorController {
motorApp/NewportSrc/HXPDriver.h:class HXPController : public asynMotorController {
motorApp/NewportSrc/SMC100Driver.h:class SMC100Controller : public asynMotorController {
motorApp/NewportSrc/XPSController.h:class XPSController : public asynMotorController {
motorApp/NPointSrc/C300MotorDriver.h:class C300Controller : public asynMotorController {
motorApp/OmsAsynSrc/omsBaseController.h:class omsBaseController : public asynMotorController {
motorApp/SmarActMCSSrc/smarActMCSMotorDriver.h:class SmarActMCSController : public asynMotorController

plus a few that the grep missed.

Basically you have to implement some of the abstract functions in the asynMotorController and asynMotorAxis classes. eg. move, stop, poll, etc.

Then write some code to provide shell functions to instantiate the objects. Normally this is done separately for the controller and the axes, but some drivers do it all in one shell function.

The SMC100Driver would be a good place to start. The XPSController and XPSAxis are one of the more complex drivers.

The main difference from a model 1 driver is that you won't need to write device support. You would make use of the motor record, and the 'asynMotor' device type. e.g.:

record(motor,"blah:1")
{
        field(DTYP,"asynMotor")
        field(OUT,"@asyn(SIM1,0)")
        field(MRES,"0.001")
        field(PREC,"4")
        field(EGU,"mm")
etc….

The OUT field specifies the Asyn port name (the name of the port that Asyn uses to call your driver functions) and Asyn address (an index used for the axis number).

Typically there would be a low level Asyn port used for the comms (created using drvAsynIPPort for example). This is passed into the driver so the driver knows how to talk to the comms bus. Or, you could pass an IP address into your driver so it acts as a wrapper for drvAsynIPPort.

You would also gain the ability to use other records (that have Asyn device support) to talk to the driver and/or the controller. Something that I find useful is to instantiate an asynRecord, and connect it to the Asyn low level comms port, and that can act as a debug record for sending arbitrary strings to the controller.

Finally, it will be much easier to extend the driver so it supports functionality that doesn't fit into the motor record interface (eg. controller wide functions, or more detailed axis status bits).

Cheers,
Matt

On Sep 17, 2013, at 1:12 PM, [email protected] wrote:

> Hi,
>  
> Does anyone have an EPICS motor record driver for the Newport 8742 picomotor controllers?
>  
> We were going to be using the trusty Newport NewFocus 8752 controllers for our project, which we’d got working nicely with the existing PMNC87xx driver, but sadly when we came to order more of them from Newport we were informed they’ve just been discontinued and are no longer manufactured.
>  
> The 8742 replacement uses a more recent command set and so doesn’t work with the 87xx driver.  If nobody’s already done it, we will probably have a go a modifying the existing 87xx driver, although I note this seems to use the older “model 1 “ asyn approach so I wonder if we’d be better off starting something like the Newport SMC100 “Model 3” driver instead? (We’ve never developed an EPICS asyn driver before so not too sure what the best approach would be).
>  
> Cheers
>  
> Tim Hayton
> Central Laser Facility
> Rutherford Appleton Lab
>  
> 
> -- 
> Scanned by iCritical.
> 
> 
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System