Topics created by Otso

@Otso said in CrcAppender on ARM Mac:

Are you running on an Arm Mac? Are you sure you don't have the .NET framework installed (perhaps indirectly as a dependency from something else), or libhostfxr.dylib in your library path?

Yes, running on a 14" M2 MacBook Pro using MacOS Ventura. Though I did download the .NET Runtime, I didn't install it; if I run dotnet --list-sdks I get command not found: dotnet. I also got an error on libhostfxr.dylib, but I seem to have got around it another way. I didn't compile CrcAppender.

I'll check through the instructions when I get a chance, and see if I can work out why.

If you add /usr/local/bin to the PATH here, then you don't have to start Eclipse from the terminal (to get the shell's PATH environment variable), and it will find CrcAppender.

Thanks, I'll give that a go too.

Ian

@Otso @fcwilt @gloomyandy Thanks to this thread, I have updated various parts of the documentation:

G1 S parameter section is updated to include that max laser power is set by M452.
G1 S parameter range has been updated, which was 0..254, to 0-255.
G1 S parameter section now describes 'laser clustering', which was added in RRF 3.5.0-beta3.

M42 and M106, where the range of values for PWM and fan settings is referred to, is now worded as follows:

The S field may be in the range 0.0-1.0 or >1.0-255. 0 is off in both cases.

I investigated M3 and M5 support (M4 has never been supported) in laser mode. M3 and M5 are still supported in laser mode, but in 'non-sticky' mode (M452 S0), they are redundant, as all G1 commands need an S parameter to fire the laser, otherwise it just defaults to S0. In 'sticky' mode (M452 S1), you can set the laser with, for example, M3 S255, then subsequent G1 moves will use that setting without needing an S parameter. M5 effectively sets G1 S0. M3/M5 can't be used to fire the laser on their own; the laser will only fire with a G1 movement command.

I will update M3, M4, M5, M452 in the Gcode dictionary, and https://docs.duet3d.com/User_manual/Machine_configuration/Configuration_laser, with the above information.

Ian

@droftarts Thank you, this is very helpful! It will be easy to extract what I want to from that.

@otso The Telnet responder isn't designed to deal with binary file uploads. The reason is that Telnet data is processed line by line and if the line length exceeds the maximum length (255 chars), the line content is dropped and an error message is written to the USB line (if possible).

So, at least for now, you should use the rr_upload HTTP request for binary data. I'll discuss with @dc42 how we will treat M559 from Telnet in the next RRF version.

@otso this is now fixed in the source code. The fix will be in RRF 3.5.0beta1 and in 3.4.1beta1.

@dc42 I now understand the purpose of this. It can be useful for routers when you have a Z endstop in the high position and a fixed Z probe. You drive the router to the Z endstop and measure the distance between the router tool holder and the Z probe. This is the M585 Z "expected distance". You insert your endmill and run the M585 command. The tool offset will now be the distance it is sticking out of the router tool holder.

@oliof said in Enable laser without moving:

@chimaeragh you could even put macros called M3.g / M5.g into /sys ... add a parameter to M3 and you can control the PWM when calling M3. That said I see no reference to M3/M5 being disabled in RRF. Did you enable laser mode?

https://docs.duet3d.com/User_manual/Reference/Gcodes#m452-select-laser-device-mode:
"M3 and M5 no longer turn the laser on and off; use G1 Snn moves to control laser power."