@hezekiah Soldering looks fine. If it's a hardware fault, the processor may get hot pretty quickly after starting up, even on USB power. Does it?

You said "I’ve only used the SD card for the original set up and then this recent stirring of attempted updates." Have you been using the board on a machine between these two times? Just trying to ascertain if it's been working, or if you did initial setup, then left it until now.

I'd have a close look at the SD cards. If possible, put the 'freshly reformatted' one in your PC and see how you formatted it; maybe it is formatted incorrectly. I think you have already, but best to format both cards again (backup Duet files first) with the official SD Card formatter https://www.sdcard.org/downloads/formatter/index.html and try each.

It may help to update the firmware. As the card isn't working, it's probably best to do the firmware erase and flash using the Bossa program on a PC connected by USB. See https://duet3d.dozuki.com/Wiki/Installing_and_Updating_Firmware#Section_Fallback_procedure_Num_3

Ian

There's also nothing wrong with sticking with 2.05 for the time being unless there's a specific feature in RRF3 you need. Development is still heavily underway, so there will likely be some bugs and missing features for a while.

@percar said in Error on home all:

G29 S2 disables the height map which is what is required in order to home the machine

Try M561 instead

https://duet3d.dozuki.com/Wiki/Gcode#Section_M561_Set_Identity_Transform

Sorry, silly question.

Those messages are coming from Duet Web Control, but I don't know why. One for @chrishamm.

yes DWC 2.0.7

The 3.0 beta firmware had a problem with frequent data corruption when you uploaded files using the on-board Ethernet. Maybe that was the reason?

I fixed it, feeling kind of silly for missing it.

For anyone else that comes across it, I was missing updating my M563 command to also use H2

David,

@Dr_Ju_Ju said in RRF3.01-RC2 CoreXY Movement differences:

I was on the latest 2.05.1 \ DWC 2.0.7 on Duet Ethernet 1.02 or later
Board ID: 08DGM-95BNL-MGPSJ-6J1F2-3SD6L-9JZHX

& yes Nuramori, I was playing with the axis limits to try & get things working in the right direction...

@SoDamnInsane … and I had to print new part-cooling ducts without having part cooling available to print them - that was a major design challenge 😱

@dc42 well i think i will need to write some e-mail to maxwell and ask them why they yend me hot end with thermistor and not PT100 as i want, because if i plug them in E2 thermistor conn. then temperature apper 👿 👿 👿 👿 👿 👿 👿 👿 👿

@Danal That did the trick. Thanks!

@Danal thank you for your help

@dmbgo Yes RRF3 is going to be the future of the firmware. 2.05.1 is likely to be the last update for the 2.x versions. Which you can look at as being a long term stable release with no new features and maybe bug fixes. For the Duet 2 Wifi and Ethernet and Maestro boards that's not a bad thing since it's very feature rich already. But with things like conditional gcode in RRF3 it will open a lot of possibilities for doing some cool stuff with scripting and automation.

So for the time being, sticking with RRF2 is the sane thing to do if you just wanna print. RRF3 is you wanna mess around.

@JuJuDelta said in Trouble updating WiFi, classic noise on 8266 problem:

The Duet PCB was in the Kossel XL+ and powered normally using 24V on Vin.
If it happens again I will look at the various voltage rails for noise and ripple, and the ground PCB track to WIFI module. Fatten it up and decouple the WiFi module supply Pin maybe. There is a DNF on the schematic for a cap. Need to check what’s actually on the PCB.

I do have an Ethernet module to swap out if needs be. But the wifi module, in Normal operation, has never given me problems.

Thanks. We have had a number of instances where the WiFi module refuses to update due to failure to connect, and replacing the WiFi module has fixed it.

Thanks @Phaedrux !!!!

@droftarts That's exactly what i've got. Sorted, thankyou.

@MauriceM It's fine to leave it if you home Z using G30. But if, by mistake, you try using (or your homing.g files contain) a G1 H1 (ie a homing move) on Z, it will try to use the non-existant endstop, rather than the probe, to home Z, resulting in a crash. Better to remove the chance!

Ian

@secure To edit config.json you'd have to load it up in the configurator, make changes, and save it out again.

Or just stick to editing config.g since it's human readable.

Yes I did. On a Duet WiFi it was disappointingly low, around 45kHz to each of 3 motors moving simultaneously AFAIR. The changes I made helped somewhat, but more improvement is planned for release 3.02.

I have a config for a RailCore II / Duet 3 / SBC that's compatible with 3.0 or 3.01 here:
https://www.dropbox.com/sh/pg0ugu5qunokjc9/AAD8PkPqVGPp-yWV5Cug3_Usa?dl=0

Some sample conditional gcode examples here: https://www.dropbox.com/sh/gb8v16bgmyzq78t/AABgqjcDaqf4cLirguvjDlFfa?dl=0