External Z Probe Sensor

[brvdboss]

@brent113

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.

That’s more or less where I’m a bit stuck (stuck as in life interrupted me a bit and haven’t had time to work further on it). I’ve made some modifications to the firmware, have aa proof of concept of the probe and have that connected to the the can bus using an esp32. but still need work on the initialization.

Although I think my proof of concept could also work with just sending the same signal as an endstop in a linear module (after reading this thread). Not sure if it would have other negative side effects.
With the 3d printhead and another probe it does work.

Maybe I’ll spend some time on it again this weekend. This discussion has motivated me to have another go at it again. But have some big deadlines at work this week first.
(this thread 3D touch probe connected to can bus) but you’ve both been active in it already.

[brent113]

@brvdboss

Although I think my proof of concept could also work with just sending the same signal as an endstop in a linear module (after reading this thread).

Yes, but, it needs to be initialized at startup (or just modify the controller firmware to always register that function since we’re doing brain surgery anyways)

I think that’s the best answer. And since we’re doing that you could put absolutely anything you want on the bus and just program the controller to accept it

[pastitas]

@brent113

Yes, but, it needs to be initialized at startup (or just modify the controller firmware to always register that function since we’re doing brain surgery anyways)

What exactly does that mean? Is it just a matter of sending some CAN packets? I really need to get my hands dirty with CAN bus and have a teensy3.2 waiting for the chance, but until the second week of may I’m deep in work deadlines as well.

Enabling this option always seems like a win-win, until we can get some probe-module specific code or something like that, just removing the limitation would allow for a lot of options with other tools, ie. even height mapping surfaces for the laser to engrave.

[brvdboss]

@brent113

Yes, but, it needs to be initialized at startup (or just modify the controller firmware to always register that function since we’re doing brain surgery anyways)

But isn’t the endstop in the linear modules always initialized at startup anyway?

[pastitas]

@brvdboss

But isn’t the endstop in the linear modules always initialized at startup anyway?

If you could “Impersonate” one of the linear modules in CAN (which I think should be possible) everything should be initialized, wouldn’t just sending a “triggered Z end-stop” work?

There’s a need still for enabling the feature with tool heads other than the 3dp one, but you could always hook up the 3d-printing one as a dummy to get the probing done, and then switch to the other head to do the job. It seems like a pain since a reboot is mandatory but hey, we could do it without touching the firmware.

@brent113

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.

Could you link to the code bit that blocks the probes when cnc/laser head is on?

[brent113]

@brvdboss

isn’t the endstop in the linear modules always initialized at startup

The way it works now, at startup the controller sends a “magic packet” requesting every function to register itself. Each functionID responds as “present”.

Without the probe responding then it will not be registered as an endstop.

I wouldn’t use the linear module endstop as that has motion implications and could cause an issue I’d think. Would have to think about it more.

[brvdboss]

@pastitas

If you can “Impersonate” one of the linear modules in CAN (which I think should be possible) everything should be initialized, just send a “triggered Z end-stop” and bingo.

Yes, so I have that working with the 3D print module. But I was referring to use the end stop in the linear module (for example from the YZ-axis) and use that one. As far as I remember those should just work with the probe gcodes.

There’s a need still for enabling the feature with tool heads other than the 3dp one, but you could always hook up the 3d-printing one as a dummy to get the probing done, and then switch to the other head to do the job. It seems like a pain since a reboot is mandatory but hey, we could do it without touching the firmware.

And really a pain to get everything aligned every time and setting your origin. But that’s why I thought using the function id of an endstop from a linear module instead. Those are always there and always initialized.

[quote]

That’s basically filling in the correct function ID in this code here to get it working then. The 0x605 is the id I saw with my 3d print head probe. But by using the id from the linear module when it hits the end stop might be good enough as well.

brvdboss/3D-touchprobe-controller/blob/main/src/main.cpp#L373

(Note: that project also has the can bus monitor included, but the actual can reading/writing part is very limited, would be cleaner if it was split up, but hey, prototyping )

If you want to get a quick overview of where the changes would be needed to have changes in the firmware, the commits in my current working branch of the controller might help you. (again, not really tested that thing)

[brvdboss]

@brent113

The way it works now, at startup the controller sends a “magic packet” requesting every function to register itself. Each functionID responds as “present”.

Without the probe responding then it will not be registered as an endstop.

Correct, but the magick packet part isn’t completely clear to me yet right now. (not the concept, but the implementation in the firmware)

impersonating the linear module thus seemed a solution that doesn’t need changes.

I wouldn’t use the linear module endstop as that has motion implications and could cause an issue I’d think. Would have to think about it more.

As far as I can remember I don’t think it would really be a problem if you’re using it with the probe commands. If it is triggered at any other point in time, it probably will have undesired effects indeed.

[brent113]

I don’t have vscode where I’m at right now and don’t want to dig deeply using notepad++, but I think the program flow goes from setup->snapmakersetupPost->event task handler creation, which triggers the CanHost::EventHandler(…)

In the canhost eventhandler is this:

Snapmaker/Snapmaker2-Controller/blob/016df380401704a9d1c678df98521b14699b6ae7/snapmaker/src/module/can_host.cpp#L432

I think the preceding line is the magic packet, with the functionID=0x01, 0 data. This triggers all modules to respond.