@DocTrucker That's right, but you could enable the Telnet port if you wanted to.

@droftarts Thanks Ian

@dc42 Installed the beta, everything is fine!

M409 k"move.axes[]" f"f"
{
"key": "move.axes[]",
"flags": "f",
"result": [
{
"machinePosition": 2.652,
"userPosition": 0.102
},
{
"machinePosition": 5.511,
"userPosition": 0.102
},
{
"machinePosition": 180.17,
"userPosition": -0.03
}
],
"next": 0
}

Many Thanks!

@Z4c_Sm1th I have ask @Phaedrux to follow up with you.

Leaving this for future reference.
https://forum.duet3d.com/topic/14544/guide-to-marlin-s-fast-bltouch-probing-feature-on-duet

@tecno best to start a new thread showing what you have tried.

Thanks for clarifying and providing the schematic showing the two inputs tied internally.

Thanks Mark

ecb19ea5-90f2-4a4b-8c8c-140ff1ca9dd2-image.png

Here is screen shot. The temperatures all read!

Thanks again.

@oliof said in Motor problems on RatRig V-Core 3:

The duet boards are best cooled by blowing a bit of air above and below the board along the drivers.

Hindsight IS def 20/20 here...If I only saw that in the documentation from RatRig when I built it. They did mention that passive cooling should be enough...but the standoffs they provided to mount the Duet 3 Mini 5+ were simply not up to par.

My brother has a real nice O-Scope, so will prob send to him to check it out.

Many thanks again, for your sage advice. You are a credit to the forum here more certainly!
I did post pictures of my wiring and even some FLIR thermal pictures, which did show the drivers getting hot, so I should have realized to check the thermal limits before trying to run some test prints. Doh!

Regarding the Octopus drivers, I agree that the duet PCB wicks better, but with the 120mm Noctua PWM fanmounted directly above the board, I think it will cool down fairly well.

Thanks again for the reply- duly noted.

@bugpwr said in resume redundant extrusion:

by the way, I am having some (unrelated) motion troubles with the beta3+1. On a couple of incidents homing commands got stuck (e.g. G1 H1 Y480 F5000) I did not investigate further.

That is the second line of a 2-line error message. The first line includes a single-digit error code, which I need to know to investigate this further.

@T3P3Tony I switched it to Out9 and it works fine. Go figure.

@T3P3Tony Email sent, thanks for your help.

@droftarts This fixes my problem thank you.

@droftarts Okay , 🙏 thank you.

@droftarts 😀 😁 😁 😁 oh godd!! Thank you 🙏

@HeidiH Possibly because you are setting the target temperature that is outside the allowed limits of the heater? ie you're setting 0C, but the heater temperature range set by M143 as 20 to 250.

Ian

@IndeX4D For "Timeout while waiting for transfer ready pin" errors, see https://docs.duet3d.com/en/User_manual/Machine_configuration/SBC_setup#troubleshooting

This error, reported in the DWC console, is usually caused by:

Other wires running too close to the ribbon cable, creating interference. Heater and motor wires can be particularly noisy, route them as far away as possible. Ribbon cable too long, damaged or poorly connected. Check installation of ribbon cable. Ribbon cable should ideally be not longer than 150mm. Signal reflections have been reported by one user. This may have been caused by a ribbon cable that was too long, or damaged.

Ian

@chrishamm I solved the problem (so close the topic as solved please). I dont know the causes but this is how it is working now:

.- In config.txt I commented the line

#disable_fw_kms_setup=1

By doing this and rebooting, I can see the raspberry logo at boot but then again all goes white and stays there

So again in config.txt I made the change:
dtoverlay=vc4-kms-v3d to dtoverlay=vc4-fkms-v3d

And these 2 changes solved the problem. Everything in "normal " now, The camera is not working either but it is detected.

On the other printer I checked, and disable_fw_kms_setup=1 is not commented... Documentation says this uses kernel defaults. So my guess is since the difference between both raspi images is the date and I can see a difference on kernel vlaues, there is something internal that makes all this trouble to me.

Either way, it is solved. Thanks for the help

@Rob-Holierhoek What slicer are you using? Slicers have a bad habit of changing the default speed and acceleration limits, and often send values in mm/s while RRF uses mm/min. Also there's usually a switch to set the Gcode flavour to 'RepRapFirmware'. See https://docs.duet3d.com/en/How_to_guides/Calibration#h-7-suggested-slicer-settings

If you still have issues, post a simple gcode file. Also please post your config.g and the response to M122, so we can see which firmware version you are using.

@Rob-Holierhoek said in Duet2 wifi on ender 5:

my question is could it be the update delay for settings is set to 500ms and the update for delay for cache changes 1000ms

I think you're seeing that in the DWC > Settings > General. No, don't change them, they won't speed up the printer, they're the settings for how DWC communicates with the Duet. Not relevant to your issue.

Ian

@deepakvarma Please supply more information, it is impossible to help with this otherwise. See https://forum.duet3d.com/topic/5909/guide-for-posting-requests-for-help

RRF version Which Duet board(s) Post config.g Post M122 output What hardware is causing the problem? (In your case, what probe type? eg BLTouch) Post homez.g as it is related to Z homing. If you pressed 'HOME ALL', also post homeall.g

Ian