@gloomyandy the values I quote are as used in my config.g, so yes there is a unit confusion error here. Which would put massive limits on e acceleration (although it is not entirely clear to me what happens if E acceleration exceeds the limit of E jerk/PA).

EDIT: OR the limits are to be computed as above and the unit confusion is irrelevant. One for @dc42 to clarify.

@jenna-k2 interesting, when you can share more it would e great for you to post about it in the "My Duet controlled machine" forum section.

@droftarts i was looking in the seial window for debugging and missed the module numbers.
My Bad no issue

@droftarts Much appreciated, thank you!

@Herve_Smith very nicely explained and done, thanks!

As shown in @Phaedrux 's screen shot, if you're using google, you can use a site-specific search, which will return results from solely the specified website. I use this a lot to search the forum.

For the forum, start your search with site:https://forum.duet3d.com/ with your search terms after.
For the wiki, start your search with site:https://docs.duet3d.com/ , again with your search terms after.

Ian

@nikscha Thanks, I've updated the Gcode dictionary. https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m567-set-tool-mix-ratios

Ian

@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