#linuxcnc-devel Logs

Feb 26 2024

08:42 AM mozmck: I *think* there is a bug in gantry homing in 2.9. Looks like it only synchronizes the final move, which means the gantry racks when search_vel == latch_vel
08:58 AM mozmck: What it does right now is when the switch on one side is detected, it immediately reverses direction on that side while the other side is still searching for it's switch. So each side is moving in an opposite direction
11:09 AM pcw--home: That's completely wrong, I'm suprized there have not been more complaints
11:10 AM pcw--home: You should never increase the racking
11:54 AM lcnc-relay: <satiowadahc#0> If your gantry is square and has the same motors... shouldn't it just be a given they're fairly close anyways?
11:59 AM pcw--home: I guess it depends on where it was when the motor were energized (and how much self centering the mechanics do when there is no motor torque)
12:20 PM pcw--home is now known as 040AAEAAJ
12:24 PM mozmck: Yes. In looking at the code in homing.c I find that the only move that is synchronized is the final move to home position.
12:27 PM mozmck: I'm just now (finally!) moving our stuff from 2.7 to 2.9, and noticed this problem on a machine initially racked. First side to hit the switch immediately reverses. Distance between active and not active on these switches is considerable so the problem is compounded.
12:29 PM mozmck: I'm working on a fix and will probably make a pull request out of it for others to check.
12:53 PM mozmck: The simple method of fixing this will require that both switches on a gantry are set up the same. i.e. both use index or not
03:25 PM andypugh_: rmu: You commented here about https://github.com/LinuxCNC/linuxcnc/pull/2904/commits/9f82dcec53ba419eaed3289d5fcae5ff09360d07 but you seemed to be talking about double single quotes, not a single double quote?
03:37 PM rmu: hmm. don't know. I probably misinterpreted "lone quotes" as "single quotes"
06:04 PM mozmck: Well, I thought it would be simple....
06:19 PM andypugh_: What?
06:23 PM mozmck: Hi andypugh_: synchronized homing is not really synchronized, and the two sides of a gantry can move in opposite directions while homing.
06:24 PM andypugh_: I think that is true, but they should only be getting better aligned, even if moving in different directions?
06:26 PM mozmck: no, that racks the gantry more. So one side hits it's switch and immediately reverses to move off the switch while the other side is still searching for the switch.
06:26 PM mozmck: If switch throw is large then the racking can be significant.
06:27 PM mozmck: Ideally for each change of direction it waits until all joints are at the same state.
06:45 PM lcnc-relay: <big_kevin420#0> is the bug in 2.8?
06:46 PM mozmck: I don't know for sure - I'm working on 2.9 - but I would assume it hasn't changed from 2.8?
06:49 PM lcnc-relay: <big_kevin420#0> ok, i only ask because theres a ton of guys with printNC on linuxcnc and they are doing it fine
06:49 PM lcnc-relay: <big_kevin420#0> i found where their docs talk about it, but if they are usign 2.8 and the change is in 2.9, was the reason i asked
06:50 PM lcnc-relay: <big_kevin420#0> https://wiki.printnc.info/en/controllers/linuxcnc#q-how-do-you-tell-linuxcnc-that-you-want-your-y-axis-motors-synchronized
07:17 PM mozmck: I'm sure it works, but imo it should never move the joints opposite directions at the same time. The machine I'm testing on has switches with long arms and the distance between switch ON and OFF is something like an inch or more.
07:18 PM Tom_L: that's quite a bit
07:19 PM mozmck: Yeah, they are chinese limit switches and probably need to be replaced, but they made it noticeable.
07:22 PM mozmck: I also ran into a problem where if there was switch bounce and the homing errored out, the position.txt file has to be deleted when you re-start or you get following errors and can't come out of estop.
07:22 PM Tom_L: is the position.txt a 2 motor gantry thing?
07:23 PM Tom_L: i've never come across that
07:24 PM mozmck: position.txt is the file that stores position between runs of linuxcnc
07:24 PM mozmck: So you start up in the position you shutdown.
07:25 PM Tom_L: hmm, i always home mine so i've never noticed
07:25 PM mozmck: Yeah, this only showed up when homing errored out.
07:27 PM mozmck: beacuse the joints were not in the same place I think
07:29 PM Tom_L: maybe i don't have one because i never set a POSITION_FILE= setting
07:30 PM Tom_L: i rely on the G54 offset values
07:31 PM mozmck: Ah yes, that would be different - I use the position file as it can be pretty handy at times.
07:31 PM Tom_L: one never quits learning linuxcnc :)
07:31 PM mozmck: Heh, for sure!
07:32 PM Tom_L: so with that you don't need to home?
07:33 PM Tom_L: that's the way i read the doc anyway
07:41 PM mozmck: I think that can be the case if nothing moved - but I don't remember now when all it's handy.
07:56 PM lcnc-relay: <big_kevin420#0> https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/homing.c#L411
07:58 PM mozmck: Huh, that looks odd
07:59 PM mozmck: Looks like all numbers in a sequence would be forced to negative if any are.
08:00 PM mozmck: So if there are two joints on X and one on Y, and you want Y to home at the same time as X, then all joints will have a synchronized final move.
08:01 PM lcnc-relay: <big_kevin420#0> thats what it looks loike yeah
08:01 PM lcnc-relay: <big_kevin420#0> http://linuxcnc.org/docs/stable/html/config/ini-homing.html#sec:homing-section
08:02 PM lcnc-relay: <big_kevin420#0> does it mean the y1 will stop and y2 will keep moving?
08:04 PM mozmck: It looks like the final move goes to the home position of each joint - so they will all start at the same time and each will stop at it's home position.
08:05 PM mozmck: See line 1250 and forward in homing.c
08:06 PM mozmck: I'm pretty sure the sync_ready() call on line 1298 will not work because the static global sync_now is set to 1 on line 1270 and not reset to 0 anywhere.
08:08 PM mozmck: Also not sure why that second wait for sync is necessary there.
08:10 PM mozmck: Line 411 is a bit strange, because the code everywhere else uses ABS() to get the absolute value - so I don't see why it is needed?
08:11 PM mozmck: It also makes it so the method I was going to use for sync'ing homing of just the gantry will not work.