Toolchanger HAL Component project

So one of the problems, with hard switch logic that iterates every single loop, is switch input noise. working within the constraints of halcompile , the linuxcnc rtapi behavior I have observed and the compiler and the code that it generates, I devised this after some trial and error for input filtering.

I plan to implement all the variables as params and io but the current variable naming is essentially there for discussion.

If anyone see's any obvious ways to improve this I am open to the idea. As you can see the camel case naming makes spotting and reading variable names much easier !

bool SwitchUF = false; // unfiltered input
bool SwitchFT = false; // filtered output
bool TimerFlag = false; // to control buffer counter
int float FilterBuffer = 0; // default state of buffer
int float TimerBuffer = 0; // timer

if ( SwitchUF != SwitchFT ){
Buffer += feriod * 100;
TimerFlag = true;
}

If (TimerFlag = true){
Timer1 += fperiod *100;
}


If (SwitchUF == true && (buffer / 10 >= 1.2) && (buffer <= timer1)){
SwitchFT = True;
Timer1 = 0;
Buffer = 0;
TimerFlag = false;
} else {
if (SwitchUF == true || false && (Buffer / 10) <= 0.7 && (Buffer < Timer1)) {
SwitchFT = false;
Timer1 = 0;
Buffer = 0;
TimerFlag = false;
}
}

 

I wrote a new filter algorythm, it is much simpler than my previous attempts and it acts as a debounce and rolling average filter. will post tommorow once I do a bit more debugging on it.

Got a little bit of coding done tonight. Long way to go still but I already flushed out a good bit of the needed code in the other file above. I will start merging these together soon.

I propose, Block, it can be copied and pasted relatively easily, uses a very flat construction idea and includes a error state and execution watch timer. More to come. It will be a part of the toolchanger, but it does a bunch of things. Creates the first way to adress logic steps, integrates 2 timers, and turns on a output based on inputs and conditional variables etc.

filtering pocket values, versus de-bouncing the switches, both have trade offs, if there is a machine with a lot of input switches, pocket filtering is probably a better solution. This little snippet is working well in my applications, it starts a debounce timer and then it uses a rolling average incremented  and decremented by the pocket boolean value  changing. this works well so far in testing, the variables are adjustable to.

in this configuration, the timer period is 10 msec, and if the switch is false it subtracts from the filter and if the switch is positive is increments the filter, the pocket number change can only be true if for 10 consecutive cycles the switch is either true or false. other wise the output will have to wait until one of them is true and as they can botr change the value from -10 to 0 to 10, it creates a weighted average based in input switch time. Think of it as duty cycle in 10% increments. once the duty cycle is -100% or +100%   and the timer is greater than10 fperiod loops, then it updates the pocket number or it doesn't. better than a simple timer, avoids crazy filtering algorithms and solves noisy input problems, needs a watchdog timeout added for the case where the primary timer is greater than 250msec or some  type of value , then fault out with a error for switch input noisy etc.  


if (PocketFilterFlag == true){ // is flag true to start comparison value count
PocketFilter += fperiod; // set in milliseconds
}

if (pocketunfiltered != pocket){ // set flags and start comparison operator for new pocket value
timer8 = 0;
timer8 += fperiod; // increment timer in milliseconds
PocketFilterFlag = true; // set the flag
}else{
if (pocketunfiltered == pocket){ // cancel if pocket and pockunfiltered are the same and supress timer
timer8 -= fperiod; // flush timer
}
}

if (PocketFilter >= timer8){ // set new pocket value if the pocket value is euqal to or greater than unfiltered for more than 10 milliseconds consecutively
pocket = pocketunfiltered; // set pocket value
PocketFilterFlag = false; // clear flag
timer8 = 0; // flush timer
}



 

Day3 of program build, I will need some folks to help debug and test code soon, if you know C or C or really any programming language, the help will be needed, this is going to be a 3000 line program most likely.  I am trying to reusue as much debugged logic as I can to prevent bugs. a good bit of boiler plate and variable naming modification. the main portion of the control logic is flushed out, and because most all of it is the same, debugging 1 blocks fixes ALL of the execution blocks. Next up, I need to think on how to get from the end of the block to the tool changer and back again. I can get to the carousel but I need to think about how I am going to get back from the carousel pocket to the logic blocks. Need a day or so to think on that one. Feedback wanted if available. I will get started on a hal file shortly so people can experiment if they want to. 

removed watchdog timers form execution blocks as they were superfolous, streamlining the logic of the blocks a lot, removed excess variables and bits etc to simply the logic. working on duplicating the logic for all 10 blocks now. figured out how to enable and disable the carousel with caveman logic. added some checks and changes some arguments. Cleaned up and streamlined the logic. file is truncated to 2 ready to start testing blocks, need to finish the other 8. 

I am in the redesign stage, and I am actually considering standing up a small TI Dev MCU with a c++ code base that will talk to hal over serial. But it's one of many design paths I am considering, offloading the toolchanger to a micro controller using the TI RTOS on a dedicate card would solve a lot of the code complexity issues with trying to build this in a hal component.

I am open to all kinds of ideas, but this one may be the best long term.