Back
[01:50:13] <KGB-linuxcnc> 03Sebastian Kuzminsky 05ja9-docs 0b77623 06linuxcnc 10docs/src/code/code-notes.txt docs: add code notes about joints and axes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0b77623
[01:50:25] <seb_kuzminsky> does that look less wrong?
[01:51:51] <seb_kuzminsky> maybe we should un-deprecate .axes, and deprecate .axis_mask, and put a .present flag in the .axis[n] struct
[01:52:17] <seb_kuzminsky> good night...
[07:31:10] <jepler> deprecating axis_mask feels like unnecessary churn to me. but your suggestion makes sense too.
[07:32:58] <jepler> seb_kuzminsky: [AXIS]HOME probably should have moved to [JOINT].
[07:34:00] <jepler> but you're right, a (new) [AXIS]FOO number is less ambiguous than [TRAJ]HOME as a series of values when you have missing axis letters etc
[07:38:22] <REEEN> Hello guys :)
[07:38:44] <REEEN> again I have a question to the developers of you
[07:41:59] <REEEN> I have a 5 Axis machine, for simultaneous milling, the b axis can be locked, but using the b axis as locked rotary will disable simultaneous 5 axis milling
[07:42:41] <REEEN> I want to lock the b axis if I don't need it so I made an mcommand to do that
[07:43:12] <REEEN> the problem is that sometimes I forget to unlock the axis before using it....
[07:43:29] <REEEN> is it somehow possible to inhibit a axis ?
[07:44:34] <REEEN> I have also written a mcode to lock the z-axis this will improve my surface quality on older machines
[07:44:47] <REEEN> same problem here...
[08:06:45] <jepler> no, I don't think linuxcnc currently fits those needs. without writing "C" code all you have are hacks and tricks.
[08:07:24] <jepler> the interpreter would need new codes to lock and unlock axes, and track those locks internally. I have no idea if there are any established codes used for this purpose in other software.
[08:09:09] <jepler> afk
[08:14:18] <REEEN> Thanks for the Information, I think the motion component is the target for any hacks
[08:19:33] <REEEN> I found this in the ini :
[08:19:37] <REEEN> ini.n.max_velocity
[08:19:53] <REEEN> sorry I mean I found it in the documentation
[08:20:17] <REEEN> maybe i can set ini.n.max_velocity to 0 ??
[08:24:33] <seb_kuzminsky> jepler: currently both [JOINT] and [AXIS] have HOME
[08:27:09] <REEEN> yeah wow this really works but I have to be in man mode
[08:30:13] <cradek> previously, [AXIS_n]HOME was the joint home position, and [TRAJ]HOME was the list of axis home positions
[08:30:42] <cradek> I agree using [JOINT_n]HOME and [AXIS_n]HOME in the brave new world seems like the way to go
[08:38:23] <jepler> all the relevant information's probably here, but who in the world takes a *perspective* 3d rendering and then plasters dimensions on it?
http://jtechphotonics.com/wp-content/uploads/2013/05/J-Tech-Photonics-Laser-Diode-Component-and-Mount-dimensions-full.pdf
[08:39:00] <jepler> it would also be nice if they'd called out the hole distance center-to-center
[08:39:43] <cradek> wow, I've never seen a hole radius dimensioned before
[08:40:06] <jepler> yeah what screw do you use for a 1.7 mm radius hole anyway
[08:40:19] <cradek> #4 probably
[08:40:38] <cradek> eh, you'd just dig in the baby-food jar until you found one that fit
[08:43:09] <jepler> I assume the intended answer is M3, 3.4mm is the clearance hole diameter according to the first table I found
[08:44:32] <cradek> ok #5-40 then (probably as rare around here as M3)
[08:45:26] <jepler> it's ~4% over the free fit for a #4 (.129 vs .134) so you'd probably be fine
[08:46:27] <jepler> or in this case I'd probably be fine
[09:03:37] <REEEN> I found out how an axis can be blocked for motion, simply set ini.n.min_limit and ini.n.max_limit to the current position and the axis now won't move anymore and there will also be no following error and no estop
[09:04:18] <REEEN> Thanks to the developer who made this new pins available :)
[09:13:47] <cradek> that's extremely surprising
[09:46:30] <jepler> I had forgotten how large the INPUT_SCALE is on zenbot. 74666.67/in ~= 2940/mm
[09:47:01] <jepler> quadrature rate ~180kHz at top speed
[09:48:40] <cradek> wow
[09:49:43] <cradek> heh the HNC is INPUT_SCALE 204800
[09:52:27] <cradek> MAX_VELOCITY = 3.33334
[09:52:55] <ssi> yeah there's a LOT of "counts" on those resolvers
[09:56:16] <jepler> that's 683kHz
[09:56:30] <jepler> those are actually coming into a mesa card as quadrature, right?
[09:56:45] <cradek> yep
[09:56:59] <ssi> in my case, no
[09:57:31] <ssi> the resolvers are driven and sampled by a mesa 7i49 resolver counter, and I think the 7i49 reports it back as a number, not as quadrature
[09:57:45] <cradek> yeah mine are converted to quadrature
[09:57:53] <cradek> it's from the before times
[09:57:55] <ssi> heheh
[09:57:59] <ssi> using pico converters?
[09:58:01] <cradek> yes
[10:07:09] <skunkworks> The K&T is only around 60,000 counts..
[11:35:01] <mozmck> Interesting comment at the end of this post:
http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-October/002445.html
[12:26:49] <mozmck> Hmm, in
http://www.linuxcnc.org/docs/2.7/html/remap/remap.html#remap:referto-inifile-variables
[12:27:05] <mozmck> it says, "this section doesn’t really belong here but since it comes with the same branch, here it rests for now until its clear this will be merged. It should go into the gcode/overview Named Parameters section."
[12:29:06] <seb_kuzminsky> aah yes, the remap docs
[12:30:02] <mozmck> Same with the section below on HAL items.
[12:30:35] <jepler> I have to speculate about why the author thought it made sense to do that
[12:33:31] <seb_kuzminsky> that whole file needs some serious editing
[12:33:51] <seb_kuzminsky> a bug report for M61 and build dependency information for lucid, really?
[12:38:30] <seb_kuzminsky> the "Models of Task execution" section is an edifying read
[12:38:48] <seb_kuzminsky> http://www.linuxcnc.org/docs/2.7/html/remap/remap.html#remap:referto-inifile-variables
[12:38:56] <seb_kuzminsky> http://www.linuxcnc.org/docs/2.7/html/remap/remap.html#_models_of_task_execution
[12:39:50] * JT-Shop runs and hides from the remap docs lol
[12:42:05] <mozmck> fooey
[12:45:58] <JT-Shop> every time I look at remap.txt I get lost
[13:12:48] <mozmck> I don't understand the o100 id [EXISTS] notation - why the o100?
[13:15:45] <mozmck> if [EXISTS] that is...
[13:18:16] <archivist> if exists is a thing one sees in some database language, horrible imo
[13:19:45] <mozmck> Not sure why it would be horrible
http://www.linuxcnc.org/docs/2.7/html/gcode/overview.html#sub:functions
[13:20:10] <mozmck> it uses o10 in that sample, but no explanation.
[13:21:55] <mozmck> huh, looks like the if block is a different O code? how strange. could you call just the if block in a subroutine?
[13:23:39] <archivist> just some set of oXX line numbers to tie the three lines together in the absence of {} constructs like other languages
[13:24:52] <mozmck> interesting. I suppose you can't use that o number anywhere else in the same code then, or is it only valid for the scope of the subroutine?
[13:26:39] <JT-Shop> yea, you need a different o for each if
[13:39:00] <jepler> you could imagine a different design which did without numbers for all the o-constructs but sub and call, but that's not the implementation we got
[13:47:13] <andypugh> I can’t think of any other language which requires the programmer to explicitly pair the block start and end.
[13:48:06] <andypugh> Though sometimes I wish that C did, as when (at work) I get 20 pages of auto-coded C as 2 columns of PDF I find it impossible to pair braces by indentation…
[13:49:28] <archivist> I use an editor to pair for me
[13:51:40] <andypugh> archivist: That’s why I mentioned that I get the code as PDF..
[13:52:51] <archivist> reject anything in pdf form
[13:53:33] <archivist> it is an insult to send out stuff in that unusable form
[14:08:15] <andypugh> Yes, but try telling that to my work colleagues, who send me it.
[14:10:13] <PCW> Obviously the wrong thing for a source listing but what file type would you use for fixed format documents other than PDF?
[14:10:37] <cradek> 7 bit ascii text
[14:10:43] <cradek> (whenever possible)
[14:10:49] <andypugh> Especially as other sections of the documentation pack are Simulink diagrams
[14:23:05] <cradek> uh-oh bug 448 looks serious
[14:29:28] <andypugh> Hmm, that does look like an actual bug for a change
[14:33:53] <cradek> (I haven't tried it)
[14:40:59] <jepler> http://paste.ubuntu.com/12887801/ (LINUXCNC - 2.8.0~pre1-ja)
[14:41:40] <jepler> 9 N..... STRAIGHT_TRAVERSE(0.0000, 0.0000, 2.0000, 0.0000, 0.0000, 0.0000)
[14:41:40] <cradek> ouch
[14:41:43] <jepler> 10 N..... SET_MOTION_CONTROL_MODE(CANON_EXACT_PATH)
[14:41:45] <jepler> 11 N..... STRAIGHT_TRAVERSE(3.0000, 3.0000, 0.0000, 0.0000, 0.0000, 0.0000)
[14:43:21] <seb_kuzminsky> drilling upside down? weird
[14:44:27] <cradek> seems like 2.6 does the same
[14:44:29] <jepler> I get the same thing on LINUXCNC - 2.6.10
[14:44:41] <skunkworks> phew
[14:45:08] <skunkworks> I don't what to yell at rob again..
[14:45:19] <jepler> I guess that's a bright side
[14:45:28] <skunkworks> ;)
[14:45:40] <cradek> also 2.5
[14:46:24] <jepler> now we'll find out just how old a version cradek is interesting in building
[14:46:31] <andypugh> What is the oldest system you can try it on?
[14:47:30] <cradek> READ => g81x3y3z1r2
[14:47:30] <cradek> 8 N..... STRAIGHT_TRAVERSE(0.0000, 0.0000, 2.0000, 0.0000, 0.0000, 0.0000)
[14:47:33] <cradek> 9 N..... SET_MOTION_CONTROL_MODE(CANON_EXACT_PATH)
[14:47:35] <cradek> 10 N..... STRAIGHT_TRAVERSE(3.0000, 3.0000, 2.0000, 0.0000, 0.0000, 0.0000)
[14:47:41] <cradek> umm 2.4 does it right
[14:47:44] <cradek> sigh
[14:47:53] <jepler> so you can even bisect it if you want to blame somebody
[14:47:58] <cradek> oh it'll be me
[14:48:01] <jepler> hah
[14:48:06] <cradek> it'll be uvw cycles or polar
[14:48:16] <jepler> seeing what commit introduced it could still be helpful
[14:48:25] <cradek> I need a drink
[14:51:43] <cradek> (I'm bisecting)
[14:52:21] <cradek> argh, a bunch of these don't build
[14:52:27] <jepler> boo
[14:52:41] <jepler> I know a guy who takes a really hard line on that sort of thing
[14:53:05] <cradek> he sounds right
[14:55:10] <cradek> oh just adding -lm fixes it, yay
[14:55:17] <andypugh> I wonder how many commits there are, and hence the maximum number of trials needed for a bisect?
[14:55:29] <cradek> 6 (successful) trials
[14:57:23] <jepler> $ git rev-list origin/v2.4_branch...origin/v2.5_branch | wc -l
[14:57:23] <jepler> 3438
[14:57:39] <cradek> Bisecting: 1 revision left to test after this (roughly 1 step)
[14:57:39] <cradek> [e9d24671e482dc3f2dc794436a90544a6eb436cf] Fix g83 peck retract to match fanuc
[14:57:43] <cradek> siiiiiiigh
[14:57:48] <cradek> any guesses?
[14:58:01] <jepler> ummm
[14:58:06] <andypugh> I guess Fanuc was broken and we chose to copy it?
[14:58:07] <jepler> remap?
[14:58:29] <cradek> Bisecting: 0 revisions left to test after this (roughly 0 steps)
[14:58:29] <cradek> [df5a469d702a0f2023dd5a74f331af235b2c0abf] Fix g98/g99 to match fanuc retract planes behavior
[14:58:32] <cradek> jepler: haha
[14:58:37] <cradek> jepler: I appreciate that, though
[14:59:11] <cradek> df5a469d702a0f2023dd5a74f331af235b2c0abf is the first bad commit
[14:59:32] <andypugh> And the description fits
[14:59:40] <cradek> wow that's a lovely log message, though
[14:59:42] <andypugh> The quest is, bug or feature?
[15:01:01] <cradek> and now this [g98 retract] is changed to mean "to the position that axis was in just before this series of one or more contiguous canned cycles was started"
[15:01:39] <cradek> so ..... maybe it was on purpose
[15:01:52] <cradek> I wonder what reference I was using
[15:02:03] <cradek> if this was because of a bug report I didn't put the number in the message
[15:02:59] <cradek> > Program a G98 and the canned cycle will use the Z position prior to the canned cycle as the Z return position if it is higher than the R value specified in the cycle. If it is lower, the R value will be used.
[15:03:23] <cradek> doesn't match the docs (which seem more sane than what the code is doing)
[15:10:18] <cradek> 5 years 3 months from writing a bug to a user finding it
[15:10:30] <cradek> software is amazing
[15:12:21] <skunkworks> heh
[15:14:30] <seb_kuzminsky> it's a bizarre use of g81, i'm not surprised it went untested for so long
[15:18:37] <cradek> yeah it's a little surprising
[15:19:01] <cradek> but pretty sure we should be doing "use the higher of R and initial" for g98 like the docs say
[15:44:02] <seb_kuzminsky> cradek: i agree, the g98 documentation sounds like the safer behavior
[15:46:39] <cradek> Eric's bug report is extremely great
[15:47:40] <cradek> looks like his gcode cuts down to a feature and then commands the drill cycle while it's still at the bottom of that feature
[15:52:28] <seb_kuzminsky> do you want me to add sai test(s) for this? or do you have it in hand?
[15:52:39] <cradek> I am not working on fixing it right now
[15:53:01] <cradek> it would be lovely if you'd make tests for the retract modes (and even better if you test all the planes)
[15:53:27] <cradek> pretty sure the fix will be a one-liner (in six places)
[15:53:35] <seb_kuzminsky> heh yeah
[15:53:42] <seb_kuzminsky> ok, will do
[15:53:46] <cradek> sweet
[15:54:22] <cradek> I'm still basking in how good a bug report that is
[15:54:55] <cradek> the only thing that would have made it better is a patch
[15:55:01] <cradek> :-)
[16:17:43] <jepler> we should have a policy where, if you send a high quality bug report, we send you the replacement cost of your broken tool up to a certain limit
[16:17:59] <jepler> (and you're the first reporter)
[16:18:06] <jepler> if you fix it we'll send you two replacements
[16:18:20] <seb_kuzminsky> in 2.4, drilling upwards is rejected
[16:18:36] <cradek> how about this instead: if you send a great bug report we probably won't just ignore it
[16:19:08] <seb_kuzminsky> if Z > OLD_Z, it emits the misleading error message "R less than z in cycle in xy plane
[16:28:12] <seb_kuzminsky> nevermind, i goofed
[16:28:27] <seb_kuzminsky> the error message is correct
[16:28:57] <seb_kuzminsky> 2.4 accepts Z > OLD_Z, but rejects Z > R (G98)
[16:45:27] <skunkworks> zlog:
[16:50:02] <jepler> huh, I didn't know about "crt.sh", which lets you see all issued (TLS) certificates made by participating issuers. e.g.,
https://crt.sh/?cn=www.unpythonic.net&iCAID=97
[16:51:30] <jepler> which was how I learned that there is a
https://usr.bin.coffee/ -- one of the early domains with a certificate issued by letsencrypt.org
[16:51:47] <jepler> .. and which is not trusted in my browser on wheezy. odd, they were recently proclaiming that they were trusted in all major browsers now
[17:09:12] <mozmck> does reading a hal pin in a gcode routine work? I have an o routine and I'm calling it from mdi and it tells me: "Named parameter #<_hal[gscreen.loadmat_z-f]> not defined"
[17:14:37] <jepler> as far as I know we have no tests verifying the proper functioning of that code
[17:14:45] <jepler> so it would not be surprising if it could break unnoticed
[17:15:29] <seb_kuzminsky> sai is 6 axis only, so can't test the UVW planes
[17:31:21] <mozmck> Hmm, it does the same thing with an #<_ini[]> parameter
[17:31:24] <jepler> who is "pkm"?
[17:31:39] <jepler> his remarks about home symbols are interesting and included a case I hadn't thought of
[17:32:01] <jepler> but that case is for a nontrivial machine in which case I don't care about the per-axis-letter home symbols as much
[17:35:53] <mozmck> Oh, looks like I need to set the FEATURES = <mask> under [RS274NGC]
[17:40:29] <micges> mozmck: what version are you using?
[17:40:43] <mozmck> 2.7
[17:41:05] <micges> those hal and ini variables looks usefull
[17:41:16] <mozmck> Yes, if I can get them to work!
[17:41:40] <mozmck> I set the FEATURES mask to 272, but it didn't seem to help
[17:42:05] <andypugh> mozmck: 272 is wrong. Try 12
[17:43:03] <andypugh> http://www.linuxcnc.org/docs/html/remap/remap.html#_optional_interpreter_features_ini_file_configuration
[17:43:32] <mozmck> oh, I was thinking those were bit numbers - i.e. set bit number 4 and 8
[17:45:18] <mozmck> that worked! thanks andypugh
[17:45:55] <andypugh> Bear in mind that the values don’t necessarily update “live”
[17:51:51] <mozmck> Yes. I have floating Z on a plasma table. I can set HOME_OFFSET in the ini file and now use that in a probe routine as well.
[17:52:43] <mozmck> the hal pins are for setting some values in the GUI to be used in gcode.
[17:57:30] <seb_kuzminsky> looks like #448 applies to many (all?) canned cycles
[18:20:17] <seb_kuzminsky> and the obvious fix fixes them all, just like cradek said
[18:21:35] <KGB-linuxcnc> 03Dewey Garrett 052.7 74173eb 06linuxcnc 10configs/sim/axis/classicladder/demo_sim_cl.ini demo_sim_cl.ini: make homing work * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=74173eb
[18:21:36] <KGB-linuxcnc> 03Dewey Garrett 052.7 051c761 06linuxcnc 10configs/sim/axis/halui_pyvcp/halui.ini halui.ini: make homing work * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=051c761
[18:36:47] <jepler> dgarr: thank you for your recent work, those configs need someone to look after them
[19:24:19] <cradek> seb_kuzminsky: you fixed it already?
[19:26:37] <cradek> > We're sorry -- the Sourceforge site is currently in Disaster Recovery mode
[19:27:59] <cradek> The sourceforge.net website is temporarily in static offline mode.
[19:28:01] <cradek> Only a very limited set of project pages are available until the main website returns to service.
[19:33:28] <jepler> oops
[20:29:26] <seb_kuzminsky> cradek: i think i got it fixed but i gotta clean it up and get it reviewed
[20:30:05] <cradek> yay, thanks for working on it
[21:14:17] <KGB-linuxcnc> 05dgarr/ja_configs 11e047f 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=11e047f
[21:14:37] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs 210cdb1 06linuxcnc 10(8 files) hallib: use [KINS]JOINTS (not [TRAJ]AXES) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=210cdb1
[21:14:37] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs 94eded6 06linuxcnc 10(6 files) sim/axis/ngcgui fix helper file names * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=94eded6
[21:14:38] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs c88f2c7 06linuxcnc 10(8 files in 7 dirs) sim configs add dummy joint_1 for lathes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c88f2c7
[21:14:38] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs 3307430 06linuxcnc 10(64 files in 28 dirs) sim/axis configs use [KINS]JOINTS (not [TRAJ]AXES) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3307430
[21:14:42] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs 441f576 06linuxcnc 10configs/sim/pyvcp_demo/pyvcp_demo1.ini sim/pyvcp_demo/ use [KINS]JOINTS (not [TRAJ]AXES) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=441f576
[21:14:49] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs bcef202 06linuxcnc 10(7 files in 3 dirs) sim/touchy/ use [KINS]JOINTS (not [TRAJ]AXES) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bcef202
[21:14:52] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs fd60b0d 06linuxcnc 10configs/sim/tklinuxcnc/servo_sim.ini 10configs/sim/tklinuxcnc/tklinuxcnc.ini 10configs/sim/tklinuxcnc/tripod.ini 10tcl/tklinuxcnc.tcl sim/tklinuxcnc/ use [KINS]JOINTS (not [TRAJ]AXES) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fd60b0d
[21:14:57] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs b75b88f 06linuxcnc 10configs/sim/low_graphics/keystick.ini 10configs/sim/low_graphics/xlinuxcnc.ini low_graphics/(partial) [KINS]JOINTS(not[TRAJ]AXES) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b75b88f
[21:15:02] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs 3cd4c60 06linuxcnc 10(12 files in 3 dirs) sim/gscreen use [KINS]JOINTS (not [TRAJ]AXES) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3cd4c60
[21:15:05] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/ja9_configs 8f79131 06linuxcnc 10(12 files in 2 dirs) sim/gmoccapy/ use [KINS]JOINTS (not [TRAJ]AXES) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8f79131
[21:15:45] <seb_kuzminsky> dgarr: thanks for working on all those configs, it helps a lot
[21:16:58] <seb_kuzminsky> feel free to push directly to the joints_axes9 branch if you feel confident about the commits and don't need a review/feedback
[21:17:37] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.4-bug-448 0a7f54f 06linuxcnc 10(18 files in 6 dirs) tests: add an interpreter test of G81 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0a7f54f
[21:17:54] <seb_kuzminsky> cradek: there are the new tests that highlight the #448 bug
[21:18:18] <seb_kuzminsky> it runs g81 in all 6 combinations of {g98,g99} x {g17,g18,g19}
[21:18:50] <seb_kuzminsky> i can't test g1{7,8,9}.1 because sai doesn't do UVW, but the pattern in the failure is simple enough
[21:23:51] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.5-bug-448 6dbe449 06linuxcnc Merge branch '2.4-bug-448' into 2.5-bug-448 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6dbe449
[21:23:51] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.5-bug-448 fbdb686 06linuxcnc 10(6 files in 6 dirs) update g81 tests for new init/shutdown Canon calls in 2.5 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fbdb686
[21:23:51] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.5-bug-448 a561cf2 06linuxcnc 10src/emc/rs274ngc/interp_cycles.cc fix canned cycles where old Z is below retract plane * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a561cf2
[21:24:11] <seb_kuzminsky> there's the proposed fix
[21:24:33] <seb_kuzminsky> i would appreciate a review on the test itself in 2.4, and the fix in 2.5
[21:27:40] <seb_kuzminsky> also (jepler & cradek & anyone else with a dog in this race), does ja9-docs describe your understanding of the reckoning of joints & axes in ja?
[21:31:32] <jepler> seb_kuzminsky: I glanced this morning and didn't see anything wrong in your changes to that documentation
[21:31:38] <jepler> would appreciate micges comments too
[21:42:04] <seb_kuzminsky> and alex_joni maybe?
[21:55:01] <jepler> sure if he drops in and sees his name
[22:08:04] <linuxcnc-build_> build #1733 of 1405.rip-wheezy-armhf is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1733 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:14:11] <linuxcnc-build_> build #698 of 1903.clang-wheezy-amd64 is complete: Failure [4failed install-missing-build-dependencies compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1903.clang-wheezy-amd64/builds/698 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:17:38] <jepler> something is confused by such an old branch?
[22:17:42] <seb_kuzminsky> yeah
[22:17:52] <jepler> in that case goodnight
[22:18:11] <seb_kuzminsky> 2.4 was forever ago
[22:21:35] <linuxcnc-build_> build #698 of 1902.clang-wheezy-rtai-i386 is complete: Failure [4failed install-missing-build-dependencies compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1902.clang-wheezy-rtai-i386/builds/698 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[22:46:32] <linuxcnc-build_> build #2753 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2753 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:12:20] <linuxcnc-build_> build #1705 of 1403.rip-wheezy-amd64 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1705 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:14:28] <linuxcnc-build_> build #1896 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1896 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:15:28] <linuxcnc-build_> build #1704 of 1400.rip-wheezy-i386 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1704 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:17:04] <linuxcnc-build_> build #1215 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/1215 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:30:29] <linuxcnc-build_> build #1368 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1368 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:32:16] <linuxcnc-build_> build #172 of 1502.rip-jessie-amd64 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1502.rip-jessie-amd64/builds/172 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:34:03] <linuxcnc-build_> build #172 of 1503.rip-jessie-rtpreempt-amd64 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1503.rip-jessie-rtpreempt-amd64/builds/172 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:34:55] <linuxcnc-build_> build #172 of 1500.rip-jessie-i386 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/172 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:35:44] <linuxcnc-build_> build #172 of 1501.rip-jessie-rtpreempt-i386 is complete: Failure [4failed install-missing-build-dependencies configuring] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1501.rip-jessie-rtpreempt-i386/builds/172 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[23:35:44] <linuxcnc-build_> build #3557 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3557 blamelist: Sebastian Kuzminsky <seb@highlab.com>