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 | 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 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Coordinated motion of slits |
From: | "Davis, Mark via Tech-talk" <[email protected]> |
To: | Wayne Lewis <[email protected]> |
Cc: | Steven Schofield <[email protected]>, "[email protected]" <[email protected]> |
Date: | Tue, 23 Apr 2019 17:44:16 +0000 |
Steven and Robert: Could I get a "full copy of the IOC" that Wayne mentioned? And could you include the configuration and motion program code(and any other code) for the controller as well? Thanks. Hi Wayne, Thanks for the info. That fills in some of the gaps. Still some important details that I am hoping you (or someone) can help with. What I (think) I know/understand so far (please correct me if I am missing something or have something wrong):
Mark Davis , NSCL/FRIB Control Systems Software Engineer [email protected] On 4/18/2019 8:04 PM, Wayne Lewis wrote:
Hi Mark, You can interface the motor record directly to the PMAC-implemented coordinate system axes using the DLS pmac module: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dls-2Dcontrols_pmac&d=DwIDAw&c=nE__W8dFE-shTxStwXtp0A&r=D7ZiziuMQuq40HlGYOZPBg&m=N5c9jjxdKJKM4FL5kzUqRKVlLFVSxrq-5uXTMd9aXwI&s=gaBMbu_Zw5cT9kXWue1vMO3nvrKexmPSWd7zMu59NLw&e= A few things to include in your IOC to make use of this: In <ioc>App/src/Makefile: <yourioc>_DBD += drvAsynPowerPMACPort.dbd <yourioc>_DBD += pmacAsynIPPort.dbd <yourioc>_DBD += pmacAsynMotorPort.dbd <yourioc>_LIBS += pmacAsynIPPort <yourioc>_LIBS += pmacAsynMotorPort <yourioc>_LIBS += powerPmacAsynPort In iocBoot/ioc<yourioc>/st.cmd: epicsEnvSet("PPMAC_IP", "192.168.0.201") epicsEnvSet("PPMAC_SSH_PORT", "PPMAC_SSH") epicsEnvSet("PPMAC_PORT", "PPMAC1") epicsEnvSet("PPMAC_CS2_PORT", "CS2") # Attach to the SSH port #drvAsynPowerPMACPortConfigure(port_name, host_address, username, password, priority, noAutoConnect, noProcessEos) drvAsynPowerPMACPortConfigure("$(PPMAC_SSH_PORT)", "$(PPMAC_IP)", "root", "deltatau", 0, 0, 0) # Configure Model 3 controller driver # powerPmacCreateController(controller_port, low_level_port, address, axes, moving_poll, idle_poll) pmacCreateController("$(PPMAC_PORT)", "$(PPMAC_SSH_PORT)", 0 , 32, 100, 200) # Create the Model 3 motion axis drivers #pmacCreateAxes(controller_port, axis_count) pmacCreateAxes("$(PPMAC_PORT)", 7) # Set up for running coordinate system #pmacCreateCS(coordinate_system_port, controller_port_name, coordinate_system_number, motion_program_number) pmacCreateCS("$(PPMAC_CS2_PORT)", "$(PPMAC_PORT)", 2, 2) # Create the coordinate system axes #pmacCreateCSAxes(coordinate_system_port, num_coordinate_system_axes) pmacCreateCSAxes("$(PPMAC_CS2_PORT)", 9) # Define coordinate step resolution #pmacSetCoordStepsPerUnit(coordinate_system_port, cs_axis, counts_per_egu) pmacSetCoordStepsPerUnit("$(PPMAC_CS2_PORT)", 8, 1000000) Then in your motor record substitutions file, you can define both the physical motors and the virtual motors, with the only necessary difference being the asyn port that they talk to. The physical motors use the port created in the pmacCreateController() function in the st.cmd file. The virtual motors use the port created in pmacCreateCS(). file $(MOTOR)/db/basic_asyn_motor.db { pattern {P, M, DESC, DTYP, DIR, VELO, VBAS, ACCL, BDST, BVEL, BACC, PORT, ADDR, TIMEOUT, MRES, PREC, EGU, DHLM, DLLM, INIT } # Physical motor (using PPMAC1 port) { $(P),"Mtr", "Stepper motor counts", asynMotor, 0, 0.5, 0.0, 1.0, 0.0, 0.0, 0.0, PPMAC1, 1, 1.0, 0.0002, 3, mm, 0.0, -26.0, 0 } # Coordinate system motor (using CS2 port) { $(P),"CSGap", "CS Gap", asynMotor, 0, 0.5, 0.0, 1.0, 0.0, 0.0, 0.0, CS2, 8, 1.0, 0.000001, 3, mm, 0.0, 0.0, 0 } } A few other points: The Diamond PMAC driver has a defined interface for the coordinate system motor positions and setpoints. Q71-79 for the setpoints, Q81-89 for the position reporting readbacks. You will want to write a position reporting PLC the implements the forward kinematics to provide continuous readback updates for the motor record RBV field. This was definitely a requirement for the Turbo PMAC; the Power PMAC documentation no longer refers to it, but I haven't found a way to get continous updates from the coordinate system forward kinematics. Maybe someone else out there can help more here. You could contact the LBNL people copied on this email to get a full copy of the IOC. Some answers to your other questions:And even then, doesn't there need to be some supporting logic running on the controller? As near as I can tell, coordinated motion on the Power Brick controller requires a motion program running on the controller, however trivial a program it may be.If you want to use the PMAC coordinated motion, you need to define the kinematics (either via forward and inverse kinematics or through the equation-based definition) and provide a motion program. PMAC coordinate systems must run through a motion program. Hope that helps. Wayne On Thu, Apr 18, 2019 at 02:50:32PM +0000, Davis, Mark via Tech-talk wrote:Hi all, We will soon be adding a couple of motors to a Delta Tau Power Brick controller that will control the left and right drives for a slit and I was hoping someone could provide me some direction about how to go about using the Model 3 motor interface to achieve coordinated motion control of the two drives on the controller itself. From what I learned from the Delta Tau online training videos I was able to use the vendor's PowerPMAC IDE to define a coordinate system with the two motors and two axes (one for center position and one for the gap), define the relationship between the motor's positions and the two axes, and write a trivial motion program that causes the two motors to move correctly in response to a change to the setpoint for the two axes. But that is as far as I have gotten. Ignoring for the moment everything but the most basic aspects of this, what I need is to have two records, one for the center position and one for the gap, and to have changes to one or both of these to cause the two motors to move as needed to satisfy the new settings. I currently have such a setup where all the coordination of the motion is done in EPICS record logic (using the separate motor records for each drive), but we want to eliminate all that and have the controller coordinate the motion of the motors. As I understand it, one of the basic advantages of the Model 3 interface for motors is that it includes support for such coordinated motion. And, from what little I have learned so far, it requires you to supply the interface with a list of the motor movements that the controller should execute. Is this correct? And if I want to avoid going around the Model 3 interface, is this the only way to get coordinated motion that is managed by the controller? If so, this would still seem to require some significant record logic (and possibly supporting code) to go from a change in the center and/or gap setting to generate and set the values in the necessary data structures and call the appropriate functions in the interface. And even then, doesn't there need to be some supporting logic running on the controller? As near as I can tell, coordinated motion on the Power Brick controller requires a motion program running on the controller, however trivial a program it may be. If someone could outline the whole process and what is needed to go from the center and gap setpoint records to invoking the motion on the controller, that would be a major help and save me loads of time and effort. ------- Mark Davis NSCL/FRIB Control Systems Software Engineer [email protected] |