Experimental Physics and
Industrial Control System

"Davis, Mark via Tech-talk" <[email protected]> · Wed, 15 May 2019 18:26:13 +0000

Hi Giles,

Thanks again for all your help and time.  Your responses have already 
saved me a lot of effort.

What I have found out since my last message (and a couple more questions):

The reason there was a difference between the setpoints I wrote to one 
of the motor records and the value sent by the driver was that I somehow 
ended up with a non-0 value in the OFF(set) field for one of the records 
(oops!)  So that minor mystery has been resolved.

Regarding the resetting of the setpoints: This was occuring every time I 
changed a setpoint for one of the axis motor records , even when I left 
the amplifiers enabled all the time.

To figure out what was causing this, I started with the function you 
mentioned and branched out from there.  Eventually I found that the 
problem is in pmacHardwarePower code:
    * The name o f PMAC_STATUS1_OPEN_LOOP  should be changed to 
PMAC_STATUS1_CLOSED_LOOP (in the .cpp and .h files).  I am guessing the 
logic for this bit is reversed compared to the Turbo models.
    * The method pmacHardwarePower::parseAxisStatus() was not setting 
the power_ value in the axStatus struct.  To fix this, I added the 
following line:
             axStatus.power_ = ((axStatus.status24Bit1_ & 
PMAC_STATUS1_CLOSED_LOOP));

This cures the root problem and results in what is apparently the 
intended behavior.

However:  This still means that the amplifiers must always be enabled 
and closed-loop control enabled.  If that is not done, the next movement 
will be preceded by commands to change the current setpoint for each 
axis to the latest readbacks, even if the most recent movement completes 
normally and the readback did not change at all.

Which means the practice of disabling the amps between moves will result 
in some 'creeping' of any axis whose setpoint is not changed while those 
for the other axes were changed.  The only way I can think of to avoid 
this while also "effectively" disabling the amplifiers would be to 
change the holding current to something really small (as I believe 
someone else was suggesting in an earlier post).

I don't know the details of what this behavior was meant to address, but 
I would think that the simplest way to avoid this issue would be to add 
support for an error/threshold setting for each axis. Regardless of 
whether or not the amplifier or closed-loop control was disabled for a 
motor (or probably any other events it checks for), as long as the 
difference between the last setpoint and readback does not exceed the 
specified threshold, there would be no need for the driver to reset the 
setpoint for that axis.  This would avoid the problem of 'creeping' 
setpoints caused by unnecessary resetting of the setpoints for axes.  I 
expect this would work as well for the cases this practice was meant to 
address just as well as (and perhaps more simply) then keeping track of 
changes in the status between new move commands.

Regarding the problem I mentioned before about the initial values for 
the motor records after an IOC restart not always being correct.  After 
I bit more experimentation, I discovered the following:
     * It is the setpoint for the Gap axis motor record that is affected
     * The incorrect values appear to = the correct value *  10000
     * Once in a while it does have the correct value after a restart

That 10000 multiplier seems rather suspicious.  Is this by chance the 
default setting for the value set by the pmacSetCoordStepsPerUnit() 
function?  If so, might this be a timing issue, where the driver reads 
the Q8x value from the controller and (usually) computes the value to 
post to the motor record before this call occurs in the startup script?

One more question I have about the startup script:  What is the purpose 
of the pmacCreateCsGroup() and pmacCsGroupAddAxis() functions?  They 
don't seem to have any effect on my (rather basic) configuration for 
slit drives (adding/removing them from my startup script doesn't appear 
to have any effect).  Are these needed for delayed motion and/or 
trajectory scans?

Mark

Mark Davis NSCL/FRIB Control Systems Software Engineer [email protected]
On 5/15/2019 3:28 AM, [email protected] wrote:
> Hi Mark,
>
>
> First, we have not talked about MRES. I assume from your kinematics that you are using axis scaling and that this matches your motor record MRES. (I assume that because there was no multiplier in the kinematic to convert between EGUs and counts).
>
>
> It is possible that your first issue is due to rounding, depending on your choice for scaling.
>
>
> The second problem sounds like we do still have an issue with the 'axis creep' code. If you are making your moves with enough delay that your kill PLC had kicked in between the two moves then this would be expected behaviour. Kill is one of the conditions that cause the code to copy the current position to a motor, it is a safety feature because we can't guarantee where the motor is once it is killed.
>
>
> If you are not killing the axis between moves then this implies the positions reset is happening incorrectly. If you are able to debug the code then you could look at the function makeCSDemandsConsistent in pmacController class. This is where the copy of current positions occurs and you would need to discover why the flags it relies on are being set.
>
>
> regards,
>
> giles.
>
> ________________________________
> From: Davis, Mark <[email protected]>
> Sent: 14 May 2019 21:15:55
> To: Knap, Giles (DLSLtd,RAL,LSCI); George Nicolas Kontogiorgos; Greer, Alan (OBS,RAL,DIA); Tech Talk
> Subject: Re: RES: Pmac Slits
>
> Hi Giles,
>
> Thanks for the help.
>
> I changed it to use the forward and reverse kinematic definitions
> (although I assume the first line in the FORWARD one should specify that
> A and B are used, rather than X and Y).  It now works (mostly) as expected.
>
> There are still two things (related to the axes setpoints) that I find
> confusing.
>
> When I change the setpoint for an axis, why is it sending a value that
> is mearly CLOSE to the requested value, rather than EXACTLY the
> requested value?  At present, the value sent is generally off by
> anywhere from 0.5 to 3.5 encoder counts.  If the driver is remembering
> the last demanded positions to avoid 'axis creep', and none of the
> things you mentioned occur (not homed, no limit triggered, no errors,
> etc., since the last move - I even tried leaving the amplifiers
> enabled), I can think of no reason why it would alter the value the user
> entered before sending it.
>
> In addition, each time I change the setpoint for an axis, the driver is
> changing the setpoint for all the axes to the current reading for that
> axis.  This seems like a really good way to generate 'axis creep'.  In
> fact, I just tried doing a dozen or so changes to just the center axis,
> and the error on the gap setting slowly crept up to about 8 counts.  Not
> a lot, but I would guess that if an operator was using a knob to tune
> (generating a continuous stream of small changes to one axis), the creep
> could cause the error to get much larger much faster.
>
> Mark
>
>
> Mark Davis NSCL/FRIB Control Systems Software Engineer [email protected]
> On 5/14/2019 11:10 AM, [email protected] wrote:
>> Hi Mark,
>>
>>
>> It turns out that I did not introduce a new bug. In fact, I had some problems with the example coordinate system kinematics and the issue looked similar to yours.
>>
>>
>> I discovered that the approach to defining the kinematics is causing your problem.
>>
>>
>> I have re-written your kinematics as follows and these then behave correctly:
>>
>> &1
>>
>> OPEN FORWARD
>>      KinAxisUsed = KinEnaAxisX + KinEnaAxisY;
>>
>>       // B is the slit gap (motor 1 is on the - side of the centre)
>>       KinPosAxisB=(KinPosMotor2-KinPosMotor1)
>>       // A is the slit centre
>>       KinPosAxisA=KinPosMotor1+KinPosAxisB/2
>> CLOSE
>>
>>
>> OPEN INVERSE
>>      // Motor1 is to the negative side of the slits
>>       KinPosMotor1=KinPosAxisA-KinPosAxisB/2
>>      // Motor 2 is to the positive side of the slits
>>       KinPosMotor2=KinPosAxisA+KinPosAxisB/2
>> CLOSE
>>
>> The above file should be in the folder 'Kinematics Routines' and the axis definitions should now be:
>>
>> &1
>> #1->I
>> #2->I
>>
>>
>> It turns out that at present, our driver cannot support the calculated axis mappings that you used in your coordinate system motors. Only the form #1->A or #1->I is supported. I previously thought that this only affected trajectory scans but you have noticed an additional effect.
>>
>>
>> The driver goes to a huge amount of effort to avoid 'axis creep' when doing sequential coordinate system moves. This involves caching the last demanded position of all of the motors. But we also have to know when to reset the cache when motors are not at the positions they were last asked to go to (hit limits, following error, kill, stop, homed etc. since the last move). The code that does this cannot cope with calculated mappings, I will look into fixing this but it may be non-trivial.
>>
>>
>>
>> giles.
>>
>> ________________________________
>> From: Davis, Mark <[email protected]>
>> Sent: 13 May 2019 14:01:19
>> To: Knap, Giles (DLSLtd,RAL,LSCI); George Nicolas Kontogiorgos; Greer, Alan (OBS,RAL,DIA); Tech Talk
>> Subject: Re: RES: Pmac Slits
>>
>> Hi Giles,
>>
>> My CS definition and readback update PLC:
>>
>>
>> //----- coordinate systems.pmh ----- 05/01/19 -----(04/11/19)-----
>>
>> undefine        // clears def for cur addressed CS
>> undefine all    // clears all axis defs of all CS
>>
>> // CS1:  Slit drives
>> //    A = Center
>> //    B = Gap
>>
>> &1            // address CS 1
>> #1->A-0.5B   // Motor[1].DesPos = Center - Gap/2
>> #2->A+0.5B   // Motor[2].DesPos = Center + Gap/2
>>
>>
>> //----- update_CS_readings.plc ----- 05/01/19 -----(05/01/19)-----
>>
>> open plc 10 //update_CS_readings
>>
>>      Ldata.Coord = 1;
>>
>>      // From coordinate systems.pmh:
>>      // axis A = Center, axis B = Gap
>>      //#1->A-0.5B
>>      //#2->A+0.5B
>>
>>      // Compute current Gap value
>>      local mtr1Pos = Motor[1].Pos - Motor[1].HomePos;
>>      local mtr2Pos = Motor[2].Pos - Motor[2].HomePos;
>>
>>      // CS values that the EPICS powerPMAC driver reads the cur axes
>> values from
>>      #define Center Q81   // Axis A
>>      #define Gap    Q82   // Axis B
>>
>>      Gap = mtr2Pos - mtr1Pos;
>>      Center = mtr1Pos + Gap * 0.5;
>>
>> close
>>
>>
>> Mark
>>
>>
>> Mark Davis NSCL/FRIB Control Systems Software Engineer [email protected]
>> On 5/13/2019 3:49 AM, [email protected] wrote:
>>> Mark,
>>>
>>>
>>> Thanks for the feedback. I can confirm that I have introduced the new bug you describe (and that my system tests failed to pick it up!).
>>>
>>>
>>> Investigating now.
>>>
>>>
>>> I don't see the problem with initial values of coordinate system axes. Please, can you send me your kinematics and readback PLC for gap and centre?
>>>
>>>
>>> Cheers,
>>>
>>> giles.
>>>
>>> ________________________________
>>> From: Davis, Mark <[email protected]>
>>> Sent: 10 May 2019 18:37:49
>>> To: Knap, Giles (DLSLtd,RAL,LSCI); George Nicolas Kontogiorgos; Greer, Alan (OBS,RAL,DIA); Tech Talk
>>> Subject: Re: RES: Pmac Slits
>>>
>>> Almost forgot:  The initial value of the motor record for the gap axis
>>> is also still nonsense.
>>>
>>> Mark
>>>
>>>
>>> Mark Davis NSCL/FRIB Control Systems Software Engineer [email protected]
>>> On 5/10/2019 1:31 PM, Mark Davis wrote:
>>>> Hi Giles,
>>>>
>>>> I tried the 2-4-10 version.  It does indeed fix the problem with the
>>>> DMOV state for the CS axes motor records, but it is causing a new
>>>> problem:
>>>>
>>>> When I change the setting for the motor record for the gap axis, it
>>>> works fine.  But when I change the setting for the center axis, it
>>>> changes the gap value as well.  This much was working fine in version
>>>> 2-1 (which is the one I have been using until this test).
>>>>
>>>> Looking at the values of the Q71 and Q72 variables, I can see that in
>>>> the first case, only one of the values change, but in the second both
>>>> values are changing (which of course it shouldn't do, since I didn't
>>>> change the value for the corresponding axis).
>>>>
>>>> Mark
>>>>
>>>>
>>>> Mark Davis NSCL/FRIB Control Systems Software Engineer [email protected]
>>>> On 5/10/2019 9:43 AM, [email protected] wrote:
>>>>> Mark, George,
>>>>>
>>>>>
>>>>> Please can you try the latest release
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dls-2Dcontrols_pmac_releases_tag_2-2D4-2D10&d=DwIFAw&c=nE__W8dFE-shTxStwXtp0A&r=D7ZiziuMQuq40HlGYOZPBg&m=8kPsz2FY3017RssIszO4L0jWjZeIhq9Gcd4dq3OpZzE&s=2I6nTnRlqbUzOPwzMf4peJcYABUBoIjK4TulCBESvmU&e=
>>>>>
>>>>> This has improvements to the handling of DMOV monitoring of
>>>>> coordinate system motors
>>>>>
>>>>> It will hopefully fix your issues.
>>>>>
>>>>> ________________________________
>>>>> From: [email protected] <[email protected]>
>>>>> on behalf of giles.knap--- via Tech-talk <[email protected]>
>>>>> Sent: 09 May 2019 16:15:55
>>>>> To: George Nicolas Kontogiorgos; [email protected]; Tech Talk;
>>>>> Greer, Alan (OBS,RAL,DIA)
>>>>> Subject: Re: RES: Pmac Slits
>>>>>
>>>>> Mark,
>>>>>
>>>>>
>>>>> My idea of adding to PROG 10 is no use, unfortunately.
>>>>>
>>>>>
>>>>> The motor record does not let you send demands while the DMOV=0, so
>>>>> it does not help.
>>>>>
>>>>>
>>>>> I hope to get a fix out tomorrow.
>>>>>
>>>>>
>>>>>
>>>>> ________________________________
>>>>> From: Knap, Giles (DLSLtd,RAL,LSCI)
>>>>> Sent: 09 May 2019 13:38:09
>>>>> To: George Nicolas Kontogiorgos; [email protected]; Knap,
>>>>> Giles (DLSLtd,RAL,LSCI); Tech Talk; Greer, Alan (OBS,RAL,DIA)
>>>>> Subject: Re: RES: Pmac Slits
>>>>>
>>>>>
>>>>> Mark,
>>>>>
>>>>>
>>>>> There is indeed an issue with this feature on power pmac. The command
>>>>> to enable motors in a CS varies between turbo and power pmacs (turbo:
>>>>> &2e , power: &2enable), I had not noticed this and did not previously
>>>>> have a system test for moving CS motors after a kill.
>>>>>
>>>>>
>>>>> I will be pushing a fix soon but in the meantime, you could quickly
>>>>> fix the issue by adding the single command 'enable' to the beginning
>>>>> of your PROG 10.
>>>>>
>>>>>
>>>>> George,
>>>>>
>>>>>
>>>>> I've looked at your PR and I do not think it addresses the issue of
>>>>> resetting DMOV for coordinate systems. I will update the PR with
>>>>> details.
>>>>>
>>>>>
>>>>> Please can you try an experiment to better understand your problem:
>>>>>
>>>>>
>>>>> Please turn off your IOC and run up the Delta Tau IDE. Use the jog
>>>>> ribbon to make some moves of your coordinate system axes.
>>>>>
>>>>>
>>>>> When you move the axes, please inspect the Status pane and look at
>>>>> your coordinate system status field 'Coord[x].InPos'. Can you let me
>>>>> know if you see this value changing as you move axes withing the
>>>>> Coordinate System?
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> giles.
>>>>>
>>>>>
>>>>> ________________________________
>>>>> From: [email protected] <[email protected]>
>>>>> on behalf of giles.knap--- via Tech-talk <[email protected]>
>>>>> Sent: 09 May 2019 09:17
>>>>> To: George Nicolas Kontogiorgos; [email protected];
>>>>> [email protected]
>>>>> Subject: Re: RES: Pmac Slits
>>>>>
>>>>> Mark,
>>>>>
>>>>>
>>>>> I have just noticed that the feature of enabling before moving
>>>>> coordinate system motors has not been tested on power pmac and there
>>>>> is a reasonable chance there is an issue here.
>>>>>
>>>>>
>>>>> I'm looking at the DMOV problem for George today and will also
>>>>> investigate this.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> giles.
>>>>>
>>>>>
>>>>> ________________________________
>>>>> From: Davis, Mark <[email protected]>
>>>>> Sent: 08 May 2019 21:07
>>>>> To: Knap, Giles (DLSLtd,RAL,LSCI); George Nicolas Kontogiorgos;
>>>>> [email protected]
>>>>> Subject: Re: RES: Pmac Slits
>>>>>
>>>>> HI Giles,
>>>>>
>>>>> Your description sounds just like my setup (a PLC that "kills" the
>>>>> amplifiers for motors 5 seconds after they stop moving), and this works
>>>>> fine for control of individual motors.  But not for coordinated motion.
>>>>>
>>>>> If I comment out the kill command from my PLC code and enable the motors
>>>>> manually using the "enable" command, then the coordination motion works
>>>>> fine.  If I let the PLC kill the amplifiers and then stop it from
>>>>> running (or disable most of its logic by setting a flag I included for
>>>>> doing so), then the coordinated motion stops working until I manually
>>>>> issue the "enable" command for my CS.
>>>>>
>>>>> Has the driver always issued an "enable" command before running a motion
>>>>> program, or was that added sometime in the last year?
>>>>>
>>>>> Is there any way to see the commands sent to the controller with any
>>>>> kind of context filtering?  Using the debug setting for the driver or
>>>>> the asyn trace commands is like opening the valve on a fire hose.
>>>>>
>>>>> Mark
>>>>>
>>>>>
>>>>>
>>>>> Mark Davis NSCL/FRIB Control Systems Software Engineer [email protected]
>>>>> On 5/7/2019 3:18 AM, [email protected] wrote:
>>>>>> Hi Mark,
>>>>>>
>>>>>>
>>>>>> That is good news.
>>>>>>
>>>>>>
>>>>>> re: disabling amplifiers: At Diamond we use a 'kill when idle' PLC
>>>>>> to kill motors that have been inactive for a configurable period.
>>>>>> When you move a motor or virtual motor, the pmac driver sends an
>>>>>> enable command before it does the move. Once it completes, the 'kill
>>>>>> when idle' will kick in and send a kill which disables the amplifier.
>>>>>>
>>>>>>
>>>>>> At present, this PLC is only written for turbo pmac but it should be
>>>>>> easy to translate to power pmac. See our template at
>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dls-2Dcontrols_pmacUtil_blob_master_pmacUtilApp_pmc_PLC7-5Fkill-5Fwhen-5Fidle.pmc&d=DwIFAw&c=nE__W8dFE-shTxStwXtp0A&r=D7ZiziuMQuq40HlGYOZPBg&m=OjUDRBkIQTQLgKctNECgv3s3td5kmyqhghBf3FNQcBA&s=RjgonIAvztoJoaaiRlhn17BqsXYywflmpPfuHukjdmU&e=
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> giles.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ________________________________
>>>>>> From: Davis, Mark <[email protected]>
>>>>>> Sent: 03 May 2019 18:09:55
>>>>>> To: George Nicolas Kontogiorgos; Knap, Giles (DLSLtd,RAL,LSCI);
>>>>>> [email protected]
>>>>>> Subject: Re: RES: Pmac Slits
>>>>>>
>>>>>> Hi Giles and George,
>>>>>>
>>>>>> Based on everyone's helpful input, I was able to get a really basic
>>>>>> coordination motion config working yesterday, which consists of:
>>>>>>
>>>>>> On the IOC:
>>>>>>          - 2 motor records for the actual drivers
>>>>>>          - 2 motor records for the CS axes (center and gap for a slit)
>>>>>> ON the Power Brick:
>>>>>>          - A CS definition providing the mapping between the CS axes
>>>>>> and the
>>>>>> motors
>>>>>>          - A motion program to process new settings for the center and
>>>>>> gap axes
>>>>>>          - A PLC program to update the readbacks for the center and gap
>>>>>> axes
>>>>>>
>>>>>> There are still a number of details I need to work on (like how to keep
>>>>>> the motor amplifiers disabled most the time but still enable them just
>>>>>> before the IOC sends the command to execute the motion program), but so
>>>>>> far the moving status values in all the motor records are doing what
>>>>>> they should.
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>>
>>>>>>
>>>>>> Mark Davis NSCL/FRIB Control Systems Software Engineer [email protected]
>>>>>> On 5/2/2019 2:05 PM, George Nicolas Kontogiorgos wrote:
>>>>>>> Hi Giles,
>>>>>>>
>>>>>>> I could solve the problem od DMOV not returning to stopped status
>>>>>>> by changing the condition on callback function on
>>>>>>> pmacCSController.cpp. There is a if that compare type with
>>>>>>> pmacMessageBroker::PMAC_PRE_FAST_READ (the values are 2 and 3
>>>>>>> respectively) and the result is false. It results that the code
>>>>>>> inside this if (which get the coordinate system status) is never
>>>>>>> executed. As consequence, EPICS can not get CS status and DMOV
>>>>>>> never come back to stopped state.
>>>>>>>
>>>>>>> To solve the problem I supposed that we are talking about a fast
>>>>>>> read, not pre fast read (the difference is that they have the same
>>>>>>> rate but variables on pre are read  first, according to comments on
>>>>>>> pmacMessageBroker.cpp) since the variable type has value 2.
>>>>>>>
>>>>>>> After this modification DMOV work fine, since status is being
>>>>>>> refreshed.
>>>>>>>
>>>>>>> I did a pull request on dls repo in order to fix this issue. Feel
>>>>>>> free to suggest better modifications.
>>>>>>>
>>>>>>> Hi Mark,
>>>>>>>
>>>>>>> After all this studies I figured out that DMOV or MOVN doesn't need
>>>>>>> to be mapped manually, this is made by program itself (the system
>>>>>>> polls the status).
>>>>>>>
>>>>>>> I could solve the problem of slits at all by Wayne method.
>>>>>>>
>>>>>>> Regards
>>>>>>> George
>>>>>>>
>>>>>>> -----Mensagem original-----
>>>>>>> De: [email protected] <[email protected]>
>>>>>>> Enviada em: terça-feira, 30 de abril de 2019 04:07
>>>>>>> Para: George Nicolas Kontogiorgos <[email protected]>;
>>>>>>> Davis, Mark <[email protected]>
>>>>>>> Assunto: Re: Pmac Slits
>>>>>>>
>>>>>>> I'm seeing this exact issue on my power clipper. It has started
>>>>>>> happening since I factory reset the configuration.
>>>>>>>
>>>>>>>
>>>>>>> I have yet to work out which setting(s) are responsible but intend
>>>>>>> to spend time on this next week.
>>>>>>>
>>>>>>> ________________________________
>>>>>>> From: [email protected] <[email protected]>
>>>>>>> on behalf of Davis, Mark via Tech-talk <[email protected]>
>>>>>>> Sent: 29 April 2019 18:31:52
>>>>>>> To: George Nicolas Kontogiorgos; [email protected]
>>>>>>> Subject: Re: Pmac Slits
>>>>>>>
>>>>>>> Hi George,
>>>>>>>
>>>>>>> I haven't yet had a chance to try a configuration like one Wayne
>>>>>>> described (and Giles helped me understand).  Hopefully I will have
>>>>>>> time this week to give it a try.
>>>>>>>
>>>>>>> The behavior you describe for the DMOV and MOVN does sound like an
>>>>>>> issue that needs to be addressed.
>>>>>>>
>>>>>>> Are you also using a Delta Tau Power Brick (or some other Power
>>>>>>> PMAC model) controller as I am?
>>>>>>>
>>>>>>> Regarding your Tech-Talk subscription:  I would expect that once
>>>>>>> you are subscribed, you should be able to include the Tech-Talk
>>>>>>> list email in your To or Reply-To list (we will see momentarily, as
>>>>>>> I included it in the To list for this email).
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>>>>>>
>>>>>>> Mark Davis NSCL/FRIB Control Systems Software Engineer
>>>>>>> [email protected]<mailto:[email protected]>
>>>>>>> On 4/29/2019 7:30 AM, George Nicolas Kontogiorgos wrote:
>>>>>>> Hello Davis!
>>>>>>>
>>>>>>> I am George and I and @Luciano Carneiro
>>>>>>> Guedes<mailto:[email protected]> are working with coordinated
>>>>>>> motion on a 2 motor slit controlled by PowerPMAC and integrated
>>>>>>> with EPICS (The same setup as you).
>>>>>>>
>>>>>>> I saw your message on EPICS
>>>>>>> techtalk<https://urldefense.proofpoint.com/v2/url?u=https-3A__epics.anl.gov_tech-2Dtalk_2019_msg00684.php&d=DwMFAg&c=nE__W8dFE-shTxStwXtp0A&r=D7ZiziuMQuq40HlGYOZPBg&m=k7CLCJno5gjAruO8gtDsAKM9ugfmt3N1wib_vy4Mcn8&s=TuASR5lFnez6KMJ0vYQrq8TzXXQvv2A_q-ps57L7SFg&e=>
>>>>>>> and I would like to know you if your setup is running well.
>>>>>>>
>>>>>>> Here we achieved  the point that we can drive a virtual motor using
>>>>>>> motor record as Wayne Lewis sad. The problem is that the DMOV (or
>>>>>>> MOVN) is not set to 1 (not moving) when all motors reach the
>>>>>>> setpoint specified by the kinematics.
>>>>>>>
>>>>>>> I could not reply the message on techtalk because I subscribed on
>>>>>>> it after you send those messages (and I don't know if it is
>>>>>>> possible to reply now.)
>>>>>>>
>>>>>>> Best regards
>>>>>>> George Nicolas Kontogiorgos
>>>>>>> Electrical Engineer
>>>>>>> Beamline Software Group (SOL)
>>>>>>> Brazilian Synchrotron Light Laboratory (LNLS)
>>>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lnls.cnpem.br&d=DwIFAw&c=nE__W8dFE-shTxStwXtp0A&r=D7ZiziuMQuq40HlGYOZPBg&m=rb2n3stwbYGCr-pSN_O8nBkdlvlL27qtR_1mA50Tie4&s=2ehNKztIJwNVKcs5qwU1cWwh-hYXxG5_PGOKQA2axyo&e=<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lnls.cnpem.br_&d=DwMFAg&c=nE__W8dFE-shTxStwXtp0A&r=D7ZiziuMQuq40HlGYOZPBg&m=k7CLCJno5gjAruO8gtDsAKM9ugfmt3N1wib_vy4Mcn8&s=bn2OpbndTqv8qG1bvTHojoFLoD_4u5TpWmPDvtkn--s&e=>
>>>>>>>
>>>>>>>
>>>>>>> Aviso Legal: Esta mensagem e seus anexos podem conter informações
>>>>>>> confidenciais e/ou de uso restrito. Observe atentamente seu
>>>>>>> conteúdo e considere eventual consulta ao remetente antes de
>>>>>>> copiá-la, divulgá-la ou distribuí-la. Se você recebeu esta mensagem
>>>>>>> por engano, por favor avise o remetente e apague-a imediatamente.
>>>>>>>
>>>>>>> Disclaimer: This email and its attachments may contain confidential
>>>>>>> and/or privileged information. Observe its content carefully and
>>>>>>> consider possible querying to the sender before copying, disclosing
>>>>>>> or distributing it. If you have received this email by mistake,
>>>>>>> please notify the sender and delete it immediately.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> This e-mail and any attachments may contain confidential, copyright
>>>>>>> and or privileged material, and are for the use of the intended
>>>>>>> addressee only. If you are not the intended addressee or an
>>>>>>> authorised recipient of the addressee please notify us of receipt
>>>>>>> by returning the e-mail and do not use, copy, retain, distribute or
>>>>>>> disclose the information in or attached to the e-mail.
>>>>>>> Any opinions expressed within this e-mail are those of the
>>>>>>> individual and not necessarily of Diamond Light Source Ltd.
>>>>>>> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
>>>>>>> attachments are free from viruses and we cannot accept liability
>>>>>>> for any damage which you may sustain as a result of software
>>>>>>> viruses which may be transmitted in or with the message.
>>>>>>> Diamond Light Source Limited (company no. 4375679). Registered in
>>>>>>> England and Wales with its registered office at Diamond House,
>>>>>>> Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11
>>>>>>> 0DE, United Kingdom
>>>>>>>
>>>>>>>
>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System