docs: dual_carriage #4508

charlespick · 2021-07-21T21:21:28Z

Added an STL for calibration, some gcode macros to the sample idex config, and an entire document on configuring an idex printer.

Signed-off-by: Charles Pickering charles.pickering@live.com

charlespick · 2021-07-22T08:25:52Z

If anyone knows how dual carriage works with bed level, please let me know. That's the other big question I wanted to answer but couldn't because I don't have one on my idex printer.

KevinOConnor · 2021-07-26T00:40:15Z

Thanks. As high-level feedback, it looks good to me. I think this change should wait until after #4512 though. As for idex work, I don't have that hardware, but @Tircown has done a lot of work in that area recently.

-Kevin

Tircown · 2021-07-26T20:30:51Z

I didn't test a bed_mesh or z_tilt myself on a IDEX but for what I know it works. Ankurv, tester of hybrid-corexz, uses the bed_mesh.

I am a little embarrassed because #4464 will overwrite the M106 macro totally. In addition I don't agree on some points:

if P param is not set, the fan speed should be applied to both fans especially if there is no switching for active fan in T0/T1 macros.
if S is not defined the current macro will raise an error. Despite the G-Codes.md doc the S parameter is optionnal. M106 is equivalent to M106 S255. Klipper's base M106 allows it (in terms of code).
M107 overide is needed too.

Concerning the documentation I have a few comments too:

Dual_carriage on Y-Axis is only available for cartesian printers.
I would use the command SET_GCODE_OFFSET X= Y= Z= instead of dealing with the position_endstop of the dual_carriage section to adjust the position. But it's just a personnal preference since offsets are still needed for Y and Z. Also it can be adjusted and tested without restarting the firmware. So it's easier to perform an adjustement < 1mm as early as the step1.
step1: After making a few movements to overlay the real position of the second nozzle on the first, M114 is helpful to get the firmware position and calculate the offsets. It would be nice to mention it.
Most calipers have an accuracy of 0.1 mm. This is not enough for fine adjustement. I use ad-hoc stl files to calibrate the offsets i.e. https://www.thingiverse.com/thing:3873434. This perform the step2 and step3 of the guide in more or less 1 print and is pretty accurate. Few tests prints are still needed after to confirm.

charlespick · 2021-07-26T23:24:25Z

Can you tell me more about how #4464 will overwrite the M106 macro? I just took a look at it and I can see this comment mentions the fan things but I didn't see anything about where or how to configure multiple part cooling fans so each extruder can have it's own fan speed.
Otherwise I agree that my macro is a little stupid. I wrote it in a rush about 3 weeks ago for my own printer and didn't really test all the possible execution flows. I'll fix that and add an M107 if it's still needed after #4464.

At this time, [dual_carriage] only supports cartesians period according to config_referance.md. If #4464 merges first we'll update this branch to reflect that, if this merges first then #4464 will need to update this file.

Using g-code offsets to calibrate an IDEX printer seems like the wrong tool for the job and is a bad idea in my mind for a couple of reasons.

I am not sure if Klipper would properly prevent the carriages from running into each other
If you use g-code offsets for any other reason then you'd have problems.
I don't believe this persists across restarts of the firmware.

I believe all 3d-printer owners should have calipers that go down to .01mm anyway for calculating flow. But even if you didn't already have them, I don't think the solution is a printable vernier. First of all, I'm not sure how the part you linked would achieve any accuracy beyond .1mm so step 2 could accomplish that without any need to slice and with much less filament. Without a .1mm nozzle or some really fine slicer tuning, or a lot of filament and a big bed, I'm not sure a .01mm printed vernier could achieve the accuracy of a calipers either. No matter whether you're going for multiple colors in a model, or soluble supports in a functional part, you're gonna need the precision that you can only get with a dedicated measuring tool. And tbh if you have a printer with dual extruders, I think you can afford a .01mm calipers.

Tircown · 2021-07-27T11:26:29Z

Can you tell me more about how #4464 will overwrite the M106 macro? I just took a look at it and I can see this comment mentions the fan things but I didn't see anything about where or how to configure multiple part cooling fans so each extruder can have it's own fan speed.

4464 is still a work in progress concerning the macros and documentation. You can have a preview of the macros in DrumClock's comment. We are currently testing and improving the macros in order to use all idex modes.

At this time, [dual_carriage] only supports cartesians period according to config_referance.md.

That's a forget, thank you to pointed out. Since #4296 is merged, hybrid-corexy and hybrid-corexz have a dual_carriage ability too.

g-code offsets to calibrate an IDEX printer seems like the wrong tool [...]

This is however the typical use of SET_GCODE_OFFSET according to the documentation G-Codes.md. G-Code offsets are still needed for Y and probably Z, so why not X too?

I am not sure if Klipper would properly prevent the carriages from running into each other

True. In your documentation you advise the user to modify the limits after doing the adjustments. This last step should avoid collision.

If you use g-code offsets for any other reason then you'd have problems.

One can use the X_ADJUST, Y_ADJUST, Z_ADJUST parameters for that purpose.

I don't believe this persists across restarts of the firmware.

No need, it is typicaly set in the T1 macro. You will find this command in the current sample-idex.cfg.

To be clear, I don't advise to set all the X adjustement in offset. IMHO the endstop_position adjustment should be the tool for the precision range of the tape measure (>2mm), then use the G-code offset for fine tuning.

charlespick · 2021-07-27T17:54:28Z

I haven't tested these new macros yet, don't merge

charlespick · 2021-07-27T18:13:27Z

Using the adjust commands for g-code offsets might be a bit easier if you were expecting to make multiple adjustments in a row but you shouldn't need to. You should start with an idea of how big your printer is I think, after the first test you'll likely need to configure the macro for step 2, which will require a restart, and if you were to put your tuning into gcode offsets in t0 and t1 macros, you'd still need to restart again to get your new macros to take effect before running step 3 anyway.

Where it says gcode offsets are useful in tool change macros is referencing when you have 2 extruders fixed relative to each other, not an idex.

I think you should use the config options for what they're meant to do. Position_endstop exists so Klipper knows where the endstop is and can accurately place the limits that protect the printer from itself and yourself, and who knows what else will be dependent on the position_endstop value down the line. You wouldn't write a macro to replace M104 or M140 to compensate for a weird thermistor, you would define a new thermistor.

I've fixed the fan macros I think, will test them in about an hour when my FlashForge is done printing something.

charlespick · 2021-07-27T18:22:53Z

they work

Frix-x · 2021-07-27T19:01:22Z

Hi, just read this issue as I'm myself interested into IDEX machines.

Coming from the professional CNC industry world, I can only second that using SET_GCODE_OFFSET in tool change macros (like T0, T1, Tx) is THE WAY to do it properly if you want to follow industrial standards from for example Fanuc or Siemens.
Machines limits are the physical one that your cariage should not go over. Offsets are the one you use to set up and calibrate and fine tune the machine. If you change the tool (spindle or hotend here) or just dismount/remount it, you need to be able to calibrate it again easily without having to change the axis limits -> in klipper, I think modifying the tool change "T0" or "T1" macro is good enough as there is not proper "tool HMI".

And I also second that using a calibration part is easier if you don't have the proper precise caliper tool. Everybody is able to print a part but not everyone have the proper caliper.
It would follow the same logic than calibrating pressure advance or flow for example.

charlespick · 2021-07-27T20:27:58Z

And I also second that using a calibration part is easier if you don't have the proper precise caliper tool.

I never said that was a bad idea. In fact that is what step 2 is. What I said is to achieve the precision necessary to make an IDEX actually make sense, you need to calibrate the machine down to tolerances that you cannot see with the naked eye and would require too large a build area for something like a printed vernier in some cases. You have to remember that typically on an idex, both extruders cannot reach the entire build area which shrinks your available build area.

Just like how Marlin and Klipper have different suggested ways of tuning linear/pressure advance, I'm sure someone else is going to come up with another way to do this. Maybe you print a vernier that isn't all in one line. Maybe you print a vernier that goes up the Z axis and uses Klipper's tuning tower command. Maybe you use sensorless homing to home the right one into the left one. There are other docs here that recommend using a calipers for various things and I still stand behind that if you have money for an IDEX printer you should have a calipers anyway.

Machines limits are the physical one that your cariage should not go over

This is literally the reason I recommend using the position_endstop config setting and not gcode offsets. At the end of the day here, we're using the printheads to print objects that allow us to calibrate said limits and I think we need to stop thinking about tool changes entirely. Imagine if you had 4 extruders, 2 on each carriage. That's potentially 4 gcode macros you'd have to update and play around with as belts tighten and your printer does other weird things.

If we wanted to truly match the best practices of the CNC world then we should have something like another configuration option for dual_carriage just for this that is tuned like a probe offset. This would be managed by Klipper with the SET_DUAL_CARRIAGE command leaving no way for the printer to enter an invalid state. But this is not a code pr, nor are cnc machines with multiple toolheads actually that common to my knowledge - they just eject one tool and mount a new one.

charlespick · 2021-08-03T06:37:29Z

Alright, I have an idea that might make people happy but it's gonna take a while to test so I'm converting to draft for now

eddietheengineer · 2021-08-10T00:17:00Z

I can provide a little feedback! I just went through setting up a hybridcorexy IDEX printer in the last few days and love that this functionality is being improved in Klipper.

I did initially use the X_max endstop position as a way to get the toolheads relatively close to aligned (within 0.5mm or so), but after that I used the vernier test print to get X and Y offsets. I wasn't expecting to need a Y offset but I ended up needing one--likely just tolerance stickup and assembly of both my toolheads. It took me a try or two to figure out the test print but it was super easy to read and visually see what offsets I needed. I wouldn't have wanted to try to measure with a caliper, once you're in the fractions of a mm range it's hard to be very precise.

The results are pretty good I think--I probably could adjust alignment a little bit (I was streaming on YouTube and just wanted to get to a test print) but it's functional.

charlespick · 2021-08-12T01:10:34Z

Same, I am realizing that a Y offset is also necessary. So I am working on a system that uses [save_variables] to define the offsets and apply them as necessary.

KevinOConnor · 2021-08-31T22:04:30Z

What's the status of this PR?

-Kevin

grigi · 2021-09-08T10:50:37Z

I just had to go through figuring out the fan situation for fans on an IDEX, and right now the best solution is to have a sacrificial [fan] section so that all the "normal" fan feedback works as expected.
This isn't ideal as we are now PWM-ing to a pin that isn't connected.

# Sacrificial "main" fan
[fan]
pin: rpi:gpio20

[fan_generic fan_extruder]
pin: PC6

[fan_generic fan_extruder1]
pin: yz:PC6

[gcode_macro _SET_TOOL_FAN]
variable_speed: 0
gcode:
    SET_FAN_SPEED FAN=fan_{printer.toolhead.extruder} SPEED={params.SPEED}
    # Store the fan speed so that we can carry it over during toolchanges.
    SET_GCODE_VARIABLE MACRO=_SET_TOOL_FAN VARIABLE=speed VALUE={params.SPEED}

[gcode_macro M106]
rename_existing: M106.1
gcode:
    {% set s = params.S|default(255)|int %}
    _SET_TOOL_FAN SPEED={s / 255}
    # Set the original fan speed pin, else Klipper itself thinks the fan isn't on.
    M106.1 S{s}

[gcode_macro M107]
rename_existing: M107.1
gcode:
    M106 S0

I did not yet use #4464, but once that lands these macro's will have to be updated to sync the fans when in duplicate/mirrored mode.

charlespick · 2021-09-10T20:16:32Z

@KevinOConnor -
I am working on macros to set the gcode offsets of the dual_carriage and set them as needed using save_variables. I'm almost done

regarding fans, I've been printing with double fan_generic sections and custom m106 and m107 macros and it's worked great for me. @grigi did you have an issue with this implementation that forced you to go about it the way you did?

grigi · 2021-09-10T21:32:19Z

regarding fans, I've been printing with double fan_generic sections and custom m106 and m107 macros and it's worked great for me. @grigi did you have an issue with this implementation that forced you to go about it the way you did?

The issue for me is that without having a sacrificial/dummy [fan] that I drive, feedback in the Klipper display interface and in Mainsail isn't working properly.

For example, mainsail only shows the separate fan controls, but not a combo one, and in the display the fan speed is always reported as 0% (and the menu options to change fan speed is missing). Thus just restoring the functionality that is there standard for single-tool printers.

Ideally I would like to completely virtualise it, instead of having to have a real pin. Hence me using a pin on the RPi host, as I don't have those connected.

Another thing is I wanted my default fan to automatically apply to the active toolhead only, for when printing gcode that has no knowledge of multiple toolheads. (e.g. not using P) This may be a bad assumption on my part, or not.

Now that I think of it, I should:

Clean up my macros (can simplify/clean them some more)
Provide a sample of how fan interaction works with the existing sample T0/T1 commands. (right now I swap the fan speed on tool swap)
Extend the M106/M107 to support all the cases of:
- Specifying P
- Not specifying P and in SET_DUAL_CARRIAGE_MODE MODE=FULL_CONTROL (default) mode (swop fan between toolheads)
- Not specifying P and in SET_DUAL_CARRIAGE_MODE MODE=DUPLICATION|MIRRORED modes (update all fans like yours) (This would depend on kinematics: add duplication/mirror modes to idex_mode #4464 so I'll comment this block out)
- M107 should stop everything for all above cases (so, basically calling M106 S0 for P= and each P to always cover all cases)

I will have a go at this, this weekend.

Disclaimer: Note this is my first IDEX (and its built from spare parts), and I don't have much experience on how best an IDEX should be used yet. If you believe that I'm missing a point here, please tell me.

grigi · 2021-09-10T21:38:57Z

Minor update to a misunderstanding: According to spec here: https://www.reprap.org/wiki/G-code#M107:_Fan_Off M107 should just be an alias to M106 S0, but that it needs to disable all fans if P is not specified.

grigi · 2021-09-15T08:13:01Z

Hi, Apologies for not getting back when I said I would. I have been reworking my config a lot to try and keep the macros I propose as simple as possible.

For getting a polished IDEX experience there is docs that wasn't clear re:

Getting the display to show dual extruder data (it still doesn't show which tools are "active", and could be neater, etc...)
The sample T0/T1 macros will destroy print state, causing out or movement range errors (Still need to fix that)
Probing where one of the tools have the probe would fail disastrously if the wrong toolhead was active (fixed this already)

I feel the IDEX docs should make these gotchas clearer.

Another thing, having "perfect" docs is not a requirement, this PR significantly improves the situation already.
So I'd vote for getting this "good enough" and in so we can have other PR's that address the other shortcomings (like Menu/Probing) and improve things a little.

charlespick · 2021-09-15T21:23:45Z

@grigi

For example, mainsail only shows the separate fan controls, but not a combo one, and in the display the fan speed is always reported as 0% (and the menu options to change fan speed is missing). Thus just restoring the functionality that is there standard for single-tool printers.

When I started working on this, rename_existing: wasn't an option for gcode_macros. Now that it is, I will look into ways to make this look more elegant. I also know that #4464 introduces something about syncing extruders together. I am not sure how or if that touches fans, but since I said today that I think 4464 should merge first, I'll revisit this after that happens.

Regarding your comments on screens, I do not have a display on my printer, I use klipperscreen. I assume this will involve custom glyphs or menus or something but I literally have no knowledge of how the klipper menus work so someone else will have to introduce config examples/documentation in another pr.

Regarding m107, I am trying to follow the reprap spec so when I revisit the fans macros after 4464 I will review those before undrafting this pr. Apart from that, I'm sure there's someone who will want the macro to work differently, and they can do that in their own config, which is the beauty of Klipper.

config/sample-idex.cfg

charlespick · 2021-10-04T22:06:59Z

@grigi can you check that I integrated your fan work correctly?

grigi · 2021-10-05T12:47:17Z

@charlespick The fan macros look good 👍

One other comment, I found that printing this: https://www.thingiverse.com/thing:6632 and both measuring the height and then looking at the first layer visually, so that they are identical, helped me dial in the Z offset very well.

It's important to also mention Y offset tuning, as for example, even though I have 2 v6-clone hotends (probably different manufacturers) and mounted in the same way, I have a colossal Y offset of 1.23mm

charlespick · 2021-10-06T18:42:33Z

I mentioned y offset tuning a couple of times 👌

Retroactively signing off some commits of mine. This squash consists of: commit 9831cf20d4cc08731e6d3d24989293e1085a74d1 Author: Charles Pickering <17918019+charlespick@users.noreply.github.com> Date: Mon Oct 4 14:56:17 2021 -0700 white space and fans commit d1c1d90 Author: Charles Pickering <17918019+charlespick@users.noreply.github.com> Date: Fri Sep 17 17:58:04 2021 -0700 minor changes todo: [fan] section commit f6eac58 Author: Charles Pickering <17918019+charlespick@users.noreply.github.com> Date: Fri Sep 17 17:20:53 2021 -0700 update docs commit 414e2d7 Author: Charles Pickering <17918019+charlespick@users.noreply.github.com> Date: Fri Sep 17 16:22:24 2021 -0700 update toolchange macros with offset management syste commit a3ee140 Author: charlespick <17918019+charlespick@users.noreply.github.com> Date: Tue Jul 27 11:22:29 2021 -0700 well that didn't go as expected Signed-off-by: Charles Pickering <charles.pickering@live.com> commit 4c73e6d Author: charlespick <17918019+charlespick@users.noreply.github.com> Date: Tue Jul 27 10:53:22 2021 -0700 changes_1 Signed-off-by: Charles Pickering <charles.pickering@live.com> commit 9d43291 Author: charlespick <17918019+charlespick@users.noreply.github.com> Date: Wed Jul 21 14:17:45 2021 -0700 docs: dual_carriage Added an STL for calibration, some gcode macros to the sample idex config, and an entire document on configuring an idex printer. Signed-off-by: Charles Pickering <charles.pickering@live.com> Signed-off-by: Charles Pickering <charles.pickering@live.com>

grigi · 2021-10-25T18:21:10Z

Hi @KevinOConnor , this PR is ready for another review round from you. 😄

github-actions · 2021-11-16T00:04:10Z

It looks like this GitHub Pull Request has become inactive. If there are any further updates, you can add a comment here or open a new ticket.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

grigi · 2021-11-16T10:56:44Z

You know after the work that I put in to help @charlespick to get this ready, and it just getting ignored like this is quite discouraging.

KevinOConnor · 2021-11-16T16:08:50Z

You know after the work that I put in to help @charlespick to get this ready, and it just getting ignored like this is quite discouraging.

I apologize. The ticket should not have been closed as there was feedback provided after I asked for it.

Unfortunately, I'm severely backlogged on reviews and I fear I have to face the reality that I can not review all the PRs that Klipper receives. At this point, I'm going to try to focus on changing the PR review process (ideally by getting others to help with reviews) instead of trying to review all the current PRs. I know this is slow and discouraging, but I don't know of a good alternative at this time.

-Kevin

dmbutyugin

Please be advised that I do not own an IDEX printer. So, I looked at the PR from the theoretical point of view. So, take my comments with a grain of salt :)

config/sample-idex.cfg

dmbutyugin · 2021-12-07T23:02:07Z

config/sample-idex.cfg

+    G90
+    M83
+    T0 ; test T0
+    G1 X120 Y150 Z.2 F4800


The way the tuning guide goes is that the Z height for the hotends is calibrated (step 4) after this macro is used (step 2). And the step 4 says "To print with low layer thicknesses, you'll probably find that the error between your nozzles in the Z axis is more than your layer height itself." I'm thinking if the layer height .2 is too small at this point?

config/sample-idex.cfg

dmbutyugin · 2021-12-07T23:11:12Z

config/sample-idex.cfg

+# Only rename_existing if you have a sacrificial [fan] section
+rename_existing: M106.1
+# The variable that controls fan speed swopping if not specifying P parameter
+# -1 means the control is disabled, a value of 0-1 is the requested fan speed.


It could be just me, I got confused a bit at first by a description of P parameter. Maybe you could say that P is the index of a fan (0-1)? *And -1 is the active extruder fan.

dmbutyugin · 2021-12-07T23:13:07Z

config/sample-idex.cfg

+    {% set p = params.P|default(-1)|int %}
+    M106 S0 P{p}
+
+[gcode_macro M107]


This is duplicate?

dmbutyugin · 2021-12-07T23:14:49Z

config/sample-idex.cfg

+
+    # Update core Klipper's fan speed
+    # Only do this if you have a sacrificial [fan] section
+    M106.1 S{s}


@grigorig so, this is only useful for reporting?

If you are talking of the unused fan pin, then it also allows you to alter the fan speed for the active tool from the display menu(or a webUI).

Most of the benefit is seeing the fan speed correctly reflect on the 12864 display for me though.

dmbutyugin · 2021-12-07T23:45:20Z

config/sample-idex.cfg

+    {% endif %}
+    {% set fan_speed = printer["gcode_macro M106"].swap_speed %}
+      {% if fan_speed != -1 %}
+        SET_FAN_SPEED FAN=fan_extruder SPEED={fan_speed}


I wonder what is supposed to happen to the fan speed of the other extruder? Would it make sense to really swap their speeds, so that the fan of the parked extruder get the fan speed of the previously parked extruder?

So, using CURA, if you tell it you have separate tools it will set the fan speed of each manually and the variable_swap_speed will stay -1 (Because P is set) and let CURA control everything.

If using PrusaSlicer, it won't emit the P{n} so it expects the active tool's part fan to be controlled.

Currently having the part fan of the parked extruder run will cool somewhere on the bed that isn't where printing is happening. In theory this unnecessary draft could cause part warping so I set it to turn off entirely to minimize risks.
This is based on the assumption that the heatsink fan is adequate to not cause the tool to melt.

dmbutyugin · 2021-12-07T23:46:52Z

config/sample-idex.cfg

+# The variable that controls fan speed swopping if not specifying P parameter
+# -1 means the control is disabled, a value of 0-1 is the requested fan speed.
+# Access via {printer["gcode_macro M106"].swap_speed}
+variable_swap_speed: -1


Maybe this would be more like 'active_fan_speed' ? Because the active fan gets this speed. But I do not insist on this.

I do like that name convention. Ultimately @charlespick will have to alter this PR to have that change, so it's up to him.

dmbutyugin · 2021-12-07T23:48:41Z

config/sample-idex.cfg

+# create the file and insert the folloring content (without the #) to start
+#
+# [Variables]
+# xoffset = 0.0


I didn't try it myself, but would it be possible to use |default(0.0) at the place of their use? Or is defined. So that the user does not have to manually add this section to the save variable file. But maybe it doesn't work that way.

kodonnell · 2021-12-30T09:19:21Z

config/sample-idex.cfg

+
+    {% if params.Z_ADJUST is defined %}
+        {% set newZ = params.Z_ADJUST|float + oldZ %}
+        SAVE_VARIABLE VARIABLE=yoffset VALUE={ newZ|float }


yoffset should probably be zoffset = )

DrumClock · 2022-01-10T19:52:23Z

Hi @charlespick

there are a lot of bugs in sample-idex.cfg ..... e.g.

you define:
[fan_generic part_fan_0]
pin: PE5

[fan_generic part_fan_1]
pin: PD13

but you use:
SET_FAN_SPEED FAN = fan_extruder SPEED = 0
SET_FAN_SPEED FAN = fan_extruder1 SPEED = 0

charlespick · 2022-02-12T18:39:18Z

this pull request has gotten really confusing to me as more and more code snippets keep getting piled on. right now I am too busy with work and school to keep contributing to this pr that I started in the summer, especially since my idex printer is the one I use for school so I can't be tinkering around with it constantly.

when spring break comes around I might make one last push to get it to a workable state.

charlespick · 2022-03-20T22:23:59Z

My IDEX is not working after sitting in the closet. Not exactly sure what's going on and I don't know when I'll be getting back to it. I'm going to close this now but I encourage @grigi and @dmbutyugin to take what they are comfortable working on from here and charlespick/klipperconf to start a new discussion.

Sorry it has to end this way :( I really appreciate everyone else who contributed to this.

grigi · 2022-03-23T13:23:06Z

Sigh, timing isn't great. I'll only have a look at it in probably 3 months. Goods and people are not traveling together during emigration 🤷
Maybe I'll update documentation or something. A subset of this PR.

grigi · 2022-10-22T21:48:25Z

Finally basically settled again. I have started on this, can I just copy what I like and credit you in the PR?

charlespick · 2022-10-24T03:00:16Z

@grigi Go ahead I don't have a dual carriage printer anymore so I don't have anything to contribute beyond what I have already published here

Adds documentation for IDEX printers. This includes: * Offset calibration macros, docs and prints * Fan control improvements * Tool changing macros * Sample config * Some extra comments around IDEX printers Based on Klipper3d#4508 Signed-off-by: Nickolas Grigoriadis <nagrigoriadis@gmail.com>

KevinOConnor added the other work first Topic waiting for other changes to complete label Jul 26, 2021

charlespick force-pushed the work-dual-car-docs-20210721 branch from 77f1e1a to 79ccba0 Compare July 27, 2021 16:53

charlespick marked this pull request as draft July 27, 2021 17:53

charlespick force-pushed the work-dual-car-docs-20210721 branch from 60c9acd to 08a17e0 Compare July 27, 2021 18:13

charlespick marked this pull request as ready for review July 27, 2021 18:22

charlespick marked this pull request as draft August 3, 2021 06:37

charlespick force-pushed the work-dual-car-docs-20210721 branch from 3c0c11d to a3ee140 Compare August 3, 2021 19:16

KevinOConnor removed the other work first Topic waiting for other changes to complete label Aug 17, 2021

KevinOConnor added the pending feedback Topic is pending feedback from submitter label Aug 31, 2021

Tircown mentioned this pull request Sep 1, 2021

kinematics: add duplication/mirror modes to idex_mode #4464

Closed

grigi reviewed Sep 21, 2021

View reviewed changes

config/sample-idex.cfg Show resolved Hide resolved

grigi reviewed Sep 21, 2021

View reviewed changes

config/sample-idex.cfg Outdated Show resolved Hide resolved

charlespick force-pushed the work-dual-car-docs-20210721 branch from d1c1d90 to f2928f6 Compare October 4, 2021 22:04

charlespick marked this pull request as ready for review October 6, 2021 18:42

charlespick force-pushed the work-dual-car-docs-20210721 branch from f2928f6 to f2cfa70 Compare October 6, 2021 18:49

github-actions bot added the inactive Not currently being worked on label Nov 16, 2021

github-actions bot closed this Nov 16, 2021

KevinOConnor reopened this Nov 16, 2021

KevinOConnor removed inactive Not currently being worked on pending feedback Topic is pending feedback from submitter labels Nov 16, 2021

dmbutyugin reviewed Dec 7, 2021

View reviewed changes

kodonnell reviewed Dec 30, 2021

View reviewed changes

charlespick closed this Mar 20, 2022

grigi mentioned this pull request Nov 11, 2022

docs: Dual Carriage #5897

Closed

github-actions bot locked and limited conversation to collaborators Oct 24, 2023

docs: dual_carriage #4508

docs: dual_carriage #4508

Conversation

charlespick commented Jul 21, 2021

charlespick commented Jul 22, 2021

KevinOConnor commented Jul 26, 2021

Tircown commented Jul 26, 2021

charlespick commented Jul 26, 2021

Tircown commented Jul 27, 2021

charlespick commented Jul 27, 2021

charlespick commented Jul 27, 2021

charlespick commented Jul 27, 2021

Frix-x commented Jul 27, 2021

charlespick commented Jul 27, 2021 • edited Loading

charlespick commented Aug 3, 2021

eddietheengineer commented Aug 10, 2021

charlespick commented Aug 12, 2021

KevinOConnor commented Aug 31, 2021

grigi commented Sep 8, 2021

charlespick commented Sep 10, 2021

grigi commented Sep 10, 2021

grigi commented Sep 10, 2021

grigi commented Sep 15, 2021

charlespick commented Sep 15, 2021

charlespick commented Oct 4, 2021

grigi commented Oct 5, 2021

charlespick commented Oct 6, 2021

grigi commented Oct 25, 2021

github-actions bot commented Nov 16, 2021

grigi commented Nov 16, 2021

KevinOConnor commented Nov 16, 2021

dmbutyugin left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DrumClock commented Jan 10, 2022 • edited Loading

charlespick commented Feb 12, 2022

charlespick commented Mar 20, 2022

grigi commented Mar 23, 2022 • edited Loading

grigi commented Oct 22, 2022

charlespick commented Oct 24, 2022

charlespick commented Jul 27, 2021 •

edited

Loading

DrumClock commented Jan 10, 2022 •

edited

Loading

grigi commented Mar 23, 2022 •

edited

Loading