@dc42
SPI success! Before unwinding everything, I took another look at the git repo and spotted LISAccelerometer.cpp had been updated after my other file update. I updated that file and everything compiles for LIS3D on SPI.

Ill mark this question as solved once I confirm HW function. I have the chip carrier for the SAME5 on order but probably won't rec for a couple weeks. I may just order the PCB regardless as I need the machine back up and running and the accelerometer no critical for its fxn.

@dc42 understood, thanks 🙂

@droftarts
I have updated the description so that it hopefully becomes clearer how much material has to be extruded and why you should aim for a 20% plus error margin and that you should use the temp_base for slicing.

@dc42 I see... I was trying to use the default baud rate of the device I communicate with, which is 57600. I tested with 9600 and it seems much better!
Thank you very much! I would never have thought of such a thing...

@ReXT3D What settings did you end up using for Klipper? Did you set the sense resistor value to 0.076, or did you have to configure vsense somehow? I'm having some overheating issues with the example klipper config, even with the motor current set quite low.

@blair yes this new functionality applies to axes driven by expansion motors too in RRF 3.6.

@dc42 said in Change name of 1LC or Sammy board in Firmware:

That is where you would need to change the name of the file that is installed when you command a firmware update or a CAN reset.

Awesome, thanks, I will try it!

@NineMile please create a feature request for this on the Github Issues page of the RepRapFirmware project.

Thanks for giving me some context, I might tackle that feature request at some point 🙂

@dc42, the Modbus sounds very interesting, but I think CAN-FD is the more fail-safe system.

Creating a bootloader and firmware for a SAMC21N18A went smoothly and because of the GPIO limit I also found a way to address many more ports.

As a newbie, i'm still impressed by the many possibilities that duet3d has to offer.

@dc42 thanks!

I upgraded to 3.5.2 and it seems the issue is gone.

Thanks for the help

@Omer1015 What makes you think the firmware is being corrupted? It sounds more like your newly built firmware is not working for some reason. I suggest that you try just building the standard firmware using your build environment and test that (as well as comparing the size of your build with the official build). I know of several folks that have successfully built the firmware, so I don't think there is a major problem with doing that. Are you certain you are using the correct version of the gnu C compiler and tools, that is what folks often get wrong.

Returning to the topic of integration of a THC, I'm a little baffled how the implementation works.
I see there is M951 and M594, but it's unclear to me where the reference value is set.
Typically your cut charts will have a reference voltage which ensures that at a given speed, if the measured arc voltage is X then your torch to work distance is correct.
If the measured voltage is X-nn then the THC raises the torch and vise versa
Is the reference taken at the point when you turn on height following mode?
If so then you would have to ensure you are at full speed before it's enabled because speed affects the arc voltage. (Not just height)

@qurt I think it would need to be modified before it gets to the command queue, as it's very difficult to modify anything once it gets there. For more information on how the command queue works, see https://docs.duet3d.com/en/User_manual/Reference/Gcodes#command-queueing

You can shorten the command queue for quicker response to changes that you are streaming in, using M595.

But the shorter the queue, the more likely buffer starvation will occur. If you are streaming Gcode over USB, see Printing over USB connection for other limitations.

Ian

@sh54 For the 6HC and SBC mode just use the regular MB6HC build.

@chrishamm Thank you. That's exactly what I was looking for.

@meeloo @dc42 I just tried to reproduce this in SBC mode and G00 is interpreted as G0, and G01 is interpreted as G1. I couldn't see a difference between G00/G0 and G01/G1 from a USB terminal either.

@xXJRUSHMANXx See:
https://docs.duet3d.com/User_manual/RepRapFirmware/RepRapFirmware_overview
https://docs.duet3d.com/User_manual/Reference/Developers
https://docs.duet3d.com/User_manual/Reference/APIs

Ian