M6 Remap for ATC with carousel

More
22 Feb 2021 06:09 #199676 by Michael
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?

File Attachment:

File Name: toolchange...2-22.hal
File Size:2 KB


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).

File Attachment:

File Name: toolchange...2-22.ngc
File Size:3 KB


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.
Attachments:

Please Log in or Create an account to join the conversation.

More
22 Feb 2021 19:57 #199757 by andypugh
You might not need the prolog and epilog files, depending on your system. They mainly serve to put some tool data in to named G-code parameters.

However, the pre-made ones that are part of LinuxCNC should "just work"

Please Log in or Create an account to join the conversation.

More
03 Mar 2021 15:32 - 03 Mar 2021 20:12 #200910 by Michael
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.
Last edit: 03 Mar 2021 20:12 by Michael.

Please Log in or Create an account to join the conversation.

More
03 Mar 2021 15:42 #200911 by andypugh

Michael wrote: 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.


No, I have never been entirely clear on the difference myself.

How to configure to use it is also not particularly easy to find out.

linuxcnc.org/docs/2.8/html/config/ini-co....html#_emcio_section

EMCIO = io
or
EMCIO = iov2

(I did think that I had put that info in)

The files are quite short, so the differences should be evident.
github.com/LinuxCNC/linuxcnc/tree/master/src/emc/iotask

Please Log in or Create an account to join the conversation.

More
31 Mar 2021 15:40 #204236 by Michael
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 */

Please Log in or Create an account to join the conversation.

More
01 Apr 2021 10:14 #204382 by andypugh
I think that a lot of the rationale is described here:
wiki.linuxcnc.org/cgi-bin/wiki.pl?ToolchangerProtocolProposal

Please Log in or Create an account to join the conversation.

Time to create page: 0.085 seconds
Powered by Kunena Forum