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
>>>>>
>>>>>
>
- 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
- Re: RES: Pmac Slits Davis, Mark via Tech-talk
- Re: RES: Pmac Slits giles.knap--- via Tech-talk
- Navigate by Date:
- Prev:
Channel Access implementation for Siemens S71500 PLCs Miklós Boros via Tech-talk
- Next:
OS question 网易邮件中心 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 giles.knap--- 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
|