Back
[00:02:06] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 a3e1557 06linuxcnc 10debian/changelog Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a3e1557
[00:04:11] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 2d20def 06linuxcnc 10debian/changelog Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2d20def
[00:33:21] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/sam 069d6b0 06linuxcnc 10src/Makefile 03src/emc/motion/cycle-time.c 10src/emc/motion/mot_priv.h 10src/emc/motion/motion.c Motion: move cycle time management code out to its own file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=069d6b0
[00:33:21] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/sam eed52da 06linuxcnc 10src/emc/motion/command.c Motion: better debug output * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eed52da
[00:33:21] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/sam 72a6b7e 06linuxcnc 10(5 files in 2 dirs) start adding a Standalone Motion test program * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=72a6b7e
[02:24:51] <cmorley> mozmck: convenience, standard methods, plus it would help to better Gscreen's available functions. It's funny to me that lots of people wanted a customizable screen, so i built the infrastructure and they either ignore it or build one from scratch - reinventing the wheel :)
[02:30:06] <cmorley> Kwallace: I imagine the flexibility needed was for the fancy looking images? It could have been done with the theme engine. Gscreen allows the full power of Glade - you can mix gladevcp objects with non. It supports a python 'handler file' to add custom touches.
[02:31:07] <cmorley> I would be interested to play with the glade file if it was available
[02:31:13] <cmorley> Night
[02:49:33] <linuxcnc-build> build #1183 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1183 blamelist: Mick <arceye@mgware.co.uk>, dummy, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Robert W. Ellenberg <rwe24g@gmail.com>, Bence Kovacs
[02:49:33] <linuxcnc-build> <bence.kovacs@generalmechatronics.com>, Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>, Andrew Kyrychenko <amkyrychenko@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[03:58:18] <linuxcnc-build> build #3006 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3006 blamelist: Mick <arceye@mgware.co.uk>, dummy, Michael Geszkiewicz <micges@wp.pl>, Chris Radek <chris@timeguy.com>, Robert W. Ellenberg <rwe24g@gmail.com>, Bence Kovacs
[03:58:18] <linuxcnc-build> <bence.kovacs@generalmechatronics.com>, Norbert Schechner <nieson@web.de>, Moses McKnight <moses@texband.net>, Andrew Kyrychenko <amkyrychenko@gmail.com>, Sebastian Kuzminsky <seb@highlab.com>, Dewey Garrett <dgarrett@panix.com>
[11:56:29] <seb_kuzminsky> crap, i broke gantries :-(
[12:15:17] <skunkworks> We give you 1 job...
[12:20:55] <seb_kuzminsky> heh
[12:21:36] <seb_kuzminsky> i thought i was being careful with testing the nontrivkins jogging change and didn't see any problems, but i guess i missed something
[12:23:01] <seb_kuzminsky> a friend in the brl-cad project has offered to let us piggyback on their GSoC application
[12:23:22] <seb_kuzminsky> any suggestions for student projects, or should i just pull things off the feature-request tracker?
[12:25:05] <seb_kuzminsky> something outside the critical path, something that can be tested
[12:25:32] <seb_kuzminsky> gantry homing maybe? that'll be testable after we finish the standalone-motion test framework
[12:34:13] <skunkworks> jog while pause? (sorry)
[12:35:24] <seb_kuzminsky> heh
[12:35:49] <seb_kuzminsky> after we fix the architectural obstacles, that might be a good student project (for the right student, with the right mentors)
[12:39:00] <skunkworks> I would think there would be a lot of universities that would love to get some hands on motion control
[13:11:33] <dgarr> i want to do a u32/s32 in a .comp, i added #include "rtapi_math64.h" and it works rtai but fails halcompile on uspace . I can patch halcompile.g to make it work but not sure if that is right solution. I could also convert the .comp to .c but would rather not. More info:
[13:11:34] <dgarr> http://www.panix.com/~dgarrett/stuff/tst.comp
[13:11:52] <dgarr> oops i mean u64/u32
[13:13:44] <skunkworks> pcw_home, is it me or the post you quoted missing from the forum thread? (I go the email...)
[13:19:49] <cradek> dgarr: I don't understand what is trying to do 64-bit things
[13:20:27] <cradek> is the uspace ubuntu 12.10 a amd64 kernel?
[13:20:47] <dgarr> i didn't include them in the example just to keep it simple, the example fails because of the #include "rtapi_math64.h"
[13:22:21] <pcw_home> skunkworks: its out of order somehow (cnczone forums always seem on the verge of collapse)
[13:23:00] <dgarr> pcw had suggested adding min,max to latency-histogram and in doing that i was going to add a calculation for variance, need to accumulate in rtapi_u64 type hence u64/u32
[13:24:17] <skunkworks> pcw_home, ah - I see his post now.. so odd.
[13:28:49] <seb_kuzminsky> ok, we're on the brl-cad (aka CAx) GSoC application :-)
[13:31:34] <dgarr> now i see my change to halcompile.g probably doesn't work so question is how can i use rtapi_math64.h functions in a .comp file that will work on both uspace and rtai?
[13:35:05] <seb_kuzminsky> dgarr: bldc.comp seems to be using 64-bit ints, and it works on both
[13:35:37] <seb_kuzminsky> here's last year's GSOC CAx page:
https://www.google-melange.com/gsoc/org2/google/gsoc2014/brlcad
[13:36:38] <dgarr> seb_kuzminsky: bldc.comp doesn't use the div functions from rtapi_math64.h
[13:37:08] <seb_kuzminsky> hmm, right
[13:37:20] <seb_kuzminsky> but it uses the data type that your compile error complained about, right?
[13:38:50] <dgarr> the problem is not the data type but using the functions defined in rtrapi_math64.h
[13:39:35] <dgarr> sserial.c uses them but no .comp file uses them hence my question
[13:40:20] <dgarr> do i have to convert my .comp files to .c files to use functions defined in rtapi_math64.h
[13:40:55] <seb_kuzminsky> it'd be better to fix halcompile
[13:41:34] <dgarr> my fix is not right, so i don't know a good solution
[13:41:38] <seb_kuzminsky> sounds like you're close, by juggling what halcompile #includes, right?
[14:15:37] <dgarr> ok, after fixing some typos , i think my change to halcompile.g does work, tested on a uspace and a rtai system:
[14:15:38] <dgarr> http://www.panix.com/~dgarrett/stuff/0001-halcompile.g-provide-rtapi_math.h.patch
[14:15:54] <dgarr> i am just not sure it is the right solution, please advise
[15:18:13] <seb_kuzminsky> dgarr: i'll take a look at it later today/tonight
[15:18:16] <seb_kuzminsky> glad you got it working
[15:18:29] <seb_kuzminsky> i dont really know how that stuff's supposed to work either, but between us we can figure it out
[15:18:50] <dgarr> it seems harmless , i'm just not sure
[15:19:17] <seb_kuzminsky> does anyone have anything they want me to say to tormach?
[15:20:10] <Tom_itx> tell them welcome to the right side of the tracks
[15:20:15] <seb_kuzminsky> i plan to express gratitude for sponsoring the work on the new planner, and hope that we can keep collaborating well together
[15:20:19] <seb_kuzminsky> heh yep
[15:22:44] <CaptHindsight> did someone say that the new planner is going into 2.7? or already is
[15:23:04] <cradek> already
[15:23:15] <cradek> please test
[15:23:28] <PCW> its been there for quite a few months
[15:23:42] <CaptHindsight> ok, so it's that one
[15:23:55] <CaptHindsight> I thought maybe it was a newer new one
[15:24:17] <PCW> Has Sam posted any of his torture tests?
[15:24:43] <CaptHindsight> he was posting all sorts of tests with that planner
[15:24:43] <skunkworks> as in?
[15:25:04] <skunkworks> a lot of the programs that found to have problems where integrated into robs tests.
[15:25:05] <PCW> been runnin hm2_eth for more than a year now, it might as well run some TP torture
[15:25:13] <skunkworks> oh
[15:25:34] <CaptHindsight> if it detects that you're running it on a reprap it refuses to start
[15:27:49] <PCW> Cant trip up 3.18.7-rt1 at 4 KHz even with the usual things (kernel compiling and youtube videos at once)
[15:38:11] <mozmck> PCW: what motherboard/CPU is that on?
[16:00:29] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a eafe2c6 06linuxcnc 10docs/html/index_fr.html 10docs/src/gui/gmoccapy.fr.po 10docs/src/gui/gmoccapy_fr.txt 03src/po/gmoccapy/fr.po French doc translation update * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=eafe2c6
[16:01:52] <PCW> Gigabyte H81-d3 Pentium G3258
[16:08:52] <PCW> Going to try a ASRock H97M Pro4 MB next (built in Intel MAC)
[16:10:37] <PCW> and also see if 3.18.7 improves the J1800 performance (which is fine at 1 KHz but marginal at 2 KHz)
[16:12:39] <mozmck> have you tried any AMD boards?
[16:14:56] <PCW> the Biostar A68N-5000
[16:15:07] <mozmck> how does that compare?
[16:16:08] <mozmck> I plan to try 3.14.31 here soon - I got sidetracked by other projects right now.
[16:16:38] <PCW> its about like the J1800s fine for normal things with HM2-eth (1KHz fine 2 KHz marginal)
[16:18:05] <PCW> 1 KHZ is fine for step/dir and velocity mode servos
[16:18:07] <PCW> 4KHz improves performance when running a torque loop
[16:18:26] <mozmck> ok, so 1khz is probably all I will need.
[16:19:10] <PCW> even 500 Hz may be ok for step/dir systems depends on required accel
[16:24:39] <mozmck> Hmm, we use 35 to 150 inch/sec^2, depending on the hardware.
[16:24:59] <PCW> Lower servo thread rate means larger velocity steps during acceleration (until I get busy and add acceleration to the stepgen hardware)
[16:26:01] <mozmck> oh, so 1000 velocity steps at 1khz?
[16:26:30] <mozmck> how will you add acceleration to the hardware? will that require sending more information from linuxcnc?
[16:26:33] <PCW> 1000 if it takes 1 second to accelerate
[16:26:46] <mozmck> yes, I meant to say per second.
[16:30:28] <PCW> Done by sending velocity and acceleration (I have to do a rate multiplier to scale the accel without increasing the accumulator length)
[16:32:29] <mozmck> you could send begin velocity and end velocity, and just smoothly ramp during the period...
[16:33:15] <PCW> Yeah it could be extracted
[16:34:45] <PCW> but ideally you want the velocity and acell for to get to the next waypoint (differences done in HAL or hardware would be late)
[16:36:18] <PCW> ( why I think the TP should hand out these numbers to the hardware )
[16:38:18] <PCW> on your 150 inch/sec^2 machine what is the rapid speed?
[16:39:52] <mozmck> that would be the accel
[16:40:07] <PCW> yes...
[16:40:31] <mozmck> lets see, rapids up to 1200 ipm
[16:41:21] <PCW> so about 1/8 second to full speed
[16:42:49] <mozmck> Yes, at the top end. Most probably don't run that fast.
[16:43:42] <mozmck> For plasma cutting thinner metals the cut speeds will be 200 to 300 ipm
[16:48:53] <PCW> You can make the experiment as see if acceleration is noticeable smoother at higher update rates,
[16:48:55] <PCW> I suspect any noticeable roughness mainly disappears at 1 KHz or so
[16:48:56] <PCW> (at least I dont think Ive ever heard of anyone needing higher than 1 KHz for step/dir systems)
[19:17:30] <wortley_> .
[20:06:12] <seb_kuzminsky> i missed the nontrivkins axis jog bug because i use the keyboard shortcut, which works, and i didn't test the mousey-clicky menu item that does the same thing but is broken
[20:17:51] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 8679f71 06linuxcnc 10share/axis/tcl/axis.tcl axis gui: fix jogging on nontrivkins machines, again * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8679f71
[20:22:07] <seb_kuzminsky> i think i need to go look at something else for a while
[20:22:16] <seb_kuzminsky> happy weekend, all!
[20:24:47] <KGB-linuxcnc> 05micges/master/loadable-tp 2d20def 06linuxcnc branch created * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2d20def
[20:26:24] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/loadable-tp 8b5dbf2 06linuxcnc 10src/Makefile 10src/emc/motion/motion.c 10src/emc/tp/tp.c 10src/emc/tp/tp.h tp: make trajectory planner loadable in hal by loadrt function, it must be loaded before motion module * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8b5dbf2
[20:47:53] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/loadable-tp cdefd08 06linuxcnc 10src/Makefile 10src/emc/motion/motion.c 10src/emc/tp/tp.c 10src/emc/tp/tp.h tp: make trajectory planner loadable in hal by loadrt function, it must be loaded before motion module * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cdefd08
[21:19:38] <linuxcnc-build> build #1347 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1347 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Geszkiewicz <micges@wp.pl>
[21:22:38] <linuxcnc-build> build #667 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/667 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Geszkiewicz <micges@wp.pl>
[21:28:36] <linuxcnc-build> build #1186 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1186 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Geszkiewicz <micges@wp.pl>
[21:49:46] <kb1kdw> exit
[21:50:22] <linuxcnc-build> build #1156 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1156 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Geszkiewicz <micges@wp.pl>
[21:52:46] <linuxcnc-build> build #1156 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1156 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Geszkiewicz <micges@wp.pl>
[21:55:45] <linuxcnc-build> build #2999 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2999 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Geszkiewicz <micges@wp.pl>
[21:57:18] <linuxcnc-build> build #815 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/815 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Geszkiewicz <micges@wp.pl>
[21:58:16] <linuxcnc-build> build #2998 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2998 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Geszkiewicz <micges@wp.pl>
[22:00:09] <linuxcnc-build> build #3000 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/3000 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Geszkiewicz <micges@wp.pl>
[22:05:14] <linuxcnc-build> build #2200 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/2200 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Geszkiewicz <micges@wp.pl>
[22:18:54] <linuxcnc-build> build #2999 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2999 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Geszkiewicz <micges@wp.pl>
[22:21:10] <linuxcnc-build> build #2999 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2999 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Geszkiewicz <micges@wp.pl>
[22:21:11] <linuxcnc-build> build #3009 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3009 blamelist: dummy, Sebastian Kuzminsky <seb@highlab.com>, Michael Geszkiewicz <micges@wp.pl>