Posts made by dc42

@justGuner it's documented in the Trinamic datasheets that you can get spurious short to ground errors in stealthChop mode at high speeds. StealthChop only works properly at low to medium speeds. So it's not much good for 3D printing unless you are prepared to reduce the maximum speed for the sake of quietness.

@dwuk3d thanks for trying.

@Tech_Sam03 said in Core XY high speed closed loop tuning:

Also increasing the a therm didn`t help because i get those weird spikes in the P and Error therm. Im really exhausted i dont now if it will ever work...

What weird spikes? Please post a plot from the tuning plugin that shows them.

We have some more work planned on the closed loop code that we expect to improve the speed somewhat. It's also possible that using higher current lower inductance motors might help - but it's the product of inductance and current that matters, so the inductance needs to go down more than the current goes up.

@DMMAGIC said in RFF 3.6.0 Sensorless Homing, strange behavior:

since the update to 3.6.0, I've been having issues with sensorless homing. When I home the X-axis, it works. But when I home Y afterwards, it immediately triggers a stall. After M112 Same thing the other way around: if I home Y first, it works, but then, after X homing, X triggers a stall right away.

TBH I'm surprised that it worked in 3.5.4. On a CoreXY machine, homing either X or Y involves moving both motors, and when either of them stalls the homing move is stopped. The stall flag for the motor will remain set until it has moved at least one full step in the opposite direction. So if you try to home the other axis immediately, then depending on the acceleration setting, that same stall indication may stop the homing move.

Reducing acceleration for stall homing moves using M201.1 might avoid this happening. However, the recommended approach is that after homing an axis you should use a G1 H2 move to move both motors a small amount in the opposite direction, before homing the other axis. For example, after G1 H1 X-1000 to home to a low X endstop, G1 H2 X3 Y3 will move both motors in the opposite direction.

The behaviour with M915 H0 sounds like a bug. I have logged it at https://github.com/Duet3D/RepRapFirmware/issues/1124.

dc42 created this issue in Duet3D/RepRapFirmware

open M915 H0 causes loss of CAN connection #1124

@MaxGyver please connect a PC running a terminal emulator to the USB port of the main board, and see whether it prints any debug messages on that terminal when this error occurs.

@ironhydroxide thanks for all the data. I am tracking this issue, but unfortunately it will be some te before I can investigate it further.

@demonio669 ok, if it happens again then please post a M122 report again.

@madedi even at high baud rates, Modbus RTU isn't fast enough to handle the motion commands needed to drive an axis of a 3D printer, especially when using advanced features such as input shaping and pressure advance.

@dwuk3d thanks for the information.

I've been looking into this issue and found a couple of relevant points:

1. The restriction that an expansion board can only be used with a single motion system should not apply in firmware 3.6.0 (it does apply to previous firmware versions).

2. I've found a possible issue with the use of a main board as an expansion board, which doesn't apply to ordinary expansion boards such as the 3HC. I've generated a new RRF for the Duet 3 Mini with a fix for this issue, attached to this post. Please try it.

Unfortunately it will be some time before I am able to set up a test system to replicate your configuration, so if this build doesn't fix the issue then I will ask @droftarts to see if he can.

Duet3Firmware_Mini5plus.uf2

@FHesse because you are using an isolated power supply, I think you need to install this jumper on the ADC daughterboard too.

o

@sebkritikel said in ATSAME51J19A (Adafruit M4 CAN ) Bootloader and Firmware:

For XOSC1, from what I can tell, this seems to be working correctly. From my read of the code, it should be grabbing the changes I made to use XOSC1, and with an oscilloscope I see a 25MHz signal.

It's also important that the both DPLLs use the correct XOSC as the source; but as far as I can see, this is the case.

TOOL1RR, EXP3HC, and EXP1HCL use TC0, TC6, and TC0 respectively, while the SAMMYC21 (recognize its a SAMC21) uses TC2. Is the selection arbitrary, or do you have to ensure you select a TC that is not used in the pin table?

The TCs are 16-bit so to get a 32-bit one the hardware uses an even numbered TC and the next higher one. So you can select any even TC number with neither that TC nor the next higher one used for anything else. So if you choose TC0 then neither TC0 nor TC1 should appear in the pin table.

@sebkritikel said in ATSAME51J19A (Adafruit M4 CAN ) Bootloader and Firmware:

For the PinTable, what drives the population of TC, TCC, ADC, etc. Of course you have the definition of user accessible pins, but not all of the capabilities listed per-pin from the SAM datasheets are present in the table. From what I've seen, it appears as if a TC is defined for a pin, you don't define a TCC, and vice versa.

We allocate each spare TC or TCC to provide PWM capability on one pin. In principle some TC/TCCs could provide PWM on multiple pins, but then the PWM frequencies wouldn't be independently settable. We allocate spare ADC channels to input pins in the same way.

@sebkritikel said in ATSAME51J19A (Adafruit M4 CAN ) Bootloader and Firmware:

When working in Eclipse, whats the best approach to creating new build configurations and targets?

Create a new build configuration, telling Eclipse to copy it from the most similar existing configuration - in particular, one that uses the same processor family. In your case the most similar debug configuration is EXP1HCL-Debug as there isn't a TOOL1RR Debug configuration.

@sebkritikel said in ATSAME51J19A (Adafruit M4 CAN ) Bootloader and Firmware:

Can't edit the makefile directly, as if you even made changes, they're overwritten on the next build.

You can delete the makefile, that forces Eclipse to recreate it from the Eclipse project configuration. You may get an error when you try to build, but just press Build again and it will go away.

@timschneider I've analysed that stack trace. The reset occurred when RRF was talking to the I/O expander on the DueX, probably adjusting the PWM of a heater connected to the DueX. However, the address of the hard fault doesn't make much sense. I think that either the Heat task stack was corrupted by some other error, or there was an event such as electrostatic discharge that corrupted the processor or memory state.

I suggest you check that the VIN ground connection between the Duet and DueX is solid and secure, that all hot end metalwork is connected to Duet/DueX VIN ground either directly or via a resistor, and all extruder motor bodies are grounded. We know that extruding filament causes static charge to build up if these parts are not grounded, and that charge can flash over to heater, thermistor or stepper motor connections,

Does the character sequence "XL7M" occur anywhere in your configuration?

@dwuk3d please can you supply a macro or job file that can reproduce this issue, without needing to use any heaters. Also your config.g file if it has changed since your opening post in this thread. I will try to reproduce it.

Can you provoke this issue by running a file that only moves U and V, or do you need to move X and Y too?

@sebkritikel I've looked at your changes and I don't see anything wrong. However, I can see some possible reasons for issues:

1. We don't have any other SAME5x configurations that use XOSC1. So it is possible that the startup code that references the crystal oscillator doesn't work when the xosc number is set to 1. However, I've looked at that code and apart from some comments being out of date, I didn't see any errors.

2. Debug builds can either user serial debug or CAN debug, controlled by defining USE_SERIAL_DEBUG. The only other debug build I have used in depth is the EXP3HC debug build, which uses serial debug. You are using CAN debug. I think this may lead to problems or recursion if there is a problem in CanInterface that results in debug output being generated, So I suggest that for now you modify functions debugPrintf and debugVprintf so as not to call CanInterface::DebugPutc but instead throw the character away. You might also like to put breakpoints there so that you can see if these functions have been called, and where from. Alternatively you could switch to serial debug, but then you will have to set up a serial port for it.

HTH David

@sebkritikel please can you provide a complete diff of your fork in its current state against 3.6-dev. For the linker script and Pins file, please diff against the original files from the TOOL1RR configuration.

We've logged an issue with 3.6.0 which arises when using manual bed probing (G30 with no Z probe) and when using M291 dialogs that include jog buttons. See https://github.com/Duet3D/RepRapFirmware/issues/1121.

Temporary RRF 3.6.0+1 firmware builds that fix this issue are available at https://www.dropbox.com/scl/fo/voozf7t89z62xtsuvujpw/AFCw88c8AD9KkIJWu1WUWQw?rlkey=1v4avgwztmfawesphfqu6hbw7&dl=0.

dc42 created this issue in Duet3D/RepRapFirmware

open Issues with manual bed probing using G30 and manual jogging in M291 in 3.6.0 #1121

@sebkritikel your linker script sets the code start address to 0x4000 which is correct if you have a 16K bootloader. The bootloader will change the vector table register to point to address 0x4000 before transferring control to the main firmware, and it will set the stack pointer to the to of RAM as indicated by the vector table.

If you are loading the code directly via the ICE and not using a bootloader then you must build the code to start at address zero instead (unless your debugger gives you the option to set the vector table register to 0x4000 before starting). See configuration EXP3HC-Debug for an example. Aside from the DEBUG flag being set (which you have done already), the linker script is changed to start the code at address zero.

@dwuk3d ok. After UV stops moving, please run both M122 and M122 B# where # is the CAN address of the expansion Mini5+, and post the responses here.

@demonio669 is this repeatable?

@dwuk3d please try setting idle current percent to 100 (i.e. M906 I100) in the expansion Mini5+ config.g file, in case the expansion Mini5+ is incorrectly implementing its own idle detection.