Posts made by Otso

This is not a problem for me personally anymore. I built an osx-arm64 CrcAppender for myself, and everything works now.

@droftarts said in CrcAppender on ARM Mac:

I don't know if this was a bug in Eclipse, but this was the only way I could work around it, as outlined in steps 3 and 4 of the build instructions. Let me know if this solves your problem.

It's not a bug. /usr/local/bin is not in the PATH:

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.

But, above when I got the error, I did exactly as instructed in step 3 and 4.

@droftarts Thanks for your reply. I did step 3 and 4, and still get the same runtime error when building from Eclipse:

19:52:46 **** Incremental Build of configuration Duet2 for project RepRapFirmware ****
make -j9 all 
Building target: Duet2CombinedFirmware.elf
Invoking: Cross G++ Linker
Finished building target: Duet2CombinedFirmware.elf
 
Generating binary file
arm-none-eabi-objcopy -O binary ".../RepRapFirmware/Duet2/Duet2CombinedFirmware.elf" ".../RepRapFirmware/Duet2/Duet2CombinedFirmware.bin" && CrcAppender ".../RepRapFirmware/Duet2/Duet2CombinedFirmware.bin"
A fatal error occurred. The required library libhostfxr.dylib could not be found.
If this is a self-contained application, that library should exist in [/usr/local/bin/].
If this is a framework-dependent application, install the runtime in the global location [/usr/local/share/dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [/etc/dotnet].

The .NET runtime can be found at:
  - https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=osx.14-x64&apphost_version=6.0.5
make[1]: [post-build] Error 131 (ignored)

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?

Edit: The CrcAppender page says:

In order to use the standalone files, the .NET Runtime must be installed.

which seems to be true.

I should probably update the to the title to "Building on (Arm) Mac".

Some additional minor documentation feedback https://github.com/Duet3D/RepRapFirmware/wiki/Building-RepRapFirmware for building on the Mac:

• Step 5: When building newer firmwares one should also import CANlib and DuetWifiSocketServer to Eclipse
• Step 6: To be fair, this step mentions with regards to the above:

See the instructions for Windows (above), step 12, for the dependencies and configurations needed.

but I believe the correct step is 11.

I'm looking into building the firmware on an M2 Mac.

https://github.com/Duet3D/RepRapFirmware/wiki/Building-RepRapFirmware says:

Building RepRapFirmware lately requires a tool called crc32appender to be in the user's PATH as it will be called at the end of the compilating process. It can be found as Golang source code in Tools/crc32appender together with pre-compiled binaries for Windows, Linux and MacOS x86-64.

Apparently this has been replaced with a dotnet version that is located here: https://github.com/Duet3D/CrcAppender so the documentation could be updated to indicate that newer firmwares use a different version and the location of the source code.

I tried to run the Mac x86 version on my M2 Mac, and it executes using Rosetta, but I get the error:

A fatal error occurred. The required library libhostfxr.dylib could not be found.
If this is a self-contained application, that library should exist in [...RepRapFirmware/Tools/CrcAppender/macos-x86_64/].
If this is a framework-dependent application, install the runtime in the global location [/usr/local/share/dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [/etc/dotnet].

The .NET runtime can be found at:
  - https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=osx.14-x64&apphost_version=6.0.5

Before I install dotnet, I just want to make sure, do I need to install it, or is the library libhostfxr.dylib available, or do I have some other problem?

(A prebuilt native ARM binary would be nice, although Rosetta is fine, or then one can of course compile it oneself.)

Edit: Reading https://github.com/Duet3D/CrcAppender, I see that it should be possible to make a standalone CrcAppender:

dotnet publish -r osx-x64 -p:PublishSingleFile=true --self-contained false

This will generate a standalone application without additional runtime files. See here for a full list of runtime identifiers.

So is the binary in the 3.5-dev branch supposed to be standalone, but is not?

Edit again:

I know nothing about dotnet, but just reading about it I found this:

Standalone Deployment:
When you create a standalone deployment, your application relies on the presence of the .NET runtime on the target machine. It means the target machine must have the necessary version of the .NET runtime installed in order to run the application. This is similar to how traditional .NET Framework applications have functioned.

Self-contained Deployment:
In contrast, when you create a self-contained deployment, you package the .NET runtime and the libraries that your application needs along with your application. This allows your application to be deployed and run on machines that do not have the .NET runtime installed. Self-contained deployments are larger in size compared to standalone deployments, as they include the necessary components for the application to run independently.

So apparently I need to install the .NET runtime. A self-contained binary would be really nice, but I'll go ahead install the x86 runtime for now. The requirement could be reflected in the building instructions.

@droftarts Please update G1 documentation too to say that the max value for S is defined by M452, which defaults to 255.

I may continue the M3 discussion elsewhere.

@droftarts said in Unclear interval in M42:

Thanks for highlighting this. I’ll check with @dc42 whether it’s a documentation and/or firmware change.

Ian

If you are referring to my sarcastic complaint about M3 , then I asked about it here quite some time ago:

https://forum.duet3d.com/topic/27718/enable-laser-without-moving

I.e, it was a deliberate firmware change for some reason and is documented in M543:

M3 and M5 no longer turn the laser on and off; use G1 Snn moves to control laser power.

@gloomyandy said in Unclear interval in M42:

@Otso How do you propose fixing it without causing other problems with existing gcode/slicers/etc?

My snarky reply would be that you have the existing programs update accordingly, like I had to do in multiple places when M3 didn’t turn on the laser anymore. This affected both controlled moves and laser focusing/aligning. I still can’t understand why the support for that was removed as removing the support just removed it without adding anything that made it worthwhile, AFAIK. But’s that another topic, that doesn’t belong here.

And the G1 documentation should be updated to say that the max value for S is defined by M452, which defaults to 255.

@gloomyandy said in Unclear interval in M42:

@Otso How do you propose fixing it without causing other problems with existing gcode/slicers/etc?

Just clarifying the documentation would be sufficient for me.

But like I said above, I think it already introduced potential problems when the meaning of value of "1" was changed with the introduction of fractions. But again, I'm not asking for a code change, just a documentation fix.

@gloomyandy said in Unclear interval in M42:

@Otso If you are converting from grey scale you should really be using G1 S, which I don't think has any of these issues.

You're right. I wrongly assumed the same issue would be with G1 S1. But that's not the case. The only potential issue if the other one I mentioned, but that would be less of a problem in practice if the operator takes proper care with the assumption that it can blast at full power regardless of what commands you feed it (by always wearing eye protection etc.) as one should.

So yes, I agree, not a big issue.

@gloomyandy said in Unclear interval in M42:

@gloomyandy Going back to the problem with M42, remember it is used to control things other than laser output (it sets a general pwm level). I suppose a possible fix might be to add a parameter to the M950 used to create the pin and allow that to specify what the range is that will be used by M42. At least that's the best I can come up with that would probably still allow most things to work as they do today.

I'd expect it to work like @fcwilt assumed it worked (and I did too), and that the code would check if it is "1" or "1.", and make the decision based on that. I think that wouldn't break anything, and would retain best backwards compatibility because that was how "1" was interpreted before fractions were introduced, and I'd assume those using fractions now will use 1.0 for full width pulse.

The quick and simple fix would be to mention this is the manual, just as a caution if nothing else.

@gloomyandy said in Unclear interval in M42:

@Otso I'm pretty sure the default is 255 (so the documentation is correct). If you specify a value with R it will be in the range 1 to whatever value you choose, that max function returns that largest value of 1 or your value, so in this case 1 is the minimum value you can set.

Yes, you're totally correct, and so is the documentation. I wasn't thinking clearly.

@gloomyandy said in Unclear interval in M42:

@gloomyandy Oh and in case you are wondering laserMaxPower is set of M452 and defaults to 255.0

Looking at the code for M452:

if (gb.Seen('R'))
{
    laserMaxPower = max<float>(1.0, gb.GetFValue());
}

I haven't tested, but based on that it seems like R is expected to be in the range 0..1 and defaults 1.0, which makes the formula for ConvertLaserPwm() make sense. If that's correct, the manual on M452 is wrong or misleading:

Rnnn The value of the S parameter in G1 commands that corresponds to full laser power, default 255

@fcwilt said in Unclear interval in M42:

Yes, in practice it works. After all how many times are folks going to specify a PWM value of 1 out of the range 0 to 255.

For example, if I use an application that converts a gray scale image to laser power, then some light pixels could map to 1 and cause the laser to blast out full power.

Or if you manually enable the laser at a very low level to set the laser focus or to line up the zero point. (I've been using S0.0001, but I could just as well have started with 1 and expecting it to be low power). Of course, you would notice the problem immediately and shut it down, but still, I don't like this I think it should be fixed.

@gloomyandy said in Unclear interval in M42:

@Otso I've fixed the link to the code used for G1 S it is here: https://github.com/Duet3D/RepRapFirmware/blob/47435151e110f373fc80721a2c265e38b8ec5e3b/src/GCodes/GCodes.cpp#L4770

Thanks! I think I need to get to my computer to investigate the code more to figure where laserMaxPower is set, and what value it has in my case.

Pwm_t GCodes::ConvertLaserPwm(float reqVal) const noexcept
{
	return (uint16_t)constrain<long>(lrintf((reqVal * 65535)/laserMaxPower), 0, 65535);
}

Edit: Thanks for giving the info about laserMaxPower.

@fcwilt said in Unclear interval in M42:

Question: where are you seeing this 0 to 254?

https://docs.duet3d.com/User_manual/Reference/Gcodes G1 documentation says:

RRF 3, G0/G1 S parameter AFTER M452 Laser Mode.
S parameter sets laser power with range of 0 to 254.

Yes, this can be a pretty dangerous bug. I’m using firmware 3.4 and haven’t checked if it has been fixed.

I just tested with my laser and M42 S1 (no fraction) sets it at full power and not at 1/255 as one would expect from the documentation.

Either the code or the documentation needs to be fixed.

Personally I think this should be fixed in the code, especially if it is for backwards compatibility, where one can assume that “S1” previously set it at 1/255 of the power and since the introduction of fractions that changed it to full power.

With the firmware 3.4 implementation the documentation should say:

The S field may be in the range 0..1 or 2..255.

It should be noted that apparently values like 5.76 will probably also work, and be converted to 5.76/255. So the documentation could clarify that fractions are accepted, and the correct documentation would actually be:

The S field may be in the range [0,1] or ]1,255].

With further noting that the notation for the 1..255 range means any fractional value above, but not including, 1.