custom hal component failed to compile, undeclared (first use in this function)

component cinturnchanger """This component controls the Cincinnati Cinturn 12u Lathe 6 position 12 tool turret. M6 calls this""";


pin in bit toolchange "Receives signal that tool change required";
pin in s32 toolnumber """Receives Tx data (tool number requested) Only allows 1-12""";

pin in s32 currenttoolnumber "Receives old tool number";
pin out bit toolchanged = false "Sends signal when tool change finished";

pin out bit delaystart = false "Starts timerdelay";
pin in bit delaydone =false "Signals timer finished";

pin in bit bcd1 = true "State of bcd switch 1";
pin in bit bcd2 = false "State of bcd switch 2";
pin in bit bcd3 = false "State of bcd switch 3";
pin in bit bcd4 = false "State of bcd switch 4";


pin in bit turretunlocked = false "State of turret unlocked switch";
pin in bit turretlocked = false "State of turret locked switch";

pin in bit strobe = false "State of strobe switch";

pin out bit motor = false "turret motor solenoid";
pin out bit unlock = false "turret unlock solenoid";

pin in bit ishomedX = false "Status of X axis homing";
pin in bit ishomedZ = false "Status of Z axis homing";


param rw s32 pocket = 0 "create pocket and use for debugging of truth table";

param rw float times = 500 """Number of polls of progress_levels 1 & 3 before beginning next move - gives delay for relays""";

pin out s32 progress_level = 0; // show progress of component in stages


variable bool bWarn = false; // first toolnumber reminder


option singleton yes; // change to no for multi turret machine, configured for single turret machine originally

function _;
author "OPEN AI CHATGPT and some guy with a broken lathe";
license "MIT";
;;



#include <unistd.h>
#include <time.h>


int i, d, pow;
int pcalc = 0;
int mod_pocket = 0;
int new_pos = 0;
unsigned int mask;
int align_pin = 0; // used for slow align move, input depends on mode for historical reasons






// BCD or Binary Coded Switch Decoding to determine turret position.



align_pin = strobe;
i = 0;
pow = 1;
pocket = 0;
while (i < 3) { // we only have 3 input bits: bcd1, bcd2, bcd3
int lim;
d = 0;
for (lim = i + 4; i < lim && i < 3; i++) {
d += (bcd1 & (1 << i)) + (bcd2 & (1 << i)) + (bcd3 & (1 << i)) << (i % 4);
pcalc ^= (bcd1 & (1 << i)) + (bcd2 & (1 << i)) + (bcd3 & (1 << i));
}
pocket += d * pow;
pow *= 10;
}
rtapi_print_msg(RTAPI_MSG_INFO, "Decoded pocket number: %d", pocket);





switch (progress_level)


{


case 1: // idle state waiting for tool change request

if (progress_level == 0)

{
if(!currenttoolnumber && !bWarn)

{
bWarn = true; // just warn once, its not an error as such but INFO won't display unless debugging is set 3+
rtapi_print_msg(RTAPI_MSG_ERR, "No tool selected. Use M6Tx to set current tool");
}
}
progress_level = 1;
break;







case 2: // check if toolnumber is within the bounds of the truth table

if (progress_level == 1)
{



if (toolnumber > 1 && toolnumber < 6)

{
progress_level = 2;
break;
}

else

{
rtapi_print_msg(RTAPI_MSG_ERR, "Invalid tool number. Use M6 Tx to select a tool between 1 and 6");
progress_level = 9;
break;
}
}






case 3:
if (progress_level == 2)

{
if (toolnumber == pocket) // If the toolnumber and pocket are the same, exit the program

{
toolchanged = true;
break;
}

else if (toolnumber != pocket) // If the toolnumber and pocket are different, proceed to the next case

{
progress_level = 3;
}
}
break;



case 4:

if (progress_level == 3)
{
if (toolnumber != pocket) // if requested toolnumber is different than truth table perform toolchange
{

// First tool change loop to run turret

unlock = true;
sleep(1); // Wait at least 1 second
motor = true;

// Set a timeout of 10 seconds

time_t start_time = time(NULL);
while (motor)
{
if (pocket == toolnumber)
{
motor = false;
}

if (time(NULL) - start_time > 10)
{
rtapi_print_msg(RTAPI_MSG_ERR, "Error: Motor loop timed out");
motor = false;
progress_level = 9;
break;
}
}


sleep(2); // Wait at least 2 seconds
if (strobe && pocket == toolnumber)
{
unlock = false;
}
else
{
rtapi_print_msg(RTAPI_MSG_ERR, "Error: Turret align failed");
progress_level = 9;
break;
}
}

}
progress_level = 4;
break;











case 5: // alert iocontrol loop that tool change is complete

if (progress_level == 4)
{


if (toolnumber == pocket);
if (turretlocked == true);
toolchanged = true; // signal finished


}
progress_level = 5;
break;





// should never get here but if we do then loop endlessly doing nothing

case 10:
if (progress_level == 9)
{
// rtapi_print_msg(RTAPI_MSG_ERR,
// "Error state in toolchanger - now disabled - unload toolchanger");
}
progress_level = 10;
break;

}

this is the current state of the code after working with chat gpt and learning my way around C more. It appears to have cribbed some of the code from carousel for decoding the bcd inputs, and I will ensure that the proper attributions are given afaict. I will simply put this under mit and allow for anyone who this may have inadvertently copied to put in open claims. Obviously some of this is my work, some is GPT's. It's almost working. maybe soon.adding error checking, fault states etc. and some debugging messages now to. I think the case switch statements are working properly now. haven't had a chance to test yet. I am probably going to end up rewriting the state machine with else if statements, the case logic seems to break constantly and the halcompile preprocessor seems to compile or compose it in such a way that it won\t execute reliably.

Looks much better

Although this will not affect how the program works I would now suggest to do a little work on indentation. Have a look here for the 'Why' and 'How'
www2.cs.arizona.edu/~mccann/indent_c.html


 

... Or just go there and have proper indentation done automatically: codebeautify.org/c-formatter-beautifier

(but where's the fun then mphhh)

.... or use a code block when posting code to retain the formatting...

Now onto my next irritation, why the hell is the tool table written SOLELY around the idea of a single tool spindle. ? I think I am going to look into changing the tool table and iocontrol logic to allow for multi tool turret stations, and then some additional logic.The redesign will encompass the following1. the logic to store multiple tools at each station in the tool table. IE reusing the station number while assigning/storing multiple tools worth of information at each station.. IE tool 1 and tool 4 on station 1, store the offset for each2, expanding the type of information stored for each tool, IE drill motor, hobbeer, etc. RPM and other data can be input here. I am not entirely sure on the design yet, but live tool information should be capable of being stored in the tool table IMHO.3. add more of the standard Fanuc Mcodes to IOcontrol, and the interpreter. pretty much everyone uses m68 m69 etc the same way etc.and here is the ternary rewrite, feedback appreciated 

here is the current switch statement, couldn't get the ternary logic to work  right. so went back to the drawing board. here is the conversation with chat gpt, walking through the code, as I read it this also appears to be the case, but I am absolutely certain there is some kinda quirky problem within linuxcnc at this point that is making me chase my tail. I have not tested this latest revision, but man, chat gpt makes it super easy to rewrite, iterate and explore code logic. If only it was netting me the desired results, but I am actually kinda enjoying learning C with chat gpt, and I hate programming. tedious and slow. not my kinda work. the problem is that the code stops executing at the end of the decoding for the pocket with the bcd switches, and I have no idea why.

Sure! Let's go through the code step by step:

The first line defines an enumerated type called ToolChangeState, which is used to represent the different states that the tool change process can be in. The possible states are INIT, SELECT_TOOL, MOVE_TO_TOOL, CHANGE_TOOL, FINISHED, and ERROR.

The next line initializes a variable called progress_level to the value INIT, which is the first state of the tool change process.

The if statement checks if the toolchange flag is set. If it is, then the program will enter the switch statement. If it is not set, then the program will skip the switch statement and continue with the rest of the code (if any).

The switch statement checks the value of progress_level and executes the corresponding block of code for that state.

In the first case (INIT), the program checks if the tool number is between 1 and 6. If it is, then the progress_level is set to SELECT_TOOL. If it is not, then an error message is printed and the progress_level is set to ERROR.

In the second case (SELECT_TOOL), the program checks if the tool number is not equal to the current pocket. If it is not, then the progress_level is set to MOVE_TO_TOOL. If it is equal, then the toolchanged flag is set to true, signaling that the tool change process is finished.

In the third case (MOVE_TO_TOOL), the program sets the unlock flag to true and waits for 1 second. It then sets the motor flag to true and enters a loop. The loop will continue until the motor flag is set to false. Inside the loop, the program checks if the current pocket is equal to the tool number. If it is, then the motor flag is set to false and the loop is exited. The program also checks if the loop has been running for more than 10 seconds. If it has, then an error message is printed, the motor flag is set to false, and the progress_level is set to ERROR.

After the loop, the program waits for 2 seconds and then checks if the strobe flag is set and the current pocket is equal to the tool number. If both conditions are true, then the unlock flag is set to false and the toolchanged flag is set to true, signaling that the tool change process is finished. If either condition is not true, then an error message is printed.

In the fourth case (ERROR), the program does nothing. This case


 

I converted this entire program to a jump table logic flow, after looking at the limitations of hal components for the last few days. quickly iterating through lots of failuire, While loops are out, polling speed just inhales the cpu, the switch statements don't seem to execute properly, not sure what is going on there i suspect some kind of parsing/compiler issue I don't have time to debug,  if else statements are to fragile and cause problems with recursion to easily, ternary logic got to convoluted. Cracked my programming books, and enlisted the sheer speed of the gpt bot and got this working for the most part, the code executes through the jump table as far I can test tonight, and the error flags reset properly. so, hopefully good news tommorow. I do feel as if the jump table is the proper solution for a fast polling program that needs to execute sequentially with minimal fuss. I might post up all the scrap code that's been debugged and executed thus far when I have a working component. I will be rewriting my other program for the lathe chuck as well using a jump table. I think it's more extensible, I may even revisit the bcd decoding as well in the not to far off future. 

 rebuilt my powerchuck hal component with similar logic as well. none of this is finished accepting design and input ideas. 

and yet another complete redesign, with error checking, fault states more optimizations, removed the jump table and other superfluous logic. Testing today, the virtual machine testing seems to indicate it should work. I even included a estop output to make it shut the machine off. If this is working good, I am working on powerchuck and then I am doing a estop loop component, all the current implementations leave me, wanting and are to complicated. I want my estop to do 1 thing, stop the machine, at all costs. now.

the basiuc design of the estoploop component will be

variable definable number inputs and outputs, a watch loop in the servo thread, and all output will be executed when any input goes to true. this way you can have one program that shuts down the machine. I might add a wait feature later for powering down hydrualics etc, and add some input check for things like spindle stopped etc. but start with the basics and add on. anyway here is the finished hal component I am testing for the turret changer, can probably be used with other tool lathe changers adding a few bits of ligc here and there, and yes it compile clean, error free, no warnings and has been tested on my virtual machine, ymmv, my sample hal file is not in any way rational, it exists only for testing in the vmc grey coded sim config

No need to write estop components.
The estop_latch component allows you to  build an estop chain in software using muliple instances
linuxcnc.org/docs/2.9/html/man/man9/estop_latch.9.html
There is an example here
forum.linuxcnc.org/47-hal-examples/25861-external-e-stop
I find its easiest to sketch out the estop-latch components in the chain before writing your hal file.
So if you had 1 estop button and say fault sensors for air, lube and a door switch, each fault would be connected to its own estop_latch fault-in and if any one is triggered, it breaks the chain and the machine will stop.
It would be safer to do it this way so you stay inside the Linuxcnc paradigm
 

no I want 1 master estop control, period, writing that as multiples is just to many paths for failure. it's the illusion of safety through excess complexity. in my plan, ANY component sets a estop whether single or parallel ALL estop engages everywhere. your' making a chain of failures there.

Rodw, if you see any obvious errors in loigic or known no no's here with what I have, I am getting close. I did sucessfully operate the tool changer today and I decided to add more logic and fix a few nagging issue. Also included the error states, lots of those, the fatal errors disable the tool turret and set the estop actually. I also expanded the tool table in the turret code. it does work btw. for those who might be interested in how to implement a multi tool per station lathe turret.