External Z Probe Sensor

[brent113]

Hi everyone, new to the forum, got my A350 a couple weeks ago and after a thorough calibration it’s working well.

Huge shoutout to @Tone and all the other forum posts that helped me get through some of the common problems.

My background is in electrical engineering and programming, and I have an older delta printer I modified a version of Repetier for, adding in an external Z probe sensor switch, which solved quite a few problems, as it didn’t come with a z-height sensor.

I was thinking about CNC tool changes on the A350, and the paper method works pretty well, but I also have a small project box I made with an alligator clip and touch pad that turns a light on. You clip the alligator clip to the tool, and slowly lower Z until it just barely turns the light on, then you know the tool is at the right spot. The next step for me is to get that functionality as automated as possible.

I’m thinking there’s a couple paths forward:

1. Like Repetier, it would be awesome if there was a way to get the touch probe to be read directly by the firmware. The 3DP toolhead has a z-height sensor built in, but the CNC would need a sensor plugged in somewhere else, perhaps via a CAN connector - but this would require significant firmware changes.
2. Write a plugin for Luban or external API that automates the process. I could get the sensor status into the computer via a USB microprocessor (Arduino or equivalent). Then I could write a plugin or API to issue gcode commands that mimics the functionality of a G30 single point probe to measure the tool stick-out and adjust the z-offset appropriately.

It seems to me like the next steps will depend on the future releases of either the firmware source, or documentation for the Luban plugin system. Now that the Kickstarter has been fulfilled, I’m looking forward to progress being made on open-sourcing the firmware and adding drawings and documentation to the ecosystem, like has previously been indicated.

Has anyone seen any documentation or information already available that would allow something like this to be implemented now? I looked through the Luban source code, and writing a plugin seems almost unattainable at the moment, it would be very hacky.

Edit: Aha - I’ve found the firmware from here: FYI:Source code of Snapmaker Firmware
Will take a poke around.

Also found some work already done from @Streupfeffer from here Poking around in CAN Bus

Will update if I can make any further progress.

__
Brent

[xchrisd]

@brent113 Great to have you in this community, Welcome!

I will forward this to the sm team @whimsycwd @parachvte @Edwin @JKC20, please make it possible or give us some hints how we would be able to do so

[xchrisd]

@brent113 Here is a topic which could be interesting for you, its the same idea, but he didn´t has as many time as needed…:

Autoleveling and CNC journey

I decided to add autoleveling to snapmaker for cnc, I don’t have a problem milling pcbs but I would like to make the process easier. Right now I can mill a board in 1 shot correctly, but it’s slow and loud due to having to move at 6% speed, I’ve attached a picture of the results below: [20200409_220417] [image] This is a good result but it could be better, namely if there was autoleveling, I could move faster and also use isolation routing. Based off Lubans source code I’m trying to figure …

[brent113]

Sure enough, thanks!

[Streupfeffer]

Just had a quick Ohm meassure on the CNC Module. To my surprise the Motor rotor isnt connected via bearings or simmilar to the GND of the Powerconnector. Same for the Controller side. The Metal chasis isnt connected to either 24V or GND, which is a good thing i assume. So your options of having a “simple” check for continutiy might get a bit more complicated. BUT if you get yourself a Pogopin wiht a round head, some Coppertape with conductive gluestrip you could do a Slipring like connection above the milling for the Wrench to tighten the ER11 Nut. Or the simpler route, some springmetal instead of the Pogopin.

What ive found sofar, each of the Modules exposes a set of [3V3,DIO,CLK,GND] Pins on the board. Maybe with a modified firmware of the Toolhead you can send stuff from an arduino to the Toolhead which then is packaged into a CAN msg which is then understood by the controller. So much to modify but depending on how the 3D Printhead Probe works its a “small” change in code to do something with the Data.

If you’re not stretching the size of the work area, a Probepoint at the bottom of the left Linear Module would be an option. (The block is 30mm high.) Checked for clearance with the print bed attached and the MDF board layed ontop.
If you keep it close to the centerline of the Linearmodule, you would need a probe with roughtly 50mm (to the Black Nut, Toolstickout and such not considerd) to not drive yourself into the MDF. Homing and then lowering to 10mm or so is enough to get there. No need to hack stuff around and drive the Modules further down then the internal Coordinate system wants them.

[brent113]

This is the circuit I’m using now - a touch pad with and alligator clip you clip onto the tool. I’ll worry about getting it 100% hands off if I can get the basic concept working - for now I’m okay with having to manually clip an alligator onto the tool before performing the measurement.

Your idea of mounting this off the left side is exactly what I was thinking - essentially being able to hit a button, the tool zooms over, slowly lowers, measures the height, and gets a new calibrated Z offset - exactly like professional CNCs do.

I’ve been digging through the firmware and I don’t see anything specific to using G30 for only 3DP - my current line of investigation is to see if I can make the system think the CNC toolhead has a Z probe just like the 3DP toolhead.

[Streupfeffer]

Get it to respond on CAN ID 1557. The signal is usually 0x01 but when the probe is “active” its 0x00. So basicly a NC switch which opens when the Probe turns on.
Just tested, when the ID 1557 goes to 00 and you try to move the CNC head, it doesnt care. no Z home or what ever is set on the screen. Didnt check via Luban though.

[brent113]

I’ve been digging through the source trying to find a reason for the CAN ID to be 1557. I haven’t been able to find any reason it should be that. I came up with ID 3, 10, or 17.

So here’s how I came up with that:

Best I can see, the canbus2 ISR listens to message IDs < 20, and those represent axis endstops (The Z probe is treated as a special Z_MIN endstop)

This is the code that requests all endstops report their status:

This is the ISR that handles the responses and calls the UpdateEndstops(Buff) function:

And here is that UpdateEndstops(Buff) function:

The uint32_t CanModule.Endstop set on line 1363 is then queried using a series of macros that refer to enum Z_MIN_PROBE, which represents bit value of (1<<3) as stored in Endstop.

Putting all this together, working backwards from a Z Probe Endstop of 1<<3, the incoming ID must be one of 3 possible values, 3, 10, and 17.

Perhaps the 1557 number you see includes other CAN headers?

Additionally, from looking at the source, it appears that many things trigger a status poll. Perhaps your unexpected end stop behavior has to do with that - the controller does an initialization at boot up where it registers all the devices in the system, and then polls everything. Is your setup responsive to that kind of environment, or are you doing a more simple setup - firing off status changes as they happen?

My online scratching to determine the valid IDs based on the source is runnable here: https://onlinegdb.com/S1N369f8w

[Streupfeffer]

Just added a dump on my CAN topic. Poking around in CAN Bus has some anotations in the post on IDs.
IDs 0-20 arent used exept homing from what ive seen sofar.

[khyeung]

Sorry to step in the discussion. I was poking around the source code as well for an idea to “fake” a connected enclosure.

to know which address the zprobe sends info to, wont it be easier to just connect it to the 3dprint module and then trigger the z probe? (probe, not end stop).

In the firmware, the message after filter and so on shall call in CANFuns[1] (line 297 from your screenshots)<- 1 is the enum for int ProbeReport() in GenerialFunctions.cpp. This also explain why the ID is >20. In ProbeReport it updates the Endstop variable in CanModules. It somehow looks like the UpdateEndstops function but actually it is different (I am not sure how does the machine reads this variables and knows that a probe or endstop has been triggered. It is something to be discussed)

The reason why I think you should focus on probe and not endstop is because if you trigger the soft endstop on top of your work piece, that location becomes the home. So the next movement will basically strike to the work piece and also it will not lift more than that point.

As a side notes:
3d print leveling mesh can be used in CNC as stated in the post below, but autoleveling most probably wont work unless you change the firmware, as the level_service.cpp checks for the connected module to be 3d print before accepting a levelling command.

Bed leveling for pcb milling?

@Mika, @Melanchrom, @Tone, @Edwin, @parachvte I’m pleased to announce that I have successfully leveled my Carving platform/Wasteboard. Can you please implement Manual Bed leveling for CNC in the next firmware? First, my CNC bed was 0.65mm lower at the back than the front, actually lower than the middle since the front and middle had the same offsets/measurements. I could not do a proper CNC engraving on acrylic. (same problem as milling on a PCB board) Following is my process; I followed …

[brent113]

@Streupfeffer Thanks for the dump! I need to make a canbus analyzer, doing static analysis of the source code is really hard because they layered custom functionality on top of the built in Marlin functionality, and I can’t really tell which is active sometimes.

@khyeung Thanks! I came across ProbeReport, this weekend I’ll dive into that and look around some more.

I agree - replacing the built in probe on the 3DP is easy and will generate valid CAN data for easy testing. However, I want to be able to G38 probe with the CNC toolhead for workpiece positioning and G30 probe the tool stickout, so eventually I’ll need a probe plugged into CAN.

@khyeung

because if you trigger the soft endstop on top of your work piece, that location becomes the home

Regarding what you said there - from what I saw there are Z_MAX and Z_MIN soft and hard endstops that will stop the axis from travelling too far, and there’s 2 separate topics here, neither of which I’m claiming to be an expert on, just trying to make sense of what I was reading in the code, which very well may be inactive due to Snapmaker’s custom additions:

1. Outside of a G28 Z, I don’t think I saw anything in the firmware that would automatically set a new home when an endstop is hit. However, hitting the endstop absolutely cancels all motion in the Z axis, and if in a G38 it cancels all motion in all axes.
2. There is a special endstop called Z_MIN_PROBE that is separate from the rest of the axis endstops. From what I saw, all probing is done using this special endstop. I think the idea was that there is already built in functionality to stop motion from the stepper ISRs if an endstop is hit, it makes sense to add the probe as a special endstop, since hitting the probe would naturally result in stopping motion.
   a. Hitting the probe doesn’t cause a Z home reset to happen, so I don’t think that’s an issue.
   b. The G30 implementation doesn’t specifically call any probe checks. It
   1. Enables the Z probe
   2. Moves Z down to the commanded height
   3. Checks the position of the stepper motor.
      This works because 2) will automatically stop moving when the Z_MIN_PROBE “endstop” is hit, so all you have to do is read the stepper position.

Regarding the CNC mesh levelling - I’m happy other people are working on that . I’m sure I’ll be using that, although currently I’m trying to shim the mounts so that they are actually flat, and then I can just disable the mesh levelling altogether.

[khyeung]

I didnt know about the Z_MIN_PROBE, a quick google helped me to understand the basics.

The G30 and G38 gcode function seems to be deactivated, or at least visual studio says so as it could not find G30 HAS_BED_PROBE nor G38_PROBE_TARGET enabled.

Why are hacks so complicated ??

[brent113]

@khyeung

could not find G30 HAS_BED_PROBE

Found it - CAN_ZMIN_PROBE is defined in Configuration.h

I know right hahaha, it’s complicated

[brent113]

I think I’ve figured out the Z probe.

Your 3D toolhead’s MAC address is 1557. In your CAN dump it’s sending FuncID 1, which is report probe. The data is 0 and 1.

I have some parts on order, I think I can get this working. Going to make my own canbus sniffer out of chips and mcus lol.

[halps]

Sorry to ping an old post… I just got my A350 and work with full size CNCs at work so a digital probe for setting WCS jumped out at me like an awesome addition/something I want to setup right away. Additionally using this sort of add-on as a tool setter. Reading through this it seems like you were on the right track, did you ever get further when your parts arrived?

[brent113]

I postponed that project for awhile. The firmware is going through tumultuous changes, and I’m waiting for it to mature a bit. This still is something on my radar, but also there’s some other projects going on as well.

I believe a digital sensor was actually on the very long-range plan of staff, it was mentioned offhand.

[halps]

Thanks for the update! Given that and what I have been able to learn I think I will make something that runs externally to the machine then and use the PC to coordinate the two. It will be a little less clean but I think it can have the same functionality. If this is something that is interesting to you I will post my progress.

[brent113]

Yes, please do! And let me know if I can help at all.

[Streupfeffer]

My Board is slowly getting along, i have a Opto isolated OUTPUT but didnt come to the idea to add a Isolated INPUT . Im currently not that active on the forums or 3D printing in general. the CANbus stuff still sounds awesome. If brent tells me how to get the hardware to talk to firmware, ill see what i can do.

[halps]

Sounds good! It will be ultimately built around some ‘blind’ moves and a sensor/probe that measures displacement instead of just contact (as we wont have real-time coordination with the machine). Tool setter seems like an easy starting point.