Cartographer Probe

[Yezariael]

19 minutes ago, Penatr8tor said:

Nice!

What model Beacon Probe? The new Rev H or the old Rev D model.

I have a Rev D style

I have D, works with both. I have a H for spare here but as long as the D works I don't see the point to change.

[Penatr8tor]

2 minutes ago, Yezariael said:

I have D, works with both. I have a H for spare here but as long as the D works I don't see the point to change.

They were talking something about a firmware update. Did you have to do that?

 

[mvdveer]

11 hours ago, Penatr8tor said:

They were talking something about a firmware update. Did you have to do that?

Yep - Basically update beacon to v2.0 either through mainsail or SSH into pi, change to beacon_klipper directory and run git pull to get v2. Then issue

./update_firmware.py update all

Firmware updated - This is on a Rev H

But also worked on my Rev D in the micron

[mvdveer]

Did the first "calibration" print on the VZBot with the recommended settings for the [beacon] and macro (START_PRINT) settings.

 

However there is still some manual adjusting to do in the macro. The supplied macro additions has a section to allow for hotend thermal expansion and has set a value for 0.06, which I may change for this printer, depending on how the test print goes.

[Shapeshifter]

Looking at updating my two Vorons from inductive probes, skipping klicky and tap. Not really all up to date on latest developments, just been using the printers as needed, but Cartographer looks interesting. Is there any reason to wait for possible improvements or just get them when back in stock? I'd probably get the cnc mounts at the same time. I should have a few EBB36 1.1 in a box somewhere, so CAN would be nice.

[Dirk]

2 hours ago, Shapeshifter said:

Is there any reason to wait for possible improvements or just get them when back in stock?

No, no reason to wait.

The TAP functionality they are currently working on, will support all current probes. (backward up to even v1)

I can also definitely recommend the CNC carriage. a lot of stability which is also light, in the center of all movement. Ideal. It works not only with the stealthburner, but also with a whole list of other toolheads. (ao XoL).

The reason they are currently on backorder, seems to have to do with a large order from Siboor, which is going to include them with ALL their kits.

But I hear they will again ship within 2 weeks.

 

[Shapeshifter]

On 6/10/2024 at 8:47 PM, Dirk said:

But I hear they will again ship within 2 weeks.

Didn't take long, shipped now. Free shipping, so it'll probably arrive in a few weeks.

[Andreas386]

On 5/17/2024 at 12:17 PM, DerHolgi said:

I did install the Cartographer and it worked very well.

But then, i was thinking it is annoying to have different profile for different plates. (Z-offset)
So i ordered a ChaoticLab TAP mount and designed a mount to mount the cartographer on the lower back of the TAP mount.
Now i do the Z probing with the TAP and the QGL and mesh probing with the Cartographer.
I'm very happy with this, as i no more need to take care about Z-offset adjustment.

Hi Holgi  I am currently also building this setup (tap for z, carto for the others). Thanks for sharing your config thoughts. I'll try that and hopefully it'll work Otherwise I'll hope to may come back to you and get in touch to get your help a bit on this   

 

If it's working and someone wants the stls I'll surely can upload it for you

If tested just now and everything is working perfectly  

https://www.thingiverse.com/thing:6669320

I needed to move the x sendor a bit to the right, so the carriage can move up and down with the mounted cartographer

 

 

 

 

Edited June 20, 2024 by Andreas386
tested now and working - adding stl link and pictures of installed version

[PFarm]

Question: can you run a Cartographer probe with sensorless homing? I can't find any info online.

• I use sensorless homing on both of my printers.
• I installed a Cartographer probe on my V2.4
• I'm trying to calibrate my Cartographer probe but with sensorless homing when you home X it moves Z up 5mm and when you home Y Z goes up another 5mm when I center the hot end at 175/175 it still thinks it is 5mm above the bed!
• You can't use homing override which is used in sensorless cfg. I tried commenting out that section in the cfg and using Safe Z homing or commenting out Safe Z homing but no luck there either.

Edited June 30, 2024 by PFarm

[mvdveer]

3 hours ago, PFarm said:

I'm trying to calibrate my Cartographer probe but with sensorless homing when you home X it moves Z up 5mm and when you home Y Z goes up another 5mm when I center the hot end at 175/175 it still thinks it is 5mm above the bed!

Thats normal behaviour. To calibrate:

• Home X,
• home Y
• Physically move the toolhead to the centre of the bed - G1 X175 Y 175
• CARTOGRAPHER_CALIBRATE (The value that is displayed then,  WILL NOT be the actual Z-Height. (mine for example was Z=245 when max Z=180) It DOES NOT matter
• Manually move Z down using the MAINSAIL interface, not the Klipperscreen one. (Using a feeler gauge or paper)
• Push accept - Cartographer will calibrate. Then home as per normal.
• Now you need to set your Z-Offset:
  • Home the printer
  • Place paper under nozzle
  • Issue command G1 Z0 F600 with paper/feeler gauge ready under the nozzle
  • Adjust Z-Offset through mainsail again
  • Issue command: Z_OFFSET_APPLY_PROBE
  • Issue Command SAVE_CONFIG

You're all set to go.

(See here)

[PFarm]

5 hours ago, mvdveer said:

CARTOGRAPHER_CALIBRATE (The value that is displayed then,  WILL NOT be the actual Z-Height. (mine for example was Z=245 when max Z=180) It DOES NOT matter

Thanks for the info, for anyone using sensorless homing, you need to comment out the homing override in your homing.cfg and use the Safe Z Homing for the calibration to work properly.

Got it working, thanks I appreciate the help!

Edited June 30, 2024 by PFarm

[Dirk]

The cartographer documentation mentions that you do need to set a 'safe_z_home' section: However this is only true if you do have x/y endstops / sensors. If you do define a safe_z_home, your sensorless homing will not work anymore. so it is a bug in their manual.

The several guides on sensorless homing that I followed, 'demand' that you REMOVE the safe_z_home section in printer.cfg, because homing is overriden in the 'sensorless-homing-script' so can be adjusted for the homing current and the tmc settings.

So @PFarm I am glad you got it working. But I would do it the other way around. So remove / comment-out safe_z_homing in printer.cfg. and Leave the homing override in sensorless homing.cfg.

 

If you are happy like it is, keep using it, however, my [homing_override section in my homing.cfg, performs many more checks than the one mentioned in the cartographer docs.

 

 

[PFarm]

@Dirk I tried the other way around but you can't do the Cartographer Calibration with the override. You need to comment out just the override in the cfg and leave everything else. Sensorless homing still works with Safe Z Homing. 

Edited July 1, 2024 by PFarm

[Dirk]

13 hours ago, PFarm said:

you can't do the Cartographer Calibration with the override.

I have done it. Along with me, many others. 

As I said before, if it is working for you like it is, fine. But it is not a safe method. If you look at my homing override script that I installed when I set up sensorless, you will see that it assures your toolhead won't crash into the bed, it then calls the home_x and home_y modified sensorless macros.

The safe_homing as described in the documentation of cartographer is simply a way of defining one, so people that do not have it, do not crash their nozzle into the bed (for example by trying to home at a y=max position when cartographer hangs outside the bed, which is standard when you have a z-bolt, and come from that setup).

I have asked the documentation makers to update this for sensorless homing, but they have been very busy, but I am sure it will be updated soon.

If you could not home z with your current sensorless homing and cartographer, you may want to try a safer sensorless homing guide if you ever get the time from your endless fun projects

 

[PFarm]

@Dirk Thanks for the info I got it figured out and got it working with homing override.

[PFarm]

I like this probe! Appreciate the help @mvdveer @Dirk setting it up. The only issue since installing it is I get the "MCU 'mcu' shutdown: Timer too close This often indicates the host computer is overloaded. Check for other processes consuming excessive CPU time, high swap usage, disk errors, overheating, unstable voltage, or similar system problems on the host computer" performing QGL. A reboot will normally fix the problem it's a BTT Manta 8P with the CB1 on this printer so guessing the CB1 is working overtime. I will add a fan onto the CB1 heatsink and see if this cools it down enough to eliminate the error.

[xyleth]

2 hours ago, PFarm said:

I like this probe! Appreciate the help @mvdveer @Dirk setting it up. The only issue since installing it is I get the "MCU 'mcu' shutdown: Timer too close This often indicates the host computer is overloaded. Check for other processes consuming excessive CPU time, high swap usage, disk errors, overheating, unstable voltage, or similar system problems on the host computer" performing QGL. A reboot will normally fix the problem it's a BTT Manta 8P with the CB1 on this printer so guessing the CB1 is working overtime. I will add a fan onto the CB1 heatsink and see if this cools it down enough to eliminate the error.

I got this problem a lot with my Siboor 2.4 that came with the BTT Pi which is based on the same SOC as the CB1.  The problem isn't really to do with the system working too hard, it seems to be buried deep in the internals of the CB1s USB architecture.  The issue only manifests itself when you have a setup with multiple MCUs (my 2.4 has three - the Octopus, the SBB2209 and the Cartographer).

There are some band aids you can apply, for example increasing the Klipper CAN time out from 25ms to 50ms, but ultimately the only true fix that I know of is to move to a different hardware platform.  Raspberry Pi doesn't seem to suffer from the same problem as far as I know, but I moved over to a mini x86 PC (a refurbed Beelink unit) and I haven't had any reoccurrence since.

[Penatr8tor]

2 hours ago, xyleth said:

I moved over to a mini x86 PC (a refurbed Beelink unit) and I haven't had any reoccurrence since.

I recently got a Beelink SER5 to try Linux out. Nice units and the cheap x86 units aren't much more than a Pi4-5. Not a bad deal when you factor in the performance boost.

[PFarm]

3 hours ago, xyleth said:

the BTT Pi which is based on the same SOC

Since the motherboard is a Manta 8P with no capability to connect an RPI via USB or UART, would one solution be to add a CM4 module to the Manta? I also like that I can get one with eMMC storage to upload Klipper to.

[chrisalbertson]

6 hours ago, xyleth said:

... my Siboor 2.4 that came with the BTT Pi which is based on the same SOC as the CB1.  The problem isn't really to do with the system working too hard, it seems to be buried deep in the internals of the CB1s USB architecture. ...

The BBT Pi is a Pi3 clone.    The Pi3 had a bottleneck where the WiFi, Ethernet and USB shared a bus.   So all of the above were slow.      It seems that maybe the BTT Pi is like the real Pi3.   The Pi4 fixed this and has greatly enhanced IO.

[mvdveer]

9 hours ago, PFarm said:

I like this probe! Appreciate the help @mvdveer @Dirk setting it up. The only issue since installing it is I get the "MCU 'mcu' shutdown: Timer too close This often indicates the host computer is overloaded. Check for other processes consuming excessive CPU time, high swap usage, disk errors, overheating, unstable voltage, or similar system problems on the host computer" performing QGL. A reboot will normally fix the problem it's a BTT Manta 8P with the CB1 on this printer so guessing the CB1 is working overtime. I will add a fan onto the CB1 heatsink and see if this cools it down enough to eliminate the error.

If you are using a USB camera - try disabling this and see if the error persists, or decrease the frame Rate

[Penatr8tor]

One of you guys can probably help me, @PFarm, @mvdveer, @chrisalbertson...

I'm thinking of trying canbus on my Voron refurb. I also want to use a Beacon-H.

So...

Which CAN board for the tool head? I have a Stealthburner with LGX-Lite (might get and Orbiter) and Rapido HE.

How should I interface the controller / Pi?

How does a Beacon H fit in?

[mvdveer]

7 minutes ago, Penatr8tor said:

Which CAN board for the tool head? I have a Stealthburner with LGX-Lite (might get and Orbiter) and Rapido HE.

How should I interface the controller / Pi?

How does a Beacon H fit in?

I like the Mellow products (Cannot speak for BTT) and choice of board will depend on the extruder. For Orbiter - SHT36/42. (Rear Mount)  For the LGX Lite - SB2040 /SB2209 (Side Mount)

I would use a UTOC/U2C  board as the interface.(Setup is just easier)  I also run the can off the octopus by flashing it with CanBoot / Katapult and using the RJ45 jack on the Octopus to interface with CanH and CanL. Still running the Voron printers this way without an issue. (Only one USB cable from Octopus to Pi)  The VZBot has a UTOC board as the interface. (USB connection to PI)

Beacon will be an excellent addition to the setup. Would recommend a CNC mount for the Beacon and Voron toolhead.

Pi has 4 USB ports utilised as following:

• 1. Controller Boards
• 2. Beacon Probe
• 3. USB Camera
• 4. U2C/UTOC board

Hope this helps

 

[PFarm]

28 minutes ago, mvdveer said:

If you are using a USB camera - try disabling this and see if the error persists, or decrease the frame Rate

Yes, I have two cameras and I've disabled one of them and see if that helps. I'll disable both if I need to.

Edited July 2, 2024 by PFarm

[Penatr8tor]

44 minutes ago, mvdveer said:

I like the Mellow products (Cannot speak for BTT) and choice of board will depend on the extruder. For Orbiter - SHT36/42. (Rear Mount)  For the LGX Lite - SB2040 /SB2209 (Side Mount)

I would use a UTOC/U2C  board as the interface.(Setup is just easier)  I also run the can off the octopus by flashing it with CanBoot / Katapult and using the RJ45 jack on the Octopus to interface with CanH and CanL. Still running the Voron printers this way without an issue. (Only one USB cable from Octopus to Pi)  The VZBot has a UTOC board as the interface. (USB connection to PI)

Would this be a good choice for the toolhead CAN PCB?

 

Fly-SB2040-V2

and pair it with

 

Fly UTOC-3

Also, what do you use for cabling? Are you buying a premade cable or fabricating one yourself?

I assume that my umbilical will end up with 2 cables, the CAN and the Beacon USB.