@bugpwr Original thread is here: https://reprap.org/forum/read.php?416,832302

Please post your config.g, and the gcode (or a test gcode) that exhibits the problem. Are you pausing in the middle of a long move? Are you using absolute extrusion? Do you have segmentation enabled?

Please could you also test with RRF 3.6.0-beta.2, as this issue may already have been fixed. https://github.com/Duet3D/RepRapFirmware/releases/tag/3.6.0-beta.2

Ian

@dc42 Ah ok, I thought any digital input simply had to be assigned a unique 0-15 Exint. Makes sense now. Ill review the DS and see if I can sort it out.

Thanks for the help 🙂

@dc42
1, point taken and thank you for the heads up.
2, yes this is by design
3, I presumed as much, thanks for confirming as I was having trouble following the revs to understand the relationship

I finally got a blank chip flashed and running w the bootloader and able to tie into the Duet CAN system. The issue was improper fuse setting. To fix I simply set the USER_WORD_x fuses as I read from the OE 1HCL chip;

USER_WORD_0 = 0xFE9AE239 (valid) USER_WORD_1 = 0xAEECFFB1 (valid) USER_WORD_2 = 0xFFFFFFFF (valid)

This is good because I can now debug on the bread board which I can't do in circuit. I proceeded to order my untested circuit because I couldn't get the bootloader to work on the breadboard. I thought this was because the chip carriers got don't have a provision for the bottom solder pad. I assumed that pad was an essential ground that when missing was causing all of my problems. Fortunately not the case.

Thanks for the help David! 🙂

20241207_163237.jpg

@dc42 Oh i was not aware you have forked version on your github. It compiles fine now. Thanks for help.

@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.