G2 non-Cartesian homing

Home › Forums › TinyG › TinyG Support › G2 non-Cartesian homing

Tagged: ,

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • March 11, 2017 at 7:06 am #10306
    Thingomy
    Member

    I am building a device, and will be using non standard geometry. It will be similar to a dual Z gantry system, but I will have hinges and a telescopic section in the middle of the platform connecting the 2 Z axes drives such that the platform can deliberately tilt by up to 30 degrees by driving the motors separately.

    The inverse kinematics for this should be very simple, and I can see how to code this easily; there is a placeholder function in the kinematics source file. I intend to use the A axis as an angle offset from level and Z axis as the height of the center of the platform. Maths requires only 1 call to tan and some addition/subtraction.

    Homing is a problem though, ideally I would like to home it as a basic separately driven dual gantry system (drive both motors, turn of each motor when its separate switch is triggered). It looks like there is no support for that in current code, though I have seen some commented out code for this in cycle_homing file.

    It is also unclear even which switch would connect to which port, there is only 1 z-max port.

    If I’m really desperate I could wire up a tilt switch on the tilting bed, and hack the code to home the A axis first, but this feels a bit messy.

    Does anyone have any advice on how to do dual gantry homing with separate switches for each motor?

    March 11, 2017 at 8:24 am #10307
    cmcgrath5035
    Moderator

    On this Forum tool, search only works at the TinyG level.
    Back up to tinyG and a Search box will appear, search on: cartesian.
    You will find several old items on topics similar to yours, although I don’t recall them addressing homing.

    Also have a look at

    Riley hacking about, in 2011

    I don’t recall how any of those projects worked out in the end.

    You seem to be headed into a very “non-standard” space, both FW and HW, relative to the tinyG design model.
    The HW and FW flexibility of G2 might be better suited to your project.

    March 11, 2017 at 5:56 pm #10309
    Thingomy
    Member

    Thank you for the reply — I will look into these.

    I must admit a certain amount of confusion with respect to the exact definitions of TinyG; G2; G2 core, and exactly what they all run on.

    But, yes, I’m currently working on a due, though I certainly don’t need it’s power, I’m unlikely to ever use a queue depth of more than 1. While I am certainly going non-standard, it’s all fundamentally g-code motion control of a 3d machine. Your tool solves 99% of the usecase out of the box and is an absolute joy to work with.

    March 11, 2017 at 8:19 pm #10310
    cmcgrath5035
    Moderator

    It can be confusing.
    tinyG started as a ‘product’, FW running on an Atmel ATxmega192 in pretty much hard wired fashion. A few folks have coaxed it to compile for other Atmel devices of that class.

    As more hardware options appeared, it became obvious that tinyG was really a FW feature set running on hardware.

    G2 was the original ‘next generation’ tinyG, a superset of the tinyG functionality that took advantage of more powerful, and flexible hardware platforms such as the Due, based on 32 bit Atmel uCs such as the Atmel SAM3X8E.

    G2 now morphs to G2Core, a recognition that there are several hardware implementions, including a DUE, that are viable build (compile) targets.

    Maybe this will help:

  • Author
    Posts
Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.