Unexpected Behavior with Homing

Home Forums TinyG TinyG Support Unexpected Behavior with Homing

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #11333
    Scubajoel527
    Member

    Hello guys, I am new to the forum and to working with the TinyG, but was hoping with your experience you might be familiar with this behavior, or help me determine the cause and fix it.

    I have three limit switches connected to the Xmax, Ymax, and Zmax screw terminals, and wired as normally closed switches. The tinyg is configured so that the min switches for these three axes are disabled and the max switches are set to homing+limit (3). When I run the g28.2×0 command to home the x axis, it moves the axis until it hits the limit switch, backs off from the switch 3mm (per the configuration setting), and then backs off an additional 5mm (zero backoff). I can run this same command for the Y or Z axes and they also home correctly. However, if I run the “combo” command to home all three axes, g28.2X0Y0Z0, the TinyG correctly homes the Z axis first, then correctly homes the X axis, but does not correctly home the Y axis. The Y axis searches for the switch, stops once it presses the switch, backs off the 3mm so that the switch is no longer pressed, and then runs itself directly into the switch until you unplug the system. As an attempted workaround, I attempted to send a g28.2X0 command, wait for the X axis to home, then send the g28.2Y0 command, wait for the Y axis to home, and then send the g28.2Z0 command, but this has the exact same problem. The last axis (in this case the Z axis) searches for the switch, presses it, stops, backs off 3mm, and then runs itself into the switch until the system is unplugged. It seems to be a bug in the firmware since the axes all home correctly on their own (as long as I send g1 move commands between home commands) but do not home correctly when 3 axes are homed in a row with no other functions performed between. Have you seen this issue before? Is there maybe a configuration setting that is wrong?

    #11334
    Zootalaws
    Member

    Why are you homing on max, rather than min?

    Max is for limit, not homing

    • This reply was modified 5 years, 8 months ago by Zootalaws.
    • This reply was modified 5 years, 8 months ago by Zootalaws.
    #11337
    Gaylord
    Member

    It is in the settings, or you are missing steps due to a slight binding at the end of travel or you are getting noise from somewhere. Can I ask what kind of machine this is, the size of the steppers, are the feed screws acme thread or bearing?

    #11339
    Scubajoel527
    Member

    Thanks for the quick replies.

    Zootalaws: I am using max purely for convenience – the system’s hardware was previously setup such that the positive directions for the motors moves the axis towards the motor, and I wanted to mount the limit switches beside the motors. I could rewire the motors and switches to reverse their direction and make them minimums, although it would be a bit of a hassle. This doesn’t seem to me like it would fix the problem, since homing works correctly on every axis when done individually (with move commands between homing commands) and since it is possible to set the maximum limit switches to homing, but if you guys are more familiar with the firmware and this is a non-standard configuration that it was never designed to use, I can rewire it and see if that fixes it.

    Gaylord: The machine is sort of custom – it is based around six openbuilds v-slot linear rails, so I am using two TinyG boards where each one controls three rails. I believe we are using the openbuilds nema 23 stepper motors, and an 8mm acme lead screw. These are how I have the settings set:

    $xsn=0
    $xsx=3
    $ysn=0
    $ysx=3
    $zsn=0
    $zsx=3
    $asn=0
    $asx=0

    [xsn] x switch min 3 [0=off,1=homing,2=limit,3=limit+homing]
    [xsx] x switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
    [xsv] x search velocity 100.000 mm/min
    [xlb] x latch backoff 5.000 mm
    [xzb] x zero backoff 3.000 mm

    I’m not sure what the jerk homing or latch velocity settings are, since I did not change them. It doesn’t seem like it is binding since the axis homes fine except when trying to home all three axes together – and then it is never one particular axis, it is whichever axis is homed last. Maybe there is something wrong in the settings. I will look at this some more later today and hopefully get a better understanding of what specific order of operations results in this problem.

    #11341
    cmcgrath5035
    Moderator

    Give this a careful read https://github.com/synthetos/TinyG/wiki/Homing-and-Limits-Description-and-Operation

    I read it to say Homing is hardwired to to Zmax, X min, Ymin.

    #11342
    Scubajoel527
    Member

    cmcgrath5035: I read that page and I do not believe homing is hardwired to Zmax, Xmin and Ymin, just that these are the most common points to home the machine to – since it is how a 3d printer or milling machine would normally be setup. If you look at the switch configuration section of that page, it looks to me like either of the $xsn and $xsx settings can be set to disabled, limit, homing, or homing+limit. I can confirm that when you program these settings in the TinyG, either min or max can be configured as a limit, homing, or homing+limit switch. Although I agree that they are probably not often used in the configuration in which I am using them.

    I finally got back in the lab today to test this issue a bit more. I read a bug ticket that homing would go in the wrong direction when run a second time without resetting the board, so I thought I would test this out. Resetting the board between homing commands did not solve this problem, and the first time homing was run after powering the device on exhibited the same problem. I did get some more information on the problem though. When running homing, the Z axis homed correctly, the X axis homed correctly, but once the Y axis (normally where the problem occurs) started moving, I depressed the limit switch with my finger, and the motor continued to move toward the switch without stopping. I held the switch pressed for 1-2 seconds while the motor continued to move towards the switch, but as soon as I released the switch, the motor stopped moving, and backed off. I’m not sure why it triggered on the switch release, instead of press, but that’s what happened.

    After seeing this, I rewired the system to use limit switches on Xmin, Ymin, and Zmax since multiple people in this thread suggested that, and it fixed the problem. Homing now appears to work as intended. However, if this is the only supported homing configuration, I think it would help new users to make this more clearly stated, and maybe disable the TinyG options for setting unsupported limit switch configurations (only allow Xmin and Ymin to be set to limit or disabled). On the other hand, if other homing configurations are intended to be supported, then it looks like this might be a bug in the firmware. If there are some instructions somewhere for setting up the board to allow debugging on a computer, I could maybe look into it and see if I can figure out what is going wrong. Thanks everyone for your suggestions, I am happy to have the system working correctly.

    #11343
    cmcgrath5035
    Moderator

    Thanks for the detailed analysis.
    I’ll pass it on to the Devs for comment.

    How exactly did you connect the two tinyGs to the six motors?
    And how do you launch commands to keep them in synch?

    #11346
    JuKu
    Member

    Another thing to look at: The homing algorithm has issues if there is no room for the axis to get up to speed. If your acceleration setting is low and your backoffs are small, and you have already homed an axis, when you try homing again and hit the switch when the machine is still in the acceleration phase, it misbehaves.

    #11347
    Scubajoel527
    Member

    cmcgrath5035: sorry I am just now getting back to you. Each tinyG is connected to three of DQ542MA stepper motor drivers, which in turn are connected to the three motors. I am naturally using the motor 1, motor 2, and motor 3 ports on the tinyG board. The machine I am controlling is a bit odd – it is an RF material characterization machine, so if you can imagine three arms connected to a rod at the center of a circle, with carts that can move closer to the circle’s center or further out from it. Each cart also has a rail protruding up from it with a 2nd cart, and mounted on that cart is an antenna, for a total of 6 motors/carts.

    I send commands to the tinyG’s from simple terminal line for manual control, of I use a labview program I am writing to automate some processes and allow anyone to use the machine as needed. Keeping the two tinyG’s in synch is not a concern because of the machines layout – it isn’t like a cnc machine where you might want to make a circular cut and have the two boards working together to perform it. But even so, to simplify the labview code I am writing, I only perform one move/home command from one board at a time, so only one motor is moving at a time. For this application, I am mainly just concerned with keeping tight tolerances on the antenna positions to reduce errors in my measurements.

    JuKu: Thanks for the tip. I haven’t changed the acceleration settings from the default, and my search velocity is very low right now, but I probably will increase the velocity when I finish programming to make the machine run a bit quicker. I will keep that in mind and make sure the values I select do not cause this problem.

    #11351
    cmcgrath5035
    Moderator

    OK, this description helps a bit.

    You might want to review G2Core, the next generation of tinyG capability will a lot of 3D Printing enhancements.
    It can simultaneously output motion on 6 axis to external drivers, the six from a menu of up to 6 axis of linear motion and 3 rotational.
    Have a look here https://github.com/synthetos/g2/wiki

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