Moving extruders to mirror XY movements for diamond hotend
-
@Frederic. Here is a little tip if you want to try that method. For the counter weight, I printed a container then added lead shot which I bought from a place that sells Scuba diving gear. They sell it loose by the Kg and it was the cheapest source I could find. It's an easy way to get exactly the weight that you need for a counter balance. HTH
-
What if the extruders where resting on the main carriage, with a system allowing lateral (small) moves? I'm thinking of a flexible part, like a glass fiber rod, anchored on both side. This way, when the carriage moves, it pulls the extruders, but all fast accelerations are absorbed by the glass fiber rod.
This would also require some damping system, to avoid oscillation (which can mess up if in resonance); 3 chock absorbers (without the springs) from RC car models, mounted like a inverted pyramid, may do the work.
-
@fma:
What if the extruders where resting on the main carriage, with a system allowing lateral (small) moves? I'm thinking of a flexible part, like a glass fiber rod, anchored on both side. This way, when the carriage moves, it pulls the extruders, but all fast accelerations are absorbed by the glass fiber rod.
This would also require some damping system, to avoid oscillation (which can mess up if in resonance); 3 chock absorbers (without the springs) from RC car models, mounted like a inverted pyramid, may do the work.
That's exactly the lines I've been think on regarding the driven system that I have now. It works well enough but I now have in the order of 4 kg of moving mass which is all about a metre above the floor. So unless the printer feet are perfectly levelled and the floor is very rigid, the printer tends to rock when doing small zigzag moves. I was thinking along the lines of connecting the belts to the extruder carriage via springs or some such. The thought being that it would give some degree of decoupling such that the extruder carriage didn't have to exactly mimic every tiny movement of the hot end. Short zigzag moves would be absorbed by the springs and flex in the Bowden tubes. I do wonder how the system would then react to large fast non-print moves though. I can see belts coming off pulleys if the spring tension isn't sufficient and all sort of potential inertia related effects. It won't be difficult to lash up something to test the theory though. It's my list of things to try next - a list which is getting very long indeed.
-
4kg! I guess it is for the Diamond full colors… Well, it can't be handled by the main carriage as I was suggesting.
-
As you have a second XY carriage for the extruders, I'm wondering if a software approach couldn't be use…
For example, it could detect zizag moves, and decide not to move at all, as the PTFE tubes can handle the difference. In fact, moves should only start when the difference between hotend carriage and extruders carriage becomes too high for the PTFE tubing. This way, low accelerations could be used, to avoid shaking the machine. And smaller motors could be used.
Maybe a second path planner, based on the first one, but doing some average?
-
Mmm, this could even be done at the G-Code level, by parsing the G-Code file, doing the average of XY moves, computing UV moves, and inserting needed new G-Codes. Nice work for a Python script
-
Frederic,
The calcs go something like this for my machine which uses twin 2020 open build V slot rails for the moving X carraiage(s).
Diamond 5 colour assembly on mount 600 gms (X)
Y carriages and X rails 848 gms (Y)So for the hot end only its about 600gms in X and 1448gms in Y that has to be moved.
For the extruder carriage (5 off titans plus motors plus mounts and vslot wheels etc) it's an additional 1540 gms in X
Plus the rails and carriages at around 1,000 gms makes Y 2540.Hence a total mass in Y of just over 4,000 gms (in X it's only 1,600).
As for your idea - you'd have to separate the two gantries and control each one individually in both X and Y. Currently I just map the drives so that the duet considers the whole thing to be a single XY gantry. I know the Duet can have extra X axes, but I don't believe it can have extra Y axes. Not sure on that. In any case, the firmware would have to essentially be able to run 2 gcode files concurrently - one for each gantry. I doubt very much if David is likely to want to spend time developing that, given that it's a pretty crazy idea that might not work
-
Yeah, I can understand it would be a lot of work to do this in the firmware to implement another path planner…
But working on the G-Code file is totally transparent for the Duet. Here is how I see things; tell me if I miss something important:
1. define 2 more axes, U and V, with their own settings (accell, speed, jerk...);
2. parse the G-Code file and build a smooth trajectory for UV axes;
3. insert UV drive G-Codes in original G-Code file.Point 2 requires some maths: the smooth trajectory may be build using minimum square root from, say, the next 10 XY moves, taking into account the relative positions allowed by PTFE.
For point 3, I think there are different cases: for short zizags in the same zone, UV moves can be inserted between XY moves. But for long moves, it may require to split XY moves in several shorters moves to include the UV moves. Don't know if this can lead to troubles for the path planner...
This may be a little tricky, but interesting! And valuable if it works.
-
Mmm, I think I missed an important thing: it is not possible to do G1 Uxxx Vxxx!!! Only XYZE is allowed…
-
Yes. Actually I think we'd need G1 Xnnn Ynnn Unnn Vnnn Ennn which could be a bit tricky
-
I agree. But if the script splits the XY moves, it could be possible to alternate G1 Xnnn Ynnn Ennn and G1 Unnn Vnnn…
David, would it be very complicated to implement G0/1 UVABC? A basic implementation, without look ahead, just with inter-axes synchronisation, totally disconnected from XYZE path planner?
-
@fma:
Mmm, I think I missed an important thing: it is not possible to do G1 Uxxx Vxxx!!! Only XYZE is allowed…
You should already be able to do G1 Uxxx Vxxx moved if you have created U and V axes and have not hidden them. IDEX printers use G1 Uxxx moves in the tool change and homing files.
-
But are the UV axes linked as XYZ are, to move in straight line? How are G1 UV commands queued, and when are they executed, regarding the XYZ path planner? If we add G1 UV commands between hotend moves, are they going to mess up the print?
-
fma, what not put them all in the same line:
G1 Xxxx Yxxx Zxxx Uxxx Vxxx Fxxxx
-
G1 UV moves are queued just like any other G1 moves. In most respects, the motion control system does not differentiate between axes. There are just a few places in which X and Y are treated specially.
-
TBH though guys, it isn't really a problem just driving the extruder carriage the way I do. i.e map the drives so that the Duet treats both gantries as one. Like I said, I have around 4kg moving in Y at 1,000 mm above the floor, so a very high centre of gravity and it really isn't an issue, even the short zigzag moves. Just a very slight rock if the feet aren't levelled and there is some "give" in floor. Even then, the entire printer, including the bed moves as one so I haven't noticed any artefacts with the prints. I guess it might be an issue if the frame wasn't rigid but it all seems like a lot of complication to get around a problem that doesn't really exist IMO.
Edit. Another approach might be to use flexible drives like the nimble for example, and stick with a single gantry. My pockets aren't deep enough for me to now abandon my 5 E3D Titans and replace them with 5 off Nimble flexi drives. Actually, I did briefly look into it but getting them to fit a diamond hot end was just going to take up too much X and Y travel for my liking.
