@JoergS5 Thank you!

@dc42 Ah, I see. I think that would be a good edit to clarify what that jumper is doing.

@0nn0 the USB connection is just there for setup etc using YAT. its not needed for day to day operation

@ComedianTF2 thanks for pointing this out. I have fixed it.

@dc42 said in CoreXY homing:

Assuming that you are using one of our standard stable builds of RRF, I can't see any way that RRF could fail to execute a G90 command. Please check using M115 or M122 exactly which firmware version you are using and tell us.

FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 3.4.5 ELECTRONICS: Duet Ethernet 1.02 or later FIRMWARE_DATE: 2022-11-30 19:36:12

Thanks, I will remove the "fine hope" part

@danielkrah I’ve run through installing Eclipse and getting the firmware to compile on an M2 MacBook Pro on Ventura, and updated the instructions further. I had problems getting Eclipse to recognise CrcAppender; Eclipse doesn’t use the system $PATH by default, and I couldn’t seem to add the path to it in Eclipse. I had to run Eclipse from the terminal for it to use the system path. Can you take a look and comment on your experience?

Ian

@oliof yes, I saw their blog post and twitter thread:

https://twitter.com/Duet3D/status/1649257952723730432?s=20

I expect it wont be quick to integrate into our documentation site directly. potentially something to look at when WikiJs graduates to 3.0.

In the mean time I will play with it in the next few weeks to see if its hostable in another sensible way.

@dc42 - thanks. For the first time, it's not "pilot error". Looking forward to beta3.

@T3P3Tony

Just tried the 3HC board sch file and I believe you are correct that it wants a different format as got the same error as before.

I will try a different approach, thanks for the help.

@luxirius As @droftarts said, the KiCAD source is there. I do not know of a good import to Eagle from KicAD, especially not the Eagle got bought by autodesk. I suggest you use KiCAD for this. and don't forget to publish your source from your project as well (see the terms of the license agreement ).

@synfinatic I've added "but only 3.3V-tolerant in revision 1.03 boards and earlier" to the table here: https://docs.duet3d.com/Duet3D_hardware/Duet_2_family/Duet_2_WiFi_Ethernet_Hardware_Overview#description-of-connections

Ian

@achrn Thanks for reporting this. I think I got part way through updating G31 a few weeks ago, and didn't quite finish it! I have updated the documentation with a better description, but also used your examples. See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#g31-set-or-report-current-probe-status
For the 3.3 and later section, it now reads:

X,Y,U,V,W,A,B,C...nnn offsets of the Z probe relative to the print head (i.e. the position when the empty tool is selected) can be specified. This allows you to calculate your probe coordinates based on the geometry of the bed, without having to correct them for Z probe X,Y,U,V,W,A,B,C...nnn offset.

Optional parameter 'S' specifies the temperature in °C at which the specified Z parameter is correct. The default is current temperature. In RRF3 you must specify which temperature sensor to use in the 'H' parameter.

Optional parameter 'T' specifies one, or two, temperature coefficients of the Z parameter, default zero. This is useful for probes that are affected by temperature.

If one parameter is specified, it is the variation in Z parameter height with the change in sensor temperature in mm/°C. The parameter is applied to the difference between current measured temperature and calibration temperature 'S'. For example, G31 Z1.2 T0.02 S20 H2 when sensor 2 measures 26C would calculate trigger height as 1.2 + 0.02x6x6 = 1.92mm If two parameters are specified, the first is the variation in Z parameter height with the change in sensor temperature in mm/°C, and the second is variation in Z parameter height with the square of temperature. The parameters are applied to the difference between current measured temperature and calibration temperature 'S'. For example, G31 Z1.2 T0.03:0.02 S20 H2 when sensor 2 measures 26C would calculate trigger height as 1.2 + 0.03x6 + 0.02x6x6 = 2.1mm

I saw your comment in another thread about the reporting of values not working; I'll highlight that to @dc42.

Ian

@kuon Sorry for the slow reply. I added the following to the M950 description a while ago:

Pnn or Snn Output/servo pin number. Each P and/or S number needs to be unique, eg P1, P2, S3 P4, S5 etc. Servo pins are GpOut pins with a different default PWM frequency.

Ian

@Phaedrux M98 did the job. To be on the save side I directly addressed the macro with M98 P”0:/macros/add my network.g” and it worked. Thank you very much for your help.

@achrn thanks for pointing this out. I have amended the text, and I will have the link fixed.

@SDJ thanks, its fixed now.

02fd09f5-6281-4577-91eb-79856fdb0d1e-image.png

@Merlin246 Thanks, I have updated the Gcode dictionary for clarity.

Ian

@dc42 I tweaked the description a bit, as it was a little tautological, to:

From RepRapFirmware 3.2.0 and later, more granular logging is available. There are three log levels, and no logging. When logging is enabled, each line in the log will have the log level of that message added after the timestamp.

Ian

@achrn I have passed this on to our documentation maintainer.