tool changer component design feedback wanted.

alright, so I have been thinking long and hard on how to engineer the toolchanger component, here is a 5000ft view. before I head down this path, let me know if there are any kinks in the road that I have not considered. when completed this should give the community a configurable toolchanger component that can in theory drive almost any tool changer out there and should be extensible well into the future. anyways I have been having chat gtp produce a lot of the boiler plate psuedo code simply because I have ben super busy but I have been thinking about the process more than the code.  

Got it. Given the mapping you've provided:

1 is for linear motion, with 11 being the first instance.
2 is for orient, with 21 being the first instance.
3 is for carousel motion, with 31 being the first instance.
We can certainly design a state machine that uses these codes for operations and executes sequences like 11 21 31 12, based on the provided string from the HAL files. We can then use the HAL files to also configure various parameters of each instance.

Here's how you can design this:

State Definitions and Data Structure:
c
Copy code
typedef enum {
LINEAR_MOTION = 1,
ORIENT = 2,
CAROUSEL_MOTION = 3,
} OperationType;

typedef struct {
OperationType type;
int instance;
void (*func)(void* config); // Function pointer with a configuration parameter
void* config; // Pointer to configuration, populated from HAL file
} OperationInstance;

void linearMotion1(void* config) {
// Access configuration using config pointer and implement logic
}

void orient1(void* config) {
// Access configuration using config pointer and implement logic
}

void carouselMotion1(void* config) {
// Access configuration using config pointer and implement logic
}

// Create an array of operation instances
OperationInstance operationInstances[] = {
{LINEAR_MOTION, 11, linearMotion1},
{ORIENT, 21, orient1},
{CAROUSEL_MOTION, 31, carouselMotion1},
//... more instances
};
Execution of Operations:
c
Copy code
void executeOperation(int code) {
for (int i = 0; i < sizeof(operationInstances) / sizeof(OperationInstance); i++) {
if (operationInstances.instance == code) {
operationInstances.func(operationInstances.config); // Execute with the corresponding configuration
return;
}
}
// Handle error: operation instance code not found
}
Reading and Execution from String:
c
Copy code
void executeSequenceFromString(const char* sequenceString) {
int length = strlen(sequenceString);
for (int i = 0; i < length; i += 2) {
int operationCode = (sequenceString - '0') * 10 + (sequenceString - '0');
executeOperation(operationCode);
}
}
Configuration from HAL Files:
You can define a struct for the configuration of each instance. When reading the HAL file, populate the configuration structs accordingly.
For example:

c
Copy code
typedef struct {
int timerValue;
int configPin;
// ... other configurations ...
} LinearMotionConfig;

// For instance 11:
LinearMotionConfig linearMotion1Config;

// Populate it from HAL file:
linearMotion1Config.timerValue = // value from HAL file;
linearMotion1Config.configPin = // value from HAL file;

// Then, set the config pointer in the operationInstances array:
operationInstances[0].config = &linearMotion1Config; // Assuming 0 is the index for instance 11 in the array
This design allows you to:

Execute operations sequentially based on a string of two-digit codes.
Adjust various parameters for each instance via the HAL file.
Avoid potential conflicts as each instance has its own configuration.
This modular approach also makes it easy to add more operation instances in the future.

I don't understand anything past "Got it...", but thank you for your efforts on this.  Your 5000 foot explanation sounds both promising and useful.

trying to figure out how to make configuration of the component as simple as possible. I'll work up a code draft over the next few weeks.

the paste function with the forum software is abysmal

smc.collins wrote:

the paste function with the forum software is abysmal

Try CTRL-V 

When I use that it bypasses the secondary paste box and just immediately pastes.

Alight so I have been thinking more about this.

The first issue is, originization of the various parts of the hal component to be easier to implment.

So we have a naming and ordering scheme.

for instance we have functions those are define with 2 digit numbers.

For instance Motion " linear or rotary " has a timeout limit and is turned on in sequence dicated by the second 2 digits. so for instance motion1 is defined like so in a string sequence then ordered by the hal component.

0101 so Motion step 1 and then 0102 motion step 2,


so the setup string in the hal file looks like this

createinstance 0101,0201,0202,0301 etc etc etc etc etc

so I am thinking a rough organization like so.

01 orient
02 motion
03 position " carousel integration ? not sure yet"
04 macro calls " needed for Z on some machines for move spindle"

so that gives up up to 99 function types. each with 99 possible types of motion with up to 99 instances of each. I think this covers every type of toolchange I can think of and I have studied a number of those systems.

Internally, we parse the string from the hal file this create the instances from pointers and give us the order of each component.

Internally in the hal file,. each function will have a somewhat rigid structure, but the ordering will come from the string. there will be probably be 4 states for each function, waiting, running, sucessful/ completed and failed, obviously failure trigged by a timer if the motion output does not flip on the input in a set amount of time. IE we turn on the air solenoid and the end stop switch takes to much time to reach it the machine faults out with a Estop command.

. in the hal file that might look like this

motion1 = htmi,output,1,1,1 ( solenoid)
motion1return = htmi,input1,1,1
motion1failtimer = 2.0 (seconds)

etc.

so I am trying to design up front the configurability that is required in the hal file to make this much easier to implement. Obviously this is somewhat limited to the hal file format, so concessions have to be made here but I am thinking about how this might integrate into some of the utilities that exist for working with hal files and configurations.

What would be helpful, before I get into writing to much code, would be

1. what kinds of functions are required ?
2. are there any examples of parsing input string that I can look at ? 
3. I could use some help with writing the pointer functions, if anyone wants to help, greatly appreciated. 

anyways, looking for feedback on this thanks

I don't know anything about tool changers but:
I don't like hard coded lmiitations
They do your head in to understand, but have a look at personalities and arrays in components. They may work.
linuxcnc.org/docs/2.9/html/hal/comp.html

very much going for KISS here