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://github.com/dls-controls/pmac/releases/tag/2-4-10
>>
>> 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
>>>>
>>>>
>>
>
- Replies:
- Re: RES: Pmac Slits giles.knap--- via Tech-talk
- References:
- Re: Pmac Slits Davis, Mark via Tech-talk
- RES: Pmac Slits George Nicolas Kontogiorgos via Tech-talk
- Re: RES: Pmac Slits Davis, Mark via Tech-talk
- Re: RES: Pmac Slits giles.knap--- via Tech-talk
- Re: RES: Pmac Slits Davis, Mark via Tech-talk
- Re: RES: Pmac Slits giles.knap--- via Tech-talk
- Re: RES: Pmac Slits giles.knap--- via Tech-talk
- Re: RES: Pmac Slits giles.knap--- via Tech-talk
- Re: RES: Pmac Slits giles.knap--- via Tech-talk
- Re: RES: Pmac Slits Davis, Mark via Tech-talk
- Navigate by Date:
- Prev:
Re: RES: Pmac Slits Davis, Mark via Tech-talk
- Next:
Re: RES: Pmac Slits giles.knap--- via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: RES: Pmac Slits Davis, Mark via Tech-talk
- Next:
Re: RES: Pmac Slits giles.knap--- via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024
|