search

grblHAL / core

grblHAL core code and master Wiki
Other
310 stars 76 forks source link

Automatic Tool Change #278

Closed karoria closed 7 months ago

karoria commented 1 year ago

Hi @terjeio I just wanted to know if fully automatic tool change is possible with grblHAL or with combination of sender and grblHAL? If so, where can I write macro or program file for ATC routine in firmware?

terjeio commented 1 year ago

Fulyly automatic tool changes is possible if code to support the tool changer is provided. There are HAL entry points that can be claimed by such code, see this example.

karoria commented 1 year ago

Thanks Terje. I will try to understand it and write a code as per my requirement. Do you consider a common code in firmware for ATC related Inputs/Outputs defined as M codes and just write a nc program for ATC from sender side. That should be more generic and should support many type of ATC mechanisms and should be easy to go for so many users who don't know embedded C programming. If such M codes are existing presently, can you point me so that I can try developing ATC from webUI? How about planner buffer allocation in such case? When in TOOL mode, the system should be able to independently execute a gcode file in such case and return to RUN mode after successfully execution of ATC routine. Any thoughts?

terjeio commented 1 year ago

Do you consider a common code in firmware for ATC related Inputs/Outputs ...

Yes that would be possible.

... defined as M codes ...

M-codes are already available for I/O, but better to use the ioports API directly.

... and just write a nc program for ATC from sender side.

Where to store such a program? In RAM? And it would not be very portable (to different senders).

If such M codes are existing presently, can you point me so that I can try developing ATC from webUI?

M62-M67, FYI these commands is implemented on top of the ioports API. See below.

Any thoughts?

IMO It would be better to just use T and M6 commands and let the firmware handle the tool change. Some simple pseudo code could be used to define an ATC and a generic plugin written to handle that. Best would be to bypass the gcode parser as this keeps state information - if using that the current state has to somehow be saved and restored over a tool change.

karoria commented 1 year ago

Oh yes! ioports API and M62-67 implementation both are great stuff I was unaware of. Now I will study your example ATC code and refactor it as per my requirements using ioports. However, in my quick go through, I came to know that in your atc.c, you have not used ioports API. Am I right?

terjeio commented 1 year ago

You are right, I am using a second MCU to control the ATC - via I2C.

BTW the published atc.c code is outdated, here is an up to date version (but still not yet in use):

atc.zip

karoria commented 1 year ago

Thanks a lot. That will surely help me.

LoganFraser commented 1 year ago

Keep us updated on your progress @karoria, there's lots of interest on the PrintNC discord about ATCs and grblhal but not that many coders. ;)

karoria commented 1 year ago

Keep us updated on your progress @karoria, there's lots of interest on the PrintNC discord about ATCs and grblhal but not that many coders. ;)

Hi @LoganFraser Now we don't need to write firmware code for ATC as new macro support makes ATC very easy. Please follow discussion https://github.com/grblHAL/core/discussions/309 for updates. I have already made a very basic ATC for my machine using macros plugin code for ATC.