Forum Replies Created
-
AuthorPosts
-
Scubajoel527
Membercmcgrath5035: 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.
Membercmcgrath5035: 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.
MemberThanks 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 mmI’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.
-
AuthorPosts
