Project done 
Photos and videos att. Also, I my original post with the new design, and files.
3 Likes
Did you end up actually trying this design?
I’ve got an idea for a sort of inline module that modifies a toolhead cable to have a phone trs audio socket and the minimum hardware required for the probe to talk to the can bus built into the side that plugs into the module. (In my mind right now this is a buck converter, a teensyLC and a trs socket, plus maybe some caps for noise)
This would sit right on top of the cnc module and allow you to mount the probe to the toolholder and just plug in the cable from the probe into said module.
This solution does not permanently modify anything other than a 5eur cable and, with that functionality, the problem of repeatability of this machine can be somewhat mitigated, because at least if you square it right, z tilt front to back is usually my biggest problem.
It should also be fully compatible with future revisions of the toolhead, as I’d expect them to keep the plug the same.
I think making a module firmware by stripping everything away from the 3dprinthead and just leaving the probing function should work. (I’m trying to figure out that right now)
I did not, and have no motivation to anymore. It will require firmware modifications and the developers keep introducing radically breaking changes that make no logical sense. As such, any such time investment will require fixing after every change they make.
I have done a fair amount of development in this codebase and it’s been a pain the whole way. The culmination of my last major pull request is the latest change the devs pushed broke functionality because they decided to scatter “safety” code all around the codebase in random places. This is after I’ve patched it about a dozen times for other breaking changes they pushed.
My takeaway is as long as the developers are continuing to change protocols, communication, and otherwise ignore Marlin’s logical organization and built in functions there’s no reason to spend any time doing development unless you want to a) never upgrade your firmware again or b) spend the rest of your days patching every release.
1 Like
@pastitas I got mine working, and I agree with @brent113, on his words. Now, if you want a reliable 3D-printer-only, buy a Prusa. Mine, never let me down. I decided to buy a dedicated low volume CNC machine which also allows me to attach ANY laser I want for cuts. It’s two (Prusa + CNC/Laser) machines instead an “all-in-one”, but all works properly, and as expected. I’m now using my machines instead of developing them.
1 Like
Which CNC/laser did you go with? I’m in the market for one for the same reason. Looking at a shapeoko or similar probably - there’s several in that price point.
I actually come from there.
I have a heavily modded ender3 that, for two years now, just works, and a chinese 3040 cnc machine that was really functional and sturdy, but was not useable at all. Reason being I kind of obsessed on building it myself electronics-wise. This has been an incredible learning opportunity and has served the purpose of being a “low-cost”(all in all around 600eur) cnc machine that I’ve learnt with. This is something I woudn’t really recomend since is messy, and has lead me to a lot of trial and error. There was one for around 300 eur that was interesting for a starting point, but way less sturdy or powerful than the snapmaker.
My reasons for buying the snapmaker were mainly 2:
- ease of use (which i feel was a bit underdelivered)
- reliability/build quality (I’m fairly impressed and, if you recognize the limitations of the machine, it’s delivered)
A machine that really seems to deliver on what I’d need is the carvera by makera, albeit being very expensive.
I’ll probably end up building a sort-of carvera-inspired DIY cnc machine that would be open source, but for now maybe I’ll try to find a middle ground between not updating (until really big features are implemented) and patching only when major changes are done if I end up developing this solution further.
@brent113 Thanks for the heads up, but for milling PCBs I find it hard to use a different solution from a z probe that can do a matrix with height measurements, and I’d really like this to be a feature of my machine.
@thalesfsp when you say you got yours working you mean the above printed parts or a solution that integrated with electronics and all?
Just checking that you understand you’re going to have to read that matrix into your computer and rip the gcode in theory something like this: GitHub - martin2250/OpenCNCPilot: autolevelling gcode-sender for grbl. The matrix cannot be applied on the machine natively.
For getting those measurements the original probe I was proposing would not work well at all as it was primarily for internal use in the firmware. @thalesfsp’s data logger is much more elegant.
For getting datalogger measurements I usually use a spreadsheet to generate gcode scripts. Those scripts could easily be played back through a command line where the height responses are captured for further processing.
Or, that OpenCNCPilot project could perhaps be modified to work with Marlin, and then a probe is added natively to the toolhead like originally proposed.
My original idea was to use the native marlin leveling matrix, but your response makes me think that that wouldn’t be an option.
If I was to use some software i’d just use some sort of esp32 wireless solution that talks to the pc via bluetooth.
Honnestly, I’d rather not delve to deep into the software bit since it’s easy to get lost in the woods
That’s exactly right, because the native marlin levelling matrix is fixed size and too coarse to be useful. Even at the maximum the controller can handle of 11x11 the resulting grid size an an A350 is something like 35mm on a side. And even if that was granular enough the probing would still probe the entire bed and transition “Z=0” down from the PCB to the bed surface making it unusable on the edges.
mood lol. Also esp32’s run on wifi not bluetooth. And if you want to go that route check out tasmota - that’s what I use to control my sea of IoT devices. Supports OTA upgrades and is pretty featureful. That would be a relatively easy way to get wireless contact closures back via MQTT.
1 Like
I got both, my 3D “multi-head” stuff and levelling. @pastitas I did what @brent113 described. I love DIY too, for the same reasons: learning skills and reduce costs, but I got tired of fighting the machine, and the code, and the lack of community’s support from Snapmaker. IMHO they lost a HUGE opportunity to be big, work with the community, open source stuff, people could build many new modules, and etc, but look, you don’t even have the fully spec of the machine shared with the community, I believe there’s a thread somewhere about “reverse engineering” it so people could get that working/“modify” that. Passed all these years, and almost no new modules but people struggling, frustrated, and “developing”/“fixing” an unfinished product.
I went from “this is a nice machine” to finish my projects on that, and use my good and old Prusa, plus OpenBuilds. I don’t regret.
My Snapmaker is set to be given as a gift to a close friend which loves Warhammer but has no money to buy a high-quality resin printer, he is a talented painter and finisher which deserves the help to kick-in the next step on his life.
Best regards
Another thing you could do: scan the surface in as a 3d mesh (I’m sure there’s something out there to do it given a grid of height points), pop it into f360, and just apply a sketch to the surface top, then just generate the CNC paths from f360 and it should “just work” (ofc, this is all theory so don’t trust me). I think I saw AvE doing this perhaps in one of his videos (but I don’t remember which, and it could have been some other YouTuber).
1 Like
Now that I think about it, as long as you could have a working G38 command on the CNC head candle gcode sender can do the matrix leveling of the gcode. Could that make it more feasible? Just trying to measure how much needs to be changed, as if this is possible, as long as we can trigger a probe operation and return the state of the probe when activated there might not be a need for anything else.
In other words, If there’s no need for implementing any specific gcode is there any reason why firmware changes on the controller itself if we can manage to send a “probe activated” can message from the custom board?
I’d say if the only reason you can’t run a g38 command is there’s no probe, that would be a fix for that.
1 Like
Actually in the docs it appears the gcode is supported, and should count any endstop trigger as a probe activation
https://snapmaker.github.io/Documentation/gcode/G038
I haven’t been able to replicate this using the endstops, as it seems to wait for the endstop to trigger
but it does not move the machine at all
Yes, g38 works because Marlin wrote that documentation and snapmaker did not modify any of the existing g code they only added like a couple new ones at the end
But of course the problem is the only probe is on the 3D printer head and so you would have to g38 with the print head
And yes you’re correct if you read through the source code any end stop trigger counts and the probe is an end stop… At least for g38. Not for g30 entirely.
Have you been able to do a G38.2 or .3 command that actually moves the machine?
after reading the code I tried to do the test myself but I’ve never set up the 3d printing head and with the CNC head the axis didn’t even move.
My idea was to open one of the linear modules and try and manually activate the endstop while the machine is doing the G38, to see if it would stop it.
Splicing into the enstop (just soldering some extra wires and a trs socket, and printing a new cap for the module that exposes the port.) would be more of a hardware modification rather than a software one, but could work as a solution.
Yes, I have. Everything works as expected at least on firmware 1.10. Used the spatula to trigger. This is with the 3dp head obviously. I tested every g38 variation successfully
That’s an idea I haven’t considered. Can’t see any reason that wouldn’t work. What are you going to trigger with, a normal ruby probe? Just hook in series with the NC (I think) end stop?
That’s hella easier that a firmware mod
Okay, so there’s something in the module code that stops movement when no probe is defined. That could be modded into the module firmware itself I guess (if swapping heads for the probing was enough of a PITA)
Is there resources for running custom module firmware?
I don’t see any changes to the cnc module code since a year ago, and only one commit actually changes code (although it’s a lot of it) so maybe maintaining a custom module firmware version is less work than any other option regarding controller firmware.
Yeah, I was thinking on the probe you specified above, something DIY with a similar design to this that acts electrically like a normally closed (if that’s what the endstops are doing). EDIT(this looks hella sexy but probably not so useful)
Sure sounds like it is, and also plugging in the 3d print head for probing seems like a minor inconvenience if modding the module’s firmware themselves turns out to be too much pain.
It’s simpler than you’re thinking. The firmware is just awaiting an edge trigger of an end stop which is provided over CAN via a function ID.
Yeah I’ve done it, it’s pretty straightforward you just compile from the module GitHub with any modifications you’ve included.
That won’t work, you need just the probe to report its function ID on the can bus and not the entire tool head because otherwise the controller will not accept multiple tool heads plugged in simultaneously. You just need some piece of hardware somewhere on the can bus that reports a function ID corresponding to the probe state. My original thought is this would be a separate piece of hardware completely divorced from the tool head and module firmware. Of course you could integrate it directly into the CNC custom toolhead firmware
yeah, my dream solution would be to just open the CNC head, find a unused GPIO and splice it, then modify the firmware to read the state into the probe state. This of course assumes many things to be possible that might not be, and also permanently modifies an expensive component of the machine.
Here’s where my idea of the modified tool cable with the inline CAN hardware with the trs plug for the probing. This only modifies 1 cheap tool cable and could report the ID on the can bus without problem (as I understand, the can bus of the toolhead and linear modules is the one where the probe should report.)
Maybe We’d need to add the probe initialization to the toolhead firmware so that the machine knows there’s a probe (although I think that you just told me that wouldn’t be necessary) but it seems like a minor thing to maintain.
That was my thought as well, something that is separate from the toolhead entirely. The toolhead wouldn’t need to know anything about the probe, but the controller firmware would require a decent chunk of work to get it working as the probing-specific initializations that register the CAN callbacks for handling probe changes exist solely in the 3dp object. All of that functionality would need to be duplicated over onto the cnc objects, as well as writing a new mcu firmware to monitor the initialization of the toolhead at startup and then supply the correct registration information that the 3dp head would’ve sent to initialize the probe functions.