My journey of switching from Onefinity/Buildbotics Controller to gSender + SLB

My suggestion behavior should be:

  • When Passthrough is enabled, the gSender just send whatever M6 line code to the firmware and also disabled the “Strategy to handle M6 Tool change command” drop down. No alteration to the M6 command and no pop-up.

  • When Passthrough is disabled, the “Strategy to handle M6 Tool change command” should be enabled and whatever the options is selected, it will continue working as-is.

I can probably make the code changes and request another pull-request if this something you agree.

Can you remind me, how are you performing the tool change function currently for the RapidChange if you’re not using modified firmware and not using modified gSender - is it one of the tool change strategies you’re using?

I’m using RapidChangeATC macros stored on the SD card. These macros can only be executed if the NGC_EXPRESSIONS_ENABLE flag is enabled. However, this flag can only be enabled during the firmware build process, so I need to rebuild the firmware. The NGC_EXPRESSIONS_ENABLE flag is already enabled in the PlatformIO configuration for the SLB-Ex for the Alt Mill so I assume that for the stock Alt Mill firmware, this should work out of the box.

When the firmware encounters an M6 command, such as M6T1, it will invoke the macros from the TC.macro file.

The P200.macro file contains all the configuration for the ATC, including machine coordinates, tool setter settings, etc.

All macros can be found here: GitHub - greilick-industries/rcatc-scripts-grblhal: Macros for the integration of RapidChange ATC with GrblHAL..

There are also special commands, like M61Qx, where x is the tool number, which tells the firmware what the current tool is. This is necessary when booting the SLB, as the firmware doesn’t know what tool was last loaded after the shutdown. I was looking to improve this on the firmware but busy with some other stuff.

On the gSender side, I don’t need any strategy, I just need the M6 command to be send to the firmware as-is.

This is completely different from Dons video which only use grbl and gSender macros. This is the preferred way of doing it for grblHal. I’m working closely with Don and James, the creators of RapidChangeATC. He was actually excited that I was able to make it work with SLB and gSender. By the way Onefinity recently announced a partnership with them to developed an Easy ATC specifically for Onefinity machines, same concept just different shape. :smiley:

2 Likes

Hi siganberg, excellent work. I’m a new Rapidchange ATC customer and attempting to implement it using a Big Tree Tech SKR 3 board. I’m currently struggling with the source code not supporting reading from the SD Card and facing challenges trying to work through that. In the interim, Don suggested starting a correspondence with you regarding your work with G Sender. Until I get the sd card reading, or the grblhal macros working with the macro files loaded onto the eeprom or use a fram via i2c, I was going to just go the vanilla grbl route with the macros in g sender. He said you might have some tricks to stop the user interaction loading prompts etc along with some other insights. I can’t private message on this forum yet due to my lack of posts, perhaps we could chat via discord?

So basically I found 2 issues with gSender. First, the gSender is actually altering the original gcode line of M6 or omitting it depending on the preference settings. Second, it pops up a prompt message, which is really not required for ATC.

With this issue, I forked the gSender code and made my own modification to fix this issue. There is already a Passthrough flag in the preference I use to fix those issues. You can see more details on my previous message here with Chris.

You can find my own gSender build here: https://github.com/siganberg/gsender/releases/tag/untagged-cef17eba85a62920925a

But all of this information is for grblHal and I didn’t work with just regular grbl.

So I’m also going to Grblhal with an stm32h723 based skr 3 ez. The webuilder doesn’t seem to support the sd card tinyfs or eeprom / fram over i2c. I’m going to take a stab at compiling it with platform io. There’s an older fork of Dresco’s branch for these boards where the sdcard has been made to work, but it’s a couple of years old. I want to have the gsender vanilla grbl workflow as a short term backup plan. I use my router in my home shop for my work and there’s a real need to get some parts done. The grbl workflow with your custom fork for gsender will help me if I run into issues implementing the gs274 regex code to keep working and utilize the atc which will free me up a lot. Thank you for your help. Are the macros in the fork?

Macros for grblHal can be found at RapidChangeATC git repository.