Posts made by wcj97

@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

@Phaedrux RRF 3.0, and all webserver related things were updated to the most recent version just a couple weeks ago.

I've been trying to run a large print of head straps for some of the new PPE that's been going around the 3D printing community, and because they're taking up the entirety of my almost 500mm x 500mm bed, I've found my bed probing to be a little less accurate than I'd like. Usually this wouldn't be a big deal, but my Z babystepping doesn't seem to be working (or holding I should say). During the print, if I send a babystep command, I can see my ballscrews rotate to compensate, but after about 2 sec, they rotate back by the same amount. I thought maybe I was just seeing the printer adjust for a change in the height map, but it is clearly doing this after any babystep command I send. If I send 4 babystepping commands, one after the other, I can watch as about 2 seconds later my Z axis hits ctrl+Z and undoes whatever adjustment I made. I thought maybe my motor idle time was set too low, and the motors were adjusting a step and then losing it due to a loss of power, but my idle time is set to 30 seconds, and even right after the controller reverts from the babystep I applied, I can see my ballscrews rotating ever so slightly due to mesh bed, so it can't be the motors going idle.

Is anyone else having this problem? Is there some other line in my config that may be affecting this?

Thank you in advanced!

@dc42 Something I just thought of - why not use the rotating magnet filament sensor for this? I could place it in the bowden path between the selector and my extruder (much closer to the selector) and use that to monitor whether the commanded retraction to the selector matched the actual distance traveled by the filament. I would then only need the single sensor - no switches or combinations of switches with other sensing techniques. That would also allow me to monitor filament feed issues during a print.

@dc42 I hadn’t, but that’s a good idea. Then I would only need a single switch or sensor on the low end of the filament path.

I’m thinking of implementing an inductive sensor as my switch on the low end as well, in a very similar implementation to Prusa’s MMU2

I should also note that I'd like to use this as a way to run multi-color prints, so everything needs to be able to run within the tool free/pre/post/ macros

So I looked around as much as I could, but couldn't find anyone else using a filament sensor in quite the same setup that I intend to, so I wanted to ask a couple questions about what will and won't work.

I've been working on a filament auto-load/switch setup for my printer. It's very similar to the Prusa MMU2, but I'm only using 2 motors (for now (; ). My printer is direct drive, but there is a bowden tube running from the filament selector to the extruder drive which is maybe 300-400mm long. When I perform a filament swap, the loaded filament will be driven all the way back to the filament selector, the selector will slide to the next filament position, and the new filament will be loaded to the extruder. I need a way to detect that filament has been driven all the way to the hotend, or all the way to the selector (depending on whether the load or unload procedure is carried out). I'd like to just use micro switches to do this (one within 50mm or so of the extruder, and another within 25mm of the selector). Can I essentially home the filament position like a normal axis? Tell it to reverse the filament up to 500mm, or until a switch is triggered? I would also like to use the switches as filament out sensors if it's possible to set this all up.

Apologies for any poor explaining! If any clarification is needed please let me know.

Thank you in advanced!

@Phaedrux Coming back to this thread for a quick question regarding jerk (instantaneous speed change).

The instantaneous speed setting is the speed the motor can jump to before acceleration is taken into account, correct? So if my max speed for my extruder is 6mm/s, and I set my instantaneous speed settings to 360mm/min (6mm/s), acceleration isn't being taken into account at all, right? The controller is assuming that it can instantaneously accelerate from 0 to 6mm/s?

Currently, performance is good at my current jerk values, which are set well above my max speed. I guess what I'm asking is: at this point, increasing jerk or acceleration settings doesn't really make any difference right? I've already told my printer that it can instantaneously jump to extrusion speeds well beyond my max speed, so does increasing my jerk values from here (or making any change to my accel values for that matter) have any affect at this point?

@Danal Whew! Didn't have to do the erase procedure luckily. I was finally able to get connected over serial. For whatever reason, the Duet was ignoring an apostrophe in my SSID. Not sure why, but I just changed my network name on my router and was able to get connected again.

Thanks!

@Danal Tried a couple different cables, and every individual port. Still nothing. Also, running the Duet standalone. No Pi connected