Back
[01:10:23] <memleak> good night all!
[01:10:47] <qingpei> good night
[01:10:56] <qingpei> memleak: have a nice dream ... :)
[01:11:38] <memleak> thanks! if you have any questions about the cubieboard let me know, ill work on more of my cubieboard kernel tree tomorrow
[01:12:24] <memleak> trickiest part might be GPIO support but i'll see
[01:13:49] <memleak> the whole point being an RT-ready cubieboard kernel tree with a very clean code base for the cubieboard2 such as board and memory init
[01:16:13] <qingpei> ok
[01:16:14] <qingpei> got it
[02:40:35] <chrism> Testing 123
[02:40:54] <chrism> Yay it works from my phone...
[08:13:45] <CaptHindsight> wasn't someone in #coreboot working on coreboot for init on the allwinner a10 or a20 (cubieboard)
[08:13:49] <CaptHindsight> ?
[08:15:27] <CaptHindsight> http://www.phoronix.com/scan.php?page=news_item&px=MTU2NTk ah A10 is done
[08:16:52] <CaptHindsight> http://review.coreboot.org/gitweb?p=coreboot.git;a=commit;h=f64111b4865d611821950b25dc1ea235d8d9ca79&utm_source=anzwix
[08:28:13] <CaptHindsight> A20 user manual
http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf 835 pages
[08:29:53] <CaptHindsight> A10 manual for reference
http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf
[08:57:11] <CaptHindsight> https://github.com/OLIMEX/OLINUXINO Olimex is working on some useful tools for A20 to play with GPIO's graphically
[08:58:38] <CaptHindsight> http://olimex.wordpress.com/2013/10/02/a20-olinuxino-tools-for-android-released/
[08:59:15] <CaptHindsight> https://github.com/OLIMEX/OLINUXINO/tree/master/SOFTWARE/A20/ANDROID%20A20-OLINUXINO-TOOLS
[12:36:18] <kwallace> Anyone know off hand the way to round floats to proper integers in Python?
[12:40:16] <kwallace> Maybe "int(round(23.556))" -> 24
[12:41:20] <pcw_home> its a fairly subtle question as it differs in python 2 and 3
[12:41:52] <pcw_home> (round stupidly returns floats in python 2)
[12:43:21] <kwallace> The int after the round seem to give me what I need so far.
[12:43:28] <pcw_home> Yeah
[12:44:33] <kwallace> Too much of my Python just just trying everything until it works :(
[12:47:01] <kwallace> I've found I often need to use float in front of all variable names or use 0.0 instead of 0 .
[12:49:05] <pcw_home> yeah typing is not as explicit as in other langauges
[13:01:21] <kwallace> I suppose things could get worse, we could could be heading into spring with absolutely no water... oops.
[13:02:30] <zeeshan> hi kirk
[13:02:37] <zeeshan> thanks for writing the mvx9000rtu driver :)
[13:03:08] <CaptHindsight> I'm expecting floods in the midwest, should I use floating point?
[13:03:35] <zeeshan> you had 2 versions on your website
[13:04:09] <zeeshan> the 2a has write capability, it was giving me errors during compile but it was just a few small things causing it
[13:08:34] <kwallace> I don't recall doing anything on the MVX9000 RTU driver but it has been a few years since I've done any Modbus. Modbus in LinuxCNC has progressed since then.
[13:09:27] <kwallace> As usual, I wish I had more time and good looks.
[13:10:40] <kwallace> CaptHindsight, LOL
[13:15:44] <kwallace> Oops, It looks like I do have an MVX9000,
http://wallacecompany.com/machine_shop/vfd/img_1497-2a.jpg ,
http://wallacecompany.com/machine_shop/vfd/
[13:17:19] <kwallace> http://wallacecompany.com/machine_shop/vfd/vfd_notes.html
[13:36:06] <KGB-linuxcnc> 03Dewey Garrett 05master 3713c3d 06linuxcnc 10scripts/sim_pin sim_pin: require exact_name * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3713c3d
[14:02:38] <zeeshan> kwallace: im going to be testing it with 2 of my mvx9000 drives for the mill and lathe
[14:02:44] <zeeshan> once its working, i can send you the updated copies :P
[14:15:19] <kwallace> zeeshan, thank you. Also, if you are using a serial adapter, which one?
[14:30:33] <skunkworks> steve complains about linuxcnc motion - but I don't think he has a clue what mach is doing...
[14:30:35] <skunkworks> http://imagebin.org/294307
[14:31:00] <skunkworks> http://imagebin.org/294306
[14:31:35] <skunkworks> I have come to the conclusion that mach doesn't obey constraints very well....
[14:33:10] <skunkworks> (g64) seems mach has a setting that sets the deviation - but if you set it to anything sane-sih (say .010) it slows way down...
[14:36:30] <skunkworks> the new tp is awesome... (imho) :)
[14:37:29] <skunkworks> http://imagebin.org/294309
[14:38:16] <skunkworks> and look - it follows the path!
[14:38:17] <skunkworks> http://imagebin.org/294310
[14:38:19] <skunkworks> :)
[14:39:15] <skunkworks> But - mach works for a lot of people. So - go figure
[14:45:52] <skunkworks> ^that was with a P.1Q.1.. this is strait G64.
[14:45:54] <skunkworks> http://imagebin.org/294312
[14:48:43] <skunkworks> ^Those are all logging the step/dir through the 7i80 and ploting/halscoping the signals.
[14:48:51] <skunkworks> (which is coolness)
[15:51:52] <mhaberler> cradek: will you take care of the patch for v2.5_branch as per
http://sourceforge.net/p/emc/bugs/361/ or should I just go ahead
[15:52:29] <zeeshan> kwallace im using this:
http://www.startech.com/Cables/Bulk-Wire-Connectors/Connectors-Accessories/RS422-RS485-Serial-DB9-to-Terminal-Block-Adapter~DB92422
[15:53:47] <cradek> mhaberler: would you explain why that should go on v2.5_branch?
[15:54:58] <mhaberler> cradek: would you explain why this problem does not exist in 2.5
[15:55:26] <cradek> it's not clear to me that making a discontinuity near zero is the right fix to whatever this problem is
[15:55:51] <cradek> because I have seen no failed tests on buildbot/v2.5_branch
[15:56:39] <cradek> wait, it's about named parameter expansion in comments? what is the actual bug you are fixing?
[15:56:42] <mhaberler> that just suggest you havent tripped across the right libc version
[15:56:46] <mhaberler> it is clear to me as a consequence of the definition of equality as per TOLERANCE_EQUAL
[15:57:00] <mhaberler> 361
[15:57:15] <kwallace> zeeshan, thank you. That looks like a good one. Mine is a $5 single pair type, but works well.
[15:57:41] <mhaberler> the bug was about parameter expansion in comments, named or numbered
[15:57:46] <cradek> that TOLERANCE_EQUAL is used only for tests of [a EQ b], it is not in general use by the interp
[15:58:21] <mhaberler> meaning what, IF #3 EQ #4 does not apply to zero detection?
[16:07:23] <cradek> ok, I didn't realize at first that your change was only regarding printing of comments. I wonder if the uses of sed to mask -0 in the seven other tests would also be affected by this change (i.e. whether the affected output comes through MESSAGE)
[16:08:29] <cradek> hm, probably not, see toolchange/subs/M100
[16:08:34] <cradek> er toolchanger
[16:11:53] <mhaberler> it evades me why one should use sed on results when you can fix the output generation to start with
[16:12:58] <cradek> the toolchanger tests use a different kind of output (M100).
[16:14:36] <cradek> do you know if that value you're tweaking is exactly -0?
[16:16:06] <cradek> if so, it would be better to change exactly -0 to +0
[16:16:25] <mhaberler> I know it is within the range of 0 what is considered by interp as equality
[16:16:43] <mhaberler> nevermind, I'll push to master and we get brigther downstream
[16:16:45] <cradek> currently, since 6 digits are printed after the decimal and you are changing something like -0.000007 to +0, you are causing the message to be wrong
[16:17:28] <mhaberler> wrong with respect to what, current 'expected' in that runtest?
[16:17:36] <cradek> would you turn the fightyness down please?
[16:17:48] <mhaberler> me?
[16:18:02] <cradek> wrong as in the printed value doesn't represent the internal value. those messages are used for more than tests.
[16:23:50] <mhaberler> sorry, I can see the merit of your argument, and I cant detect 'fightyness' on my behalf either. this fixes a runtest which isnt a semantical problem to start with anyway and I'll be done with that fix, and if we learn a better way downstream this is fine as far as I'm concerned. I think we have bigger holes to deep.
[16:24:01] <mhaberler> by, gotta leave.
[16:25:25] <cradek> using the tolerance of the [a EQ b] test, which very few gcode programs have ever used, as a general tolerance below which you can discard information that is presented to the user, is a big change and is unnecessary to fix the instability in the runtests
[16:26:43] <cradek> I think a more conservative and specific change of exactly -0 to exactly +0 would be entirely acceptable because that distinction is not meaningful in any machining sense
[16:28:21] <cradek> although like your current change, that still won't necessarily let us get rid of all the seds in the runtests because of the M100-based tests
[16:28:54] <cradek> maybe a similar change at the M1xx interface is called for
[18:13:05] <skunkworks> logger[mah]:
[18:13:05] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-02-18.html
[18:51:31] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/docsinwork c224860 06linuxcnc 10docs/src/common/user_intro.txt 10docs/src/gui/ngcgui.txt 10lib/python/pyngcgui.py ngcgui: update documentation for gcmc * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c224860
[19:43:37] <KGB-linuxcnc> 03Michael Geszkiewicz 05master d0bf76b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/encoder.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h hm2: Improve quadrature error reporting by driver * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d0bf76b
[19:51:19] <cmorley> skunkworks: you should wiki some of your linuxcnc / mach comparisons and how you did it. It's an interesting / useful way to evaluate real machines.
[20:28:53] <skunkworks> logger[mah]:
[20:28:53] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2014-02-19.html
[20:30:36] <skunkworks> cmorley: I could probably do turbocnc also - but it doesn't have any look-ahead.
[20:32:11] <cmorley> In the future someone may want to evaluate linuxcnc's TP or a new controller in the same way. Nice not to re-invent the wheel..
[20:32:20] <cmorley> Pretty cool what you did!
[20:33:21] <skunkworks> well - it was just using the tools at hand.. Linuxcnc is pretty darn powerful. (and of course some insite from peter)
[20:34:21] <cmorley> i wonder what Bob Warfield of cnccookbook would have to say. He likes statistics ...
[20:34:51] <cmorley> Our collective minds are pretty amazing!
[20:35:15] <cmorley> TP work is exciting - Way to keep informing us
[20:36:01] <skunkworks> Well - robert E is one smart cookie..
[20:36:10] <cmorley> On you pic of mach's deviation, how much does that represent?
[20:36:34] <skunkworks> hmm - I would have to look - that profile is pretty small..
[20:36:39] <cmorley> Yes clearly he knows his stuff. I am glad he took the project
[20:37:15] <skunkworks> I could probably set the tollerance in linuxcnc to simulate that..
[20:43:29] <skunkworks> if I set the naive cam detector to .3mm I get about the same shape at the beginning. (but it then does that all around the shape..)
[20:44:06] <skunkworks> (heh - I really don't know what that means - it really depends on the shape.)
[20:46:03] <skunkworks> hey - you can put a grid in linuxcnc.. I would say it is around .5mm deviation at the furthest.
[20:49:41] <skunkworks> with mach - you can't seem to set a path following tolerance in gcode - there is a config setting that is how far from path you deviate. If I set that lower - say .010" the speed slows way down.
[20:52:41] <cmorley> very interesting. Ya I forgot about the grid...smart.
[20:54:00] <cmorley> Well I would love to have some more linuxcnc converts - The new TP could entice some..
[20:54:53] <skunkworks> sure - I think the way it is looking - it performs better and has more control over path
[20:55:33] <Tom_itx> maybe those that had a sore spot with the TP will take a new look
[20:56:27] <skunkworks> maybe.. still doesn't have jog while paused.. ;)... (still don't know what the big deal is..)
[20:56:34] <cmorley> Yes. Those doing 3d work from cam had a legitimate complaint. Mach just worked faster.
[20:56:59] <cmorley> Jog while paused will come. The concept had been proven
[20:57:07] <Tom_itx> those produce huge files of short moves
[20:57:18] <cmorley> yes exactly
[20:57:59] <Tom_itx> we had to dnc a couple machines just because the files wouldn't fit in the control memory
[20:59:01] <cmorley> dnc was pretty common at one time wasn't it?
[20:59:09] <Tom_itx> yeah
[21:00:33] <cmorley> i bet jog while paused is one of those things that once you have it, you wouldn't want to give it up, but otherwise you didn't know you needed it...
[21:00:50] <cmorley> say that fast three times...
[21:01:08] <Tom_itx> what's the need behind that feature?
[21:01:13] <skunkworks> cmorley: exactly.. I can see where it would be nice... but I didn't know I was missing it until it showed up on the list.
[21:01:13] <Tom_itx> broken tooling?
[21:01:37] <Tom_itx> i'd love to see a resume for that built in
[21:01:46] <skunkworks> Tom_itx: or router/dremel type tooling that has to be inserted every time..
[21:02:07] <Tom_itx> rewind a couple lines and resume after touching off a fresh tool
[21:02:18] <cmorley> or cleaning swarf between passes (lathe)
[21:02:23] <skunkworks> but I would have a touchoff switch for that (worked great for circuit board stuff I was doing)
[21:02:38] <Tom_itx> you can avoid some of that with chip breaker tools
[21:02:43] <Tom_itx> not always
[21:02:44] <cmorley> yes better run from line would help alot too
[21:03:12] <cmorley> i wouls assume short runs or one offs
[21:03:42] <cmorley> would benefit from pauses to clear chips while you find the sweet spot
[21:03:43] <Tom_itx> the problem with run from line is it would have to return from z clear and know where it was
[21:04:05] <cmorley> i don't follow
[21:04:39] <Tom_itx> if you break a tool mid cut, raise z to change it then run from line z will be too high unless it remembers where it was in the program
[21:04:40] <cmorley> jog to an appropriate position and run from a line (usually a rapid move)
[21:04:54] <Tom_itx> hard to do in a surface file
[21:05:20] <cmorley> then you must run from a feed that has already been fully cut
[21:05:38] <Tom_itx> that's what i was suggesting by backing up a couple lines
[21:05:51] <cmorley> My Okuma lathe would rapid the the END of a feed move with run from line..
[21:05:56] <Tom_itx> or something to that effect
[21:05:57] <cmorley> ahh got it
[21:06:12] <Tom_itx> i loved the little okuma kadet we had
[21:07:22] <Tom_itx> it could store the axis info when the pause was presed
[21:07:53] <Tom_itx> however if you rewind lines, the data probably wouldn't be accurate
[21:07:55] <cmorley> so it could return to the exact spot it stopped at..?
[21:07:59] <Tom_itx> yes
[21:08:12] <Tom_itx> and start cutting with a fresh tool
[21:08:25] <Tom_itx> generally we had to start at a tool change and waste time
[21:08:28] <cmorley> interesting. though if you broke a tool you would want to resume a bit before that..
[21:08:57] <cmorley> yes tool change or rapid then turn up the feed override...
[21:09:22] <Tom_itx> well if you broke a tool you would want to rewind a bit
[21:09:41] <Tom_itx> but knowing where all the axis should be at that point might be hard to determine
[21:10:29] <cmorley> that's EDM territory backing up a profile.
[21:10:37] <Tom_itx> i don't know how lookahead works but it could be gotten from that i suppose
[21:13:02] <Tom_itx> even on a 2d part you'd have to return from z clear to resume
[22:23:46] <steve_stallings> skunkworks: forgive me for not following as closely as I should, but when you tested using MESA card to sample traj output of LinuxCNC and Mach
[22:24:30] <steve_stallings> were both tests done with a free standing, non-synchronized monitoring system, or was the LinuxCNC sampling done on the same
[22:24:38] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/docsinwork b987506 06linuxcnc 10docs/src/gui/ngcgui.txt ngcgui docs: add info for gcmc files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b987506
[22:24:39] <steve_stallings> computer that was running LinuxCNC?
[22:25:37] <steve_stallings> I ask, because synchronous sampling may produce fewer artifacts than un-synchronized sampling.
[22:32:14] <KGB-linuxcnc> 03Michael Haberler 05zultron/ubc3-dev 6775979 06linuxcnc 10src/rtapi/rtapi_msgd.c rtapi_msgd: use assert() without side effects * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6775979
[23:08:00] <KGB-linuxcnc> 03Dewey Garrett 05xhc-hb04 a570336 06linuxcnc 10configs/sim/axis/xhc-hb04/README 10configs/sim/axis/xhc-hb04/xhc-hb04.tcl xhc-hb04: consistent pendant: signal names * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a570336
[23:12:07] <linuxcnc-build> build #1784 of lucid-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1784 blamelist: Dewey Garrett <dgarrett@panix.com>
[23:24:44] <linuxcnc-build> build #1788 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1788 blamelist: Dewey Garrett <dgarrett@panix.com>
[23:29:10] <linuxcnc-build> build #1788 of hardy-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1788 blamelist: Dewey Garrett <dgarrett@panix.com>
[23:30:54] <linuxcnc-build> build #1784 of hardy-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1784 blamelist: Dewey Garrett <dgarrett@panix.com>
[23:34:50] <linuxcnc-build> build #1785 of lucid-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1785 blamelist: Dewey Garrett <dgarrett@panix.com>
[23:34:53] <linuxcnc-build> build #1786 of lucid-i386-realtime-rip is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-realtime-rip/builds/1786 blamelist: Dewey Garrett <dgarrett@panix.com>
[23:35:46] <KGB-linuxcnc> 03Chris Morley 05pncconf_builder cc80466 06linuxcnc 10(32 files in 3 dirs) pncconf -GTK BUILDER refactor * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cc80466
[23:35:47] <KGB-linuxcnc> 03Chris S Morley 05pncconf_builder de00712 06linuxcnc 10src/emc/usr_intf/pncconf/dialogs.glade 10src/emc/usr_intf/pncconf/pages.py 10src/emc/usr_intf/pncconf/pncconf.py 10src/emc/usr_intf/pncconf/tests.py pncconf -fix live test bugs - openloop and stepper tune test * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=de00712
[23:35:47] <KGB-linuxcnc> 03Chris Morley 05pncconf_builder b6a4d15 06linuxcnc 10src/emc/usr_intf/pncconf/build_HAL.py 10src/emc/usr_intf/pncconf/pncconf.py 10src/emc/usr_intf/pncconf/tests.py pncconf -factor out mesa and parport loading wip * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b6a4d15
[23:35:51] <KGB-linuxcnc> 03Chris Morley 05pncconf_builder df58ad6 06linuxcnc 10src/emc/usr_intf/pncconf/pport2.glade pncconf -add pport test panel button * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=df58ad6
[23:35:54] <KGB-linuxcnc> 03Chris Morley 05pncconf_builder b1ab768 06linuxcnc 10src/emc/usr_intf/pncconf/pages.py pncconf -fix parport test for pport2 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b1ab768
[23:35:58] <KGB-linuxcnc> 03Chris Morley 05pncconf_builder 1a2f74e 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py 10src/emc/usr_intf/pncconf/tests.py pncconf -fix up tests to use common I/O loading code * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1a2f74e
[23:36:03] <KGB-linuxcnc> 03Chris S Morley 05pncconf_builder c5932a1 06linuxcnc 10src/emc/usr_intf/pncconf/dialogs.glade 10src/emc/usr_intf/pncconf/pages.py 10src/emc/usr_intf/pncconf/pncconf.py 10src/emc/usr_intf/pncconf/tests.py pncconf -live test WIP * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c5932a1
[23:39:01] <linuxcnc-build> build #1786 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1786 blamelist: Dewey Garrett <dgarrett@panix.com>
[23:43:20] <KGB-linuxcnc> 05pncconf_GTK_builder 8b153f0 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8b153f0
