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

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