Galil controller connects to:
- Kollmorgen servo driver connected to Kollmorgen motor
- Renishaw encoders
Control Galil with galil glibc library (labview, c, python)
File:Galil DMC 4040 commands.pdf
notes
[edit | edit source]IPs
Galil 192.168.0.21 00:50:4c:20:65:0a Kollmorgen 192.168.0.11 00:23:1b:06:32:f5
Galil -> Kollmorgen
Analog communication 0--10V = torque (results in speed) @ 0.9 A/V (scaled by Kollmorgen)
Galil -> Kepco V->A converter (i.e. current power supply) Analog 0-10V @ 2V/A
Kollmorgen motor encoder
- 32768 count ie 16 bits / turn rotary encoder
- translates to 598924 counts/mm gap and 1.7 nm/step
Renishaw linear encoders
- 5 nm resolution = 200000 counts/mm (per mm of strongback travel, i.e gap half travel)
Questions to Steve: (meeting at 5PM)
- What happened to linear encoder B (DSU) -> it is now main encoder, not secondary -> makes high level gap renishaw calculation fail
- Does the Kollmorgen have a watchdog that needs to be kicked by Galil? Is that the "Watchdog" thread on the Galil?
- Is the EM correction lookup table not activated? (or does F40 not use that?)
- procedure in case calibration is lost?
Threads gaan weer aan bij stop?
Programmer's notes:
import gclib g = gclib.py() g.GOpen('192.168.0.21 --direct -s all') -> direct is nodig anders wil gclib connecten via gcaps (een proxy) -s all is subscribe to all g.GCommand("TT")
vragen voor mezelf: hoe limit switches uitlezen
reset gap
NIET MET gaparr[0]=101.0000;XQ #SetGap,0
MAAR MET NewGap=94;XQ #SetGap,0
g.GCommand("gaparr[0]=100;XQ #GOTOGAP")
FHI runner
[edit | edit source]
F40 control
[edit | edit source]VM for testing on instigator. Find ip by MAC 00:0c:29:cb:ec:34 on ethergids. todo: fixed IP address remote desktop user .\feloperator
relevant info from steve
[edit | edit source]The files with akd extension are the Kollmorgen AKD servo amplifier parameters. It’s burned into the ADK EEPROM. You probably don’t need to look at it
The AKD is a simple digital servo amplifier. It also handles stepper motors, but I’ve never used it that way. Unlike 1990’s servo amps that used dip switches and a long list of special purpose dumb analog amps to handle multiple motors, there has been an industry wide conversion to smart, digital amps that can handle multiple motors. The differences between motors is handled by parameters. Users can also change parameters using MODBUS/TCP. I mainly read them. (There are more sophisticated flavors of AKD with a single axis controller or a Programmable Automation Controller. Not appropriate for this undulator because there are 4X Renishaw Resolute Absolute linear encoders. That’s why the Galil is 4-axis)
The file with a dmc extension is the Galil motion controller code. Recommended way to look at it is with GDK (Galil Design Kit) GUI. Depending on how you intend to write your GUI, you may want to look at it
The code is moderately compressed by having multiple commands on a line. (There is another way that is fully compressed but essentially unreadable) The code #AUTO runs when it is turned on. The codes #CMDERR, #POSERR, #TCPERR, #LIMSWI are automatic subroutines that run when there is a command error, position error during a move, some sort of TCP/IP error and a limit switch trips during a move When my VB.NET GUI starts it establishes connection at a fixed IP address then runs #STARTUP which starts multiple threads. Thread 0 is the default, nominal one. Other threads do less time sensitive things. For example, XQ #GetGap1,1 starts a gap monitoring thread #1. It is in a loop that takes around 120 msec. It updates values that the GUI uses Likewise, #ESTOP checks the AKD motor bus voltage parameter every 2 seconds. This will instead check the STO parameter. If the ESTOP was pushed then the parameter is set. When that happens the AKD has already stopped a move super fast, then the Galil code turns on a front panel light and the VB.NET GUI sees the DIO bit 2 was set and informs the user Some other information is in the FHI_Servo_Reference.docx file. (NB: I have not updated it) The code is a union of all Galil codes for 1, 2, 3, 4 axis devices (PM quads, undulators, scanner, pseudo-CMM gantry) so it is more complicated. On the scanner I started a cleanup, but the scanner z-axis is a simpler beast than an undulator, so…
Files with vb extension are VB.NET source files. These codes are the most useful to you
The main scanner z-axis GUI code is called frmGalilRunner_z.vb. It’s in the Z_Axis_Runner.zip file. (That’s historical. Originally (2001) the code was used to run a 4-axis PM quad, then used for one-axis and four-axis undulators and most recently the z-axis on the scanner). You will see some commented lines with Galil_zAxis that were replaced with Galil_SixAxis because the scanner originally had two separate Galils (3-axis, 1-axis) which were later replaced with a single six-axis Galil There are other vb codes that this one calls The Galil class libraries are in their own zip files. Base is the base class and then other child classes are device specific with either new methods and properties or overrides. Galil commands all must use the Galil class library. Standard multi-tier GUI with OOP. These codes call vb wrappers for gclib dlls. I only use a small, small subset of the gclib dlls It’s up to you if you convert the Galil classes to python or write your own. Try to keep the main GUI logic. You can defer or avoid the advanced, random moves, gap cycling and gap logging stuff. I use them during drive testing and initial setups I’ve avoided Galil events and let the GUI update Galil values with cmd_Update that is programmatically “pushed†in a VB.NET timer loop called TimerUpdate. Reason is that Galil code is dedicated to low level, fast (1 msec rates) monitoring of the drive system. The GUI doesn’t need to be fast, but should let a user command moves and monitor things
{{#allow-groups:fft}} do not show this outside of technical group
