Ty!
maybe this section indeed helps:

```For a CoreXY or H-Bot machine, RepRapFirmware assumes that the motor connected to the X motor output moves the head in the +X and +Y directions when it runs forwards, and that the Y motor moves the head in +X and -Y directions when it runs forwards. [Note: firmware 1.18 and earlier assumes that the motor connected to the Y motor output moves the head in the -X and +Y directions when it runs forwards]. So you can start with these M569 commands in config.g:

@AgentNoise said in Start of print rams x/y carriage into frame:

I got it working by adding a G92 X0 and a G92 Y0 after homing each axis in the homeall.g file

Well they may be benign but they also may be masking a problem.

You should continue to try and find the real cause.

If you post your config.g and homing .g files we can help you.

Frederick

I'm done. So just keep the process of upgrading a NOS board at least 10X more complicated than it has to be with the current docs and repo organization. It's not my problem anymore...

@calvinx said in M581 Description:

I have a full printout of the old set of g codes in a folder

Beware - we update that page frequently! 😉

@calvinx said in M581 Description:

I think what might be handy is a few example config.g files that relate to certain printer types like before

We will need examples for Duet 3 for each gcode that is specific. I hope to have some exmaples of a Delta, CoreXY/Cartesian, tool changer and maybe one or two more before TCT show. In the longer term @chrishamm has now updated the backend of configtool.reprapfirmware.org so adding Duet 3 configuration generation will be easier for him to do

@veti

Okay that was easy then 😎

@bearer said in 2.03 + PanelDue 7i:

Shouldn't the firmware on the PanelDue show the interface and not a white screen as long as it has sufficient power regardless of communication with the Duet? -

Yes, if the ribbon cable is sound and connected to the correct connector on the Duet.

have a look in your config.g file to see if you have the same issue as the other have had lately?
https://forum.duet3d.com/post/107325

Thank you!!!!!!!!!

@dc42 The MCU isn't getting hot. After leaving it on for 10 minutes when I touch the MCU surface I can its warm

Hi Tom, best thing to do is to upgrade to 2.03 first:
https://github.com/dc42/RepRapFirmware/releases

That has all the compatible elements in the same place. Then you can upgrade to 2.04RC1.

Remember to read the "whats new" file as stuff has changed!

If using a delta you may want to use 2.04RC1 instead.

@jay_s_uk said in Firmware 2.04RC1 available:

DWC 2.0.0-RC7

@boldnuts said in Firmware 2.04RC1 available:

DWC 2.0.0-RC7

I just re-updated to 2.04RC1 and this time I updated to DWC 2.0.0-RC7, seems like I'm not having the issue with the higher than normal first layer this time. Wierd, autocalibration calibrated to the deviation I expected, but it seems to be normal now.

Seems fine like last time but we'll see after I power it off and back on in a couple of days.

I may just get some shielded cable off Ali express and put that in.

Another though, would ferrite beads work on the endstops to shield noise?

Kind Regards,

Sam

@themelle Thanks for that visual wondering though if there is a better way to determine the max height if I know all the other factors. As in where does the cone begin?

I'll change "Firmware electronics" to just "Electronics" in the next release.

EDIT: looks like that needs to be changed in DWC, not RRF.

@phaedrux no no i don't expect something huge but something like: "dynamic acceleration control" sounds already cool to me.
I will try to include that maybe. 👍

@T3P3Tony thx got it already open. 😄

Fortunately I was so foreseeing that I kept the modified sources. I made a new build based on the (to be released) 2.04RC2 version including M574 Cnnn parameter.

Note that I consider this an intermediate solution until you are able to upgrade to RRF 3.

I uploaded the firmware binary to my Dropbox.

@dc42 Thx, M84 U followed by G92 U0 does the trick

@dc42 Strangely enough I moved from the 5V PS_ON pin to an open 3.3V endstop pin and it works now...