Back
[00:09:38] ChanServ changed topic of
#linuxcnc-devel to:
http://linuxcnc.org | Latest release: 2.6.0
[00:12:34] <seb_kuzminsky> Get:3
http://linuxcnc.org/ precise/2.6-sim linuxcnc-doc-en all 1:2.6.0 [10.7 MB]
[06:19:36] <skunkworks> jepler, master has been running a day so far with no issues. (both 7i80 and 5i25)
[07:48:31] <cradek> yay!! thanks seb!
[07:51:01] <skunkworks> now what?
[07:51:49] <skunkworks> Is the new tp in 2.6?
[07:52:00] <skunkworks> (sorry)
[08:17:48] <jepler> now we get 2.7 ready!
[09:43:40] <cradek> the wheezy image in the usual place is updated with 2.6.0 etc
[09:44:15] <cradek> seb_kuzminsky: thanks for doing the release, this is great.
[09:45:45] <cradek> (whoops, I guess I lost the change of the Z positive limit on sim/axis)
[09:50:26] <jepler> if only that would turn out to be the worst bug in 2.6, we could retire.
[10:11:23] <cradek> seems I had it on timeguy/proposed, which seb rebased. he must've not fetched it.
[10:14:34] <cradek> seb_kuzminsky:
http://timeguy.com/gitweb?p=linuxcnc.git;a=log;h=refs/heads/proposed
[10:18:50] <ssi> so what does the new TP do better than the old?
[10:19:17] <cradek> programs made up of lots of very short segments
[10:19:23] <cradek> it can run them faster
[10:19:31] <ssi> CV mode essentially?
[10:19:34] <ssi> as opposed to exact stop?
[10:19:39] <cradek> as long as they are only in xyz
[10:19:42] <ssi> gotcha
[10:20:12] <cradek> we have always had "CV" but the V can be higher for these kinds of programs with the new planner
[10:20:23] <ssi> ok
[10:20:29] <ssi> is it a lookahead thing?
[10:20:30] <cradek> I don't know where the idea of "CV" vs not "CV" came from
[10:22:35] <ssi> I feel like years ago I read that linuxcnc didn't have anything but an exact stop planner
[10:22:45] <cradek> that has never been the case
[10:22:54] <ssi> yeah I may be misremembering, or misunderstood at the time
[10:23:32] <cradek> we have always had blending, way back to the first days of emc1 in the 90s
[10:26:04] <skunkworks_> in effect linuxcnc went from a look ahead of 1 to a look ahead of X
[10:26:34] <cradek> but that's not true either. we blend many moves together with the NCD
[10:26:56] <pcw_home> If i understand it correctly, the old planner limited velocity so that it could
[10:26:58] <pcw_home> always do an exact stop at the end of the current move
[10:27:25] <ssi> pcw_home: yeah that's what I remember hearing
[10:27:28] <skunkworks_> pcw_home, I think *next move...
[10:27:42] <skunkworks_> but cradek would probably have a better handle on that.
[10:27:48] <pcw_home> (which might some NCD merged segments)
[10:28:17] <cradek> I don't think you can make it any simpler than: some kinds of programs made up of very short segments can now run faster.
[10:28:29] <pcw_home> :-)
[10:28:52] <cradek> questions like Is it lookahead? Is it CV? do not make it clearer, and they may validate mistaken assumptions
[10:31:08] <ssi> understandable, but "some kind of programs made up of very short segments can now run faster" is couched in very vague, CYA terms
[10:31:19] <ssi> "sometimes maybe this will be inexplicably and imperceptibly better possibly"
[10:31:22] <cradek> heh
[10:31:31] <cradek> but it's true because it's complicated
[10:32:16] <cradek> it's certainly not inexplicable or imperceptible
[10:32:40] <cradek> but it doesn't speed up all programs made of short segments, and it doesn't speed up any programs made up of long segments
[10:32:55] * cradek shrugs
[10:34:03] <cradek> I suspect most people won't notice it (unless there are new bugs) but some people who use cam to make auto-generated gcode made up of very short moves will notice their programs run faster.
[10:34:15] <ssi> can I make an assumption that it works better on short segments that are closer to colinear, obtuse angles, and not as well on short segments with more acute angles between them?
[10:34:59] <cradek> I don't think so, no
[10:35:03] <ssi> ok
[10:35:08] <ssi> I'll kindly shut up then
[10:35:15] <cradek> instead, go try it :-)
[10:36:11] <skunkworks_> it tries to go as fast as it can with the machine constraints/tolerence selected.. (while blending segements with arcs)
[10:36:21] <skunkworks_> :)
[10:36:46] <cradek> yes it's true the blends (for xyz only moves) are a different shape now
[10:36:54] <cradek> they're now circular
[10:37:23] <cradek> but you'd probably never notice that
[10:40:06] <ssi> and ja5 has the new TP, but ja4 doesn't?
[10:42:13] <skunkworks_> rob gave a nice talk on what he did in the planner..
[10:42:23] <skunkworks_> ssi, did you see that?
[10:42:26] <ssi> no
[10:44:33] <skunkworks_> https://www.youtube.com/watch?v=4ObCqXilbrA
[10:44:58] <skunkworks_> oops no
[10:45:56] <skunkworks_> ^ that was machinekit infrastruction by john
[10:46:04] <skunkworks_> here
https://www.youtube.com/watch?v=412N5A-N8Fc
[10:46:08] <ssi> yeah I've been wanting to watch the machinekit tasks
[10:46:09] <ssi> talks
[10:47:26] <seb_kuzminsky> cradek: oh yeah, i remember we talked about that splash screen patch
[10:48:02] <pcw_home> Heres a puzzler: someone on the forum has endless trouble with ini/hal file parsing specifically
[10:48:04] <pcw_home> loadrt [HOSTMOT2](DRIVER) config=[HOSTMOT2](CONFIG) part
[10:48:05] <pcw_home> He says the parens and not mentioned in the docs and maybe cause a problem but the
[10:48:07] <pcw_home> hm2-servo .hal and hm2-stepper.hal example files have always had them and I've never seen a problem
[10:48:25] <skunkworks_> dos line endings?
[10:48:29] <pcw_home> parens are not mentioned
[10:48:45] <pcw_home> he says no
[10:48:55] <pcw_home> only edited with gedit
[10:50:23] <ssi> skunkworks_: thanks, this is good
[10:50:35] <seb_kuzminsky> cradek: when i fetched proposed from timeguy.com i got 0aa1630, which does not include the splash patch
[10:51:01] <seb_kuzminsky> (when i fetched just now i got 3ce952d, which does include it)
[10:51:16] <cradek> seb_kuzminsky: the evidence was gone, because when I saw you took those changes I deleted the branch (day or two ago)
[10:51:25] <cradek> seb_kuzminsky: I made a new proposed branch this morning
[10:51:41] <cradek> seb_kuzminsky: it's no big deal at all
[10:52:40] <seb_kuzminsky> git never forgets the evidence ;-)
[10:52:45] <seb_kuzminsky> agreed, no big deal
[10:53:24] <seb_kuzminsky> i'll check out the new proposed branch for 2.6.1, which should be soon, since andy pointed out i jumped the gun and didnt wait for his lathe-fanucy fix
[10:53:43] <cradek> release early, release often
[10:53:52] <seb_kuzminsky> yep :-)
[10:54:52] <seb_kuzminsky> pcw_home: i see that the [SECTION](VARIABLE) syntax is not described in the INI Configuration docs
[10:55:48] <seb_kuzminsky> it's described in the halcmd manpage:
http://linuxcnc.org/docs/2.6/html/man/man1/halcmd.1.html#SUBSTITUTION
[10:56:13] <seb_kuzminsky> which sort of makes sense since it's halcmd that's reading the .hal file that has that syntax in it
[10:56:42] <seb_kuzminsky> this is not the first time all our different kinds of config files, with their different syntaxes and documentation files, have caused confusion
[10:56:56] <pcw_home> OK thanks
[10:58:26] <pcw_home> I still don't really understand his problem (since I am unable to duplicate it)
[10:59:33] <seb_kuzminsky> yeah that's strange
[10:59:56] <seb_kuzminsky> pcw_home: got a link to the forum thread?
[11:00:30] <jepler> http://www.linuxcnc.org/index.php/english/forum/27-driver-boards/28103-firmw
[11:06:01] <pcw_home> if I was less lazy I'd have him post his HAL/INI files that he says dont work and try them here
[11:06:10] <jepler> I know there's a thing when you are using the "two pass" halfile feature, or using .tcl files as hal files, because Tcl quoting and halcmd quoting are not quite the same
[11:07:32] <jepler> y="a b" parses as two words, because Tcl only treats a quote at the beginning of a word as special
[11:07:42] <jepler> while halcmd parses it as one word
[11:08:50] <jepler> this difference ends up being more or less transparent with kernel realtime, because insmod does its own parsing when an argument contains a quote mark -- it pastes argv together with whitespace and then parses it again, or at least that's the black-box impression I have
[11:09:02] <jepler> while rtapi_app doesn't, because that's obviously nuts
[11:11:10] <pcw_home> in this case we are both using Preemt-RT but I'm not clear what linuxcnc version he is using
[11:15:19] <mozmck> regarding ssi's question about ja5 vs ja4 - wasn't ja something merged into master as well?
[11:15:44] <cradek> nope, not yet
[11:15:57] <mozmck> ok, remembered wrong then.
[11:16:07] <cradek> we wanted to, but our testing at sams showed it doesn't quite work well enough yet
[11:16:08] <mozmck> what is different in jaX?
[11:16:22] <cradek> in particular configs with missing axes (like lathes) seemed totally broken
[11:16:22] <jepler> mozmck: higher numbers are better :)
[11:16:56] <pcw_home> Dosn't that break most hal files because of pin name changes also?
[11:16:57] <cradek> the newest ja branch is rebased on the new master which includes the new tp, so ja needed a lot of rework
[11:17:04] <mozmck> :) I see.
[11:17:05] <cradek> pcw_home: yes but there's a config-updater
[11:17:51] <mozmck> what is the main change with ja - why does it exist?
[11:18:00] <pcw_home> right, think I remember Andy was working on that
[11:18:18] <jepler> mozmck: jaX is to improve linuxcnc on machines with nontrivial kinematics
[11:18:23] <cradek> the idea of joints and axes is currently muddled, which causes trouble for gantrys and lots of other nontrivkins machines
[11:18:31] <cradek> it sorts that all out
[11:19:09] <mozmck> I see. Or you mean - it will sort it all out when it works ;)
[11:19:30] <jepler> the branch has been rebased onto newer versions of linuxcnc from time to time, and that's when it gets a higher number
[11:19:32] <cradek> it also adds some glaring things that are missing in nontrivkins machines today, such as the ability to incremental jog
[11:21:35] <ssi> the big thing that seems missing in ja right now is the ability to switch from free to teleop mode properly
[11:22:06] <ssi> I have two gantry machines now, and both use a .axisrc chunk of python that can switch them into teleop mode automatically whenever it sees all the axes are homed
[11:22:18] <ssi> but I have no way to switch back OUT, and if I need to rehome I have to kill linuxcnc and restart
[11:32:17] <cradek> what do you mean by "properly"?
[11:32:36] <ssi> well, for instance gantrykins on master had a free/world menu option
[11:32:38] <cradek> you can switch at will
[11:32:39] <ssi> but ja doesn't
[11:32:48] <ssi> and I couldn't find any hal pins to make the switch
[11:32:49] <cradek> ???
[11:32:54] <cradek> sure it does
[11:33:06] <ssi> I don't have any way to look right now
[11:37:32] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 e03f459 06linuxcnc 10docs/man/man1/halcmd.1 10docs/man/man1/halrun.1 10docs/man/man1/haltcl.1 use easier-to-type bugtracker URL in some manpages * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e03f459
[11:54:01] <ssi> skunkworks_: this video makes me not want to write a tp :(
[11:56:15] <skunkworks_> pretty interesting huh.. I like how he aproximated arc-arc and arc-line blends..
[11:56:18] <ssi> yeah
[11:56:49] <skunkworks_> instead of solving 3 quadradic equations
[11:56:56] <ssi> I have an interest in finite-jerk planning, but watching this video, I'm pretty sure I don't have the math to do it :)
[12:17:08] <alex_joni> seb_kuzminsky: great stuff with 2.6.0.. thanks a lot!
[12:19:20] <seb_kuzminsky> alex_joni: Thanks! I'm pretty excited that it's out finally :-)
[12:29:06] <alex_joni> heh.. though I'm eager for some 2.7 features :D
[12:29:48] <alex_joni> mainly jaX
[12:29:57] <seb_kuzminsky> me too! now all we need is a 2.7 release manager
[12:30:13] <seb_kuzminsky> jaX is not in master yet, and afaik no one is addressing the identified issues with it
[12:30:16] <ssi> haha ready to give it up already?! :D
[12:30:33] <alex_joni> ssi: one release branch is a lot of work
[12:30:36] <ssi> yeah I know
[12:30:45] <ssi> is there a list of the ja issues somewhere?
[12:30:50] <alex_joni> seb_kuzminsky: identified issues?
[12:30:54] <alex_joni> what ssi said
[12:32:17] <alex_joni> one thing I remember was a lack of checking limits (vel/accel) before a move
[12:32:36] <alex_joni> and maybe scale moves so they don't exceed limits
[12:34:11] <alex_joni> and iirc jogwheels weren't completely done (carthesian mode iirc)
[12:34:52] <ssi> I'm happy to try to get involved in ja if I can, as I have a significant investment in it with two machines running it now
[12:35:12] <ssi> but I'd have to get my bearings and find a foothold in it
[12:37:10] <pcw_home> dont slip on your bearings :-)
[12:37:28] <ssi> :D
[12:37:56] <ssi> lemme try to cram more bad metaphors into my conversation!
[12:45:31] <pcw_home> seb_kuzminsky: other hostmot2 additions in 2.6 are absolute encoders (SSI,BISS, Fanuc type 1 + associated DPLL module)
[12:45:32] <pcw_home> and encoder patches (encoder error enable, filter time setting, muxed encoder cable skew adjust)
[12:45:40] <skunkworks_> https://www.youtube.com/watch?v=uoSBVNUO2LU
[12:46:28] <skunkworks_> got to love it.. 'Similes and Metaphors are similar but nothing more....'
[12:56:31] <seb_kuzminsky> pcw_home: wanna add it to the wiki?
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Released_2.6.X
[12:58:20] <pcw_home> Yeah I can
[12:59:12] <pcw_home> hmm manual needs the encoder additions
[13:07:10] <seb_kuzminsky> pcw_home: how do you like asciidoc? You could possibly write your manuals in that and put them in git and have the buildbot make the pdfs
[13:10:34] <pcw_home> Have not played with it
[13:10:35] <pcw_home> maybe I should fix those minor errors in the hostmot2 manual
[13:12:49] <skunkworks_> don't you have people for that?
[13:12:55] <skunkworks_> :)
[13:13:02] <pcw_home> Ha!
[13:19:11] <skunkworks_> cradek, stupid question.. Why if you have an ABZ encoder on a lathe and you turn the spindle backwards in a threading (spindle synced move) does the tool not go backwards?
[13:20:30] <cradek> well, I guess because it's not coded to do that
[13:20:52] <skunkworks_> heh
[13:21:26] <skunkworks_> ok - not because it was impossible..
[13:21:35] <cradek> it wouldn't be very hard to do that within one move, but blending only really works in the forward direction because of how the incoming queue works
[13:22:01] <cradek> and ... it wouldn't be a very useful addition for threading
[13:22:44] <skunkworks_> I can't think of a real good reason...
[13:23:09] <pcw_home> back and forth threading?
[13:23:26] <cradek> threading tools don't cut very well upside-down
[13:23:54] <pcw_home> details
[13:30:41] <ssi> it's useful on a manual machine, but I don't see a use for cnc
[13:35:58] <archivist> tap in the carriage should be possible as it is the same sequence as a mill really
[13:46:53] <ssi> two different moves
[13:51:23] <cradek> [finally watching this TP video] he doesn't mention inside->outside and outside->inside arc-arc blends
[13:52:33] <cradek> just in->in and out->out
[14:01:15] <ssi> I'm at a point where he's talking about generalizing to 9D, and how arc-arc and arc-line blending in 9D is messy
[14:01:23] <ssi> I can't even imagine what an arc move on a rotary axis looks like heh
[14:03:18] <cradek> yeah I think the manual says "these kinds of moves are hardly ever used"
[14:04:03] <Tom_itx> maybe for some odd gear cut?
[14:04:13] * Tom_itx doesn't know either
[14:04:15] <ssi> heheh
[14:05:22] <Tom_itx> straight end cut while it's rotating?
[14:06:13] <cradek> I can imagine chamfering a hole on a 5-axis using a move like that
[14:06:28] <ssi> true
[14:08:47] <Tom_itx> you see youtube videos of convoluted 5 axis moves all the time. especially from MFG that wanna impress
[14:13:01] <cradek> oh my, a lecture about edm and how gcode isn't what you want for it
[14:13:12] <Tom_itx> hah
[14:13:18] <Tom_itx> on the list?
[14:13:34] <cradek> no, in this video
[14:14:33] <Tom_itx> i failed to click
[14:15:52] <skunkworks_> cradek, what did you think of it?
[14:16:00] <cradek> not done yet
[14:16:20] <cradek> too bad it's in video form :-(
[14:17:37] <cradek> ok Q&A and I can't hear the questions
[14:17:44] <cradek> so I guess I'll stop here
[14:17:49] <cradek> it was informative
[14:18:08] <cradek> my only new thought is I'm curious about the conspicuously-missing arc cases
[14:20:04] <cradek> I wish his diagrams and explanations were in git with the code
[14:31:43] <seb_kuzminsky> it'd be a good addition to the Code Notes
[14:37:21] <cradek> (oh man, that one guy)
[14:39:41] <skunkworks_> ?
[14:41:37] <seb_kuzminsky> oh yeah, that guy?
[14:41:47] <seb_kuzminsky> the one with the stuff
[14:56:36] <skunkworks_> jepler, 24+ hours..
[15:06:09] <memleak> jepler, you've really been working away at that new userspace rtos API i can't wait to test it out with bleeding edge kernel and hardware
[15:07:22] <memleak> 64-bit here btw :)
[15:34:12] <tjtr33> hey thanks to all for the new release!
[15:57:02] <jepler> memleak: I've been running sim on 64-bit systems for years, I think the major bugs are worked out.
[16:02:02] <seb_kuzminsky> there may still be 64-bit driver bugs lurking
[16:02:24] <cradek> but we fixed the last one we knew about
[16:02:31] <seb_kuzminsky> jepler & andy fixed one in witchita last summer iirc
[16:19:06] <jepler> and there were at least two in hm2-eth but they surfaced right away
[17:39:36] <jepler> bummer, the "odroid"'s ethernet is internally connected via usb
[17:39:40] <jepler> (odroid u3)
[17:41:46] <seb_kuzminsky> the usb link is faster than the ethernet link
[17:41:55] <seb_kuzminsky> oh, you care about latency...
[17:43:36] <jepler> yeah
[17:45:19] <skunkworks_> that sucks
[17:45:31] <skunkworks_> is there spi on the odroid?
[17:45:37] <seb_kuzminsky> yes
[17:46:51] <jepler> another board I was looking at, cubietruck, seems to have the ethernet connected directly to the CPU's "emac" (Embedded MAC?) block.
[17:47:07] <seb_kuzminsky> skunkworks_:
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G138745696275&tab_idx=2
[17:47:23] <CaptHindsight> yes, on the A10 cubieboard and A20 cubie2 and truck versions
[17:47:27] <jepler> as far as I can find, nobody's built a -rt kernel for either cubietruck or odroid u3
[17:47:56] <CaptHindsight> we have preempt_rt running on the A10's and A20's
[17:48:05] <jepler> CaptHindsight: how's the latency?
[17:48:06] <CaptHindsight> A10 had a xenomai port
[17:48:58] <CaptHindsight> memleak is getting back on that but last week latency was >100K with preempt_RT but last Feb we were ~80uS
[17:49:26] <CaptHindsight> so he's going back over the configs
[17:49:51] <CaptHindsight> what's more exciting is the Exynos performance
[17:51:17] <CaptHindsight> allwinner has a new A80 8 core but since they joined linaro they have ignored the open community at
https://github.com/linux-sunxi/
[17:53:53] <CaptHindsight> https://www.osadl.org/Latency-plot-of-system-in-rack-9-slot.qa-latencyplot-r9s8.0.html imx.6
[17:57:25] <CaptHindsight> Exynos has no detailed open data sheets, allwinner has open data sheets on the A10 and A20, imx.6 has open data sheets
[17:58:21] <jepler> yeah, it's a pain for a hobbyist
[17:58:55] <CaptHindsight> xenomai on the allwinner A13 (same core as others)
http://www.xenomai.org/pipermail/xenomai/2013-February/027801.html
[17:59:32] <jepler> xenomai doesn't make pthreads userspace software have good latency, though, does it?
[17:59:50] <jepler> I just wrote one rtapi implementation, I don't want to do another one the very next month
[18:00:16] <seb_kuzminsky> and i dont want to tackle another kernel just yet...
[18:00:43] <seb_kuzminsky> linuxcnc devs are lazy bastards
[18:01:40] <jepler> It's the only virtue we have
[18:02:00] <CaptHindsight> we either get good docs and poor performance, or no docs but good performance, or can't get parts but good performance and docs
[18:02:20] <CaptHindsight> "it'a always something"
[18:03:05] <CaptHindsight> if we get 80uS back on the A20 that will be fine with an FPGA
[18:04:35] <CaptHindsight> and with all the preempt_RT debug tools plus xenomai is going to base itself on preemot_rt and now Paolo is using xenomai source in RTAI
[18:06:05] <jepler> yeah, though peter seems to favor 500us servo periods, so 40µs would sound better than 80µs
[18:07:06] <jepler> but of course, half as much latency always sounds twice as good
[18:09:50] <CaptHindsight> PPC QorIQ 2020 @1200 MHz 56uS preempt_rt
[19:02:14] <jepler> hm, the odroid makers have a -rt kernel, but I'm not sure which device(s) it is intended for. Last updated in April, apparently.
https://github.com/hardkernel/linux/tree/odroid-3.8.y-rt
[19:07:21] <jepler> answer: there are defconfigs for odroidx and odroidx2
[19:59:24] <MrHindsight> ordoidx2 board uses Samsung Exynos4412 Cortex-A9 Quad Core 1.7Ghz with 1MB L2 cache
[19:59:43] <MrHindsight> http://hardkernel.com/main/products/prdt_info.php?g_code=G135235611947
[20:00:41] <jepler> oh and it wasn't maintained in this April, it was April 2013
[20:00:47] <MrHindsight> figures out of stock
[20:01:01] <seb_kuzminsky> lawl
[20:01:08] <MrHindsight> http://hardkernel.com/main/products/prdt_info.php?g_code=G138745696275 might work with this since it uses the same SOC
[20:01:20] <MrHindsight> $65
[20:02:09] <MrHindsight> that's the problem with odroid, they only make a few hundred and then it's on to the next design
[20:02:50] <MrHindsight> but I did find Exynos4412 Cortex-A9 Quad COM's out of China for <$50
[20:04:52] <MrHindsight> after ARM9 Samsung stopped posting open docs and only wanting to work with large OEM's
[20:08:22] <MrHindsight> http://www.andahammer.com/t1-nanopc/ $70
[20:20:53] <MrHindsight> once the ARM vendor joins Linaro the Linux development stalls out at a kernel to support Android
[20:24:03] <jepler> yeah, that's a frustrating thing about ARM boards, much more churn of incompatible devices than x86 PCs
[20:25:08] <MrHindsight> http://com.odroid.com/sigong/prev_forum/t1605-exploring-364-kernel-and-the-real-time-rt-patch-on-odroid-x.html
[20:25:28] <MrHindsight> even their forums are gone, this is a Google cache ^^
[20:26:42] <MrHindsight> preempt_rt 23us with cpu core speed maxed out
[20:27:18] <MrHindsight> not sure if they found a way to get around the auto speed stepping of the cores when they get warmer
[20:28:11] <MrHindsight> maybe a giant heatsink or fans to keep the cores under the trip temp
[20:28:31] <jepler> adequate cooling is so low-tech
[20:29:30] <MrHindsight> well we got the AMD E350 APU <4uS with RTAI
[20:31:48] <MrHindsight> with hardware accel
[20:40:53] <jepler> > Merge 3.0.51 from Hardkernel svn repo
[20:41:04] <jepler> what great commit messages this git repo has