Homing Dual Core XY gantrys



  • This is something that was started in the Firmware wish list section s but that doesn't seem like the appropriate place so I'm starting a new thread here.

    Background info. I have two Core XY mechanisms stacked one above the other. The lower one carries the hot end, the upper one carries the extruders. Up until yesterday, only the lower Core XY had end stops. The problem is that if I have been working on the printer and the upper CoreXY gets moved, if I forget to to line it up again and it's too far to the left or forward, then when I home X or Y (or both) the extruder carriage makes contact with the frame before the hot end carriage triggers the end stop switch resulting in nasty noises and other undesirable effects.

    So, I've fitted end stop switches for X and Y to the upper gantry. I then added two extra hidden axes U and V like so

    M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3; U and V are additional axes only for homing. Made invisible by using P3

    David - note that there is a typo in your post as you had Z as being 3 which is already assigned to X.

    I also added this line to config.g which I thought would also be necessary.

    M574 U1 V1 S1 ; active high switches for when temporary U and V axes are employed during homing the upper XY

    This allowed me to confirm that all switches were working as expected using the "machine properties" page of DWC.

    Then I changed my homeX to look like this. The file is annotated so should need no further explanation.

    ; homex.g
    ; called to home the X axis

    M906 X400 Y400 Z1200 ; reduce motor currents

    M584 X0 U3; temporarily map U axis to drive 3

    ; Lift Z relative to current position
    G91
    G1 Z5 F300
    G90

    ; Move fairly quickly to X and U axis endstops and stop there (first pass)
    G1 X-380 U-380 F3000 S1

    ; Go back a few mm
    G91
    G1 X5 U5 F600
    G90

    ; Move slowly to X and U axis endstops once more (second pass)
    G1 X-380 U-380 F360 S1

    M584 X0:3 U10 ; remap X to drives 0 and 3, U to non existent drive 10

    M906 X1800 Y1800 Z1800; reset motor currents

    ; Lower Z again
    G91
    G1 Z-5 F300
    G90

    When I hit the homeX button, very nasty things happened and I had to hit emergency stop. Further investigation seems to indicate that the additional U axis isn't being treated as having CoreXY kinematics. At least I think that's what's happening but if anyone can find something I've missed in config.g or homex.g, please let me know. I also have a feeling that the main X axis is being affected too (by the creation of the U and V axes).

    With the machine re-set to my normal motor mapping (i.e X0:3), if I then enter M584 X0 U3 via the console then do G1 X-10 U-10 it looks like the upper gantry (U) tries to move at 45 degrees and I'm not quite sure where the lower gantry is going but it doesn't look like it's in the negative direction. I'll need to unload the filament and disconnect the bowden tubes and wires that link the two gantries together in order to test further because nasty things are happening as it is.

    EDIT. Firmware is 1.19.2. DWC is 1.19.3. Duet Ethernet (not WiFi) plus Duex5


  • administrators

    That's right, any additional axes you add on a CoreXY machine will not use CoreXY kinematics. What I think you need is a variation on CoreXYUV kinematics. It's a variation, because in CoreXYUV kinematics the V and Y axes are slaved together.

    I think you could probably use standard CoreXYUV kinematics to support independent homing of X and U. but not independent homing of Y and V.



  • That's a bu**er - I've spent quite a few hours printing parts and fitting all the extra switches and stops, as well as extending the wires that I had on E0 and E1 so that they would reach E2 and E3. Oh well…....

    BTW, I've removed the Bowden tubes and disconnected all the wires so that the gantries can move independently without damage and can confirm that X and Y work as normal but U and V just use a single motor so move at 45 degrees.

    So what's the chances of a variation of CoreXYUV happening?

    Another thought. Is there way to disable power from two of the motors? If I do M84 then instigate a move, do all motors get re-energised or just those needed for that particular move? I'm think along the lines of mapping just the upper motors to X and Y (3 and 4) then homing the upper axes slowly which will drag the lower gantry along with it via the connected Bowden tubes (or some connecting cords) if the motors aren't powered. Then do M84 to turn off the motors again which will lose the homing status but that won't matter because then I'll remap just the lower motors 0 and 3 and home again, this time it'll be the lower gantry. Then finally map both motors back to each X and Y. Thinking about it, that's unlikely to be practical because it'll rely on the upper gantry staying put once the power is disconnected from the motors, and the Bowden tubes are likely to drag it back.



  • @dc42:

    …......................
    I think you could probably use standard CoreXYUV kinematics to support independent homing of X and U. but not independent homing of Y and V.

    No that doesn't work because X uses both motors but U uses only one motor so moves at 45 degrees.


  • administrators

    It shouldn't be difficult to implement a variation on CoreXYUV that supports 2 independent gantries. But I was hoping to freeze firmware 1.20 very soon.



  • @dc42:

    It shouldn't be difficult to implement a variation on CoreXYUV that supports 2 independent gantries. But I was hoping to freeze firmware 1.20 very soon.

    I can wait. I've lived without it up to now. I won't be upset if you stick to your plans for 1.20 and add this to a later version.

    It'd be nice to be able to make use of the extra switches and wiring that I've put in at some point though. Any idea of time scale? Should I add it to the firmware wish list or will you remember?

    Cheers

    Ian


  • administrators

    OK, I've just implemented it. Will be in the next 1.20 beta, kinematics type 8 in the M669 command. Test it with caution!



  • Wow, that was quick. Thanks David

    I'm going away for a long weekend with 'er in doors tomorrow (spent too many hours on my printer so have to earn more Brownie points) so it'll be Monday before I can test it 🙂



  • David,

    I've just temporarily updated to this to test:

    Firmware Version: 1.20beta10 (2017-11-23)

    (Web Interface Version is 1.19.3)

    With this firmware and M667 set to type8, X and Y both now move at 45 degrees (i.e. using only one motor) for "normal" X Y moves.

    Changes I made to config.g as follows.

    This - M667 S1; Select CoreXY mode
    changed to this - M667 S8 ; Select CoreXYUV mode

    This line added - M574 U1 V1 S1 ; active high switches for when temporary U and V axes are employed during homing

    This - M584 X0:3 Y1:4 Z2 E5:6:7:8:9
    changed to this - M584 X0:3 Y1:4 Z2 U10 V11 E5:6:7:8:9 P3; U and V are additional axes only for homing. Made invisible by using P3

    As mentioned above, doing short X and Y moves results in moves at 45 degrees. Both gantry's do move together though.

    Ian


  • administrators

    It's M669 K8 you need to use, not M667 S8.



  • Oh sorry. Is that as well as M667 S1 or instead of?



  • Well it's making progress but not quite there yet. BTW I tried it both ways (with M667 S1 and instead of) which doesn't seem to make any difference so I'm guess M669 K1 would override M667 S1 if it comes after in the file and that therefore it should be instead of.

    What I have now sort of works but U and V both move 100mm when commanded to move 10mm. They move in the correction directions, both positive and negative - just too far. The web interface displays what it thinks is the correct position. For example, if I start with U=0 the send G1 U10, the web interface will show the U position to be 10 but physically it has moved 100mm.

    I've also discovered that I have to map both U and V axes in order for one or other to move correctly. e.g if I start with M584 X0:3 Y1:4, then do M584 X0 U3 and try to move the U axis, it will move at 45 degrees but if I do M584 X0 U3 Y1 V4 then move the U axis, it will move correctly. I think this is how it has to be but it's making my head hurt trying to work it out.

    Anyway, I can make the U and V directions work so just need the travel distance to be correct (as and when you have time).


  • administrators

    Yes M669 K8 will override M667 S1. All new kinematics that I add use M669.

    Regarding the amount of motion, you will need to add appropriate U and V parameters to the following commands in config.g:

    M92
    M201
    M203
    M208 (both S0 and S1)
    M350
    M556
    M906

    • there may be more that I have forgotten.


  • Ah OK. I just kind of assumed that the re-mapped drives would inherit the other settings but it makes sense that anything which is axis related needs to be defined.



  • Almost there now. All axes moving in the correct directions and distances. I'm now playing around with the homing files and what I'm finding is that once homed, the U axis won't then move. I've done the following through the console:
    M584 X0 U3 Y1 V4
    G91
    G1 X-360 U-360 F3000 S1 ; course home X and U together - This works fine and stops when one or other limit switch is triggered.
    G1 X-360 F3000 S1 ; course home X - This works fine too

    G1 U-360 F3000 S1; course home U - And this also works fine

    What I'd like to do next is move away a few mm then fine home at a slower speed but G1 X10 U10 only moves the X axis. Doing each axis individually, G1 X10 works but G1 U10 does not.

    I can get the axes to move away but only by mapping the drives back to their "normal" values (M584 X0:3 Y1:4) then doing G1 X10. Then I'd have to map them back to X Y U V and do the fine homing, which is tad laborious.

    Axis minima and maxima are defined thus:
    M208 X0 Y0 Z0 U0 V0 S1 ; Set axis minima
    M208 X360 Y364 U360 V364 Z760 S0 ; Set axis maxima
    End stops are configured thus:
    M574 X1 Y1 S1 ; Define active high microswitches
    M574 U1 V1 S1 ; active high switches for when temporary U and V axes are employed during homing the upper XY

    I can't think of anything else that would affect movement after homing. What have I missed? Or is this the way it works with hidden axes i.e once homed they can't then be moved?

    Edit. One other thing which might or might not have a bearing is that I have U and V showing up on DWC as additional axes. Is this normal when I've used P3 to define the number of visible axes in M584? Just for the hell of it, I pressed "Home U" and got an error message to the effect that homeu.g does not exist. That in itself is not a problem because I wouldn't want to home U on it's own but could the absence of a homeu.g file be the reason why I can't move the U axis once it's been homed?


  • administrators

    The first thing I suggest you do is run M208 without parameters to check that the upper U limit really is 360 and not still at 0.

    Which version of DWC are you using? 1.19.3 is current.



  • M208 does indeed show upper limits for U and V as 0. I've played around with config.g and it doesn't seem to matter where in the file I put M208 or if I use separate lines for U and V, the result is the same. However, if I map the drives first using M584, then enter M208 U360, the value "sticks" and I can then move U as normal. Obviously, I can't do this in config.g as the U and V axis are only used temporarily for homing.

    However, I can achieve what I want with my homing files if I add M208 U360 V364 S0 after M584 X0 U3 Y1 V4, which will do me for now but let me know if you make any changes and want me to test.

    DWC is latest (1.19.3). Is the purpose of the P3 parameter simply to hide those additional axes in DWC or is there some additional purpose? If it's simply to hide the axes in DWC, I don't mind the fact that it might be broken and U and V show as additional axes as I can see at a glance that the homing worked for both combinations of XU and YV. Once homing is complete, and the drives are mapped back to just X and Y, any accidental pressing of the movement buttons won't do anything so it's quite benign.

    Edit. The additional U and V axes only appear on DWC when the homing file is run. They don't show when the machine first boots. Of course I realise now that I should be using Pnnn when I re-map the motors using M584 as the first line of my homing file. But I'll just leave as is for reasons stated above.



  • I've also just discovered that the U axis maximum speed (M203) doesn't get applied from config.g when I map the drives to the (temporary) U axis in homex.g. I wanted to increase the first pass homing speed but was hitting a quite slow limit. Putting M208 U50000 at the start of the homing file fixed it, despite this being already set in config.g. It may be that jerk and accelerations are similarly affected but that's not easy to test.


  • administrators

    Ian, you need to use M584 in config.g to create U and V before you use U and V parameters in other commands. Otherwise those U and V parameters in other commands will be ignored. You can use a second M584 command in config.g after the first one to set up the default drive mapping.



  • It already is that way. That is to say, M584 is before all the other commands apart from the axes maxima but I tried putting M208 U360 after M584 in config.g but it didn't help. Unless it's the P3 parameter at the end of M584 that does more then just hide the axes from DWC?


Locked
 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.