CoreXY and handling of axis limits

Hi,
I'm trying to get LinuxCNC 2.7 working with a CoreXY machine, based on some examples scratched up from around the internet (mainly www.doublejumpelectric.com/blog/?tag=linuxcnc and forum.linuxcnc.org/forum/49-basic-config...-h-bot-corexy-system). So far I have succeeded in getting the custom 'corexykins' kinematics module installed, getting motor spin directions vs. physical axis motion directions vs. LinuxCNC-reported axis motion directions (sign) consistent (the latter required updating to 2.7), and homing seems to work.

However, I'm having some trouble with the handling of limits. On machine startup, I am following the procedure of homing the machine, then entering "$" to switch from joint space to world(?) space due to the use of non-trivkins kinematics. The issues I'm having can only be described as "strange":

Jogging the Y axis in the positive direction quickly (at ~+0.3 inches) stops motion and produces an error: "Exceeded negative soft limit on joint 1". However, the axis has physically moved slightly in the positive direction and AXIS likewise reports a positive position. After this error, I can continue to jog any axis in any direction, even beyond their positive and negative limits (and crash the machine).

Attempting a rapid (e.g. G00X0Y0) via the MDI interface fails with one or more errors along the lines of: "Linear move on line 0 would exceed joint n's (positive/negative) limit." However, the move "should" be legal, and the values of n and (positive/negative) are seemingly random. For example, a rapid on ONLY the X axis produces 3 error messages, citing all 3 joints (suggesting Z-axis involvement!), while a rapid on X and Y together only produces one, but it refers to joint 2, which I would expect to correspond to the Z axis. Likewise, attempting to run the default test g-code fails with limit errors.

I suspect it's just a case of my overlooking something stupid in the config file, but I can't find it, and the seemingly random error results aren't pointing me in the right direction so far. Any suggestions welcome!

Config files:

Hmmm. Do the recent published releases, e.g. 2.7.8, include the "joints_axis6" patch mentioned in this year+ old thread?: forum.linuxcnc.org/forum/10-advanced-con...lt-corexy-kinematics
These page (linuxcnc.org/2016/06/27/Joints-Axes-merged/) says it has been in the 'Master' branch since this summer - that plus the upgrade documentation I stumbled on when updating from 2.6 (referencing "major changes" to how joints & axes were handled, and a script to auto-update your .ini/hal files) led me to believe it was officially released, but now I'm not so sure anymore. The fact that some of the limit errors refer to "joints" being negative has me suspicious, as I don't recall entering any joint-specific limits (not that a CoreXY has "joints", at least as LinuxCNC understands them, with their own separate limits anyway!)

In any event, could this be relevant to my issue? Of the very few public references I could find to successful CoreXY/LinuxCNC integrations, this is the only one that mentions "joints_axis6" explicitly, and even there it sounds like the issue was a preview display glitch rather than inability to run the machine - but my issues do seem consistent with the software not understanding (or making wild guesses about) the relationship between axis vs. joint limits.

Re BigJohnT: Attached below, but right now there's not much to see. Currently I just have an 'XY' axis dummied together and stood off the table with wood scraps until I can confirm there is a path forward getting the kinematics working correctly. The Z is actually hooked up to my earlier CNC build on a separate table (not pictured - a MDF and pipe clamp monstrosity) just so LinuxCNC has something to home. I think you're onto something about the kins being bugged; see below.

Re tommylight: Thanks for the tip on clearing offsets. Following these steps (and/or closing and restarting LinuxCNC) seems to have at least changed the behavior a bit, although it hasn't solved the problem. Before and after this, the AXIS Preview/DRO displays are showing all 0s for every position that they show. It is showing "Position: Relative Actual".

Right now, starting from position (0,0,0), I can move the X axis arbitrarily far, or can move both X and Y together (diagonally) to somewhere between (5.0, 5.0) and (6.0, 6.0) without tripping the limit error. However, moving Y by itself from (0,0) is a no-go. I can move to only (0, 0.01) before receiving the "exceeds joint 1's negative limit" error. Note that "0.01" exactly corresponds to the negative limit I have set for the X/Y axes (IIRC this was a workaround for an older version not liking the slight negative travel in the homing sequence). In general, it seems that driving Y to a larger position than X is considered a negative Y position and is disallowed.

I don't know if this is significant, but the current crop of errors (from manual gcode entry, not jogging) is referring to a *joint* limit. A CoreXY doesn't have "joints", at least in the way LinuxCNC understands them (i.e. with their own independent limits), so I'm not sure where it is getting joint-specific limits from in the first place.

Is "2.8" the same as (or shorthand for) "2.7.8"? The latter is the version currently available for download, and what I have installed.

>>> For CoreXY I would expect the joint limits to be the physical motor limits. You might have to set the home switches up somewhat cleverly to make this work, as homing is a joint-centric activity.

For homing, it seems to be working following the method in the last post of this thread (forum.linuxcnc.org/forum/49-basic-config...-h-bot-corexy-system). AFAIK, a CoreXY's motors don't really have motor-specific (joint-specific) limits; they limit when the combined action of the two motors crash the head into a wall (or ideally the home/limit switches!) What we have to tell LinuxCNC to make joint-centric homing work might be another story of course.

Based on the assumption I have a "Joints_Axes" build of some kind, I tried updating the ini/hal files per the instructions at wiki.linuxcnc.org/cgi-bin/wiki.pl?JointAxesBranch ... and succeeded to make things worse. Note, this page makes reference to the year 2013 and version 2.5, so I have no idea if any of it is up-to-date or still valid for (2.8/2.7.8), but I figured it was worth a try since it's the only thing I found suggesting separately-specified limits for joints and axes.

Anyway, I first tried creating [JOINT_x] sections in the .ini file for the corresponding [AXIS_x] and splitting up the entries as specified. I made an un-educated guess that items not specified (e.g. STEPGEN_xxx) should stay put. In the JOINT section for the X/Y axes, I set the negative/positive limits to -99999 and 99999 respectively, since the "joints" really have no limits of their own. The AXIS limits are unchanged and reflect the actual table dimensions.

Anyway, with this configuration, AXIS' "Home All" button changes to "Home Axis", and applies only to the selected axis (er...joint?). But, now homing doesn't actually *do* anything: the position on-screen for the selected axis is immediately changed to "0.000" and gets a homed symbol, but no motors actually move.

Next, I tried making the .hal changes suggested in the same file (basically, change various "axis.n.xxx" pins to "joint.n.xxx"). However, this just causes LinuxCNC to crash on startup with the error: "Pin 'joint.0.motor-pos-cmd' does not exist".

Any ideas?

Aha, that would explain a lot! After installing the "real" 2.8 (not 2.7.8) and a little more tweaking to the config files, I seem to be getting somewhere. Since this version offers to automagically update one's .ini/hal files, I reverted to the ones from before my manual attempt and let it do its thing. The update script defaults to creating joint limits, set equal to the axis limits. This led to the familiar "exceeded xxx limit" errors, but setting the JOINT_0/JOINT_1 (X/Y) limits to (-999999, 999999) seems to have cured it.

With this done, after some brief testing homing appears to still work correctly, AND I can jog X/Y in any legal permutation within the *axis* limits. I'm still getting "joint x following error" halts when running at full speed even after setting fairly lax limits for this, but that's a separate issue and probably down to my not fixing this PC's horrible realtime performance yet.

In case anyone is coming to this thread with the same issue, here are my current config files - maybe a worked example will save someone a bit of time.

Thanks everyone for all of your help!

Hey there. Just to clarify, If I want separate joint and axis configuration in my ini file, I would need to upgrade from 2.7.8 to 2.8, right? Would I then need to change form hm2_5i25 to hm2_pci for my mesa card interface?

Also, would it make sense to keep the RTAI version since that's what I currently have and what works or should I try switching to the new uspace version?