foehnsturm

@jffry7, any news on a possible UM3 integration?

@laverda @henry-tong @Ace1992 @wimismith @3dprinting_guy @Ramzes777 Please send me a PM with your address details and add a remark if you want more than one sensor.

Update, you guys want one: @laverda @henry-tong @Ace1992 @wimismith @3dprinting_guy @Ramzes777 Correct? I'm going to order parts by the end of next week.

Hey guys, sorry for not beeing responsive lately. So, currently interested: @laverda @wimismith @3dprinting_guy Please feel free to correct or add yourself to the list.

Printed at 50mm/s, 30mm/s jerk; bottom half: 20mm square, top half: same square with tiny bulging / ringing corrections. Could a slicer or even a post-processing plugin apply those corrections to the path in a generic way? I think yes!

Well, at and least in theory, you could counteract against the ringing with smarter slicing. If you know the resonance frequency / wavelength, the slicer could alter the path in a way that e.g. at at corner it stops the moving axis like 0.1mm earlier to compensate for the belt stretch and then add this 0.1mm to the axis position again after half of the resonance wavelength to compensate the back swing / contraction of the belt.

Here is what I found so far: The resonance (ringing) frequency of my UM3 is around 26 hz; corner bulging and ringing is affected by wall speed and jerk; you can mostly ignore acceleration, as (at least with usual settings) it happens in a different time scale. As commonly known, the bulging happens due to overpressure in the hotend. This will inevitably (pressure advance algotrithms could probably help here) build up when printing with more than very modest speed (like 20-30mm/s). "Slow" deceleration doesn't help to release the pressure, because our "slow" like 500mm/s2 or even 100mm/s2 is way too fast. Deceleration still happens in a timescale of less than 0.1 sec, which is one or two magnitudes too fast to show any helpful effect on the extrusion system. So, if you want to print with more than very low speed, you're like going downhill in a car with very weak breaks. If you want to go fast straight you have also to corner fast: I got the same perfect, almost bulging-free pre-cornering surface with standard 20/5 speed/jerk as with 50/30. With a speed-jerk difference above 20 the bulging starts, irrespective of acceleration (tried from 100 mm/s2 to 2000mm/s2). But fast direction changes will produce ringing after the corner. The printhead and the belts form kind of a resonating mass-spring system. The amount of "bad" energy stored there, again monstly depends on the speed difference between the two adjacent paths, which is defined by the jerk setting. However, there's is some positve effect (less stored ernergy) when decelerating very slowly but this is ruined by the increased bulging. The ringing may possibly be reduced by some kind of hardware measures for low frequency damping. E.g. somehow decouple the belt vibrations from the printhead. Another approach, which could show some positive effect, is to measure the ringing frequency (print speed / distance between the ripples) and find a specific deceleration rate as explained in the Duet3D forum. Left (standard): wall speed 20/30mm, acceleration 500/1000, jerk 5/10 | 30 min Right: wall speed 40/50, acceleration 526/789, jerk 20/20 | 22 min

I check if I can do a test on the UM3 with 0.6

To my experience with different nozzle sizes, it's - unfortunately - almost impossible to compare different sizes. It's not just the reduced resolution with bigger nozzles, but the entire extrusion system loses some controllability, especially with 0.8 and above.

could you share a link to your test part file (stl, step)?

Could a few people share short (ideally < 1hr) real life prints where they experienced serious ringing issues with the UM3 and the settings they used? Or the other way round, prints that suffered from the massive reduction of accelleration and jerk (rounded corners etc.) I'm testing a UM3 mod and the usual ringing tests show some improvement. But real life prints might be a whole different story.

As for the material question.Its operation temperature should provide a reasonable safety margin to the bed temperature you are typically using. E.g. if you print ABS with the bed at 100°C you should look for something with a really high softening point. Other requirements are not that demanding, but as the magnets are glued, the material should work well with serious glue.

@3dprinting_guy, for an UM2GO with the old black feeder you would have to design an adapter. Not sure about the firmware (@tinkergnome ?).

Hi guys, holdays are over here now. Any experiences with the sensor to share so far? @cjs, @conny_g, @fbrc8-erin, @Dim3nsioneer, @jffry7

Super nice.? I already knew, you're well very organized person. ?

A hall effect encoder instead of the AMT is doable but would require to attach a magnetic target to the shaft and some kind of mount and housing for the PCB. The encoder you are linking to seems to be discontinued, I'm not sure if there is a newer alternative which provides the same interface.

Thank you. I made some corrections. There's no separate "mark2 for Ultimaker2 Extended" definition. I think the only important thing the Extended defintion files are overriding is the machine_height setting.

?

It should be there somewhere but I had no luck with a quick search. So: Tinker-Mark2-dual -> Standard UM2(+) Mark2 but without the tiny Mark2 PCB Tinker-Mark2-expansion-board -> UM2(+) Mark2 with the Mark2 PCB --- extended --- > same for UM2(+) Extended printers I assume you don't have the PCB as you had to extend cables.

Here are some basic operating instructions Unscrew the lower screw that holds the feeder cover, mount the adapter (use a longer screw in case). Push the flow sensor into the mount and rotate 90°. It's a very good idea to use a filament guide together with the sensor. There are a lot of designs available which are mounted to the screw some 7 cm below the feeder which secures the XY stepper cover. It's vital that the flow sensor wheel moves with almost no resistance when there's no filament present. Connect the cable as shown here. Implemented Gcode M591 T - extruder number T0 or T1 (default=active extruder) S - S0 = disable filament monitoring, S1 = enable filament monitoring E - extrusion length for each comparison (default 0.20mm) A - smoothing factor for exponential floating average (0.05) L - filament movement per pulse in mm (1 / steps, default 66) R - min/max percentage (print will be paused if the average is outside of these values) P - set value for the average percentage All parameters are optional. E and R are global (the same for both extruders) Complete example: M591 T0 S1 E0.2000 A0.05 L0.015 R40:130 P100.00 Basic settings You can set the "L" value via the screen menu as well: Advanced / settings / filament sensor. Use "move filament", there it displays the number of encoder steps and the calculated percentage as well. Move like 10 mm and use the number of pulses to calculate the movement per pulse (most likely in the range of 0.015 to 0.017). The default E and A settings: E is quite short (0.2mm) and A low (0.05). That means the average is calculated every 0.2mm but in the way that the new measured value only influences the result by 5%. For calibration I use high E like 2.0 and A1.0. Then, encoder pulses and percentage match immediately. Fo regular printing I found values like E0.5 and A0.3 to work well. Tinkerware firmware for standard, single extrusion UM2+ Tinker-MarlinUltimaker2plus-18_07.zip Tinkerware firmware for dual extrusion UM2+ Mark2 Tinker-Mark2-18.03.4.zip The original 18.03.4 works well but after a pause and resume due to a flow sensor alert it doesn't reset the calculated flow average. This is usually hidden by the retract and prime move which helps to increase the average again. But sometimes it stays low enough to immediately trigger the next alarm. Here's the link to a slightly modified firmware. Tinker-Mark2-expansion-board-18.03.4fs.hex

@tinkergnome mentioned there's already a driver for the Allegro A1335 chip, which UM uses for the encoder. So we would have to make a copy and adapt it to the registers of the chip our adapter provides, right?

@jffry7 Maybe this one already solves the hardware problem https://www.tindie.com/products/Saimon/i2c-encoder-connect-rotary-encoders-on-i2c-bus/ EDIT: Ofc just using the PCB together with our high resolution encoder

@robinmdh, if we set this to true, the UM3 would already try to read the flow sensor via I2C?

Well, right now I see two options for a UM3 integration. A) Connecting the the encoder's quadrature signal to the electronics and enhancing the firmware in the same way as for the UM2. B) Developing a tiny hardware device (< $10 arduino) which converts the quadrature signal to the I2C protocol and using (and improving) the already integrated firmware routines for a I2C flow sensor (which have never been used for the UM3) My gut feeling is that B) is the more promising.

Yep, it does but you have to print different adapter. @rigs is already testing it with a Bondtech.