@o_lampe you may need work out the correct pinout for the board but give it a whirl and see what happens

There are several consideratoins:

As @Veti says, you should make sure that the rest of your mechanics is compatible with whatever pulley size you choose.

Assuming GT2 belts, at x16 microstepping the steps/mm will be 160 using 20 tooth pulleys, or 200 using 16-tooth pulleys. So slightly better resolution per microstep using 16-tooth pulleys (5um) vs 20 tooth pulleys (6.25um). Also, 5um is easier to work with than 6.25um when measuring Z probe trigger heights.

The full step resolution will be 100um using 20 tooth pulleys, or 80um for 16-tooth pulleys. Some users prefer to use a layer height that is a whole number of full steps; in which case 100um is easier to work with than 80um.

20-tooth will allow a slightly higher speed than 16-tooth before you run out of either VIN voltage to counter the motor back emf, or step generation rate

If using 1.8deg motors then I think it's worth using 16-tooth pulleys to get better resolution. With 0.9deg motors, I don't think it makes much difference. I started off using 20-tooth pulleys and 1.8deg motors, then changed to 16 tooth pulleys for better resolution. But then I changed to 0.9deg motors. I still use 0.2mm layer height even though it is not a whole number of full steps.

Its working. Thank you guys for your help !.
@dc42
Dear David, we are 95% done with the project and robot will be online in 2 weeks. There was some problems regarding vacuum and hardware so we have changed the whole approach. We made new HW installation and cover mask design. Now when i think of it, we spend really much time on HW. Finally we choose PIAB vacuum grippers and at the moment vacuum is working at 6 bar pressure with 800 Nl/m... As we discussed long time ago :-), i will need additional 4 boards. Hear you over skype regarding this...

@zapta said in 3000w 120v spec silicone heater:

In any case, be careful, it can kill you. 😉

Well, just a little.

@dc42 yes 🙂 already printing parts

RIP delta but now i cant wait to saw it in half^^

Thank you for your reply. I will drop you a note when we complete the part that i need to finish. Best regards !

Based on that thread it would appear it's a bug that's been fixed in 3.2

@matt3o said in Power supply power:

If you have 2A motors even setting them at 1.4A that's over 100W just for the motors

Typical motor drivers act as switching power supplies so multiplying the stepper motor by the supply voltage over estimates the power consumption.

I think that the Duet document that was posted here discusses how to compute the power budget of a stepper motor.

Hi, thanks for your help, very useful. movement is all sorted now, but issues with homing, please see
https://forum.duet3d.com/topic/21391/core-xyuv-homing-going-squiffy

@Tpmoses said in Z drop on board reset:

I was struggling with was when the board resets, the z motors let the gantry lower on the side..

I made a similar transition from a dual stepper single driver to a dual stepper dual driver Z configuration and it works well.

With the single driver approach, I had a macro that lowered the bed using a reduced stepper current. That causes both sides to get to their mechanical bottom which I used a standard position for stating the Z homing process.

@chrishamm I can attest to the faster network speeds. It's much, much faster to upload gcode files to the printer in SBC mode than in standalone mode. This makes a big difference with larger files (50+MB). Like orders of magnitude.

As far as wiring, in SBC mode I need:

a 26 pin ribbon cable that must be restrictively short 1 USB-C wire for power to the Pi (the ribbon cable is insufficient to power my 2GB Pi4B +monitor without triggering warnings) 1 micro-USB wire for power to the Pi touchscreen 1 ridiculously long, delicate DSI ribbon cable between the Pi 4 and Pi touchscreen (it's not HDMI) I also once had a ridiculously long DSI ribbon cable between the Pi 4 and a Pi HQ camera, though the long cable was wrecking the images so I had to remove that

The long ribbon cables to the camera and monitor are specifically due to the location of the Pi, tucked under the printer because of the limit imposed by the 26 pin ribbon cable. Wifi signal is also poor there. So while uploading files is much faster, browsing the web or updating the system files on the Pi is slow.

In standalone mode I need:

a single USB-C power cable with Y splitter to power both the Pi and touchscreen a network cable between the Pi and Duet 3

That's it! There's no practical length limit. The Pi sits in the monitor's plastic housing way up on the side of the printer. The flimsy ribbon cable between them is inside that housing, it's like 80mm long and irrelevant. The whole thing is out in the open getting great wifi reception. I can now connect it directly to the camera with a short cable.

Incidentally, are the CAN diagnostic numbers relevant at all? I 'm not sure why CAN is there since I don't use any add-on boards, and I was under the impression that CAN and SPI are mutually exclusive when it comes to communication between 2 devices, yet the "Send timeouts" in the CAN section were consistently climbing the entire time I was testing. Maybe that's just internal board messaging stuff and completely irrelevant... I won't pretend that I'm knowledgeable about communication protocols 😂

I'd love to see an SPI-over-ethernet solution worked out to remove the distance restriction between the Pi and Duet 3. Seems like it would just take a couple of those cheap adapter hats to implement.

@chrishamm said in DuetPi - SBC/Chromium chewing CPU cycles:

That sounds odd - the new update delay should have reduced the CPU usage notably. Do you have the latest Chromium version from Raspbian installed (i.e. did you do apt update/upgrade recently)?

yes - in fact, before posting the above I ensured that chromium, etc were all updated.

I'm using the default repos from the duetpi image (so, no unstable stuff.)

@dc42
Thanks for the clue!

Finally I've ported @wilriker changes to CoreNG in 2.05.1 firmware and it is working!
I tested it on my desk and it works pretty well. I'm going to start testing that solution on my printers.

@fcwilt Yes, I have a Loctite glue for screws 🙂 I am surprised, because my 6 years old 3d printer has puleys with screew very tightened. And new puley had loose screws after 6 minutes of operation.

Thank you for your help.

Ondrej

Got it!
Thank you @Phaedrux @fcwilt

@DanS79 said in G10 for temporary Z offset?:

@fcwilt Yea thats would work set it to a given value in the start gcode, then back to zero in the end gcode.

Notice that you can use absolute or relative values - whatever works best for any given situation.

Frederick

@madeinta1wan said in Notification in Telegram:

@hector Did you manage to get a working Telegram bot running? I know it's been some time since you posted and others have asked but I thought I'd check.

-Nate

See here: https://forum.duet3d.com/topic/7745/duet-telegram-bot