Dual X carriage details

[Kulitorum]

I am running Repetier development branch on a new dual-x-carriage printer.

Mostly it works perfectly, but there's a few details that I have noticed after only 2-3 prints:

If I cancel the print while extruder 2 is printing, then Extruder 2 will home to Min-x position instead of max-x position, as would be that extruders proper homeing position.

Another problem: If I reboot and adjust Configuration/Extruder/X-offset then I can adjust the values and the heads won't move. But if I cancel a print and then adjust Configuration/Extruder/X-offset then the carriage will occilate between endstop and X-offset for each small adjustment, making it very slow to change anything.

Just thought you might want to know before release.

Thanks for all the great work.

[Kulitorum]

Another detail, when the machine is heating up, it will:

1) Heat bed 1) Home (Carriage 1 goes to xpos 0 (X-offset is -2666) 2) wait for extruders to heat up.

But Carriage 1 should wait at min-endstop, so the nozzle is blocked by the anti-ooze-clip, rather then wait at xpos 1 while heating.

Donated anther Euro 10 yesterday, keep up the good work.

[Kulitorum]

Another small subtlety is that on toolchange, say we are using head 0, changing to head 1, then this happens:

Tool 0 is at some coordinate, say 100,100 Tool 0 moves away, to its park position. Tool 1 then moves to position 100,100 (and it should not) Tool 1 moves to where it needs to be.

So on tool changes, the new tool moves first to where the "old" tool was. This bug is the main cause for unwanted color impurities in my prints.

[repetier]

That behaviour was intended. If you have a normal 2 color printer the second extruder also goes to the position of the old one. Why should that be unwanted and where else should it go?

The demo printer I had for developing prepares continuation in park position (priming, retracting and wiping at a barrier). So there are no drops visible. Isn't it the aim of dual extruder to be able to prepare in park position so you need to extra tower and wall for dual print. You have a select/deselect script that can contain your preparing code.

[Kulitorum]

When you change a new tool, it should go to where that tool needs to print, rather then where the old tool needed to print. At least for a dual-carriage configuration, but probably also for a "normal" dual hotend setup. Its rare to want to keep printing at the same position as where the other hotend left off, if ever?

[repetier]

If you send a pure T1 where do you want to start printing? You do not know and so does the printer? Later code will tell but at the switching moment we do now know so I can not go to a different position. And I can not stay where I am as the activation code is bound to T1.

[Kulitorum]

Maybe a T1 command should

Always: Register that the next command is for head 1 - nothing more

And for a dual carriage: Move head T0 to its park position

Why would a T1 command move the head? - Move commands are G1 or G0 etc.

[Kulitorum]

Oh wait.... I guess if the first command after a T command has Extrusion, then it should go to where the previous head was.... Otherwise it should not.... I see the problem, but would that not be a solution?

[repetier]

Not really. Firmware has no look ahead so you do not know what will come, even if it was already send. But currently we even have no multiple buffers so we even can not know next move. So we need to do what always works and makes most sense.

Have you tried retracting at extruder selection? At least with slic3r extruder switch code you can undo this so it is like any other position switch with retraction.

[repetier]

I'm just trying to follow your error descriptions. It's a bit hard as I do not have the dual axis printer any more. So maybe you can clarify a few things:

If I cancel the print while extruder 2 is printing, then Extruder 2 will home to Min-x position instead of max-x position, as would be that extruders proper homeing position. Essentially you mean T0 G28 X0 T1 G28 X0 ; This will move right carriage directly to left side before the left carriage does this?

I can not see that in the homing code. But maybe your description is just not exact enough for me to find what you mean. Since I can not test myself I need a detailed description to know when and where the error happens.

If I reboot and adjust Configuration/Extruder/X-offset then I can adjust the values and the heads won't move. But if I cancel a print and then adjust Configuration/Extruder/X-offset then the carriage will occilate between endstop and X-offset for each small adjustment, making it very slow to change anything.

Yes that is correct in the fact that changing values selects the current extruder when homing ha sbeen done. In my current code the moves are prevented if the same extruder is selected, which should solve the problem. Development version should do this correctly. At the beginning it was not implemented that way, so I hope you are just using a older version. As a Test T0 T1 T1 should select and move extruder 1 only once.

1) Heat bed 2) Home (Carriage 1 goes to xpos 0 (X-offset is -2666) 3) wait for extruders to heat up.

But Carriage 1 should wait at min-endstop, so the nozzle is blocked by the anti-ooze-clip, rather then wait at xpos 1 while heating.

This is intended behavior. Positions in parking position are not reachable for both extruders, so under normal conditions the active extruder should always be where it a normal extruder would be after homing. In that case x=0. Solution is easy with right slicer script T0 G28 G1 X-40 F6000 M109 T0 S200 M109 T1 S200

Now both will heat up in park position because you decided you want it.

[pbrgle1]

Hi. I would like to get involved in improving the dual x carriage feature.

So far i have the following issues with it compared to marlin version:

• When tool switching, the next tool always goes to the last position of the previous tool. This can be a problem when printing multi material (eg. flex & ABS) and also in normal multi color printing because of the unnecessary extra travel distance. This will cause extra leaking especially when printing something like ninjaflex, and color mixing by draging the second extruder on the previous part. Video
• There should be something like max travel distance for both extruders. For example, the max distance the 2nd carriage should be allowed to travell not to hit the 1st carriage and vice versa. Video
• Like Kulitorum said before. Homing the X axis should not make the active tool go to zero. If the 2nd tool is active it will travel all the way from eg. 257 to 0, only to be later sent back to 257. The solution should be more elegant than having to write extra start gcode script.
• Ditto printing with X offset. Option to set the desired X offset for ditto printing(eg. 100 if total bed width is 200). Marlin does this with M605 S2 X???.

--// From Marlin configuration_adv.h //---

// There are a few selectable movement modes for dual x-carriages using M605 S // Mode 0: Full control. The slicer has full control over both x-carriages and can achieve optimal travel results // as long as it supports dual x-carriages. (M605 S0) // Mode 1: Auto-park mode. The firmware will automatically park and unpark the x-carriages on tool changes so // that additional slicer support is not required. (M605 S1) // Mode 2: Duplication mode. The firmware will transparently make the second x-carriage and extruder copy all // actions of the first x-carriage. This allows the printer to print 2 arbitrary items at // once. (2nd extruder x offset and temp offset are set using: M605 S2 [Xnnn] [Rmmm])

---

I can test things and upload more videos if you want.

[repetier]

Ok, I have modified the code a bit for better dual x axis handling. Would be great if you could check it as I have no dual printer.

Add

define LAZY_DUAL_X_AXIS 1

to leave extruder at park position until next move command. Homing should also let them stay in park position with that setting.

Moving into opposite parking box should now not work any more.

Ditto printing is already implemented. Space is always 50% of width so you get optimal size for ditto printing. Other distances have no benefit as they only reduce allowable width of print.

[pbrgle1]

i get the following error with dual x enabled now...

Arduino: 1.6.5 (Windows 8.1), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"

In file included from Repetier.h:896:0, from Commands.cpp:22: Printer.h: In static member function 'static void Commands::processMCode(GCode*)': Printer.h:1202: error: 'static void Printer::homeXAxis()' is private static void homeXAxis(); ^ Commands.cpp:2010: error: within this context Printer::homeXAxis(); ^ 'static void Printer::homeXAxis()' is private

[repetier]

Ok, should not have made them private:-) Should now work.

[Kulitorum]

This is in the development branch?

[repetier]

Yes, only development for now.

[pbrgle1]

OK the carriages home normally now and stay at their home position but a number of other problems appeared now. When i change extruders (T0 or T1) they move in the wrong direction and slam into the endstops. When i change from T1 to T0 i think it wants to go back to -53.5 and when i change from T0 to T0 it wants to go to 257.4 which is my T1 X offset.

Also the left carriage (T0) doesn't move more than the max X value i have set (i think it's because the home position on the endstop is set at X0 and not -53.5 that i have set for T1 X offset). The right carriage on the other hand doesn't want to move at all.

my configuration.h file link

[pbrgle1]

I made a video showing a difference between marlin and the current dev version of repetier.

The first video is marlin. There you can also see how the next tool doen't just go to the last position of the previous one but just continues where it's supposed to start printing (except for the 1st tool change... don't know why that is). Ignore the 1st layer (skirt and brim)

I ran the gcode without extrusion but it's basically just two towers. Left one for T0 and right one for T1.

VIDEO: Marlin VIDEO: Repetier

[repetier]

Ok, made a new update.

I found that homing has set homing position wrong, so next moves go not where supposed to. Also in extruder switch I think was a little mistake I've changed. Hope it works now. If not please make a report like this

Starting with T0 G28 ok T1 xxx happened

It is much easier to identify a bug if you get the commands and what happens as a sequential timeline since I can not test and have to replay everything in my head to find the code creating the error.

[Kulitorum]

Here's the start of some gcode that I try to print with dual X carriage.

90 M83 M106 S0 M140 S60 M104 S220 T0 M104 S220 T1 G28 G1 E-8.0000 F1200 G1 Z0.950 F1200 ; layer 1, Z = 0.45 T0 ; tool H0.500 W0.960 ; skirt G1 X129.156 Y135.665 F4200 G1 Z0.450 F1200 G1 E8.0000 F360

But when I run it, Tool 0 moves to X128(ish) and then moves further 128mm on the X axis, leaving it at around X256

Like so: https://www.youtube.com/watch?v=_mzCedGOfuY

Nowhere in the gcode is it asked to goto X128 Y0

If I change the line "T0" to "T1" I get a different result:

90 M83 M106 S0 M140 S60 M104 S220 T0 M104 S220 T1 G28 G1 E-8.0000 F1200 G1 Z0.950 F1200 ; layer 1, Z = 0.45 T1 ; tool H0.500 W0.960 ; skirt G1 X129.156 Y135.665 F4200 G1 Z0.450 F1200

G1 E8.0000 F360

Video: https://www.youtube.com/watch?v=5FpfwrWv5aw

Kulitorum

PS: Sorry, I don't know why some of this is in large font...

[repetier]

@Kulitorum I see the problem also I can not follow why that happens at the moment.

1. I guess I look from behind in the videos since the right extruder moves first.
2. What version did you use? The last version which I reported 3 days ago?
3. Your homing x seems not to park extruder. Now I'm not sure if this comes from homing all directions or if you have not #define LAZY_DUAL_X_AXIS 1 compiled in. What did you compile with and what does a pure G28 X0? Does it leave the motor in the side?

[Kulitorum]

1) Extruder 0 is on the right. This is a front view 2) Repetier-Firmware-2016-05-24 3) I do not have #define LAZY_DUAL_X_AXIS 1 G28 X0 homes left extruder, then right extruder, then left extruder moves to X0 (-4580 steps, Ext0_Offset_x)

Eeprom data attached.

EEprom 2016-05-25.zip

[Kulitorum]

BTW, what determines the speed at witch a tool is moved away and back on tool change?

If T0 is active and T1 becomes active, how fast does T0 move back to its park position?

[Kulitorum]

Hmm, just realized my x-min-pos in firmware was set to 100, maybe thats the problem?

[repetier]

Here some math and data for analysis, mainly for me E0 x offset = -4580 steps /80 = -57,25mm E1 x Offset = 23600 steps / 80 = 295mm

From these data E0 is the left one while you said E0 is the right one. In the video the right one moved always first so that seems correct, but then you have rotated your xy system 180° to typical printer orientation if that is the front view. So the right deepest edge is your origin.

xmin = 100 should not be a real problem except that your bed then goes from 100-300 and not 0-200. Except if compiler did not see LAZY_DUAL_X_AXIS = 1 (see below), then it would take your left edge as 0 which could be the problem.

What you did not answer is if pure G28 X0 leaves the extruder in park position. Current algorithm is as follows for homing x:

1. Park E0 and E1. That part works fine in your video.
2. If LAZY_DUAL_X_AXIS = 0 => go to x min (which is what I see in your video) if LAZY_DUAL_X_AXIS = 1 => store position as currentPositionSteps[X_AXIS] = xMinSteps + Extruder::current->xOffset and do no move;

This is Printer.cpp line 1540

if LAZY_DUAL_X_AXIS

currentPositionSteps[X_AXIS] = xMinSteps + Extruder::current->xOffset;
updateCurrentPosition(false);

else

// Now position current extrude on x = 0
PrintLine::moveRelativeDistanceInSteps(-Extruder::current->xOffset, 0, 0, 0, homingFeedrate[X_AXIS], true, true);
currentPositionSteps[X_AXIS] = xMinSteps;

endif

Could you add

error wrong case

directly after the #else line and compile. It should NOT show the error. That way we see it took not what we see but what it should and I know I have to search later also I do not see a x move in y homing.

Position changes are done at EXTRUDER_SWITCH_XY_SPEED speed when switching extruders.

I have updated firmware as I found a problem in end of homing, where it might try to move x at the end. Now dual axis is a special case. Hope it now works better and with xmin = 0 it might even look better.

[Kulitorum]

Trying new version now. Looks good so far. Lazyness works perfectly (I think, from the few experiments I have done so far)

I increased EXTRUDER_SWITCH_XY_SPEED to 500, but it's only used when a head moves away, not when the "new" head moves in.

Thanks for the great work. I have been using Repetier firmware and host for years on all my printers, and it never failed me.

Kulitorum

[kyrreaa]

Hey, how about save and restore position gcode? Allows the pre/post and switch extruder code to decide how to handle the motion. For returning to last pos: save pos, park head, switch to new head (which updates the coords of current head), restore pos (which moves head to old location. For lazy: Just don’t restore pos, or even skip saving it.

The pause function has some restore position stuff already does it not?

It doesn’t look like the code I generate from Slic3r does any extrusion after switching head without motion first btw. Motion seems to position the head at new pos, then feed forward and pressure advance and finally extrusion.

Kyrre

From: Kulitorum Sent: Thursday, May 26, 2016 10:46 PM To: repetier/Repetier-Firmware Subject: Re: [repetier/Repetier-Firmware] Dual X carriage details (#526)

Trying new version now. Looks good so far. Lazyness works perfectly (I think, from the few experiments I have done so far)

I increased EXTRUDER_SWITCH_XY_SPEED to 500, but it's only used when a head moves away, not when the "new" head moves in.

Thanks for the great work. I have been using Repetier firmware and host for years on all my printers, and it never failed me.

Kulitorum

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

[Kulitorum]

Oh, BTW, can we add z-lift on tool change?

[pbrgle1]

I believe you can manually add z-lift by writing a short script for Select and Deselect tool (also in the configurator) but i have yet to test that.

[repetier]

@Kulitorum You are right that the move after parking is done in normal speed. This move is technically spoken the next G1 move just with a different x starting point in contrast to non lazy switch, so it is executed with the move speed of that move.

z-lift in select/deselect is not what you need I think. I guess you mean for unparking to go up -> position -> down. But that is not possible to do using the technique we use.

@kyrreaa Storing position is not the solution. That would require extra commands from slicer and makes everything complicated. Also we do not want to go to that position. What we do is similar. There is a last commanded position which we do not change when changing tool. So old position is still stored in lastCmdPos. Next G move will then override with new coordinates and use old stored x pos (if pure y move) or use new x position which then makes sense with lazyness. So only move we omit is the move to old x on extruder switch. In this context I can not accept that you say first move does first move and THEN extrude. If you have ; coming from T0 T1 G1 X200 E8 it would move to x200 AND extruder. That is the big problem with lazyness as it has a new starting position in contrast to what slicer thinks. On the other side normally you have a non extrusion move after extruder switch or a undo retraction.