Toolchanger HAL Component project

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.

Just stumbled on this thread. About 90% of what you've written is over my head, but it sounds interesting.

I've got a home-made ATC I'm trying to get working and appear to be on the home stretch.  What problems have you had converting your toolchanger to LCNC that would prompt you to dive in the deep end of creating what sounds like a complicated solution?

You mentioned wanting some input or feedback?

 

I've already written a tool changer component for my lathe, i am trying to create a universal toolchanger system inside of hal as a component orrr it may be easier to do outside of hal and Linux cnc as a stand alone device.

i have 3 mills to retrofit right now, they all have the same tool changer, i can easily build the hal component for my situation out of code I've already written and debugged.
.the issue is how to reduce the pain for myself and anyone else trying to do this, and make it universal in design.

there needs to be a better alternative than plc, gcode remapping etc

I'm also generally thinking about porting the core Linuxcnc software to a c++ library, that can be compiled anywhere..

that's another discussion for another day

So, my plan is to create a tool changer configuration and program for each type of Mill that I own, and to slowly work towards a more universal design.

First up is my hurco slv40, I will post the files as I make progress. the only real difference between this machine and my other 2 mills is that on those machines the umbrella goes up and down, on this machine the Z goes up and down. So I have already written the macros to position it, and set up the calls to use the macros in the ini and hal file. I am working towards the rest of the program currently.

If anyone has a better way to move the Z up and down outside of a macro, I am all ears.

smc.collins wrote:

If anyone has a better way to move the Z up and down outside of a macro, I am all ears.
 

 

Maybe exteral offsets?  I think those can be set with hal pins, which in turn could be controlled via ladder or something else...

EDIT - not having used them, I don't know if external offsets can actually move an axis or joint.  But maybe in combination with other hal pins, perhaps something like a jog-to-position could be done.

External offsets works on axes 
linuxcnc.org/docs/2.9/html/motion/external-offsets.html

Have a look in detail how  QTplasmac (sim included by default with 2.9 and above) as it uses EO's to move the tool on a plasma table to the side to change consumables and return to the original position.

that's seems like a really long way around where a macro will do. the other option is to route the servo control loop through the tool change program and overide the position and encoder data when performing a toolchange, stoting the last know Z and reverting back to g28 at the end of the program.