M6 Remap for ATC with carousel

I just finished figuring out my ATC setup. Since I am not any good at this and am learning as I go, I would appreciate any advice about the work I have done on it. I will start checking lines of the routine tomorrow. My goal was to make a 22 tool changer with geneva mechanism, tool #1 index, tool count. Pretty standard otherwise. The arm out and carousel motors are both AC motors, both with out/in or fwd/rev. Pretty basic setup but I attempted to get some additional behavior from the subroutine.

This is the hal file for just the tool change and carousel components. Should I keep this and the main hal file separate or condese into one?


The subroutine is new to me. Using the vismach example I changed the behavior to suite my hardware. I added a low air pressure check. I attempted to add "o210 if [#<tool_in_spindle> EQ 0] ; if no tool in spindle tool arm goes out" since I didn't see the point in going through the arm out process if it was already out. This line should only happen if i start with no tool in.

My sensor checks for tool arm out/in and tool clamp/unclamp were made double redundant. That is if the arm should be out then I want to see arm out high and arm in low. The proximity sensors go low when tripped so it would be possible for them to have a short and return a value of true. (Now realizing that this leaves me open to the arm only being halfway and getting sensor readings that allow the process to continue).


As for ini changes I need to add:
[RS274NGC]
PARAMETER_FILE = linuxcnc.var
SUBROUTINE_PATH = ./
REMAP= M6 modalgroup=6 prolog=change_prolog ngc=toolchange epilog=change_epilog

I just can't seem to remember where I saw/found the prolog/epilog files at but I believe there are some that are premade somewhere. Also need to confirm these files all go in the folder with hal and ini etc. But currently I have used as much brain power as I can spare on this for today.

I noticed a few mentions of iocontrol-v2 in the literature around remapping. I couldn't find much info about when you should use it or what it actually does different.

Also when using the stdglue.py I pull the prolog and epilog sections out into separate files for my remap and then link them via ini file entries?

Getting this all buttoned up hopefully. Unfortunately one of my proximity sensors arrived DOA so it's looking like not till next week will it all be done.

Thanks for the links. I started looking into the differences, but understanding the differences is step 2. So for now I am just documenting the differences I found. I will come back with what I learned those differences mean. It appears that iov2 has a few extra layers of fault control for tool changes and handles them a bit differently. Its not well documented on the man page as to how that works but I did read something that iov2 may be part of machinekit. So some cross reference to their material may be needed to make iov2 work successfully for a LCNC user.

iov2 has the following added lines of code:

#include <getopt.h>



static int support_start_change = 0;
static const char *progname;

typedef enum {
V1 = 1,
V2 = 2
} version_t;
static int proto = V2;

// extend EMC_IO_ABORT_REASON_ENUM from emc.hh
enum {
EMC_ABORT_BY_TOOLCHANGER_FAULT = EMC_ABORT_USER + 1
};

static const char *strcs[] = { "invalid","RCS_DONE","RCS_EXEC","RCS_ERROR"};

// read_inputs() returns a mask of changes observed
enum {
TI_PREPARING = 1,
TI_PREPARE_COMPLETE = 2,
TI_CHANGING = 4,
TI_CHANGE_COMPLETE = 8,
TI_TC_FAULT = 16,
TI_TC_ABORT = 32,
TI_EMC_ABORT_SIGNALED = 64,
TI_EMC_ABORT_ACKED = 128,
TI_ESTOP_CHANGED = 256,
TI_LUBELEVEL_CHANGED = 512,
TI_START_CHANGE = 1024,
TI_START_CHANGE_ACKED = 2048
};

// iocontrol states. Reflected in state pin
typedef enum {
ST_IDLE = 0,
ST_PREPARING = 1,
ST_START_CHANGE = 2, // V2 only
ST_CHANGING = 3,
ST_WAIT_FOR_ABORT_ACK = 4, // V2 only
} iostate_t;
static const char *strstate[] = { "IDLE","PREPARING","START_CHANGE", "CHANGING","WAIT_FOR_ABORT_ACK"};

static int toolchanger_reason; // last fault reason read from toolchanger

// predicates for testing toolchanger fault conditions
#define TC_FAULT (*(iocontrol_data->toolchanger_faulted))
#define TC_HARDFAULT (TC_FAULT && (toolchanger_reason <= 0))
#define TC_SOFTFAULT (TC_FAULT && (toolchanger_reason > 0))



// v2 protocol
// iocontrolv2 -> toolchanger
hal_bit_t *emc_abort; /* output, signals emc-originated abort to toolchanger */
hal_bit_t *emc_abort_ack; /* input, handshake line to acknowledge abort_tool_change */
hal_s32_t *emc_reason; /* output, convey cause for EMC-originated abort to toolchanger.
* UI informational. Valid during emc-abort True.
*/
// toolchanger -> iocontrolv2
hal_bit_t *toolchanger_fault; /* input, toolchanger signals fault . Always monitored.
* A fault is recorded in the toolchange_faulted pin
*/
hal_bit_t *toolchanger_fault_ack; /* handshake line for above signal. will be set by iocontrol
* after above fault line is recognized and deasserted when
* toolchanger-fault drops. Toolchanger is free to interpret
* the ack; reading the -ack lines assures fault has been
* received and acted upon.
*/
hal_s32_t *toolchanger_reason; /* input, convey reason code for toolchanger-originated
* fault to iocontrol. read during toolchanger-fault True.
* on a toolchange abort, the reason is passed to EMC in the
* emcioStat message.
* a positive value causes an OperatorDisplay text
* a negative value causes an OperatorError text
* a zero value does not cause any display
*/

hal_bit_t *start_change; /* signal begin of M6 cycle even before move to toolchange
* position starts
*/
hal_bit_t *start_change_ack; /* acknowledge line for start_change */

// other:
hal_bit_t *toolchanger_faulted; /* output. signals toolchanger-faul line has toggled
* The next M6 will abort if True.
*/
hal_bit_t *toolchanger_clear_fault; /* input. resets TC fault condition.
* Deasserts toolchanger-faulted if toolchanger-fault is line False.
* Usage: UI - e.g. 'clear TC fault' button
*/
hal_s32_t *state; /* output. Internal state for debugging */

All set to implement the remap of the M6. Machine and sensors are all working good and a manual walk through of the toolchange.ngc checks out.

My issue is the prolog fails. And I'm sure its because I don't have the ini file pointing to it directly. A lot of what I did was to copy from the vismach sim config. Noticed it has two python files. remap (python source file) points to a directory for "stdglue" and toplevel (python source file) that points to "remap"
This is the relevant section of my ini:
Currently the toolchange.ngc is in the same location as my hal. This is the directory that contains the stdglue file:
/home/bridgeport/linuxcnc/nc_files/remap_lib/python-stdglue/

Lost......

starting linuxcnc from the terminal should  show you if it cannot find the prolog and epilog functions.

Look  Here   for setting up the python environment for the remap.
I see no [python] section in your ini file. neither mention of toplevel.py.

I've always done python remaps and never an ngc but I still think in an ngc remap you still need these python components.

Already got a window that said:

pycall(remap.change_prolog) fail

Not sure what different results I would get from a terminal. Nor do I know how to do that.

The link you provided doesn't really point to anything different than I have setup. There is no "Python" section for ini and I don't know what toplevel.py is or does which is the problem.

Can I just put the stdglue file in the same folder as my hal/ini file or do I need this toplevel file and if so does it need to be built a certain way to find the correct files?

Update: seems I missed some directions at the start of the Remap extending G code  

Got it working. A lot of little bugs in the ngc and some other odd things too. One minor flaw is that the carousel index sensor is on pocket 1 but the carousel component subtracts 1 pocket for some reason. So pocket 2 pocket 1 as far as the control is concerned.

Here are some notes to finalize it:

• Section 4 of the Remap Extending G Code tells you how to get the toplevel.py and stdglue.py which are required for any remap. Will also show you the correct ini settings which are not covered in the INI Configuration of the documents.
• When you tune the PID of spindle orient you should have a tool in the spindle. With a brand new spindle I had to update the PID loop with the added weight of a tool in it. This did however calm down the dither I was seeing.
• M6 T0 will clear the tool out of the spindle. No need to write that into your toolchange.ngc
• Nesting the toolchange.ngc subroutine was pretty important and took me some time and caused errors.

I appreciate the help. Machine is getting close to being done. Final files attached.