Posts made by robm

@dc42 Thanks, sent email to sales@duet3d.com

@dc42 Hi, is this offer still open? We were evacuated and now in an airbnb in Berkhamsted so can receive private courier or other options.

@dc42 I was thinking that too!
I see I can't just queue the order so will just wait.
Thanks though!

Thanks that is a great offer
Just put the order through, or do you have another plan?

UK BFPO address.

I'm thinking of just queuing an order and letting it come when it does.

Stay home and stay safe.

Sigh, 17 March and I just missed Duet3D closing the shop.

Any other UK source for the set of 6 Haydn Huntley magballs?

Thanks

@Phaedrux Thanks, I started from those entries, but see I missed in particular that M593 F0 will disable as I was looking for.

To be clear on M569, written under the Hnn parameter it looks like just sending M569 Pn with no parameters will report the defaults -- will try that out tomorrow.

@bot wow, that is an interesting idea. Thank you, I will have to think about that.

@dc42 my interest is in multiple material printing. Is it reasonable to assume that IR sensors would probably be better than a mechanical switch, or not really clear cut?

I'm thinking about converting one pf my printers to be IDEX - independent extruders both on the X axis. I have a Duet2 WiFi and a DueX5 running this machine.

Seems clear there is only one Z-probe connector to use on the Duet2 WiFi, which I currently have connected to a Duet mini IR sensor. Looking at M558 P options, seems like my only other choice is a simple switch?

Would be very grateful if someone who has looked at this could give an overview of ways I might proceed to have a Z-probe on each extruder carriage? Or maybe explain that this is not really workable for some reason I have overlooked? Seems like I can do the hardware part of this on a Duet3 with more probes added on the bus, but would prefer not to replace my existing hardware.

Thanks!

I'm interested in having a play with M569 and M593 (step pulse timing and DAA). For M593 I see that DAA is disabled by default.

So, I can run through a range of values for M593, but how can I reset it to disabled?

For the various M569 options, how can I determine the starting points if I want to test deviations +/-?

In gcode, I assume that I can reset the hardware but I want to do this e.g. while printing a tower.

Thanks!

I love the bit with the £1 coin

gnydick believes the time to finish estimation based on filament usage became less accurate after a recent firmware update.

msbailly thinks that the filament usage counter employed for that estimate is off because it counts retractions but not the return from retraction.

I think prints take a long time anyway and I just check back later.

Thanks David for all your work.

In my experience The RC's and betas are fine. The state is 'all the known bugs are fixed'. If there's no significant new features or huge issues driving a release, then yes, small bug fixes will just get collected here.

If there's a bug fix you need and it is available in the RC, please try it and see if it solves your problem - then comment either way so the developers can know. In the unlikely event you find a new problem, that would be nice to know too.

If you are relying on the developers to fix the bugs for you and the rest of the community to do the testing for you, then you will have to wait longer for any bug fixes to graduate to a stable release.

@Nuramori This addresses the layer starting point seam as you say, I am looking to randomize the the motor step pulses along the entire layer line.

As @nophead points out though, there is still a direct mapping between motor step and cartesian printer nozzle position when the pulse hits, which will be unaffected by speed or acceleration.

I'm thinking now about trying the M569 and M593 gcodes as @DocTrucker suggested originally (and M593 may be the key anyway for my i3 clone now that I have a corexy to compare to), or possibly adding subtle variations to the steps/mm settings as the filament is laid down -- but these ideas await me getting back to the project

Beyond the specific case of combating VFAs, it seems like this may be interesting for changing the texture/reflectivity of the part surface in general.

Would be especially nice if can link to current layer being printed.

Thanks for these ideas, they both seem to be more along the lines of tuning for specific hardware and situations. I know that that I can optimise or eliminate VFAs on any given object/speed combination. If I'm reading correctly, the (non)linearity settings would enable varying the per-step movement pattern directly, while M569 and M593 changes would approach this but the default settings are probably best left unchanged - and both of these would remain fixed throughout the print.

I'm 'wishing' (in the firmware wishlist forum category) for a setting on selected stepper motor axes to add [random within parameter 1-5%] variation to the speed specified in a stock g-code file for each print move.

The query about where and how to best do this in the firmware is more along developer lines (no pun intended :-)), as the variation needs to occur at least between layers without modifying the slicer code. As I noted, it needs a test tower to show that the idea works at all before going to this effort.

Definitely it just masks problems, but by varying the pattern layer-on-layer it at least doesn't emphasize them. I believe this is why my delta generates my best prints, because it is such a statistical improbability to be able to synchronize the mixed contribution of three axes through the delta kinematics from layer to layer.

For my i3, it was my first re-build - probably would have gone corexy if I had known about that design. The X and Y axes are 80x20 v-slot. Like some of the threads say, "VFAs are what you get to when you've fixed everything else." Shows up best on black PETG.

I look into most threads here that raise the raise the issue of 'vertical lines on my prints', and this post references this prusaprinters thread on fixing 'VFA's. The fundamental problem is ascribed to per-step movement issues in the stepper motors, synchronized over repeated layers. This makes a lot of sense to me, and matches my experience that it is unavoidable in my i3-design cartesian but nonexistent in my delta. The solution there and here is to switch to 0.9 steppers and 16 tooth pulleys (as I have done), but seems to me that this just makes the problem smaller (as I have seen) without eliminating it.

I think this could be addressed by adding small variations in speed, acceleration or possibly extruder temperature as the filament is laid down while printing. [Probably I'll have to hack up a g-code test tower to confirm this I think as I'm typing this...]. The point is to eliminate the layer-on-layer sychonization of the motor artifact rather than attempt to tune individual manufacturers motors.

Thoughts? Where might be the easiest place to introduce this in the firmware, and what should be the source of the variation?

@fairladyz said in Using rotary encoder for filament monitoring:

Has anyone tried using a rotary encoder for this? Any advice on how I could go about wiring and configuring a rotary encoder for filament monitoring?

99p filament monitor
99p filament monitor again

It's still in use on my cartesian (diy i3 clone) and working well, although I had to set the parameters looser than I expected due to the error that accumulates with retraction and not actually knowing which way the encoder is moving when a transition comes through. I think to make this work well one would need to develop a model of the encoder in the duet firmware and predict the transitions based on the instructed filament movement.

I think this is somehow a weakness of the cartesian / 'i3' design. I go back to fighting it now and then, but don't see it on my delta or the one print I've done on my new-to-me corexy.

Out of curiosity, what is your bed surface and height sensor type? I've also struggled with getting that heightmap as good on my delta as on cartesian.