Re: RES: Pmac Slits

["giles.knap--- via Tech-talk" <tech-talk@aps.anl.gov>]

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 <davism50@msu.edu>
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 davism50@msu.edu
On 5/13/2019 3:49 AM, giles.knap@diamond.ac.uk 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 <davism50@msu.edu>
> 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 davism50@msu.edu
> 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 davism50@msu.edu
>> On 5/10/2019 9:43 AM, giles.knap@diamond.ac.uk 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: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov>
>>> on behalf of giles.knap--- via Tech-talk <tech-talk@aps.anl.gov>
>>> Sent: 09 May 2019 16:15:55
>>> To: George Nicolas Kontogiorgos; mark_a_davis@comcast.net; 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; mark_a_davis@comcast.net; 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: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov>
>>> on behalf of giles.knap--- via Tech-talk <tech-talk@aps.anl.gov>
>>> Sent: 09 May 2019 09:17
>>> To: George Nicolas Kontogiorgos; tech-talk@aps.anl.gov;
>>> mark_a_davis@comcast.net
>>> 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 <davism50@msu.edu>
>>> Sent: 08 May 2019 21:07
>>> To: Knap, Giles (DLSLtd,RAL,LSCI); George Nicolas Kontogiorgos;
>>> tech-talk@aps.anl.gov
>>> 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 davism50@msu.edu
>>> On 5/7/2019 3:18 AM, giles.knap@diamond.ac.uk 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 <davism50@msu.edu>
>>>> Sent: 03 May 2019 18:09:55
>>>> To: George Nicolas Kontogiorgos; Knap, Giles (DLSLtd,RAL,LSCI);
>>>> tech-talk@aps.anl.gov
>>>> 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 davism50@msu.edu
>>>> 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: giles.knap@diamond.ac.uk <giles.knap@diamond.ac.uk>
>>>>> Enviada em: terça-feira, 30 de abril de 2019 04:07
>>>>> Para: George Nicolas Kontogiorgos <george.kontogiorgos@lnls.br>;
>>>>> Davis, Mark <davism50@msu.edu>
>>>>> 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: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov>
>>>>> on behalf of Davis, Mark via Tech-talk <tech-talk@aps.anl.gov>
>>>>> Sent: 29 April 2019 18:31:52
>>>>> To: George Nicolas Kontogiorgos; tech-talk@aps.anl.gov
>>>>> 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
>>>>> davism50@msu.edu<mailto:davism50@msu.edu>
>>>>> On 4/29/2019 7:30 AM, George Nicolas Kontogiorgos wrote:
>>>>> Hello Davis!
>>>>>
>>>>> I am George and I and @Luciano Carneiro
>>>>> Guedes<mailto:luciano.guedes@lnls.br> 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
>>>>>
>>>>>
>


-- 
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