@Toastinator Probably best to follow DC42's request and create a new thread for your problem.

@droftarts As a further data point I use E3D 0.9 steppers with both TM2209 and TMC5160 drivers on a coreXY setup. In both cases I'd say that although they work for me, they are certainly much noisier than the 1.8 motors they replaced and it was also much harder to get sensorless homing configured with them, the range of settings in which the motor would actually move but would also stall when needed seemed to be much smaller.

I operate the drives in Stealthchop all of the time at relatively modest speeds. Print speed max 60mm/S non print moves max 200mm/S. I'm running lower steps/mm than those quoted here mine are 180steps/mm.

All of the above testing was using the RRF STM32F4 port on a Bigtreetech SKR Pro.

What exactly do you mean by having "dwc off"? In all of these tests you need to have your rPi running and connected. If you did not that would explain why G28 was not do anything when you typed it from putty. You can't use the SBC version of RRF without having the rPi/DSF connected.

It is getting pretty late here, so I've got to go.

You should probably set the option in the putty terminal settings:
Implicit CR in every LF
makes the output easier to read.

I'd still like to see the directory listing of your /opt/dsf/sd/sys directory.

Please reboot your LPC board. Make sure that DWC is connected and then connect using putty over USB (keep the rPi on and DWC running) then enter:
M111 P3 S1
M111 P16 S1
G28
M122
and post the output.

@t3p3tony Both the 5160 and 2209 were a pain to tune with the 0.9 steppers. I started out with 2209s and managed to get them working pretty well. I basically use the following sequence during and home move:
M913 X50 Y50 Z50
M915 p0 s25 H125 r0
M915 p1 s25 H125 r0
G1 H1 X-310 F2000
With the same settings and the 5160 the motors would not stall. But if I lowered the S parameter then they seemed to stall pretty much straight away. After a lot of messing around I ended up with the following:
M913 X35 Y35 Z50
M915 p0 s1 H500 f0 r0
M915 p1 s1 H500 f0 r0
G1 H1 X-310 F3000
Basically I had to use a more sensitive X setting and to prevent them from stalling too early I needed to increase the speed threshold. I also found that increasing the homing speed helped make things more consistent.

But I must say that this was not a very scientific process. I suspect that other combinations may well work (perhaps with better results). I was just happy to find a combination of settings that worked reliably!

In both cases the motors are pretty noisy (even using stealthchop) compared to using 1.8 degree steppers, especially at higher speeds. As you might expect with a coreXY pure X or Y moves seem louder (as both motors are active).

@dc42 There is a further 32K that is used for NVM emulation to hold the stack/registers after a reset. This is rather wasteful but on the chips we currently support not really an issue.

Some other things are also a little different in that we have additional code to support any mixture of TMC2208/2209/5160 drivers. A software based UART (for TMC drivers) and software SPI. I'm also pretty sure that our CoreN2G has rahter more in it than strictly needed.

From DC42's post in the 3.2 announcement. If you using the unstable feed (which it looks like you are) you need to use...

sudo apt-get upgrade duetsoftwareframework=3.2.0 duetcontrolserver=3.2.0 duetwebserver=3.2.0 duettools=3.2.0 duetruntime=3.2.0 duetsd=1.1.0 duetwebcontrol=3.2.0 reprapfirmware=3.2.0-1

Having an extruder (or any driver) in spreadcycle mode all of the time may also mean that they are "hissy" when not moving, so maybe using stealthchop with a very low speed switchover is better.

Oh and don't forget that if you are using sensorless homing then the driver must be in stealthchop mode during the homing process, you can set it to other modes once homed.

I run all my drivers in stealthchop all of the time, but I don't tend to use particularly high speeds.

I suspect the problem you are seeing is related to the issue reported here: https://forum.duet3d.com/topic/19074/bed-levelling-traming-odd-message-3-2-beta-2

I think it is a general beta2 issue and not specifically toolboard related (though having a toolboard may impact the timing and cause it to happen more often).

If you get the chance you may want to re-run the test with gcode and SBC debug enabled (using m111 p3 s1 and m111 p16 s1). This may provide a little more information as to what is going on.

Recent versions of Prusa Slicer (I'm using version 2.2.0) insert the estimated print time in the form of a comment that looks like this:

; estimated printing time (normal mode) = 38m 31s

dsf 2.1.0 contains the following regular expression:

"estimated printing time = ((?<h>(\d+))h\s*)?((?<m>(\d+))m\s*)?((?<s>(\d+))s)?"

but this does not work with recent versions of PS (because of the extra "(normal mode)", not inserted in earlier versions). A modified version that does match (and that should still match older strings) is:

"estimated printing time .*= ((?<h>(\d+))h\s*)?((?<m>(\d+))m\s*)?((?<s>(\d+))s)?"

Note the additional ".*" just before "="

In addition it is common for the start up gcode used with this version of PS to contain the following line:

M221 S{if layer_height<0.075}100{else}95{endif}

This line gets included in the gcode file (as a comment) by PS, but it causes a false match against the DSF layer height matching regular expression:

"\slayer_height\D+(?<mm>(\d+\.?\d*))"

and results in the layer height being shown as 0.07mm rather than the correct 0.20mm. The following modified version seems to avoid the false positive and returns the correct layer height:

";\slayer_height\D+(?<mm>(\d+\.?\d*))"

Note the extra ";" at the start of the string.

I've tested the above modified expressions with a number of versions of PS (going back a year or so) and it seems to match values correctly in generated files.

@deckingman The lower limit for Z is defined as -1 in your config.g file. According to https://duet3d.dozuki.com/Wiki/Gcode#Section_G0_G1_Move G1 H1 will set the position to the axis limit. So perhaps that is the cause of your -1 position? I'm surprised that has changed since 3.1.1 though.

@paulhew If you are getting network errors with an SBC setup then those errors must be between your PC and rPi. How do you have these two connected (WiFi, wired ethernet, both?). You may want to open an ssh connection between your PC and the rPi and leave it running to see if that connection shows any errors. If you are using WiFi to the rPi you may also want to check the signal strength. The change in errors may just be a coincidence with the firmware upgrade if the signal is marginal. It is also likely that when you upgraded your SBC software you also picked up changes to the rPi operating system, which may have impacted things. Oh and how are you powering your rPi? It might be worth checking for low voltage events in the rPi syslog.

If the artefacts you are seeing seem to be related to the STL have you tried increasing the resolution of the STL to see if that improves things?

@paulhew Are you running in SBC mode with a rPi attached? If so how are you connecting to the rPi? It might be worth posting the full output of M122.

@s1lencer Is there any chance you are skipping steps when probing the bed? What happens if you probe more slowly?

A couple of quick things that will help folks to help you...

1. What version of the firmware are you using?
2. Always worth checking for errors in your config.g file by running M98 P"config.g"
3. Probably worth posting your full config.g file.
4. When you say it is not working, what exactly happens? Do you get any sort of error report?

I wonder how well microstepping works at these lower speeds and relatively high motor loading particularly with the use of these smaller motors? I seem to recall that there is a relatively large reduction in torque/holding power at the intermediate microstep positions. Perhaps the actual movement is not as smooth as you might expect?

@zabana said in Vertical banding on COREXY machine:

I also extruded on the air with the printed stopped 50mm of filament at 6 and 1 mm/s and the extruded filament has the pattern I see on the printed objects so it is like the stepper movement at low speeds is not smooth at all or something weird happens with back pressure or something like that...

Can you clarify exactly what it was you did for this test and perhaps post some pictures of the result? What happens if you extrude at the rate that is used with your "good" prints, does the extruded output then look smooth?

@o_lampe In this case (using a Duet WiFi) the drivers (TMC2660) do not support stealthchop so switching is not likely to be an issue.

What makes you think that you can't set an extruder driver to be in spreadcycle mode all of the time (on boards that have drivers that support both modes)? As far as I'm aware there is nothing to stop you using the D2 option to M569 with a driver that will be used as an extruder.

@psychotik2k3 said in [3.3 RC3] All tools heaters appears to be overpowered:
That looks like your board may have reset (so the messages will have been generated when re-reading your config.g file). The M122 is reporting a reset due to an AssertionFailed which I suspect @dc42 may want to take a look at. It may help for you to post your tool change macros.

I'm pretty sure that a Thyristor (unlike a Triac) will only conduct the voltage in one direction, so if this module really is just a Thyristor you will only get half of the AC waveform.