Hey guys. About a month ago i was finally able to get my printer to a good working state - or so i thought. I started printing smaller things without issue, now I’m beginning to push the boundaries a bit and print bigger. The issue is, I’m starting to get later shifting. The shifts always occur in the Y axis, where I’m using a Nema 23 geared down with a 3:1 reduction, which drives a shaft and two g2 belts to slide a gantry (I can post photos if needed).
At first, I thought this was a mechanical issue. My print head sits very close to the build plate (only a couple mm higher than the lowest tip of the nozzle), so I thought some portion may be catching, but the Nema 23 is pretty tough, and I have to apply quite a bit of force to cause the gantry to shift (and even when I do that, the belts slip before the motor skips).
Most recently, I’ve decided that maybe the motor is getting too hot and is not behaving optimally, but I can’t imagine it’s getting that hot without causing any damage or permanent flex to the ABS mount it’s bolted to. Plus, I’m only running it at 1000 - 1200 mA (the motor is rated for 2 or 3 amp max, I believe). I would increase the current, but as I’ve said already, the belts slip before the motor stalls, so I don’t think adding MORE torque would really do anything.
Does anyone have any ideas? I’m lost and it’s starting to get frustrating because all I want to do is print big! Haha.
Thank you in advanced for any and all help (and I apologize for the super long write up)

Got it! My machine is now running 3.0. I had to revert back to 1.19, but the second time around I was able to successfully update everything. Time to update my config file and start playing around. Love the new WebControl design, btw!

Thank you everyone for your help!

@chrishamm said in Conditional Loops running slow after SBC addition:

M576 S0

That worked perfectly, thank you! I was afraid the issue might have had to do with how the SBC sends commands to the Duet. Startup script is running normally now.

I've had a duet 3 mini 5+ running on a machine of mine for about two years. Recently I added an RPi 4b and made the switch to having an SBC. Everything went pretty smooth, except I have a startup.g that runs at the end of my config that is behaving a bit odd. All the startup macro does is run a little animation on my neopixel strips. Ever since updating to the SBC (and updating to firmware 3.5.1) the startup script takes considerably longer to run (about 10x as long). I did notice that there were some minor changes to the M150 code, but I made the necessary updates after updating to 3.5.1.

There is a delay variable, but changing the value has had no effect since the upgrade. Anyone have any ideas? Am I missing something? TIA!

var ledbright = 0
var increment = 5
var delay = 0.02
var ledglow = 0
var glowcount = 3
var ledcount = 1
var ubright = 0
var uincrement = 4
var bbright = 50
var bincrement = -1

while var.ledglow < var.glowcount
	while var.ledbright < 255
		M150 R255 U0 B50 P{var.ledbright} S16
		G4 S{var.delay}
		set var.ledbright = var.ledbright + var.increment
	while var.ledbright > 0
		M150 R255 U0 B50 P{var.ledbright} S16
		G4 S{var.delay}
		set var.ledbright = var.ledbright - var.increment
	set var.ledglow = var.ledglow + 1
M150 P0 S16
while var.bbright > 25
	M150 R255 U{var.ubright} B{var.bbright} P255 S{var.ledcount} F1
	M150 P0 S16
	set var.ubright = var.ubright + var.uincrement
	set var.bbright = var.bbright + var.bincrement
	set var.ledcount = var.ledcount + 1
	G4 S{var.delay*5}
;	M150 R255 U100 B100 P255 S16
M150 R255 U100 B25 P255 S16

@dc42 was looking at this thread and was curious if this feature got carried into the newest versions of RRF, most notably version 3.0 and on. I'm testing out the possibility of wiring 2 printers to a single board (mostly for testing purposes), and I've found that it was easy to just create a macro to change certain portions of the config while the secondary printer is being run, but things like homing files and the like aren't so easy. The separate directory as you've stated would make this much easier to implement.

@dc42 Could the new conditionals be used to accomplish this? I've just started to add them to my macros and things this evening. Would it be possible to say something along the lines of:

while sensors.filamentMonitors[0].distanceMoved <= 300
     G1 F600 E-25

I'm still learning the syntax and what all of the implemented object models are, but is there a way I could make that happen?

@dc42 It's fairly reliable as I've tested it so far, but there is always a chance that the filament will drag a bit when being pulled from the extruder and won't retract the full distance, or there may be a bit of extra friction or resistance here and there that may cause the secondary extruder to slip a bit. If I can ensure that the exact amount of filament is retracted then not only can I prevent massive purge blocks, but I can make sure my filament swapper works on a closed loop and is reliable and repeatable. The swapper will cut the filament, but if there is still a meter of filament in the bowden tube on a switch, it has no way of knowing that it has to purge that much material from the nozzle before moving on with a color change.

In short, I just want to ensure that it works perfectly every time without any major changes in consistency. I could find other ways around the problem, but they require either additional hardware, or a bit of manual entry.

Hey guys, I just installed a filament sensor on my bowden line between my printhead and a filament switching system I've got set up (similar to Prusa's MMU2.0). I'd like to use the filament monitor during prints to check for filament out and clogs and whatnot, but I'd also like to use it when I swap filaments as a sort of endstop.

There is about 1 meter of bowden line running between my filament swticher (Proteus) and my printhead. I have a secondary extruder at Proteus, as well as a primary direct-drive extruder at my print head. When I swap filaments, I need to ensure that the filament retracts a fairly specific distance so that the filament swapper doesn't get caught up on the filament, but also so the filament doesn't retract so far that the secondary extruder doesn't pull the filament passed the drive gear, which would prevent it from being automatically loaded again. I thought I could use the H parameter in a G1 command to tell terminate the move when the right amount of filament is retracted, but that doesn't seem to work without an actual switch. Is there a way I can tell the printer to, say, retract the filament until the filament sensor tracks that 600mm of filament has been moved?

Thank you in advanced!

I'm having the same issue since I updated from RRF 3.0 to 3.01-RC6 and to Web Control 2.1.0

@Phaedrux That's it! I did some more testing today and found that the babystepping works fine for a few steps, but starts undoing itself after the values become a bit more extreme (~200-300 microns). I didn't realize that the axis minimum still affected babystepping values. Thanks again for helping me diagnose!

@Phaedrux DWC using the built in buttons. I don't have a PanelDue unfortunately.

@Phaedrux Nope still doing it