A new trick with my CoreXYUV(AB)
-
Very nice!
Are you using the attached Raspberry Pi now? If you are, then you could implement your Python script as an interceptor.
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in A new trick with my CoreXYUV(AB):
Very nice!
Are you using the attache Raspberry Pi now? If you are, then you could implement your Python script as an interceptor.
No. I've been too busy with other stuff to get myself up to speed with the RPi. So it's still bolted to the machine but otherwise not connected.
That would certainly be a more elegant solution that post processing slicer generated gcodes, but that will have to wait until I get this 6 input hot end working properly.
-
@deckingman did you see my reply to your other thread? I tested (in the rather limited way I was able to) that you could use a Kinematic solution, where each gantry (ie CoreXY pair of axes) followed a virtual XY for position, but each was individually addressable too. This made all motor settings specific to each gantry, and only used X and Y for coordinated movement. Homing files would need to change a bit, but otherwise would have been much as before, just that you would know exactly the motor settings for each gantry.
If you want me to work out the kinematic command for you to try, let me know.
Ian
Cartesian bed-slinger with Duet 3 Mini 5+ WiFi and 1LC : RRP Fisher Delta v1 with Duet 2 Maestro : TronXY X5S with Duet 3 MB6HC and Roto toolboard
-
@dc42 BTW - I should say that it's thanks to your firmware which does all the heavy lifting, which made this easy.
All I have to do is supply absolute coordinates for each of the axes and the firmware takes care of all the calculations to translate those coordinates into relative moves. As well as the step pulse timings to keep all the moves (which may differ in length for each axis) in sync. The more I think about, the more impressive that seems. And I can simply tack any UVA or B parameters onto the end of an existing G1 Xnn Ynn Enn, command in any order. Neat!
-
@deckingman this is very cool to see in action! It would be awesome for the slicer developers to allow you to do this directly. For example specifying an allowed deviation between the XY and UV axis and then move the UV axis just enough to keep within the deviation. So for example, in a circle the UV axis would end up traversing a smaller arc inside the larger arc that the hotend traversed.
-
@droftarts I did see it but I got lost in your explanation somewhere along the way.
I think I'll stick with this solution though - I quite like having the extruder gantry tracking the hot end but with a degree of positional freedom. I'm hoping this will allow me to crank up the acceleration settings without shaking the extruder gantry to bits by not having it doing short zigzag moves. -
@T3P3Tony said in A new trick with my CoreXYUV(AB):
@deckingman this is very cool to see in action! It would be awesome for the slicer developers to allow you to do this directly. For example specifying an allowed deviation between the XY and UV axis and then move the UV axis just enough to keep within the deviation. So for example, in a circle the UV axis would end up traversing a smaller arc inside the larger arc that the hotend traversed.
@T3P3Tony Yes, that would be cool but I can't see it happening - there aren't many crazy old farts like me around that would use it.
My "rules" make a very crude motion planning algorithm. The circular part in that video (and any smaller arcs or circles) could have been done by "parking" the extruder gantry in the centre of that circle, where it could have remained static while the hot end described the circular print paths. But I'm not clever enough to write a script which could interpret a gcode file and work out what is an arc and where it's origin is.
I'd say the ultimate solution would be some sort of look ahead program running on the SBC which could do all that clever stuff and generate the UVAB moves as a parallel stream. But that's way beyond anything I could do.
-
Ian, You and that printer continue to amaze me! Great work!!
-
@deckingman I think the information required to generalise this is easiest gathered by the slicer. You are right that it's a very specific usecase though! Probably a plugin for cura or prusaslicer might be possible but I have not worked with either of those plugin architectures.
-
Very cool!
I'd just stick your post processor into Prusa Slicer's list and you're done.
It's a bit more work in Cura, but on the upside, you could have configurable settings for your "rules" in the GUI.
Of course the hours you spend on that could also be spent adding more....
Don't know what, just more!
