motorapp / galil

ASYN based EPICS driver for Galil products

Galil-3-6

ASYN based EPICS driver for Galil products

Notes

Firmware requirements

DMC-4103 Series controller minimum firmware = 1.2F
DMC-4000 Series controller minimum firmware = 1.2i

Communication

If using RS232 communication on Microsoft Windows, need XON/XOFF flow control enabled via switches on Galil controller or else uploading a program to the controller times out and fails. However, all other read/write communication works fine without flow control enabled.

AUTO-GENERATED HOME STEPS

1. Driver starts jog in direction indicated by HOMR, HOMF
2. AutoGen Galil home code jogs off limit switch, or skip
3. AutoGen Galil home code jogs to find home switch active, or skip
4. AutoGen Galil home code jogs to find requested home switch edge, or skip
5. AutoGen Galil home code jogs to find encoder index, or skip
6. AutoGen Galil home code notifies the driver when the home completes successfully

UseSwitch (Limits&home are switches) = Yes (For stages with limits, home switches)
Begins on step 2
Home search direction away from limit
Find index direction away from limit
UseSwitch = No (For rotary stages without limits)
Find index direction indicated by HOMR, HOMF
Begins on step 5
useIndex = Yes
Includes step 5
useIndex = No
Excludes step 5

Use Limits as Home Switch = Yes
Home switch is not used, limits used as home instead
Home switch edge parameter is not used
Skip steps 3, 4

Use Limits as Home Switch = No
Home switch is used
Home switch edge parameter is used

MOTOR/LIMIT DIRECTION CONSISTENCY & WRONG LIMIT PROTECTION (WLP)

1. Commisioning partly involves verifying motor direction is consistent with limit orientation
   When the motor is moving forward, the stage must be travelling toward the forward limit
   When the motor is moving reverse, the stage must be travelling toward the reverse limit
2. Verifying motor/limit direction consistency involves both the hardware (wiring) and software
   (motor, encoder selection) configuration
3. For hardware and software configurations where the motor/limit direction consistency is not known,
   it is NOT SAFE to rely on WLP to avoid stage damage when the ioc is started with the stage already
   on a limit
4. For hardware and software configurations where the motor/limit direction consistency is not known,
   it IS SAFE to rely on WLP to avoid stage damage when the ioc is started with the stage clear of
   both limits
5. The motor/limit consistency has the states unknown, consistent and not consistent
6. The motor/limit consistency check PV is $(P)$(M)_LIMITCONSISTENT_STATUS it is in motor extras db
7. At IOC start, the motor/limit consistency for an axis is set to unknown
8. At stage interaction with limits, the motor/limit consistency will be set to
   consistent or not consistent. The motor/limit consistency check works with switch transitions,
   not switch states (refer point 3). Reversing direction off a limit is a common operation that
   must be allowed at ioc start, before motor/limit consistency is confirmed by this driver software
9. If enabled, wrong limit protection will stop a motor when the motor/limit consistency is set
   to not consistent, and a limit is active and enabled
10. WLP can be enabled at all times with no interactions with normal or home operations
    (refer to 8)

galil's Issues

Tags releases should be managed and documented clearly

Few weeks ago, we installed a new Galil IOC with the latest Galil driver from GitHub, motors were moving OK but the DMC always giving controller start error because of an issue with the generated DMC code. After deep investigation, it turns out that in the "latest" version, which has been 3.6 for a while, the GalilCreateAxis IOC shell function no longer has the limits_as_home argument and our setup, assuming it is still there, would pass 1 to the motor interlock digital port argument, therefore generating extra DMC code for stopping the motors in case of a digital port interlock.

I don't see anywhere where this is documented or at least mentioned, the release management for the Galil EPICS driver is really confusing because of two points:

• The driver has been in version 3.6 for a while now but it has been updated on the same tag many times, this is very confusing.
• Release notes for each update is not clear enough.

We really hope this to be taken care of in future releases or updates.

error when start IOC

I compiled this driver with EPICS base 7.0.4, tried to start IOC without any change, then I got the error about missing definition of GALIL:
macLib: macro GALIL is undefined (expanding string $(GALIL)/GalilSup/Db/galil_motor-v6-10up.template)
I defined GALIL in RELEASE file but that doesn't show up in envPaths file.
What's the correct way to fix this error?
======================================================
base) bl531@BL531BCS-L:/opt/epics/modules/motorGalil/Galil-3-0/3-6/iocBoot/iocGalilTest$ ../../bin/linux-x86_64/GalilTest st.cmd
#!../../bin/linux-x86_64/GalilTest
< envPaths
epicsEnvSet("IOC","iocGalilTest")
epicsEnvSet("TOP","/opt/epics/modules/motorGalil/Galil-3-0/3-6")
epicsEnvSet("SUPPORT","/opt/epics/modules/synApps_6_1_epics7/support")
epicsEnvSet("EPICS_BASE","/opt/epics/base-7.0.4")
epicsEnvSet("AUTOSAVE","/opt/epics/modules/synApps_6_1_epics7/support/autosave-R5-10")
epicsEnvSet("SNCSEQ","/opt/epics/modules/synApps_6_1_epics7/support/seq-2-2-7")
epicsEnvSet("SSCAN","/opt/epics/modules/synApps_6_1_epics7/support/sscan-R2-11-3")
epicsEnvSet("CALC","/opt/epics/modules/synApps_6_1_epics7/support/calc-R3-7-4")
epicsEnvSet("ASYN","/opt/epics/modules/synApps_6_1_epics7/support/asyn-R4-38")
epicsEnvSet("BUSY","/opt/epics/modules/synApps_6_1_epics7/support/busy-R1-7-2")
epicsEnvSet("MOTOR","/opt/epics/modules/synApps_6_1_epics7/support/motor-R7-2-1")
epicsEnvSet("IPAC","/opt/epics/modules/synApps_6_1_epics7/support/ipac-2-15")
cd /opt/epics/modules/motorGalil/Galil-3-0/3-6
## Register all support components
dbLoadDatabase("dbd/GalilTest.dbd",0,0)
GalilTest_registerRecordDeviceDriver(pdbbase)
cd /opt/epics/modules/motorGalil/Galil-3-0/3-6/iocBoot/iocGalilTest
### Scan-support software
# crate-resident scan.  This executes 1D, 2D, 3D, and 4D scans, and caches
# 1D data, but it doesn't store anything to disk.  (See 'saveData' below for that.)
dbLoadRecords("/opt/epics/modules/synApps_6_1_epics7/support/sscan-R2-11-3/sscanApp/Db/standardScans.db","P=IOC01:,MAXPTS1=8000,MAXPTS2=1000,MAXPTS3=10,MAXPTS4=10,MAXPTSH=8000")
dbLoadRecords("/opt/epics/modules/synApps_6_1_epics7/support/sscan-R2-11-3/sscanApp/Db/saveData.db","P=IOC01:")
# Configure an example controller
< galil.cmd
## uncomment to see every command sent to galil
#epicsEnvSet("GALIL_DEBUG_FILE", "galil_debug.txt")
#Load motor records for real and coordinate system (CS) motors
#Motor record version 6-9 and below
#dbLoadTemplate("$(TOP)/GalilTestApp/Db/galil_motors-v6-9down.substitutions")
#Motor record version 6-10 and up
dbLoadTemplate("/opt/epics/modules/motorGalil/Galil-3-0/3-6/GalilTestApp/Db/galil_motors-v6-10up.substitutions")
macLib: macro GALIL is undefined (expanding string $(GALIL)/GalilSup/Db/galil_motor-v6-10up.template)
filename="../dbStatic/dbLexRoutines.c" line number=268
dbRead opening file (null)
dbLoadRecords: failed to load '$(GALIL)/GalilSup/Db/galil_motor-v6-10up.template'
macLib: macro GALIL is undefined (expanding string $(GALIL)/GalilSup/Db/galil_motor-v6-10up.template)
filename="../dbStatic/dbLexRoutines.c" line number=268
dbRead opening file (null)
dbLoadRecords: failed to load '$(GALIL)/GalilSup/Db/galil_motor-v6-10up.template'
macLib: macro GALIL is undefined (expanding string $(GALIL)/GalilSup/Db/galil_motor-v6-10up.template)
filename="../dbStatic/dbLexRoutines.c" line number=268
dbRead opening file (null)
dbLoadRecords: failed to load '$(GALIL)/GalilSup/Db/galil_motor-v6-10up.template'
macLib: macro GALIL is undefined (expanding string $(GALIL)/GalilSup/Db/galil_motor-v6-10up.template)
filename="../dbStatic/dbLexRoutines.c" line number=268
dbRead opening file (null)
dbLoadRecords: failed to load '$(GALIL)/GalilSup/Db/galil_motor-v6-10up.template'
macLib: macro GALIL is undefined (expanding string $(GALIL)/GalilSup/Db/galil_motor-v6-10up.template)
filename="../dbStatic/dbLexRoutines.c" line number=268
dbRead opening file (null)

Stall detection not working if high resolution encoder is jumping around

The stall detection feature is not working if we have a high resolution encoder. The stall detection only works if the encoder does not change within the specified stall time, but with high resolution encoders the position is always changing at the sub-micron level.

Could the stall detection code in GalilAxis::setStatus also make use of a user specified tolerance value? Something like:

if (ueip_ || ctrlUseMain_)
{
//Check encoder move
if (last_encoder_position_ > (encoder_position_ + tolerance))
{
encoder_direction = 0;
encoderMove_ = true;
}
if (last_encoder_position_ < (encoder_position_ - tolerance))
{
encoder_direction = 1;
encoderMove_ = true;
}
//Encoder not moving
if (abs(last_encoder_position_ - encoder_position_)<=tolerance)
encoder_direction = direction_;
//Encoder direction ok flag
encDirOk_ = (encoder_direction == direction_) ? true : false;
}

The tolerance value could be a new record similar to the stall time, but it could default to 0.0 so that current behavior is maintained by default.

help with the default st.cmd script

the default start up script contains references to a second controller "rio", in additional to the first controller "Galil".
https://github.com/motorapp/Galil-3-0/blob/master/3-6/iocBoot/iocGalilTest/galil.cmd
I wonder what the "rio" is meant to be.
Is it just another Galil controller at a different IP address?
I happen to have two Galil controllers. Should I modified "galil.com" so make "rio" the 2nd controller?

Galil controller stuck suddenly

I found a new issue; I am not sure what cause it.
I found galil_dmc_4183 be stuck several times during last beamtime, it shows "GalilAxis::move begin failure axis B", In fact, all channels couldn't work, I must restart controller to fix it or both restart controller and restart computer to fix it.
Because restart controller wasn't enough sometimes.
If I only restart controller and run IOC again. The error report shows: "Asynchronous UDP failed, switching to TCP synchronous" and Communication status show Error and Controller start statue also shows error.
I must restart PC sometimes.
Does any people know what happened it is? Thank you

Latest version does not work with DMC2182.

Hi

We tried installing the latest version of the Galil driver to work with a DMC2182, the IOC shell showed this error:

Transferring code to model DMC2182 Rev 1.0v, address x.x.x.x
Error downloading code model DMC2182 Rev 1.0v, address x.x.x.x

This will result in a control start status of "Error". This is a serious issue because soon we will upgrade our motion IOC servers, there is no indication to which commit of the v3.6 that works with the DMC2182 or anything prior to the DMC-4000. Any insight is appreciated.

Home failed with auto-generated code

The auto-generated home code doesn't work well when there's home switch. The motor stops at forward limit switch/reverse limit switch when running HOMF/HOMR and giving time-out error. Current code has fixed value for hswact and hswiact while the state of the home (_HM) switch depends on the value set for _CN1. When _CN1 is set to -1, _HM will show 0 when inactive and 1 when active. When _CN1 is set to 1, _HM will show 1 when inactive and 0 when active.

Failure to move DMC-30019

Hi,
We are having an issue when sending commands to a Galil single-axis DMC-30019 controller. After setting up the software and establishing a connection with the controller, we fail to send commands to it via caput. Running the trajectoryA.sh script provided, the motor fails to move and we get two warnings: The requested data transfer is greater than available memory or EPICS_CA_MAX_ARRAY_BYTES and Identical process variable names on multiple servers. The full log is in the log_trajectoryA.txt file.

Simply trying caput DMC01:Prof1:M1Positions 1500 gives only the second warning, but also fails to move the motor. The full log is in the log_caput.txt file.

About the second warning, we set up the IP by enabling DHCP using the DH0 command and then the IA ip_addr command.

We are able to move the motor normally through GDK and by sending commands from the terminal via serial-to-USB and via ethernet, so it seems that the issue itself lies in the EPICS software. We also tried both the 3-1 and the 3-6 versions of the motorapp and both present the same issue.

We're unsure on how to continue, so any help or advice would be useful.

Loss on information about homedX variables upon IOC restart

This issue is aimed to report a detected misbehaviour of the Galil-3-0 IOC which consists on the loss of information about homedA,homedB,homedC... variables (which are stored on a Galil controller) values after IOC initialization.

These variables contain the status of the sucessfull completion of the last commanded homing routine, and are useful to determine positioning safety of a system on a synchroton facility.

The detected behaviour is:

1. The system controlled by the Galil controller is already homed, and the status (as obtained via use of Galil IDE "GDK", using the terminal tool) of "homedA" and "homedB" variables - which contain information about homing completion on axes A and B of the Galil - is currently equal to "1", which means both axes have already been homed with sucess.
2. The IOC is not running.
3. Then, the IOC is started via its ".cmd" file, as usual.
4. Using GDK terminal again, the value of those "homedA" and "homedB" variables is obtained, and is found to be now equal to "0"

This behaviour is unwanted, since restarting an IOC shouldn't affect the status of a homing command for any axes, as this is an information that regards only what happens with encoder readings/stepper motor pulses countings, which will only be affected by shutting off the Galil controller or artificially changing these encoder/motor associated position values.

Given this, it is provided (at the end of this post) an image of the messages output from EPICS Galil IOC at the time, and it is shown errors have happened, particularly the one that reads "Error setting variables".

The questions are:

• Can this error message imply the Galil-3-0 IOC is resetting the "homedA" and "homedB" variables at startup, causing the problem?
• If so, is this related to EEPROM burn failure?
• If so, is there a way to obtain a status bit from GalilStartController function (which is issued by the IOC associated with the Galil controller in question) so to modify the IOC initialization parameters and code specific to the system in question, and customize the IOC so it can issue additional attempts on burning code and variables whenever the first attempt fails, or even issue warnings to end users informing them the controller has not been setup successfully by the IOC for its intended operation?

See below the mentioned image with the evidences for the detected behaviour

IOC segfaults when calling GalilCreateController()

The RIO-47300-16BIT-24EXOUT returns the following in response to the ID command, which is longer than 512 chars:

outputs 0-3 = power sourcing outputs
outputs 4-7 = power sourcing outputs
outputs 8-11 = power sourcing outputs
outputs 12-15 = power sourcing outputs
outputs 16-19 = power sourcing outputs
outputs 20-23 = power sourcing outputs
outputs 24-31 = power sourcing outputs
outputs 32-39 = power sourcing outputs
outputs 40-47 = power sourcing outputs
analog inputs 0-3 = 16 bits programmable range(AQ)
analog inputs 4-7 = 16 bits programmable range(AQ)
analog outputs 0-3 = 16 bits programmable range(DQ)
analog outputs 4-7 = 16 bits programmable range(DQ)
extended IO
:

When GalilCreateController() is called, the IOC segfaults:

(gdb) bt
#0  0x00007ffff53c1d67 in ?? () from /lib64/libstdc++.so.6
#1  0x00007ffff53c1de3 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string() () from /lib64/libstdc++.so.6
#2  0x00007ffff6e14633 in GalilController::sync_writeReadController (this=0x71f5c0, output=0x71fd40 "ID", input=0x71fe40 "outputs 0-3 = power sourcing outputs\r\noutputs 4-7 = power sourcing outputs\r\noutputs 8-11 = power sourcing outputs\r\noutputs 12-15 = power sourcing outputs\r\noutputs 16-19 = power sourcing outputs\r\noutpu"..., maxChars=256, nread=0x7ffff2ce29f8, timeout=1) at ../GalilController.cpp:3527
#3  0x00007ffff6e13f20 in GalilController::sync_writeReadController (this=0x71f5c0) at ../GalilController.cpp:3414
#4  0x00007ffff6e415ba in GalilController::InitRio (this=0x71f5c0, rio3=true) at ../GalilController.cpp:4833
#5  0x00007ffff6e167be in GalilController::InitializeDataRecord (this=0x71f5c0) at ../GalilController.cpp:4298
#6  0x00007ffff6e0c002 in GalilController::connected (this=0x71f5c0) at ../GalilController.cpp:709
#7  0x00007ffff6e56899 in GalilConnector::run (this=0x7a2ff0) at ../GalilConnector.cpp:106
#8  0x00007ffff564c7a7 in epicsThreadCallEntryPoint (pPvt=0x7a2ff8) at ../../../src/libCom/osi/epicsThread.cpp:85
#9  0x00007ffff565414e in start_routine (arg=0x7a31a0) at ../../../src/libCom/osi/os/posix/osdThread.c:389
#10 0x00007ffff4816dc5 in start_thread () from /lib64/libpthread.so.0
#11 0x00007ffff4b2121d in clone () from /lib64/libc.so.6
(gdb) 

The source of the problem is these lines in GalilSup/src/GalilController.h:

#define MAX_GALIL_STRING_SIZE 256
#define MAX_GALIL_DATAREC_SIZE 512

IOC zeroes encoder on startup

Hi,

I have a question about how the Galil support handles encoder value on IOC startup/restart.

I have an incremental rotary encoder on one of my linear axes. If I don't ask autosave to restore it what should the default behaviour of the motor record be:

1. read the current value of the encoder from the Galil and use that?
2. zero the encoder

We recently moved everything to a docker container, upgraded to the latest synapps and moving from galil 3-5 to 3-6 i now get (2) where I used to get (1). But I don't know what I did to cause that. For my application (1) would be preferred. I could use autosave but I didn't need to do that in the past. I don't think the docker is responsible.

My configuration is:
galil 4183
base 3.15.6
synapps - latest tagged version from assemble_synapps.sh

Double checked a new controller

Hello,
There is a SMC-Galil controller at Xhuber website. The website is https://www.xhuber.com/en/products/3-control/smc-galil/
Could you help me double check this EPICS driver can work for SMC-Galil controller? It is a Galil DMC41, It seems no EPICS driver support it from the attachment table.

Thank you