Dual Independent X - movement limits and purge positions

Still working on my I3 style (used to be Tevo Tarantula) dual independent X axis printer. Tool 0 on the left, Tool 1 on the right. 1.0.3 firmware. Using RAMPS 1.5 board with external 2100 driver for second X axis. Will be moving to RADDS/DUE soon.

#define X_MAX_LENGTH 273 (-53mm Tool 0 park position/X Min limit position after back off from limit switch, to right side of bed)
#define Y_MAX_LENGTH 284 (-4mm Y home switch position to back of bed)
#define Z_MAX_LENGTH 200
#define X_MIN_POS -53 (Tool 0 park position/X Min limit position after back off from limit switch)
#define Y_MIN_POS -4
#define Z_MIN_POS 0

#define LAZY_DUAL_X_AXIS 0
#define DUAL_X_AXIS_MODE 1

#define EXT0_X_OFFSET 0
#define EXT1_X_OFFSET 103840 (324.5mm (271.5 + 53), still need to fine tune this, 320 steps/mm)

Bed is 220mm wide. Tool 0 parks at -53mm, Tool 1 parks at 271.5mm

I have two purge locations, Tool 0 at -22mm, and Tool 1 at 252mm. With the above settings I can not get to the 250mm position with Tool 1 (Tool 0 would hit if it could move past 220mm). Tool 1 can only go to 220mm.

So I know I should be able to fix this by adjusting the X_MAX_LENGTH setting above to 305, but wondering if there is another way. Is there a setting so Tool 0 can only move to maximum X position of 220mm and Tool 1 can only move to minimum X position of 0mm? (avoid hitting other tool in their parked position)

Once I get this set up, will be changing LAZY_DUAL_X_AXIS to 1 so both tools go to their parked positions on tools change and use tool change script to move selected tool to the purge position and do a purge before continuing with printing with the new tool. (Think I understand the difference between the two modes)





Comments

  • when everything is setup correctly both heads won't be able to crash into eachoter, so if they do, something is wrong.

    if you're using DUAL_X_AXIS_MODE 1 you will not be able to use LAZY_DUAL_X_AXIS. (it's not needed really)

    X_MIN_POS should be the distance from left head parking position to bed 0, BUT: if right head cannot get to that same point, you will have to adjust it.
    in other words, your bed 0 X coordinate must be within reach of right extruder without crashing into the left parked extruder. 

    X_MAX_LENGTH should be the max left carriage X coordinate + the negative of X_MIN_POS. in your case 220 + 53 (which seems right from your settings)

    EXT0_X_OFFSET must be 0

    and lastly, EXT1_X_OFFSET is basically right carriage parking coordinate converted in steps. which in your case should be 271.55 * 320 = 86896

    as said, you won't be able to use lazy dual with this mode. but you don't need it, you can just use M606 to manipulate the current carriage in the tool change script.

  • EXT0_X_OFFSET must be a negative number for distance to 0 position on bed. 0 position is where Tool 2 can be with Tool 1 parked! EXT1_X_OFFSET is then distance also from 0 bed position to park position on the right.
  • Where is M606 documented? Which code branch from GitHub should I be looking at and working from? (master/development)
  • This is weird. If I set EXT0_X_OFFSET to -16960 (-53mm) and EXT1_X_OFFSET to 86880 (271.5mm), and leave rest of settings alone (as indicated previously), then upon homing X-Axis, Tool 0 is brought to the left edge of the bed (what should be the x = 0 position), and the LCD displays the position as -53mm. I can not describe what happens to Tool 1 on doing a tool change.....

    What I have above works. I did change the X_MAX_LENGTH to allow Tool 1 to move to the right purge position under command.

    I like how both tools are in their parked position after X axis is homed. What would be the setting to change/modify or command to use so on a tool change, the last tool in use moves to its park position, and the newly selected tool stays in its parked position until it is told to move to some location (which for me would be the purge position?) I know there was some mention of this in another thread but not seeing the answer. Maybe this is something to do with the M606 command?
  • are you using master branch or development branch?

    because if you are using master, disregard what i said, because that branch does not have new dual x mode implemented.

    i strongly suggest you switch to development branch so you can make full use of the new dual x mode, and have M606 available.

    what M606 does (you can find description in repetier.ino file) is basically move the active head to a coordinate relative to its parking position.

    so, for example:

    M606 <- will move current head to park position
    M606 X10 <- will move current head 10 mm FROM the parking position (basically 10mm to the right for the left extruder or 10mm to the left for the right extruder)
    you can also specify feedrate F.

    with new mode and M606 you can move the heads to purge position, purge, then resume printing in your toolchange g-code, something you can't do with old dual x mode
  • Thought I had developer downloaded but was using master. Downloaded developer version, made configuration changes to Configuration.h (and pins.h to disable a couple of pins) for my installation. Compiles and transfers okay.

    Controller LCD displays as 1.0.4 with the developer code, but code does not work:
    - Can not get any movement from Octo-Pi movement page
    - Positions on LCD display for all three axis display as large negative numbers.
    - As soon as controller board boots up, appears the motors are enabled as cannot move by hand.

    Downloaded the development version 2019-01-10, 15:45 EST, so this should be after the "Host-Rescue, distortion correction fix" (what is on GitHub right now.) All files are dated 2019-01-09 23:54,except for the ones I modified.

    Master code 1.0.3 works okay.
  • have you double checked the configuration.h ? most likely something slipped.

    anyway, keep in mind that with dev version DUAL_X_AXIS_MODE 1 will actually have effect and it will NOT behave like it did with master version. you may want to reset your offsets and stuff in the eeprom
  • Normally motors are not enabled at startup. Exception if connecting shows
    RESCUE_STATE: LX:109.66 LY:90.85 LZ:1.70 LE:0.00 LT:0 X:0.00 Y:10.00 Z:11.70 E:0.00
    in the log. Send M415 S0 and it should not happen. That is the new rescue system for next server version.

    If it is not that you might have enable pin inverted. Note if you use config tool you need to do all changes there. It will not see if you change defines manually and then upload! It uses the json string at the end of the config to set current values. So if you had fixed it manually it is lost with reupload.
Sign In or Register to comment.