I hope a moderator renames this thread. if anyone is wondering I HATE underscores, they are awkward to type and I find them obnoxious to deal with later in the code particularly in the hal file pin naming, Camel Case Is More Natural To Type and you follow each instance with a Number it is easier to read and type. I will be using the Haiku Operating system coding guidelines for the most part, I find them functional and easy to read, but deviate where I feel it necassary or convenient for me.
This VariableIsEasyToName1
Step 1. design a block of reusable code, that does 4 basic things
1. read a input, compares values and commands an output,
2. can error check itself in multiple ways
3. can be accurately sequenced
4. is inexpensive to execute we have time deadlines to meet.
here is that block
1. need a timer to control the pac of the executions for some outputs
param rw float FunctionTimer0 = 0.0 " variable for timer control";
pin in float FunctionTimer0Value = 1.00 in seconds;
2. we need a watchdog to ensure the execution doesn't take to long
param rw float WatchDogTimer0 = 0.0 " variable for timer control";
3. we need a execution system to control code flow. as we enter the next block in Count2, we will set the True to False and clear the execution block from falling through as is SO problematic with execution loop.
pin out bit Count1 = false;
then we end up with this code block here with the above control variables in the hal component, this is the turret unlock routine out of my Cincinnati Lathe turret component. The plan is to refactor this into a generic block that cane be configured in the hal file. The question I have is, what are the most common types of tool changer configurations ? how many steps are there in each direction to and from the storage magazine to the spindle and back ? I am thinking I might just set this up with 10 blocks in each direction ?? I think that should cover it and then make the variables for the block numbers accessible in the hal file.
If anyone has a better alternative approach to this, lmk, I am open to idea and the code is kinda in a very amorphous state.
There is a lot happening in this block of code, execution control flags, error flags, diagnostic timeouts and messages etc. This prototype will serve as the basis for constructing the Toolchanger.comp file and program. unless someone has a better idea. The parts of other components like carousel etc could be integrated into this to reduce more hal wiring, which IMHO is a good idea. Better to debug in one place then 100
if (count1 == true){ // unlock and count1 start this timer
timer0 += fperiod; // timer is incremented by fperoid
count2_5 = true; // start timer for turret watchdog
}
if (timer0 > unlockpause && toolchanger == true){ // 1 second unlock pause
count2 = true; // move flow control forward
count1 = false; // flow control rest at start of routine
timer0 = 0; // clear timer to clean up
}
// turret unlock time watchdog system make sure turret unlocks in reasonable amount of time
if (count2_5 == true && unlock == true ){ // unlock and count2 start this timer
timer1 += fperiod; // timer is incremented by fperoid
}
else{
if (timer1 > unlocktimeout && unlock == true){ // if timer1 is greater then unlocktimeout setting and toolchange is true
count2_5 = true; // flow control rest at start of routine
}
}
if (timer1 < unlocktimeout && unlock == true){
count3 = true;
}
if (count2_5 == true && timer1 > unlocktimeout) { // just changing the timer name, becuase memory leaks
unlock = false; // disable motor
toolchanger = false; // top toolchange code flow
count100 = true; // set this error flag
estop = true; // disable machine
count2_5 = false; // cancel timer
if (set_warn_flag12 == false){ // block repetitive error messages they are annoying and flood the system
rtapi_print_msg(RTAPI_MSG_ERR, "Fault 010 TURRET TOOK TO LONG TO UNLOCK EXCEEDED ESTOP ON TOOLCHANGER DISABLED");
set_warn_flag12 = true; // set flag to block prinint excesive error messages
counterT = 105; // diagnostic counter if the program hang use this in halscope to capture the value when it does, at least you got a shot
} // diagnosing the problem
}
