https://github.com/MarlinFirmware/Marlin/issues/11330
https://github.com/MarlinFirmware/Marlin/issues/10749
Posting this as I feel it was missed by @Roxy-3D & @thinkyhead
Thanks
In looking over things, I think I can see some of what can happen with ubl and a tool change. Now that a commit was added to make the planner aware of corrected position, it may no longer occur however for dual x carriage we can try mimicking the home command for disabling and restoring bed leveling.
#if HAS_LEVELING
#if ENABLED(RESTORE_LEVELING_AFTER_G28)
const bool leveling_was_active = planner.leveling_active;
#endif
set_bed_leveling_enabled(false);
#endif
If the bed has an even tilt, which kills duplicate mode btw so for an idex machine shouldnt be left there, i can see ubl adjusting following the park and recall commands causing #11330 however its likely not noticed often as duplicate mode requires fairly accurate bed leveling, using ubl as a visual aid for it. Now that the planner is aware of the position, can you see if this still occurs? If so, ill send you a patched branch with UBL disabled and restored around tool change. Im hesitant to slant the bed on my only idex machine enough to cause this, since ive still got delivery times to make.
@silentninja1 , Hi thanks for picking up on this issue. My beds do not have slope problems (beds are adjusted with dial indicator to minimise overall deviation) but the borosilicate glass beds are not perfectly flat and this varies with bed temperature. I am willing to test changes you make to help eliminate the problem with UBL but I know nothing about programming so I would rely on your guidance.
Regards - bruce
Same person here - phones on a different login. First off, can you verify if it still occurs on the current bugfix now that the planner is aware of ubl corrections with a commit from the last couple days? If it still occurs, I'll give you a patched file to try next.
I can do that I will have to download the latest bugfix v1.1.x and transfer my configs. I will let you know result after testing.
Sounds good. What machine are you testing on?
Its basically a MTW Create but modified for Dual X Carriage and Rambo Board was changed out for a RUMBA board as it has 6 driver slots required for idex.
I do not know but this latest bugfix v1.1.x seems really mucked up re UBL and idex.
On tool change the Z axis drops 2mm, when I did a reprint the Z axis just went up until it hit the physical stop. On trying to do a bed level UBL G28 first that was ok but G29 P1 the probe moved to its first point but then the Z axis just oscillated up and down without the probe contacting the bed (BLtouch) and of course constantly showing an error on computer screen. This is all in the first 10 minutes not very thorough testing.
In transferring configs a few changes have been made but only with drivers used in Configuration.h and two extra entries in configuration_adv.h
Thats quite different results all around, that dont seem related to anything that im aware of changing.
Can you compare with whats here for 1.1.9 https://github.com/InsanityAutomation/Marlin/tree/TM_Trex and here for 2.0.x
https://github.com/InsanityAutomation/Marlin/tree/TM_Trex2+_2.0.x
Ive run both of these builds on a Formbot Trex2+ here.
Ill get a indicator strapped to my trex tomorrow and run back to back tool changes and see what I find. In the meantime, ill toss together a quick change to disable ubl during tool change and shoot it to you in the morning to test, after midnight here now!
v1.1.9 as per your link with my configs does not function at all, the GLCD just constantly squeals loudly, the display is blank, tried a G28 and there is no response from the printer and hot ends heated uncontrollably .
v2 comes up with compile error (Error compiling for board Arduino/Genuino Mega or Mega 2560)
error file attached, I used my configuration with both of these versions of Marlin.
Compile Errors Marlinv2.zip
Fyi, I did confirm the height change with ubl on during tool change today. In the back and forth, a couple other things for idex that are in 1.1.9 we're not completely brought to 2.0 and the softstop for e1 isn't set correctly. I'll be finishing those up then chasing the ubl height change. The extra moves around parking seem to be gone since @thinkyhead added the synchronize command though.
@InsanityAutomation hi, so its not just me the problem does exist. Thanks for going to the trouble of rectifying this. I have never used Marlin Parking I have a script in S3D for that. I look forward to testing.
regards - bruce
Some of the disable, restore leveling is there on tool change but there is motion before and after it, im going to test moving it around synchronize commands to make sure its not a race condition tonight and report back. It does appear that recent changes have resolved #10749 issues 2 and 3, so only issue 1 remains there, which is a duplicate of #11330. Also, I just submitted #11556 to get the 2.0.x branch caught up with the fixes in 1.1.9 - more testing when I get home tonight!
FYI, just a bit of reordering and im 3 prints in without this showing back up.... Ill watch it for another hour or so, then put in the change. @orcinus Can you verify that everything you were looking at is closed as well once I get this next pull request in?
My 8mm test print came out between 8.06 and 8.11 every time, so im calling it good on my end. I did find another crash case where E1 rams into E2 during homing to chase down. Also it seems update softstops is not respecting the new variable for X1 max, so ill chase into that as well. Need to run a 40hr job on my Formbot Trex2+ (kinda need idex for the fine details with PLA/PVA) then ill be back towards the remaining items and anything you dig up testing on your end.
Hi, downloaded "Marlin-IDEX-UBL-Prevent-z-offset-creep" made no changes yet, needed to check if it compiled. Recieved error
In file included from sketch\MarlinConfig.h:31:0,
from sketch\G26_Mesh_Validation_Tool.cpp:27:
Configuration_adv.h:1052: error: missing binary operator before token "("
#if HAS_DRIVER(TMC26X)
^
Configuration_adv.h:1280: error: missing binary operator before token "("
#if HAS_DRIVER(L6470)
^
exit status 1
missing binary operator before token "("
regards - bruce
Should have mentioned I use Arduino v1.8.5, is there another version that would successfully compile.
I downloaded the latest version of today
@silentninja1
That is strange! It did pass all the Travis tests... And I just looked (again) at all the changes...
https://github.com/MarlinFirmware/Marlin/pull/11559/files
There is nothing in these changes that would cause that problem. Maybe the problem showed up on an earlier commit?
The latest beta's of the arduino ide have been having issues parsing comments. Yet the only options for 2.0 are either the somewhat complicated platformio setup, or arduino ide betas. Ive moved to atom and platformio here because of it. Eclipse didnt seem to play nice with everything needed.
Thank You for the explanation!!!!!
Managed to get Marlin compiled with a Nightly version of Arduino. There is no difference to the perfomance as reported earlier. UBL really messes up the operation of my printer.
G28 homes, G29 P1 Zaxis oscillates up and down with BLTouch not contacting the bed, but if left long enough eventually the BLtouch contacts bed and T0 moves to the next sensing point but fails again soon after with an error and printer halts. With every oscillation the Z axis moves down a fraction and that is why the BLTouch eventually makes contact with the bed.
After homing Z0 ends up with the hotend being about 8mm above the bed.
With dual x printing at every tool change the Z axis drops by 2mm.
In the videos trying to show oscillation and Z axis moving down by 2mm each tool change.
Sorry, haven't managed to test this yet, as i've been printing 24/7 for a client the past few weeks. But judging by what @bruce356 said, seems like the original issue is still present (drop on every tool change).
Can you try a few config changes :
The z probe low point is likely the source of alot of your trouble. With a z offset of -.91, that leaves you only 0.09 left defore itll stop, so unless youre z probe for home is at the low point, youre in trouble. BLTouch documentation recommends 10mm clearance. I know you can get closer, but lets stick to the doc's for testing.
@bruce356 Also, maybe try setting
Then when you test it, please provide the output of G29 T on the terminal with youre results.
Thanks
Hi, downloaded the latest Bugfix version 2.0.x db30650 and the homing and bed level probing, Zaxis rising on XY movement issues have been rectified -thanks to dmitry-kutergin- but the UBL issue at tool change still remains when UBL is used. It seems more extenuated now where with every tool change the Z axis lowers by about 2.2mm, determined by looking at the Z lead screw coupling so only approxiamate.
regards - bruce
@bruce356 I expect youll find its moving by 2.5mm, which is the off mesh adjustment height. It appears to be getting reapplied which is why I added the late suggestion.
@silentninja1 ,hi just noticed your post, can you update your "IDEX-UBL-Prevent-z-offset-creep" to the latest version to overcome the above post problems, or have you already
thanks - bruce
@bruce356 Just looked at that commit. Even though it makes the code shorter, that highlights why I dont care for that style conditional. Short and inline, but obscures necessary bits like grouping ()'s quite a bit. Those kinds of things are tough to find!
Ill bump that shortly, check again in 5min
@bruce356 The change from that is in the base branch now, so its there when you updated to the latest.
@bruce356 Another potential config issue, see config adv #define BABYSTEP_ZPROBE_OFFSET - if you babystep away from the value set as the probe z offset, it will then be off.
@silentninja1 I have reconfigured as suggested,
Changing these numbers from my originals did not make any difference except for the length of time to probe the bed,
If you run T0; T1; T0; T1; a bunch, can you measure the drop getting lower, or is it consistent that the gantry is .15mm lower for t1 and at 0 for t0?
This might cause an issue if you babystep far from the programmed offset. It's a preventative.
Didn't expect a difference aside from that here. Like I said when I suggested it, just adhering to documentation while debugging to be safe :) The multiple probing is a huge gain on accuracy btw, I recommend it for any form of able, especially since probing is a one time deal for ubl.
@InsanityAutomation hi,
Every time T1 moves to the bed to print the Z axis lowers by lets say 0.2mm, this occurs every time the printing tool changes to T1 so it is cumulative.
After Homing I lowered Z axis with GLCD to 0.0mm and measured with a vernier (no lcd display) from X axis slide Rail to the bed, the dimension was 129.1mm
I then measured from rail to bed with every tool change, pausing the print to enable measuring.
T0 with GLCD readout of Z 0.25 distance was 129.1
T1 with GLCD readout of Z 0.25 distance was 128.9
T0 with GLCD readout of Z 0.25 distance was 128.9
T1 with GLCD readout of Z 0.25 distance was 128.7
T0 with GLCD readout of Z 0.25 distance was 128.7
T1 with GLCD readout of Z 0.25 distance was 128.45
T0 with GLCD readout of Z 0.25 distance was 128.45
T1 with GLCD readout of Z 0.25 distance was 128.3
T0 with GLCD readout of Z 0.25 distance was 128.3
T1 with GLCD readout of Z 0.25 distance was 128.1
T0 with GLCD readout of Z 0.25 distance was 128.1
T1 with GLCD readout of Z 0.25 distance was 127.9
T0 with GLCD readout of Z 0.25 distance was 127.9
T1 with GLCD readout of Z 0.25 distance was 127.75
Printing finished with T1.
My measurements are not 100% due to none digital readout vernier but they are close. Hope the above gives you the infomation you need.
I have attached an image of the simulated printed object (Simplify3D) it is only 0.25mm high therefore one layer only but there are 6 skirts per tool.
The print was simulated otherwise the tool would crash into the bed.
Gives me a direction to chase! My machine is tied up until late tomorrow/ early Mon but I'll be getting a second idex machine next week so it'll be easier to get time on it.
@InsanityAutomation hi, just wondering if any progress has been made, your probably busy.
thanks - bruce
Not much progress outside of reading a few things. No indication where that specific value comes from yet. What's you're z offset value set to? Also, can you post output from a g29 T?
@bruce356 @InsanityAutomation I'm still in the calibration process. It will be a few more days... But my new development machine is an IDEX machine. And for sure, I'll be bringing up UBL on it ASAP.
Please keep this thread updated with any issues you see. And I'll do the same. (and tell you about any merges I do to fix problems.) I've added some LCD Menu's for IDEX modes. I'm going to be adding some sanity checks to the tool_change() function for IDEX because right now it assumes the new tool can always reach the position of the old tool, and that is not true. )
Oh! And I've changed G28 so the IDEX mode survives across a G28. That is important because if you are in Duplication mode, you want to be able to send the printer a normal .GCode file (with a G28) and have it do two prints instead of one.
@Roxy-3D my batch of changes adding the no move override should have resolved this for idex. Thats what the x1 min and Max separate values we're added for. Unless one of those got reverted somewhere along the line. I'll double check both branches tomorrow.
Are those merged???? If not... I'll put those at the front of the list and expedite that!
I believe they were. It was the batch of stuff that caused an issue for a un-named manufacturer and I redid a different way. Scott had gone over adding the default configs and merging after we initially proved it out. I should have time to go over it again tomorrow.
@InsanityAutomation @Roxy-3D , that is excellent news that Roxy-3D has an IDEX.
Not sure which Z offset you meant (between T0 & T1 or Probe offset)
My Bed Topography Report
G29 T 3rd Create Bed Topography Repory.zip
Regards - bruce
That Topography Map looks pretty good!
@Roxy-3D hi, its a 1/8 inch Borosilicate glass bed, some sheets I purchased are very flat others are like 0.010" inch variation so UBL is essential. How are you doing with your new IDEX, have you found the same lowering of the Z axis when printing with both T0 & T1and UBL active?
regards - bruce
I have not yet explored the lowering of the Z Axis when switching back and forth between the different tools. I'm doing other IDEX related work. But I will get to that as soon as I can. It is on my 'To Do' list. It just isn't at the top of the list yet.
Pretty much the same story here. Day job is been fairly crazy so I haven't had a chance to sit down and correct some of those stuff with the last batch of commits that Scott had converted over for 2. 0 or get into this again. with the holiday weekend coming up here, hopefully I'll have a little bit of time to poke at it. we already know definitively that the off mesh move is being calculated even when leveling is disabled, so that needs fixing in the planner. The other one I'll have to do a little more digging to find where exactly that move is coming from.
@bruce356 You have two people wanting to help you! One of us will find the way to sneak it into our schedule!
@InsanityAutomation I have a quick question for you... If the IDEX Printer is in DXC_DUPLICATION_MODE, is it appropriate to allow it to do a tool change? I'm of the opinion a T1 command should return invalid_extruder_error(tmp_extruder); Maybe something like this in tool_change() :
#if ENABLED(DUAL_X_CARRIAGE)
if (tmp_extruder != 0)
if (dual_x_carriage_mode == DXC_DUPLICATION_MODE)
return invalid_extruder_error(tmp_extruder);
#endif
Exactly! I even 3D printed some round tuits the other day but they disappeared amazingly fast LOL
Roxy I would agree with that, it should not be allowed to do a tool change in duplication mode as it's not valid.
I'm also of the opinion this change should be made (in two places). From this:
// Park old head: 1) raise 2) move to park position 3) lower
for (uint8_t i = 0; i < 3; i++)
planner.buffer_line(
i == 0 ? current_position[X_AXIS] : xhome,
current_position[Y_AXIS],
i == 2 ? current_position[Z_AXIS] : raised_z,
current_position[E_AXIS],
planner.max_feedrate_mm_s[i == 1 ? X_AXIS : Z_AXIS],
active_extruder
);
planner.synchronize();
to:
```
// Park old head: 1) raise 2) move to park position 3) lower
#define CUR_X current_position[X_AXIS]
#define CUR_Y current_position[Y_AXIS]
#define CUR_Z current_position[Z_AXIS]
#define CUR_E current_position[E_AXIS]
planner.buffer_line( CUR_X, CUR_Y, raised_z, CUR_E, planner.max_feedrate_mm_s[Z_AXIS], active_extruder);
planner.buffer_line( xhome, CUR_Y, raised_z, CUR_E, planner.max_feedrate_mm_s[X_AXIS], active_extruder);
planner.buffer_line( xhome, CUR_Y, CUR_Z, CUR_E, planner.max_feedrate_mm_s[Z_AXIS], active_extruder);
planner.synchronize();
```
Do you agree? Or would you prefer the current form?
Funny you should say that, in one of the other threads on idexx issues I mentioned how annoying this style of iteration is with the inline conditionals and did exactly what you have here while I was debugging the issue from the LCD with jogging the wrong axis lol
Tldr I agree completely, that loop is annoying! I'll read it explicitly when I'm near a laptop again :)
OK... I'm going to start updating the IDEX code with the changes I have so far. I have one more question if I can bother you for an opinion:
I added code to the LCD Panel to have an IDEX Mode selection. That lets the user load a normal .GCode file (that only uses the left side of the bed) and do a Duplicate print. But in order to do that, I needed to change the G28 so it preserves the IDEX mode. This is because most Slicer's will put a G28 at the start of the print. By preserving the IDEX mode across the G28, it lets the user put the printer into DXC_DUPLICATION_MODE (using the LCD Panel) and then just send it a normal .GCode file.
Are you uncomfortable with that? If so... I'll add an option to let the user select the behavior when the code is built.
My concern is most slicers default to bed center, so in most cases, that will crash very quickly. A config option to enable it to persist would denote an advanced enough user to offset default slicer start point to the 1/3 mark instead of the center.
One thing I had in mind for idex is a separate z offset to allow fixed mount hotends. Would make a world of difference.
My concern is most slicers default to bed center, so in most cases, that will crash very quickly. A config option to enable it to persist would denote an advanced enough user to offset default slicer start point to the 1/3 mark instead of the center.
Yes! I understand your point. I think that is a good idea. I'll do that as a follow up later!
One thing I had in mind for idex is a separate z offset to allow fixed mount hotends. Would make a world of difference.
This is independent of what you are saying. But I'm trying to get to the point where we can do a partial bed leveling between the two nozzles. We only have one Z-Axis. So we can't correct for both nozzles. But we should be able to 'compromise' between what each of them wants. That is where I'm trying to get to.
Hi wondering if there has been any progress at all, any firmware for testing.
Regards - bruce
Yes and no. I've been working on independent z offsets which has me going through alot of the areas I suspect this to be in lately. I also discussed some of the idex stuff with makergear guys at imts yesterday. Day job is a bit busy, but I'm hoping to have time this weekend to get that far enough to test. Depends on some work I'm looking at for the Ford Ranger assembly lines.
@Roxy-3D
Im looking at these as leveling gets turned on / off
#elif ENABLED(AUTO_BED_LEVELING_UBL)
#if PLANNER_LEVELING
if (planner.leveling_active) { // leveling from on to off
// change unleveled current_position to physical current_position without moving steppers.
planner.apply_leveling(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS]);
planner.leveling_active = false; // disable only AFTER calling apply_leveling
}
else { // leveling from off to on
planner.leveling_active = true; // enable BEFORE calling unapply_leveling, otherwise ignored
// change physical current_position to unleveled current_position without moving steppers.
planner.unapply_leveling(current_position);
}
#else
From what I can see, since leveling is reapplied after the z move down is completed, it can leave it off by the ubl correction amount and not actually move the stepper back to location if the planner isnt synchronized. We may be able to help prevent it with a couple more planner.synchronize statements, one shortly after bed leveling is disabled before setting destination from current, and one right before re-enabling leveling to avoid any race conditions. We could also add a synchronize to the enable / disable leveling function
I also see a few return paths from tool change where leveling may not be restored on abort. Ill put in a pull request with a leveling active conditional block hopefully later today.
@Roxy-3D - can you take a peak here https://github.com/InsanityAutomation/Marlin/tree/IndependentZOffset
I havent added values to the eeprom read / write stuff before, so can you let me know if I missed anything there? I also added a correction to the idex softendstop logic, added a branch for no softendstops to set the limit based on config values, and added the planner sync to apply / unapply leveling.
Great! I'll have a chance to look at this in a few hours.
@Roxy-3D Sounds good - ill be sitting here staring at mechanical guys reassembling a conveyor line for another hour or two before getting into commissioning it.
Also, I am well aware that the independent z offset breaks duplicate mode. Its setup so duplicate mode will always use T0. It is intended to allow a mix of hotends such as a Volcano for infill and support and std v6 for perimeters, or high temp hotend for the part and standard for supports.
Also, I am well aware that the independent z offset breaks duplicate mode. Its setup so duplicate mode will always use T0.
Yes... As you know (and understand) the printer can only control the Z once even though there are two nozzles active. But right now I'm looking at 'splitting the difference' between what the the correction numbers would be in Duplication mode. That may help people while in Duplication mode.
I think what you have in Configuration_save.cpp looks good. I was doing a diff against my current Configuration_save.cpp file. The one thing I noticed that you might want to know about is I have this code added to my file:
#if HAS_HOTEND_OFFSET
constexpr float tmp4[XYZ][HOTENDS] = { HOTEND_OFFSET_X, HOTEND_OFFSET_Y, HOTEND_OFFSET_Z };
static_assert(
tmp4[X_AXIS][0] == 0 && tmp4[Y_AXIS][0] == 0 && tmp4[Z_AXIS][0] == 0,
"Offsets for the first hotend must be 0.0."
);
LOOP_XYZ(i) HOTEND_LOOP() hotend_offset[i][e] = tmp4[i][e];
#if ENABLED(DUAL_X_CARRIAGE)
hotend_offset[X_AXIS][1] = MAX(X2_HOME_POS, X2_MAX_POS);
#endif
#endif
//
// Global Leveling
//
The intent is to initialize the 2nd extruder to the correct location (instead of 0.000). And that is useful with this LCD Code to fine tune the X, Y, and Z code offsets:
/**
* IDEX submenu
*/
#if ENABLED(DUAL_X_CARRIAGE)
static void _recalc_IDEX_setttings() {
if (active_extruder != 0) // If the 2nd extruder is active, the machine needs to be re-homed so the next
enqueue_and_echo_commands_P(PSTR("G28")); // tool change will pick up the new offsets
// In the future, we can babystep the 2nd extruder if it active and this would make
} // homing unneeded.
static void IDEX_menu() {
START_MENU();
MENU_BACK(MSG_MAIN);
MENU_ITEM(gcode, MSG_IDEX_MODE_AUTOPARK, PSTR("M605 S1\nG28 X\nG1 X100\n"));
if (!TEST(axis_known_position, Y_AXIS) || !TEST(axis_known_position, Z_AXIS)) {
MENU_ITEM(gcode, MSG_IDEX_MODE_DUPLICATE, PSTR("M605 S1\nT0\nG28\nM605 S2 X200\nG28 X\nG1 X100\n")); // If Y or Z is not homed, a full G28 is done first.
} else {
MENU_ITEM(gcode, MSG_IDEX_MODE_DUPLICATE, PSTR("M605 S1\nT0\nM605 S2 X200\nG28 X\nG1 X100\n")); // If Y and Z is homed, a full G28 is not needed first.
}
MENU_ITEM(gcode, MSG_IDEX_MODE_FULL_CTRL, PSTR("M605 S0\nG28 X\n"));
MENU_MULTIPLIER_ITEM_EDIT_CALLBACK(float52, MSG_IDEX_X_OFFSET , &hotend_offset[X_AXIS][1], MIN(X2_HOME_POS, X2_MAX_POS) - 25.0, MAX(X2_HOME_POS, X2_MAX_POS) + 25.0, _recalc_IDEX_setttings);
MENU_MULTIPLIER_ITEM_EDIT_CALLBACK(float52, MSG_IDEX_Y_OFFSET , &hotend_offset[Y_AXIS][1], -10.0, 10.0, _recalc_IDEX_setttings);
MENU_MULTIPLIER_ITEM_EDIT_CALLBACK(float52, MSG_IDEX_Z_OFFSET , &hotend_offset[Z_AXIS][1], -10.0, 10.0, _recalc_IDEX_setttings);
MENU_ITEM(gcode, MSG_IDEX_SAVE_OFFSETS, PSTR("M500\n"));
END_MENU();
}
#endif // DUAL_X_CARRIAGE
@Roxy-3D I'd make that a toggle if we do it, since if they swap back to identical tool heads it'll need to be the same again. Also, that'd probably make adjustments weird.
A toggle? Can you explain?
The X Offset is defined as the distance between the two nozzles when they are both parked. If the 2nd nozzle's offset is 0.000 then some special case code happens to unpark it correctly. What this code does is let me dial in the 'correct' offset.
I meant splitting the difference on the independent z offset I'd make an option.
Oh! Yeah! For sure! I thought you meant about the M502 reset of values and using the parked distance between the nozzle's instead of 0.000 mm. Actually...
I was thinking it might make sense to add that to the IDEX Menu I did and have three options. Set height based on Nozzle 1, set height based on Nozzle2, or split the difference. So not a toggle. Instead 3 possible values.
How long until you will have a pull request put together for this? I'll load it and test it as soon as I see it.
I'll get the pull request in after I can test it on my machine tonight or tomorrow. Stuck at a customer's site most of the day :/
@Roxy-3D FYI, pushed a few more tidbits so it compiles nicely now. Included my config files for the trex2+
@silentninja1
FYI, pushed a few more tidbits so it compiles nicely now. Included my config files for the trex2+
Can you give me a pointer to them? I looked here and on your account and did not see them. Did you see I have a preliminary version of a T-Rex2 pins file already merged in here? It is 'borrowing' heavily from the Rumba pins file. But it is no longer a Rumba.
(I was going to compare the preliminary version of the T-Rex2 pins file with yours and make sure I don't have any crazy differences.)
@Roxy-3D added my pins file as well - For the Forbot Raptor, we will need to redefine the bed heater pin btw
Also, Trex2 is a MKS 1.4 board, the 2+ is the formbot board.
https://github.com/InsanityAutomation/Marlin/tree/IndependentZOffset
@silentninja1 Did you check out using a
#define MOTHERBOARD BOARD_FORMBOT_TREX2
in your configuration.h ? I did not check every line of your pins file. But it looks like the bulk of your changes are already in the pins_FORMBOT_TREX2.h file. It would probably be best to not modify the Rumba file. I am going to make a quick change in the next merge:
#if E_STEPPERS > 2 || HOTENDS > 2
#error "Formbot supports up to 2 hotends / E-steppers. Comment this line to keep going."
#endif
@Roxy-3D I havent been over that file yet, I was using this from formbots firmware long before they were included upstream. I plan to get it merged over to that at some point, but just havent had a chance to look at it yet.
I know some of what ive worked on adding with Tinymachines isnt here, so ill need to get those merged in regardless. Just using some of the spare pins, like the bed heater and temp sensor, as well as the laser to a filament sensor when toggled.
Ill probably get it switched over when I go to test this branch, just figured id upload what I had known working for comparison.
Right! I should have my current set of changes available in an hour or two.
@Roxy-3D Sounds good, hopefully I can get this merged with that tonight and test all of it :)
Do you want me to hold off the merge if Travis says "Ok!" ? Or is it better to just merge it and you work against that?
Might be better to wait for #11578 to get merged first.
OK... I can leave it unmerged. The problem is... I have a super hard time working through conflicts.
How about I get it to pass Travis, and just leave it sit. And after #11578 gets merged... You help me get the conflicts resolved?
Sure thing. I'll check with the testers to see if #11578 has high confidence. I think we're very close!
If that is the plan.... Please don't merge #11578 for several hours... It will take me that long to get my stuff to pass Travis. But once my stuff passes Travis, then go ahead and merge.
Thanks!!!!
Ok, just ping me when it's ready.
@Roxy-3D What you have in the trex2 file matches the 2+ except for the filament runout sensors. You have them defined 52 and 50, or 22 and 21, however I dont believe those are exposed anywhere. Im assuming you stole pins 41 and 37 for something on your machine?
Im home and caffeinated so ill be messing with stuff momentarily. Need a few parts for the day job tomorrow.
@Roxy-3D Definitely something I missed in the config store, getting a eeprom datasize error.
@Roxy-3D I forgot to add the values to the struct for the sizeof comparison :) Ill need to verify they get written back to the external variables after I make sure it works correctly.
What you have in the trex2 file matches the 2+ except for the filament runout sensors. You have them defined 52 and 50, or 22 and 21, however I dont believe those are exposed anywhere. Im assuming you stole pins 41 and 37 for something on your machine?
I certainly could be wrong... But it is my belief that the T-Rex 2+ doesn't have filament runout sensors. What I did was 'stole' pins off of the ICSP port and re-allocated them to be used by the filament runout sensors. The problem with doing that is the SD Memory card is no longer available. (Those are on pins 50, 51, and 52 if I remember right.)
I don't know where pins 41 and 37 are on the board. Any pins you know about, I'm eager to learn about. You are correct I re-allocated 37 and 41. The kill button isn't able to be pressed and I have a reset button wired into the board. And while I would have like to keep the beeper, I needed the pin for the Max7219 LED debug lights. I also stole the Arduino Board LED pin for the 3rd wire I needed for the Max7219 chips.
@Roxy-3D What we did was used fan 1 for the runout sensor as it is dedicated for the laser port. The laser and runout sensor become a toggle. If Filament runout is on, fan1 is set to -1 and the pin utilized.
This is an addon Chris pre-installs on his customers machines, not formbot direct.
Oh! OK. Thanks!
@Roxy-3D Almost, gotta figure out why X2 didnt get reloaded from eeprom correctly and this will be good to go.
@Roxy-3D kids are home, I'll finish it up later tonight or tomorrow. Functionally it works, just need to get save restore tweaked. I'll merge you're stuff in shortly as well so it's all up to date.
OK! Great! As soon as your stuff is merged in, I'll do some quick tests and then see if I can get the bed leveling to 'Split the Difference' between the two nozzles.
Theoretically this can work only if the bed is neither seriously inclined nor warped - so when you don't need ABL at all.
@AnHardt that's a generally understood limitation of any form of bed leveling with duplicate mode printing. It becomes a matter of getting close enough physically with a thick enough first layer to compensate enough that the difference no longer matters.
Yeah... The way I would word it is: In IDEX Duplication mode printing... The bed needs to be very flat. Flatter than what is needed for single nozzle printing. But even so... I'm thinking we can get better results if the two nozzles 'Split the Difference' of what each wants for Z-Height Correction.
Soon... We should have 'test results' to know if that is true.
@InsanityAutomation
You are right. It's not my wasted time. If the theory doesn't work the implementation can't be better, except it has an error.
To make it split the difference on the z offset in that mode for testing purposes is about 10 minutes and some time testing. Not a big deal regardless. Making the independent offsets work for different nozzles does most of the work already.
@Roxy-3D What you have for the pause / resume doesnt honor if only a single runout sensor is used for an idex machine. For the trex2+ where only a single pin is available, they can be wired in parallel or series depending on the switch contact type to pause if either runs out. I have that fixed in my updated branch im working on as well.
@Roxy-3D BTW, here is the branch merged with head this morning https://github.com/InsanityAutomation/Marlin/tree/IndependentZOffsetV2
@Roxy-3D Any opposition to changing the Formbot Trex2 pins file to Trex2+ or 2P to avoid confusion with the original trex2 on the mks 1.4 board? Also, if I get a chance to later today ill add a formbot raptor definition.
@InsanityAutomation I haven't checked out everything... But yesterday's merge of my IDEX stuff with the current code base seems to work pretty well. When ever you are ready... It would be good to add your updates to the mix!
@Roxy-3D I bumped a few fixes to youre stuff into what im prepping. I changed the board definition for the formbot boards as they tripped on two other defines below. I added the raptor pin definition. I added a catch on the filament runout sensor if using idex with only a single sensor. Im still at the day job though so I cant test for a couple more hours at least. Do you want me to rename the trex2 definition while im at it?
Do you want me to rename the trex2 definition while im at it?
Yeah... I didn't realize there was a T-Rex 2 and a T-Rex 2+. So what I did was definitely not a T-Rex 2.
I added a catch on the filament runout sensor if using idex with only a single sensor.
Do you mean you made the logic more robust so it can handle that case? If so, great!
if we add a heated bed to the T-Rex 2 plus, the single sensor is about our only option so yeah I added the code to make it handle that case LOL. The original T-Rex to is not even idex, it just has a second extruder head that clamps onto the same belt. I can attach a couple photos of the difference is when I get home.
if we add a heated bed to the T-Rex 2 plus, the single sensor is about our only option so yeah I added the code to make it handle that case LOL.
OK. I think I understand. But the T-Rex 2+ I have is modified to have a Marlin controlled heat bed. It uses Arduino pins D57 and D58 on the Aux-1 connector to control a Solid State Relay and to pick up the thermistor information.
My big problem is I need 3 pins to control a Max7219 LED Matix for debug information. If it wasn't for that, I have enough pins. But what I did was yank the LCD Panel Kill switch out because it isn't accessable any way. And I gave up the Board's LED Pin and the LCD Panel Beeper to get my 3 Max7219 pins.
I don't know what D4 is used for, but I think that is free. That is on that hand made cable the board plugs into. That might go to the laser (which I don't have). So that might be an option for one of the Filament Sensors.
The way that we put in the heated bed is exactly the same way that you did. And you are correct that PIN for is to lazerport on the side. That's why in the branch I have submitted their enable filament run out disables the fan 1 pin. I wanted to keep everything defined as possible without requiring any soldering.
Do you have an up to date board diagram showing where each Arduino pin is? On the diagram I have, I don't see a Fan-1 pin.
It goes through the ribbon cable out the bottom to the connector on the side next to the power supply box. I don't have any particular diagrams of it though. anything from Forum box documentation would call it the laser pin instead of fan 1. The way they implemented this was the inspiration behind the fan as laser change that I put in a while back that is still sitting due to safety concerns.
OK! That is helpful information. So one filament runout sensor could plug into the Laser connector. And most likely, that is Arduino Pin 8, right? That is a differential drive. That might not be possible to use for input. It would be nice to have schematics. But Pin 4 looks like it is not used. That gives us one filament sensor for sure!
I might be able to multiplex the Max7219 pins. Normally, those are all output. If the Max7219 is not in the middle of clocking out bits to the LED's, I could flip the data pin to be in input mode and check the filament run out sensor. And then flip it back to be output. I would just have to make sure the filament runout sensor is 'Open' when there is filament in the sensor. It would be a little bit of a hack, but it would let me keep my Max7219 debug LED's and still have dual runout sensors.
@Roxy-3D Testing is looking good now, Need to clean up a little and ill get the pull req together. Take a look at the branch I have setup, and make sure you agree with everything I did :)
@Roxy-3D have at it!
@bruce356 Have you defined a hotend z offset in your setup after flashing?
@silentninja1 hi, my hot ends are fairly close, so for the purposes of testing they are set as below and no I do not change this after flashing. I would normally test the xyz offsets and then place the results in the firmware.
// Offset of the extruders (uncomment if using more than one and relying on firmware to position when changing).
// The offset has to be X=0, Y=0 for the extruder 0 hotend (default extruder).
// For the other hotends it is their distance from the extruder 0 hotend.
// NOTE! For Dual X Carriage, if second carriage is positioned at X=291 when homed,
// then HOTEND_OFFSET_X should be set to {0, 291}.
#define HOTEND_OFFSET_X {0.0, 291.2} // (in mm) for each extruder, offset of the hotend on the X axis
#define HOTEND_OFFSET_Y {0.0, -0.3} // (in mm) for each extruder, offset of the hotend on the Y axis
#define HOTEND_OFFSET_Z {0.0, 0.00} // (in mm) for each extruder, offset of the hotend on the Z axis
// Note! Z HOTEND_OFFSET for 2nd extruder:-
// Increasing the Z negative number say "{0.0, -0.03}" to "{0.0, -0.09}" will move the hot end further away from the bed.
@bruce356 Take a look at PR #11970 The idex tool change function did not honor no move, allowing a scenario where the tool change unpark zlift may be applied incorrectly. Ive eliminated some duplicated moves as well which should speed up tool change and reduce wear on the z axis. This eliminated the second variable. For IDEX, any time tool change is called, both park and unpark were being called so only the larger of the 2 variables makes sense to use, otherwise your making several extra moves.
@InsanityAutomation hi, has this pr been incorporated into the latest bugfix-2 366fae6, if not where can I down load to test
thanks - bruce
Hasn't been merged yet, want to test in more machines than just one type.
https://github.com/InsanityAutomation/Marlin/tree/TM_Trex2%2B_2.0.x
I just merged it into this branch, so you can replace config files here and give it a shot!
@InsanityAutomation hi, have not tried any other versions in between since about 16th August so not sure what is affecting the lowering at tool change. It was that the lowering occurred when X2 was activated, now it appears to be when X1 is activated.
Also with your latest version as downloaded and my config files (dual printing), if a print is allowed to finish as normal with no resets and another print is started X2 crashes into the Right side X2 home position end stop as if its ignoring the endstop.
Also the amount of Z lift is more for the Left hand X1 than it is for the Right hand X2 at tool change.
I am attaching 3 videos to demonstrate the problems, there is a black indication line on the lead screw coupling that shows lead screw positions. Anti-clockwise rotation of the coupling Z carriage is lowered and clockwise the Z carriage is raised.
Videos are zipped into one file and resolution was been reduced for size.
Regards - bruce
UBL-Marlin2_Trex2_InsanityAutomation.zip
Also with your latest version as downloaded and my config files (dual printing), if a print is allowed to finish as normal with no resets and another print is started X2 crashes into the Right side X2 home position end stop as if its ignoring the endstop.
Are you using PronterFace to talk to your printer? I've noticed a similar issue if I do some stuff, and leave tool 1 active when I restart the printer. Some how.... PronterFace makes some bad assumptions about what tool is active and when you restart the printer the two halves of the brain aren't in sync.
(That isn't to say we shouldn't fix the problem in Marlin. But can you give us some more details like that?)
@Roxy-3D hi, I print with a Raspberry Pi3 and Octoprint, I only use Pronterface sometimes for running UBL after new firmware flash or checking configuration details, never use it for printing.
Let me know if I can be of any help.
regards - bruce
Just for the purpose of determining if we are seeing a similar problem: Are you seeing this problem after using tool #1 and then restarting the printer?
I see this if printing with both tools as I was only testing for the Z lowering problem at tool change, I have not tested using tool-1 only for a print, but I can if needed
Oh! OK! Please... More detail. Are you printing in Full Control mode, or Duplication mode?
Does the problem happen at the start? Or maybe at the end when you restart and do a G28? Can you give us specific steps that duplicates the nozzle crash problem? Over the last 2 months, most of them have been cleaned up. But I know there are a couple more to fix.
Just printed using using T1 only (T0 only used for homing G28) and yes T1 crashes into T1 end stop.
The printer homes both tools normally so one assumes all is ok, but when it comes time for T1 to move to the bed for printing it instead crashes against the T1 endstop for a short time and then moves out towards the bed printing location, but T1 does not reach into the bed as far as it should (as some of the normal movement cycles were wasted hitting the endstop) and starts printing on the right side of the bed instead of the centre. I am not using duplicate mode. (this is all starting another print without resetting the printer)
@bruce356 using the same configs you had posted before? Since youre not explicitly setting a mode by the sound of it, I am guessing you are in full control mode instead of auto parking mode. That hasnt been tested as thoroughly.
@bruce in configuration_adv.h can you change
Comment out #define TOOLCHANGE_UNPARK_ZLIFT - its essentially merged with the above
and in configuration.h
The T0 limit is now defined by bed size, separately from this. Having the park position outside the softlimit may have caused some issue.
@silentninja1 , yes the configuration has remained the same and yes I run in full control mode using a script within S3D, i have used this long before Auto Park became available in Marlin. Could not see any reason for changing.
{IF NEWTOOL=0} T1; select Tool-1
{IF NEWTOOL=0} G1 X292 F10000 ; move T1 into dock
{IF NEWTOOL=0} T0; Left Extruder is active
{IF NEWTOOL=1} T0; select Tool-0
{IF NEWTOOL=1} G1 X-42 F10000 ; move T0 into dock
{IF NEWTOOL=1} T1; Right Extruder is active
I will test your recommended config in the morning as it is about 12.30 am here.
Thanks - bruce
@bruce356 Just as an FYI... I have never printed anything in 'Full Control' mode. All of my testing has been in 'Auto Park' mode. And I did fix a number of things that were causing the two nozzles to hit each other. I'm all for finding the bugs in 'Full Control' mode and getting them fixed. But my guess is 'Auto Park' is more stable and has less problems right now.
@silentninja1 @Roxy-3D , Made changes to config files as recommended, not very successful at my end.
Have attached video and config files plus Gcode.
UBL-Marlin2_Trex2_InsanityAutomation_AutoPark.zip
Marlin_Configs.zip
Dual_Extruder_AUTO-PARK_0.25mm_high.zip
Yeah... That is interesting. It looks like it is trying to park the right extruder... But it doesn't move it far enough to the right. Your T-Rex 2 doesn't look anything like the one I have. Yours is much nicer.
We can probably find the root cause of the problem shown in the video by adding some debug prints. But it is obviously happening on the tool change. Can you reduce that failure down to 5 or 6 lines of GCode? For example... select T0. Move to some location. select T1 and have the failure happen?
That combined with some debug prints in the tool change (and maybe unpark) code... I think we can figure out the failure mechanism. In fact... If you can reduce that to 3 or 4 lines of GCode that cause the failure... Most likely I can duplicate it on my IDEX Printer. And that will speed up the resolution process.
@Roxy-3D His is a custom machine based on a different printer. Not a Trex or other formbot. Much older.
I dont see any explicit mode sets in the gcode here. Im running an 18hr job on my Trex2+ atm, but ill run this same gcode on it when its done and see what happens.
The printer is based on a Makers tool works "Create" but with Idex instead of having dual extruders on one carriage. Originally the MTW Create comes with a RAMBO board but because I required an extra driver I selected the RUMBA. Yes it is a custom build but not old, finished this one about 6 months ago and the so called technology has not really changed in many years, still moving axes with steppers.
regards - bruce
Well... I do like your printer!!!! And I think it is highly likely we can duplicate the failure on our hardware.
If we can duplicate the failure.... For sure we can fix it!
Quick question: I did not look at your configuration files. But it sounded like you changed to being in Auto Park mode. Your Right Extruder was not in a 'Park' position when it got hit. Am I missing something?
Can ensure auto park mode with an m605 s1 added in the start script after any g28 or g29 commands.
Yes... Maybe... But I made changes to G28 to preserve (and restore) the IDEX mode through a G28. It would be safest (for reproducing the error) to set the IDEX mode first.... And then do a G28.
But "Yes. I agree." with what you are suggesting.
@Roxy-3D , thanks, just for your information, I have not had any problems with the printer functioning as it should with Klipper and Repetier firmware loaded, it works perfectly with past Marlin versions as well (last one tested was mid august) as long as I don't use UBL. Bi-linear bed levelling has always been fine.
I appreciate both your efforts, thanks very much
regards - bruce
My current thought process is that manual parking is what's causing ubl trouble suddenly correcting from the opposite side of the bed. That's why I'm hoping it goes away once auto park is working, then we can figure out how to get ubl to handle that scenario!
There is probably a lot of truth to what you just said... From my perspective... UBL always dealt with destination coordinates. It didn't care where the nozzle was. At the end of the next move it would be in the 'corrected' position.
It is the correcting of the 'current' position with out an associated move that caused these issues to appear. Please keep that thought in the back of your mind as you look at things!!!! I think we have an extra 'correction' or maybe we are missing a correction. But my guess is it is happening without an actual move. It is happening because of the 'adjustment' that happens when tools are changed.
@Roxy-3D — Could you possibly add a function to UBL so we can inform it when the current position changes, so it can update its internal state?
Could you possibly add a function to UBL so we can inform it when the current position changes, so it can update its internal state?
Sure. But here is the question I have: What is it going to do with this 'information'? When a tool change happens, we are kind of messing with its values behind its back. What ever it used to think was accurate information, no longer exists. (We are adding in the new tool's offsets and subtracting off the old tool's offsets)
Maybe what you are really asking for is a UBL Tool Change method that the Planner can call. And all the logic to handle offsets for UBL is contained within that method. And probably that method could be 'smart' and not do any correction if the current tool is the tool being changed to?
I'm more of the mindset we would need to modify the full control script with a command to disable ubl / unapply correction then enable and reapply. This would prevent too low of a park/unpark raise from allowing corrections to bring it back into the part on park or recall. Edit : reasoning being it more closely emulates the auto park function.
Well... at the root of this problem is UBL has its own motion routine for crossing mesh points. It is highly optimized for speed at the cost of having more code paths for each optimization. Currently, this motion routine is not compatible with the SEGMENTED MOVES option for Cartesian.
At a higher level.... I think the right direction to go is for UBL to use the same motion routine as the other bed leveling types. And rather than abandon the different optimized code paths, move (or adapt) UBL's motion routine down into the Planner so everybody is using the same code.
The whole problem with doing the correction and uncorrection is right now UBL is a 'on off' and handled as a special case. If we were to adapt UBL's motion routine down into the Planner for everybody to use, that would give everybody the more efficient code but also bring UBL into compliance with what the other bed leveling systems are doing for 'correction'.
Fair enough, but at that point segmented moves would need to be looked at and handled, or deprecated. IIRC the planner does have functions for apply and unapply leveling, which are called as part of the set leveling active function. Do these work as expected with UBL to your knowledge? Id expect if they didnt we would see issues with auto park as well.
Fair enough, but at that point segmented moves would need to be looked at and handled, or deprecated. IIRC the planner does have functions for apply and unapply leveling, which are called as part of the set leveling active function.
When they are done... They work as expected. The problem is I think we have a corner case where we get an extra 'correction' or maybe we lose a 'correction'.
Supposedly... moving the nozzle to a part of the bed where there is a large value mesh point and then switching tools back and forth, back and forth causes the nozzle to start changing Z-Height. If we could duplicate the failure with a GCode file that did that... It probably would not be hard to add some debug info and figure out where the extra (or missing) Z-Height correction was taking place.
@Roxy-3D sorry missed your question,
Quick question: I did not look at your configuration files. But it sounded like you changed to being in Auto Park mode. Your Right Extruder was not in a 'Park' position when it got hit. Am I missing something?
Yes as suggested by @silentninja1 I changed to autopark, and made changes to the config files as below:-
@bruce in configuration_adv.h can you change
Comment out #define TOOLCHANGE_UNPARK_ZLIFT - its essentially merged with the above
and in configuration.h
The T0 limit is now defined by bed size, separately from this. Having the park position outside the softlimit may have caused some issue.
But this is not working on my printer as the video shows. On that video I have not shown the homing portion but only the part where T0 moves out for the first time to start a print. On tool change to T1 the auto home function attempts to return T0 to its park position but fails (the stepper motor for T0 sounds like it is vibrating, stalling or missing steps at the point where it stops moving), T1 then moves out to print for the first time, then when T0 is again called, exactly the same auto parking problem occurs with T1 as with T0 (vibrating, stalling or missing steps at the point where it stops moving and fails to park) and therefore the collision.
I do not know why the auto park feature is not functioning for me, this is the first time I have ever tried to use it, I will go back to full control and reverse the config changes that @silentninja1 suggested.
Regards - bruce
Bruce in that case try to bring down your max speeds and acceleration. Tool change by default goes the axis max (planner.max_feedrate_mm_s[X_AXIS]) and may simply have not been able to keep up.
I do not know why the auto park feature is not functioning for me, this is the first time I have ever tried to use it, I will go back to full control and reverse the config changes that @silentninja1 suggested.
Also... Please verify you have the spacing between the two extruders (when parked) at the correct number. When parking, it doesn't use end stops. Rather... it move the extruder to the 'correct' position. But if you have the spacing set wrong between the two extruders, you will have the wrong thing happen.
@silentninja1 , I reduced acceleration from 3000 down to 1000 and this made no difference, am I looking at the wrong thing.
#define DEFAULT_MAX_FEEDRATE { 500, 500, 6, 30 }
/**
* Default Max Acceleration (change/s) change = mm/s
* (Maximum start speed for accelerated moves)
* Override with M201
* X, Y, Z, E0 [, E1[, E2[, E3[, E4[, E5]]]]]
*/
#define DEFAULT_MAX_ACCELERATION { 1000, 1000, 100, 10000 }
/**
* Default Acceleration (change/s) change = mm/s
* Override with M204
*
* M204 P Acceleration
* M204 R Retract Acceleration
* M204 T Travel Acceleration
*/
#define DEFAULT_ACCELERATION 1000 // X, Y, Z and E acceleration for printing moves
#define DEFAULT_RETRACT_ACCELERATION 1000 // E acceleration for retracts
#define DEFAULT_TRAVEL_ACCELERATION 1000 // X, Y, Z acceleration for travel (non printing) moves
S3D speeds are set on:-
default printing speed 60mm/s
X/Y Axis Movement Speed 100mm/s
regards -bruce
EDIT:- Not sure why the change in
#define X_MAX_POS to 291.2 (your x2 park position)
as I thought it should be
#define X_MAX_POS 250 // Actual "X_BED_SIZE" Required here
Has this changed?
@bruce356 Is
Correct? If not, it will cause the problems we saw in the video. And that comment, might be more clear if it said: Set maximum to the distance beween toolheads when both heads are homed AND PARKED.
@Roxy-3D yes that is set correctly in Configuration_adv.h
#define DUAL_X_CARRIAGE
#if ENABLED(DUAL_X_CARRIAGE)
#define X1_MIN_POS X_MIN_POS // set minimum to ensure first x-carriage doesn't hit the parked second X-carriage
#define X1_MAX_POS X_BED_SIZE // set maximum to ensure first x-carriage doesn't hit the parked second X-carriage
#define X2_MIN_POS 0 // set minimum to ensure second x-carriage doesn't hit the parked first X-carriage
#define X2_MAX_POS 291 // set maximum to the distance between toolheads when both heads are homed
#define X2_HOME_DIR 1 // the second X-carriage always homes to the maximum endstop position
#define X2_HOME_POS X2_MAX_POS // default home position is the maximum carriage position
#define X_MAX_POS to 291.2 (your x2 park position)
as I thought it should be
#define X_MAX_POS 250 // Actual "X_BED_SIZE" Required here
Has this changed?
is in Configuration.h that is why I queried it.
Sorry for bad copy paste code below, on mobile.
For feed rate and Accel, here's what I'm using on the Trex for example
/*
* Default Max Feed Rate (mm/s)
* Override with M203
* X, Y, Z, E0 [, E1[, E2[, E3[, E4[, E5]]]]]
*/
#define DEFAULT_MAX_FEEDRATE { 250, 150, 5, 25 }
/**
* Default Max Acceleration (change/s) change = mm/s
* (Maximum start speed for accelerated moves)
* Override with M201
* X, Y, Z, E0 [, E1[, E2[, E3[, E4]]]]
*/
#define DEFAULT_MAX_ACCELERATION { 1500, 500, 400, 4000 }
Trying to go 500 mm/s to park may be problematic.
X max pos is used to limit any travel, including x2 into park position. Config adv has a separate limit for x1 that is set to bed size under the dual x carriage section.
yes that is set correctly in Configuration_adv.h
Was that value set at a different value in that video?
@InsanityAutomation I changed the X Y settings to yours and it has made no difference, the effect is still the same as per the video, EDIT comment removed because it was wrong.
@Roxy-3D no the values were set as:- here
Hi, wondering if you have had any luck with this
Regards - bruce
Currently verified with head, using a fresh zip this morning. Idex quick home disabled homing when t1 was active and previously homed t0 goes the wrong direction in it's homing move. Also occurred in quick home when y makes it's switch before t0. May be what caused your earlier crash that had us confused.
Since Marlin 1.1.x is now end-of-life, please move on to bugfix-2.0.x
and file a new issue if that branch is showing similar problems. Perhaps wait a few days, as we have Dual X Carriage patches pending.
Hi @thinkyhead , I know the heading states v1.1.x (because this has been a problem for ever, at least last 6 months and longer) but all the trials/testing lately has been with InsanityAutomation version 2 and Bugfix-2.0.x. and up to now the problem is still there (with UBL active).
My main concern has always been that "For every tool change from T0 to T1 the Z axis lowers closer to the bed by about 0.10 or 0.15 each time there is a tool change".
Some of the later tests the process reversed? from T1 to T0.
I will wait for the pending patches.
Thanks and Regards - bruce
I think I agree with closing this one in part due to the clutter. I'll try to go through all the referenced threads this weekend and make a list of what's still open, then get your config files set to what should be a solid base to test and open a new issue with that to track on 2.0 directly.
@InsanityAutomation , thanks very much, I know this is causing you a lot of work and it is appreciated
regards-bruce
I'm going over all the idex stuff regardless, so it's fine, but thanks for appreciating it! More testers is always better :) I'll hopefully have one more idex related pr in tomorrow then hopefully be able to go back over all this with a clean slate!
UBL is a bit of an outlier compared to the other bed leveling systems because it isn't integrated fully with the planner. In short, I believe it requires being given a move command before it gets updated on the bed leveling compensation for a given position. For other leveling systems everything is handled at the planner level, so we are able to simply disable leveling before tool-change, then re-enable leveling afterward to get the coordinates corrected for the new toolhead. So for UBL some extra code will need to be added to ensure the tool position is correct after a tool change when leveling is enabled.
@bruce356 care to give this another run? Config files for 2.0 have changed a little though, notice the zraise is now a single variable for all tool modes, park and unpark use the same value, there are firmware filament retract / prime options, and an idex babystepping tool z offset option.
Is this issue well solved now?
Hi Just noticed this post by InsanityAutomation will test my printer with the latest Marlin tomorrow
thanks
@InsanityAutomation hi, just tested Marlin 4f9ec9a, there has been improvement on the lowering distance of Z axis on tool change with UBL active but it has not been eliminated. In this test the Z axis lowered by 0.2667mm or 0.0105 inches (10.5 thou).
My test was to print a single layer model as before with 2 objects and 10 skirt outlines. With NO UBL the Z axis does not gradually lower with tool change.
Also at the end of the print instead of T1 moving to its park position it remains where the print ended and T0 moves from its parked position towards T1 and crashes into it. I do not use the Marlin parking feature but the script I have always used within S3D.
Marlin Idex 29-11-2018-1.zip
Regards - bruce
P.S. forgot to mention that if you view the video you will see that the raising of the Z axis is different for T0 compared to T1 at tool change. T0 raises quite high where T1 virtually none when T1 move in to print.
Can you try with autopark enabled and the script disabled? Most development had been with auto park. If we can confirm it doesn't happen there then it helps lock down exactly where it's occurring.
@InsanityAutomation with auto park how can I slow down the parking speed. It tries to park the carriages so quickly (or it seems) that the steppers skip most all steps (it seems crazy fast) I reduced printing speed to 50mm/sec and
#define DEFAULT_MAX_FEEDRATE { 100, 100, 6, 30 }
#define DEFAULT_MAX_ACCELERATION { 1000, 1000, 100, 10000 }
#define DEFAULT_ACCELERATION 1000
#define DEFAULT_RETRACT_ACCELERATION 1000
#define DEFAULT_TRAVEL_ACCELERATION 1000
Nothing is helping or is something else going on?
@InsanityAutomation I just disconnected the belts on the printer and the steppers with no load will stall when trying to park, so something else is amiss other than speed.
My first tests with auto park long time ago showed the same results, so nothing has changed, that is why I use a script in S3D to park the carriages. But now the script also no longer functions as expected at the completion of a print (works as expected during printing and at start of print).
How many users are there with IDEX machines and are NOT having the same problems.
It should be the first value in DEFAULT_MAX_FEEDRATE as it uses the max feedrate for the x axis. At runtime M203 can override this.
I use auto park every day so that's really confusing! Can you attach you're latest config again and I'll go over it a bit?
@InsanityAutomation
Marlin_Configs_29-11-2018.zip
Got it, I'll go over them after my 7a meeting tomorrow.... I hate meetings that early... Lol
Its nice that you closed this issue without resolving it. I got sick of waiting so have moved on to something far better.
regards - bruce
Unfortunately at least 3 of us have tried to replicate your remaining issue with no success. I understand the frustration, but if we can't reproduce it all we can do is take stabs and guesses. Quite a bit has changed since this was first opened and most items in the chain have been addressed.
All Scott was after closing this is the issue being reopened with only what still pertained to 2.0 after the last batch of changes I tagged you in.
Just remember everyone here is a volunteer.
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.