Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Thu, 8 Aug 2013 18:59:42 +0000

Ron,

What you said is not correct.  The Model 3 simulation driver is configured with the commands "motorSimCreateController" and "motorSimConfigAxis".  The source code is in motorSimDriver.cpp.

The Model 2 simulation driver is configured with the command "motorSimCreate".  The source code is in drvMotorSim.c and motorSimRegister.cc.

Clearly Konrad is using the Model 2 (phase 2 in your terminology) support, since he is using the command "motorSimCreate".  But you said the Model 2 driver has support for STUP.

Both Model 2 and Model 3 drivers use the same device support file, devMotorAsyn.c.  That device support does not modify the STUP field.  In fact the only C or C++ code in all of the motor package that modifies the STUP field is motorRecord.cc:

corvette:~/devel/motor/motorApp>find . -name '*.c*' -exec grep -i -H stup {} \;
./MotorSrc/motorRecord.cc: * .12 12-12-03 rls - Added status update field (STUP).
./MotorSrc/motorRecord.cc: * .13 12-23-03 rls - Prevent STUP from activating DLY or setting DMOV true.
./MotorSrc/motorRecord.cc: *                  - Avoid STUP errors from devices that do not have "GET_INFO"
./MotorSrc/motorRecord.cc: * .28 03-08-06 rls - Moved STUP processing to top of do_work() so that things
./MotorSrc/motorRecord.cc: * .44 02-28-08 rls - Prevent multiple LOAD_POS actions due to STUP's.
./MotorSrc/motorRecord.cc:        unsigned int M_STUP     :1;
./MotorSrc/motorRecord.cc:        else if (pmr->stup != motorSTUP_BUSY)
./MotorSrc/motorRecord.cc:                    else if (pmr->stup != motorSTUP_ON && pmr->mip != MIP_DONE)
./MotorSrc/motorRecord.cc:    if (process_reason == CALLBACK_DATA && pmr->stup == motorSTUP_BUSY)
./MotorSrc/motorRecord.cc:        pmr->stup = motorSTUP_OFF;
./MotorSrc/motorRecord.cc:        MARK_AUX(M_STUP);
./MotorSrc/motorRecord.cc:    if (pmr->stup == motorSTUP_ON)
./MotorSrc/motorRecord.cc:        pmr->stup = motorSTUP_BUSY;
./MotorSrc/motorRecord.cc:        MARK_AUX(M_STUP);
./MotorSrc/motorRecord.cc:            pmr->stup = motorSTUP_OFF;
./MotorSrc/motorRecord.cc:    else if (proc_ind == NOTHING_DONE && pmr->stup == motorSTUP_OFF)
./MotorSrc/motorRecord.cc:        pmr->stup = motorSTUP_BUSY;
./MotorSrc/motorRecord.cc:        MARK_AUX(M_STUP);
./MotorSrc/motorRecord.cc:            pmr->stup = motorSTUP_OFF;
./MotorSrc/motorRecord.cc:            case motorRecordSTUP:
./MotorSrc/motorRecord.cc:                if (pmr->stup != motorSTUP_OFF)
./MotorSrc/motorRecord.cc:    case motorRecordSTUP:
./MotorSrc/motorRecord.cc:        if (pmr->stup != motorSTUP_ON)
./MotorSrc/motorRecord.cc:            pmr->stup = motorSTUP_OFF;
./MotorSrc/motorRecord.cc:            db_post_events(pmr, &pmr->stup, DBE_VAL_LOG);
./MotorSrc/motorRecord.cc:    if ((local_mask = monitor_mask | (MARKED_AUX(M_STUP) ? DBE_VAL_LOG : 0)))

So what is device support/driver doing wrong that STUP is getting stuck with the value BUSY?

To answer Konrad's question more directly, the STUP field is generally not needed with the Model 2 and Model 3 drivers because they periodically poll even when motors are not moving.  They thus cause the motor record to update status changes (encoders, limits, etc.) without needed to use STUP.  Note however, that motor limits are only reflected in the MSTA field, not in the LLM and HLM fields, as discussed in another recent tech-talk thread.

Mark

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Ron Sluiter
Sent: Thursday, August 08, 2013 1:28 PM
To: Konrad, Martin
Cc: [email protected]
Subject: Re: motorRecord simulation & STUP field

Hello Martin,

I don't know the details, but I suspect that the asyn motor phase 3
device/driver model (which I believe "motorSimCreate" is) lacks support
for the Status Update (STUP) motor record field.

The asyn motor phase 2 simulator (see motorSimSupport.dbd) has
support for STUP; see motorAxisforceCallback() in MotorSimSrc/drvMotorSim.c

Ron

On 8/8/2013 12:47 PM, Konrad, Martin wrote:
> Hi,
> I came across the following issue while using motor record with
> DTYP="asynMotor". If I request a status update by
>
> $ caput test.STUP 1
>
> the field seems to stay in state BUSY forever:
>
> $ camonitor motorSim:test0.STUP
> test.STUP            2013-08-08 13:31:58.426150 OFF
> test.STUP            2013-08-08 13:31:58.426150 ON
> test.STUP            2013-08-08 13:32:47.299463 BUSY
>
> I guess that's not the intended behavior. Here is my database file
> (pretty much the example):
>
> record(motor,"test")
> {
>     field(DESC,"Motor Simulation test")
>     field(DTYP, "asynMotor")
>     field(VELO,"1")
>     field(VBAS,"0")
>     field(VMAX,"1")
>     field(HVEL,"1")
>     field(ACCL,"1")
>     field(BDST,"0.01")
>     field(BVEL,"0.1")
>     field(BACC,"0.1")
>     field(OUT,"@asyn(sim1,1)")
>     field(MRES,"0.001")
>     field(PREC,"5")
>     field(EGU,"mm")
>     field(DHLM,"30")
>     field(DLLM,"-30")
> }
>
> In st.cmd I have:
> motorSimCreate( 0, 0, -22000, 42000, 10000, 1, 2 )
> drvAsynMotorConfigure("sim1", "motorSim", 0, 2)
>
> Is the STUP field supposed to work with this device support?
>
> Regards,
>
> Martin

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System