Posts made by whopping pochard

@phaedrux This is definitely where I've seen it happen. With the large PCB heater bed I initially had on my coreXY, it was profound. I could see it plainly by eye, no indicator necessary.

Was chatting with some buds on Discord the other day and the thought occurred:

Perhaps it could be done to use some sort of basic machine learning model to integrate data from a bunch of different sensors in order to make a more robust filament monitor that could also identify different filaments?

I was impressed by the quality of data that Thomas Sandladerer got from his nifty filament width sensor---as well as how clearly different different spools were.

That got me thinking: what one took a couple of those filament width sensors and paired them with a few other sensors---say, light transmissivity at a couple wavelengths, capacitance, and a simple color camera under defined lighting conditions---and fed them as inputs to a model. I betcha you could train it to both recognize different filament feed error modes and filament feed rates, as well as to actually recognize particular spools after using them for the first time. Might be a clever way to keep track of filament usage too!

I don't actually have much expertise in this area, but it seemed like a fun idea, so I thought I'd toss it out there.

Thanks for your help, everyone! We have automated heatbreak profiling! Woo!!

Poe's Law strikes again!!

@fcwilt Thanks! I’m running the latest 3.x firmware on the SKR 1.4. My original Duet boards are all in actual printers.

@jrockland Ahhhh that is what was tripping me up! Thanks!!

Hi all,

I've been working on putting together a little rig for empirically testing hotend components (because I'm a giant nerd, I love data, and had an extra SKR 1.4 board laying around).

I have it set up with a basic extruder and groove mount block for pushing plastic, as well as with a second groove mount placed below a tiny linear axis. The idea is to write a gcode macro to take temperature measurements at 0.1 mm increments across the heat break.

Is it possible to just define a single axis, and still have it home that axis and accept subsequent move commands? Should I assign it to a non-XYZ axis name? Any other hints or suggestions?

Thanks!

@T3P3Tony brilliant!! Thanks so much!

Beautiful machine! It's looking really great.

Maybe M928? Could that also log temp pings? If so I could just log everything and parse after.

Hi all! Is there any gcode available to store a temperature to a log file?

I am working on a test rig for empirically testing hotends, and it would be handy to have some way to store temperature data at discrete time points using a macro. Is this possible?

Thanks!

@oliof I have some cheap rails that are pretty curved in the pitch axis. They flatten right out when bolted down to extrusions. I suppose this is not news to anyone here but probably extra important not to cheap out on the X rail if it’s unsupported.

@psychotik2k3 Yeah that is so awesome! If mine doesn't work out I might try to do that as well. I'm finally back in town so hope to get back to it soon.

@o_lampe Wow yeah a good use for stall detection on the E motor! Very interesting.

As far as I gathered, if it displayed the issue, it had the old firmware. Specifically, what it looked like was it would trigger twice -- once around 8-11 mm away, and once at the proper trigger height of ~2-3 mm. You could see it as a sort of intermittent illumination at the 8-11 mm distance. I don't think you could actually check the firmware directly without an AVR programmer, which I didn't happen to have. I solved the issue by buying a genuine part.

I will carve out some time to update my files this weekend. I'm now hosting at PrusaPrinters because Thingiverse is too unreliable. Will ping here when I get them up!

-j

It does seem like there ought to be debounce enabled in the software! A very quick search on GitHub showed debounce on rotary encoder input and fan rpm input, but none that I could see associated with basic switch inputs.

There are also debounce ICs if you want to hit it with the hardware hammer.

The fact that there is no difference apparent between settings suggests to me that retraction isn't happening, per @bot's suggestion. If you put a mark on the filament, can you see it jumping up during retractions?

Hooray!! Glad you solved it!

Your 'squaretest' file has only G1 moves, right? Are you sure you aren't missing steps due to a mechanical or electrical problem?

Check out the roadmap post here for some related info: https://forum.duet3d.com/topic/20602/reprapfirmware-road-map-q1-2021