Home › Forums › TinyG › TinyG Support › Homing without zeroing the position
- This topic has 8 replies, 4 voices, and was last updated 10 years, 9 months ago by alden.
-
AuthorPosts
-
July 15, 2013 at 5:52 pm #4326robgrzMember
Is there a way to run a homing command without resetting the X, Y, or Z value when done?
-Robert
July 15, 2013 at 6:34 pm #4328aldenMemberHomeing always sets zero. But depending on what you are trying to accomplish perhaps there’s another way. You might be able to use the work coordinate systems to set a “non-zero” location. What are you trying to do?
July 15, 2013 at 7:03 pm #4330robgrzMemberWe have a need to position the head somewhere in space (with no absolute position information) and then home back to see where that location was.
For instance:
1) We position the head
2) Zero all axis values
3) Do a homing cycle without no zeroing
4) The X,Y,and Z values should all be equal to the offset of the original position from home. (Actually the negative offset)If this is not supported then we’d be interested in adding it unless there is a technical limitation that would prevent this. I just wanted to make sure we’re not ignoring the obvious.
-Robert
July 16, 2013 at 7:47 am #4333aldenMemberThanks for the explanation. I have a few further questions:
– Is the reason for this operation to “read” the initial head position somehow?
– Is the positioning done using the motors or manually somehow?
– Is the machine already zeroed when you position the head, or is the zero not known? Can it be known?I guess it’s possible to report the machine position immediately prior to the zero reset — in fact, I think a status report will do this for you. What I don;t know is if this is the position AT the zero point, or immediately before it reaches the zero point. I’d have to look at the code to validate this. If this is nto the behavior I’d look into ho to make sure that status reports are always sent with the final axis value. If you are using status reports I recommend using JSON mode and filtered status reports.
Also, are you aware of G28 / G30 behaviors? These might be of help. Of course, the reference point for G28 / G30 resets when you home, so it might not be useful to you.
July 16, 2013 at 11:57 am #4337robgrzMemberIt’s a calibration routine for our machine. The head would be positioned there manually. What we need to find is where that initial position is relative to the home.
Ideally, the thing that I’d like is for the G28 homing routine to work as-is but without that final clearing of the position values.
If I were to try to add another version of G28, maybe G28.4, that did this, are you interested in incorporating it into the main repo? Is there anything in the current G28 code that would make the position information invalid at the end of the G28 routine?
-Robert
July 20, 2013 at 4:40 am #4347JuKuMemberI would much like this too. I would get the initial position of Z in the start of a run, and use homing without reset as a probe for component height on my pick and place build. (The pick-up needle is spring loaded with a sense switch.)
July 22, 2013 at 2:18 pm #4348robgrzMemberI’m going to take a shot at adding it in the next week (I hope). Perhaps Alden will consider adding it to the main distribution.
-Robert
February 19, 2014 at 7:01 pm #5440emMemberAny update on this? Or at least another way to calibrate homing back off. I really just need a way to align my homing switch back off with the fixtures on my table. I could do this if I could align it to 0,0 manually using precise measuring, and then get the machine to “measure to homing switch”, the result of which I can make the back offs.
I was really hoping I could get this from the filtered position feedback but unfortunately the position data is always missing that one last exact position before it gets set to 0.
I tested this by doing
G0 X10
G28.3 X0
G28.2 X0And every time I get something like this:
posx:-14.123
posx:-12.083,vel:494.375
posx:-10.426,vel:266.389
posx:-9.981,vel:11.736
posx:0.000,vel:0.000,coor:1,dist:0,stat:3Really was hoping 10 would be in there, but it seems to be reporting pos after that set to 0 happens. : [
I think what I’m gonna have to do to workaround this, is home first, rapid to something close to what my 0,0, and then come up use some kind of material jig that allows me to precisely measure the remaining difference to true 0 with a micrometer. Since my table is a grid of bolt holes, I can put a bolt in one hole securely, and do some arithmetic given the bolt diameter measured with a micrometer, and the distance between a precise rod in the spindle to the outer edge of the bolt, also with a micrometer.
For people in the future it would be easier for them to be able to manually touch a precise rod in the spindle against an edge and then find the distance to home. It would also minimize the cumulative error by introducing the micrometer’s inaccuracy into the equation.
- This reply was modified 10 years, 9 months ago by em.
February 20, 2014 at 11:29 am #5445aldenMemberWe have implemented straight probe (G38.2), which might be able to solve this problem. It’s currently in test in edge. Take a look and see what you think. It’s not documented yet, so you really have to read the code (cycle_probe.c) and play with it. Sorry about that.
-
AuthorPosts
- You must be logged in to reply to this topic.