Back
[02:09:24] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/sam 1acecf0 06linuxcnc 10src/emc/sam/standalone-motion.c sam: read motion commands from a file (or stdin) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1acecf0
[02:09:24] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/sam b323f23 06linuxcnc 03tests/motion/sam-jogwheel/checkresult 03tests/motion/sam-jogwheel/jogwheel.motion 03tests/motion/sam-jogwheel/test.sh add a jog test using sam * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b323f23
[03:00:55] <akex2> Hi all
[03:01:26] <akex2> Linuxcnc accept a negative comp for tool ?
[03:02:03] <archivist> have you tried (I dont know)
[03:02:20] <akex2> No
[03:03:43] <akex2> Because a friend programing a g41 and g42 on center tool
[03:03:57] <akex2> And her comp is at 0
[03:04:41] <akex2> It s a solution for a boring entry move comp and protection gouging
[03:06:28] <akex2> But if linuxcnc don't accepte a negative comp that don't work
[03:07:31] <archivist> gouging was talked about recently, often a coding problem
[03:08:26] <akex2> Ha shit i don t see that !
[03:09:27] <akex2> I don't aggree with that, there are a multi way for programing
[03:10:11] <akex2> And linux cnc is very precise for code
[03:15:25] <linuxcnc-build> build #2433 of 4003.deb-lucid-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/2433 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:20:10] <linuxcnc-build> build #2436 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/2436 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:21:15] <linuxcnc-build> build #2436 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/2436 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:22:50] <linuxcnc-build> build #1271 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/1271 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:36:25] <linuxcnc-build> build #2434 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/2434 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:37:23] <linuxcnc-build> build #2432 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/2432 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:39:13] <linuxcnc-build> build #477 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/477 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:39:47] <linuxcnc-build> build #1003 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1003 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:40:09] <linuxcnc-build> build #1002 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/1002 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:40:18] <linuxcnc-build> build #704 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/704 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:40:53] <linuxcnc-build> build #438 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/438 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[09:22:42] <seb_kuzminsky> akex2: yes, negative tool diameters are accepted by the linuxcnc cutter comp
[09:29:29] <seb_kuzminsky> akex2:
http://imgbin.org/index.php?page=image&id=22537
[09:33:52] <cradek> it takes much bravery to use cutter comp in mdi mode
[09:34:51] <seb_kuzminsky> pcw_home: hm2_eth uses udp, right? i wonder if ethtool 'ufo off; gso off; gro off; lro off' would improve network performance any?
[09:35:16] <seb_kuzminsky> cradek: heh yeah it's kind of confusing how delayed the motions are
[09:36:08] <seb_kuzminsky> did you see the standalone-motion commits i pushed last night? it adds the first motion test using that framework :-)
[09:36:39] <cradek> that's wonderful
[09:37:27] <pcw_home> seb_kuzminsky: I can try...
[09:38:02] <seb_kuzminsky> i think i should replace the sam input-file parser with one written in yacc
[09:40:59] <cradek> hmm, there's got to be a way that's better than writing another new interpreted language
[09:42:38] <archivist> a yacc parser could fix all those syntax sillies we currently have/suffer
[09:44:14] <seb_kuzminsky> cradek: i think the input to sam is pretty much a superset of the output of sai
[09:45:07] <cradek> that does have a useful-seeming smell to it
[09:45:21] <seb_kuzminsky> it's the sai output (canon calls), plus hal-poking of motion's mocked pins, plus some kind of waiting directive to give motion time to do things
[09:46:14] <seb_kuzminsky> i would like it if you could literally run "sai | sam", but that requires a better parser than what i'm prepared to write in C. hence: yacc
[09:46:15] <cradek> could sam be a python module you could just import and twiddle directly?
[09:46:30] <seb_kuzminsky> hmm
[09:46:57] <seb_kuzminsky> build motion into a python module... sure, maybe?
[09:47:16] <seb_kuzminsky> you'd still need an input-file parser, it'd just be in python instead of yacc or c
[09:47:49] <seb_kuzminsky> but you could do niftier live reactive things, instead of just pre-scripted sequential things
[09:48:10] <cradek> why do you want an input file instead of calling python functions?
[09:48:50] <cradek> then you also don't have the waiting problem, maybe?
[09:48:59] <seb_kuzminsky> the input file represents a timeline of things that happen outside of motion, that have an effect on motion
[09:49:11] <seb_kuzminsky> it simulates the rest of linuxcnc doing things that motion needs to respond to
[09:49:19] <seb_kuzminsky> it seemed like a natural way to do it?
[09:49:29] <seb_kuzminsky> how would the alternative way work?
[09:50:15] <cradek> I should look at your branch
[09:50:19] <archivist> for speed C rather than python
[09:50:43] <cradek> well it has to be easy to write tests
[09:50:51] <cradek> seb_kuzminsky: do you see this as just for testing motion?
[09:50:53] <seb_kuzminsky> you'd write a python script that imports motion, then does the hal & task mocking my making function calls into the mock wrapper, and calling the motion-module's "run the servo loop once" function?
[09:51:30] <seb_kuzminsky> cradek: yeah, testing motion (including the tp) is the driver for this project
[09:51:45] <seb_kuzminsky> is there some feature creep i should consider? ;-)
[09:51:55] <cradek> no, I don't think so
[09:52:49] <seb_kuzminsky> archivist: this is totally not a performance-critical thing, and the motion core is of course already written in C. it's just this proposed interface wrapper that'd be in python
[09:53:45] <cradek> well I don't care what language it is, I just feel like when you find yourself writing a new interpreted language, you should probably stop and reexamine your life
[09:54:01] <archivist> python makes me squirm :)
[09:54:02] <seb_kuzminsky> for sure
[09:54:57] <seb_kuzminsky> i hadn't thought of the sam input format as being a language
[09:55:13] <seb_kuzminsky> it doesn't have control flow or variables or anything like that
[09:55:21] <cradek> today
[09:55:29] <seb_kuzminsky> it's just a list of inputs to motion
[09:55:34] <pcw_home> only gro and gso are changeable in my test system here and they dont make a a noticeble difference
[09:55:42] <seb_kuzminsky> cradek: heh yeah
[09:56:02] <seb_kuzminsky> pcw_home: ok, cool, sorry for the noise then
[09:56:09] <cradek> (I feel this way a bit about halcmd too)
[09:56:22] <pcw_home> worth a try
[09:56:37] <seb_kuzminsky> i've often wished i could import halcmd into a python script to set up hal circuitry etc
[09:57:10] <seb_kuzminsky> and i can imagine wanting to run sam in the reactive/responsive way that you could if there was a python interpreter running the main loop
[09:57:55] <akex2> Thx seb_kuzminsky good news for me :) !!
[09:59:06] <cradek> so there are already functions like motion_set_acc(double acc)
[09:59:18] <pcw_home> can you fix mistakes with negative diameter tools?
[09:59:28] <cradek> pcw_home: yes they put material back on
[10:00:31] <seb_kuzminsky> cradek: you mean there are functions somewhere that create emcmot command structures from function arguments?
[10:00:40] <akex2> pcw_home: for esiest way for programing
[10:01:17] <cradek> seb_kuzminsky: yes I think you just wrote them? in standalone-motion.c
[10:01:46] <seb_kuzminsky> now i'm confused and i dont understand what you're telling me
[10:02:11] <seb_kuzminsky> i added the motion_*() functions to standalone-motion.c so i can provide sam with emcmot messages
[10:02:20] <cradek> I'm thinking out loud while reading your branch trying to understand how sam gets its messages
[10:02:29] <seb_kuzminsky> oooooh ok
[10:02:39] <cradek> sorry for being incoherent
[10:03:00] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/sam c60637b 06linuxcnc 10tests/motion/sam-jogwheel/checkresult fix a harmless bug in sam output validation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c60637b
[10:03:31] <cradek> do you still poke the messages into motion via the shm?
[10:04:57] <cradek> oh I see, you run emcmotCommandHandler directly to read the new message
[10:07:25] <seb_kuzminsky> yeah it's all in one process, no need for shm or hal or anything
[10:07:54] <cradek> cool, you barely had to change motion at all
[10:08:32] <seb_kuzminsky> one feature creep i've been thinking about is the ability to do things between emcmotCommandHandler and emcmotController
[10:08:42] <seb_kuzminsky> not sure if it's useful
[10:09:02] <seb_kuzminsky> yeah, the only real change to motion is in that first commit, where i pull the time-handling functions out
[10:10:08] <cradek> I wonder why those two are separate hal functions
[10:11:09] <cradek> our configs always? seem to call them one right after the other
[10:11:39] <seb_kuzminsky> didn't they at one point run in different threads, at different frequencies?
[10:11:51] <seb_kuzminsky> it might be a fossil from back when computers sucked
[10:12:39] <cradek> I don't recall seeing that, but that sure might have been the idea
[10:15:57] <archivist> while thinking of changes, I watched a few vids the other day, on for my sliding head type where there is one spindle but two tools are started at different times just missing each other
[10:16:30] <archivist> and a multi spindle that had two threading ops on one spindle at the same time
[10:22:03] <pcw_home> I saw a strange bug with mumble.tmax that seems like maybe the same bug that the latency test had under uspace
[10:22:33] <pcw_home> ( tmax going backwards )
[10:22:37] <archivist> around 2:20
https://www.youtube.com/watch?v=97JZX1JkYQk
[10:26:07] <cradek> heh the right one is doing two different threads
[10:28:06] <archivist> to get the cycle times right down, serial gcode and one motion planner is restrictive
[10:28:52] <cradek> you could use separate controls with some basic synchronization scheme between them
[10:29:05] <cradek> you can get three or four copies of linuxcnc for the price of one
[10:29:38] <archivist> heh buy one get ten free
[10:29:40] <cradek> (I have no real experience but I've been told this is how commercial multi-head machines are done)
[10:30:21] <archivist> my sliding head is one spindle and n tools though
[10:31:11] <archivist> very much a long term when I can afford it project though
[11:09:22] <linuxcnc-build> build #2434 of 4003.deb-lucid-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/2434 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:14:50] <linuxcnc-build> build #2437 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/2437 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:16:12] <linuxcnc-build> build #2437 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/2437 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:18:46] <linuxcnc-build> build #1272 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/1272 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:19:19] <cradek> yay, someone's actually excited about multiple offsets:
http://linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/26253-wear-offsets#56310
[11:23:01] <skunkworks> Linuxcnc has really exploded over the last year or 2
[11:29:22] <linuxcnc-build> build #478 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/478 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:29:31] <linuxcnc-build> build #2435 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/2435 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:30:07] <linuxcnc-build> build #439 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/439 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:30:22] <linuxcnc-build> build #1004 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1004 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:31:05] <linuxcnc-build> build #1003 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/1003 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:31:46] <linuxcnc-build> build #2433 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/2433 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:34:32] <linuxcnc-build> build #705 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/705 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[11:50:54] <KGB-linuxcnc> 03Dewey Garrett 052.7 3c816cd 06linuxcnc 10src/hal/utils/halcmd_commands.c halcmd_commands.c: check WEXITSTATUS iff retval * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3c816cd
[11:50:54] <KGB-linuxcnc> 03Dewey Garrett 052.7 ff2c1b3 06linuxcnc 10configs/sim/axis/moveoff/6_zretract.ini 10lib/hallib/moveoff_external.hal 10scripts/moveoff_gui moveoff_gui: verify non-connect of some pins * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ff2c1b3
[12:38:14] <linuxcnc-build> build #2467 of 2000.docs is complete: Failure [4failed compile rsync-docs-to-www.linuxcnc.org] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/2000.docs/builds/2467 blamelist: Dewey Garrett <dgarrett@panix.com>
[12:42:35] <linuxcnc-build> build #3029 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3029 blamelist: Dewey Garrett <dgarrett@panix.com>
[13:01:29] <pcw_home> Hmm turns out my 200 usec latency spikes on the laptop were not caused by power managment
[13:01:31] <pcw_home> but because at some point I had clicked the hardware monitor icon and it was reading CPU temperatures in the background
[13:01:32] <pcw_home> Power on this laptop management makes little difference in timing (at least liittle difference to a servo thread only system)
[13:01:58] <pcw_home> Power management on this laptop
[13:25:44] <seb_kuzminsky> dgarr: that failure is a network problem between the buildbot and www.linuxcnc.org somewhere, nothing to do with your push
[13:25:58] <seb_kuzminsky> http://buildbot.linuxcnc.org/buildbot/builders/2000.docs/builds/2467/steps/rsync-docs-to-www.linuxcnc.org/logs/stdio
[13:56:40] <seb_kuzminsky> linuxcnc-build: force build --branch=2.7 0000.checkin
[13:56:41] <linuxcnc-build> build forced [ETA 59m27s]
[13:56:41] <linuxcnc-build> I'll give a shout when the build finishes
[14:14:01] <seb_kuzminsky> i wonder why posemath is in src/libnml instead of src/emc
[14:15:12] <cradek> because it used to be part of rcslib
[14:16:48] <seb_kuzminsky> weird
[14:17:17] <CaptHindsight> I want to get Linuxcnc controlling SLA printers. There is just Z axis motion coordinated with a stack of SVG images that get projected between each motion on Z
[14:17:51] <CaptHindsight> z-axis move, image projected, z-move, image projected, etc etc
[14:17:57] <seb_kuzminsky> CaptHindsight: cool! that sounds easy
[14:18:13] <CaptHindsight> I can use an M-code to signal for the next image
[14:18:20] <seb_kuzminsky> that makes sense
[14:18:23] <CaptHindsight> but what is the best way to do this
[14:18:39] <CaptHindsight> the next step is having the printed with more than one axis
[14:18:57] <seb_kuzminsky> you have a shell utility that drives the projector with a particular svg, right?
[14:19:06] <CaptHindsight> to insert fasteners during the print like insert molding
[14:19:47] <CaptHindsight> or other operations on other axis like an arm or spindle for combined printing and cutting
[14:21:10] <CaptHindsight> starting from scratch there's nothing controlling the projector, you have the Linuxcnc PC with 2 video outs, one for the GUI and one for the projector
[14:22:05] <CaptHindsight> the other type of SLA uses galvos to direct a single laser
[14:22:17] <seb_kuzminsky> i'd try to make both of the video outs part of the same X display (just like plugging in 2 monitors)
[14:22:21] <CaptHindsight> so it just like a plotter, that is already working
[14:22:46] <seb_kuzminsky> then figure out a command-line image-viewing utility that lets you specify the geometry of its window on the command line
[14:23:15] <seb_kuzminsky> and tell it to cover the part of the X display that's handled by the SLA projector
[14:24:24] <CaptHindsight> the G-code to control the simplest of SLA printers will just have Z motion and and M-code for the images
[14:24:53] <CaptHindsight> seb_kuzminsky: do you think using an M-code for images makes the most sense?
[14:24:54] <seb_kuzminsky> yeah, sounds way simpler than the plastic extruder kinds of printers
[14:25:17] <seb_kuzminsky> definitely use an external m-code to run that shell utility i talked about above
[14:25:27] <CaptHindsight> ok
[14:25:36] <seb_kuzminsky> at least that's the first thing i'd try
[14:26:25] <CaptHindsight> there are a few apps that run on *duino but they don't see the next step in the technology
[14:26:45] <CaptHindsight> so they only do Z motion and images
[14:27:17] <seb_kuzminsky> the m-code can take arguments (P and Q, i think), one of those would be the index of the svg image to display
[14:28:08] <CaptHindsight> there can be a stack of SVG's of 1K or more deep
[14:28:30] <seb_kuzminsky> sure, one for each Z layer
[14:28:52] <CaptHindsight> I also want to preview the stack in Axis or other GUI
[14:29:11] <CaptHindsight> play the slide show and toggle through it just like running the sims now
[14:29:19] <seb_kuzminsky> axis is probably the wrong tool for that
[14:29:31] <seb_kuzminsky> since the svgs are not gcode, the axis backplot is not useful
[14:30:01] <seb_kuzminsky> you'd be better off finding or writing an svg-stack display program, and maybe swallowing that in an axis tab
[14:30:22] <CaptHindsight> yeah in a tab is what I meant
[14:31:11] <CaptHindsight> but if the next step is combining the slideshow with machining or placing operations you want to preview that as well
[14:31:22] <PCW> You need to combine this with your inkjet circuit squirter (print slice, overlay conductor/parts repeat)
[14:32:06] <CaptHindsight> say print 10 layers, place a nut into 4 locations print 100 more layers, done ....
[14:32:43] <CaptHindsight> now you have an enclosure with fasteners permanently inserted
[14:33:13] <CaptHindsight> PCW: yeah, that how it works, it combines SLA with inkjet and laser
[14:33:16] <seb_kuzminsky> cool idea
[14:33:48] <CaptHindsight> prints multilayer PCB's all from fluids
[14:34:14] <CaptHindsight> but it's a Frankenstein of different controllers and systems now
[14:34:23] <skunkworks> http://www.cnczone.com/forums/servo-motors-drives/173060-cnc-2.html#post1655748
[14:34:30] <CaptHindsight> but it can all be done by Linuxcnc
[14:38:36] <PCW> skunkworks: maybe those capacitive encoders have more phase lag at higher interpolation values
[14:39:11] <skunkworks> I think the specs say that.. and it is quite a bit iirc.
[14:39:47] <PCW> Yeah so not really much good for servos
[14:40:13] <skunkworks> I am using one for spindle motor (not spindle) feedback. works fine for that.
[14:42:06] <PCW> sure, not a high accel servo though
[14:42:20] <skunkworks> right
[14:42:34] <skunkworks> he did have better luck tuning in linuxcnc :)
[14:46:29] <linuxcnc-build> Hey! build 0000.checkin #3030 is complete: Success [3build successful]
[14:46:29] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3030
[14:46:37] <seb_kuzminsky> Hey!
[14:50:54] <skunkworks> kids unplugging network cables again for a doom fest?
[14:51:23] <skunkworks> wait - quake... no
[16:28:26] <PCW> So preemt-RT 3.18.7 is much better than the stock Debian for uspace
[16:28:28] <PCW> 0 trouble running hm2_eth at 4 KHz and doing pretty much anything
[16:29:25] <skunkworks> awesome - I wonder how that would get into the main repository
[16:29:44] <PCW> Now I just need a GigE FPGA card
[16:31:01] <skunkworks> would that be needed?
[16:31:05] <PCW> it was triivial to build (on debian, for some reason it wont build any drivers on Ubuntu, maybe i need to copy the .config)
[16:31:46] <mozmck> I'm looking at making a liveCD based on xubuntu 14.04, and I was planning on using the 3.14.x preempt-rt kernel.
[16:32:06] <mozmck> I guess there shouldn't be any reason not to use 3.18.7
[16:32:44] <skunkworks> I should try that on my laptop....
[16:32:57] <PCW> i woudl wait for about -rt3 if you read the mail archive they still have some issues
[16:33:10] <skunkworks> (well - I would have to figure out how to make 14.04 work...
[16:33:28] <PCW> debian just worked on the Dell
[16:33:40] <skunkworks> I could try that on the one at work
[16:33:55] <skunkworks> (the one that has decent rtai but crappy -rt
[16:34:52] <PCW> I had crappy -rt with the 3.2 kernel
[16:35:55] <mozmck> have you tried 3.14?
[16:36:49] <PCW> pretty sure I have 3.14-rt25 on my 14.04 machine at home
[16:37:01] <mozmck> how well does that work?
[16:37:07] <PCW> fine
[16:37:47] <PCW> thats a E8500 (core duo 3.16 g 6M cache)
[16:38:53] <PCW> the E8500 was a lot better than the low end core duo that was originally in the machine
[16:39:45] <mozmck> good - I may try both kernels.
[16:41:19] <PCW> a good way to see how well the Ethernet stuff works is plotting the hm2 read time (and watching the read time tmax)
[16:43:06] <PCW> best so far is H97 MB with G3258 (~100 usec read time worst case ~125 usec)
[16:46:29] <PCW> you need to clear the tmax when you start as it records during card setup so has a high initial value
[16:48:02] <PCW> (tmax setting and timing warnings shoud probably be held back for the first 100 servo threads or so IMHO)
[16:52:11] <mozmck> PCW: ok, I may have to ask you about that when I get something set up to test.
[16:56:08] <seb_kuzminsky> i think it'd be great if we built debs of a modern rt-preempt kernel for x86/amd64/arm
[16:56:17] <seb_kuzminsky> debian jessie dropped the -rt kernel, so it's back on us
[16:56:56] <seb_kuzminsky> the build system that i set up for the 3.4 rtai kernel should be fairly easy to adapt to building 3.18 (or whatever) rt-preempt kernel debs
[16:57:41] <seb_kuzminsky> i'd be happy to help anyone who wants to pick that work up... ;-)
[17:00:27] <PCW> building preemt-rt is much easier than RTAI
[17:02:02] <seb_kuzminsky> right, since it's just a kernel patch, and not also a bunch of userspace code
[17:02:09] <PCW> I know nothing about kernel building and the simple instructions here
[17:02:11] <PCW> https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO
[17:02:13] <PCW> just work for me
[17:02:20] <seb_kuzminsky> huh
[17:02:23] <seb_kuzminsky> useful info on a wiki
[17:02:29] <seb_kuzminsky> who would have guessed
[17:02:31] <seb_kuzminsky> ;-)
[17:03:50] <PCW> if you build system does the packaging, that probably most of the work
[17:04:19] <seb_kuzminsky> yeah, the build system takes care of packaging and chrooting
[17:04:49] <seb_kuzminsky> it uses the debian.org kernel packaging, which they keep in svn of all goofy things
[17:04:58] <seb_kuzminsky> so the job is:
[17:05:18] <seb_kuzminsky> 1. figure out the rt-preempt patch to use, which will give you the kernel version to base off
[17:05:53] <seb_kuzminsky> 2. find the commit in the debian.org kernel packaging repo for the closest kernel.org kernel version
[17:06:12] <seb_kuzminsky> 3. find the commit in the debian.org kernel packaging repo for the most recent rt-preempt support
[17:06:43] <seb_kuzminsky> 4. Merge 2 & 3, drop in the patch from 1, tweak everything to build right again
[17:06:53] <seb_kuzminsky> that's it i think
[17:07:24] <seb_kuzminsky> oh, and the added complication if we want to support armhf that we might need different kernel configs for different boards? beagle bone vs u3 vs whatever people are excited about nowdays
[17:09:02] <PCW> Yeah that a whole different Can-O-Worms
[17:09:56] <PCW> Now is just used the sources from kernel.org is there something special about the debian kernels?
[17:10:04] <PCW> s/is/I/
[17:10:17] <seb_kuzminsky> the debian.org folks usually add patches to the kernel.org kernel
[17:10:34] <seb_kuzminsky> they pretty much do long-term support of select kernel.org versions
[17:10:45] <seb_kuzminsky> they also provide their own .config files for different flavors
[17:10:50] <PCW> Ahh
[17:11:38] <seb_kuzminsky> it's less useful for us than it might be, because we may well choose a kernel version that they don't support, based on the rt-preempt patches available
[17:23:01] <PCW> might be enlightening to look through some of the debian patches
[17:24:11] <PCW> I have not noticed any trouble with my vanilla kernels but I dont test much other than RT
[17:25:41] <PCW> (and all the preemt RT kernels have a few oddnesses, debian or not)
[17:32:59] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a b34e8c5 06linuxcnc 10(10 files in 3 dirs) French doc adaptation to po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b34e8c5
[17:32:59] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a 7a95063 06linuxcnc 03docs/src/gui/tooledit.fr.po 10docs/src/gui/tooledit.txt 10docs/src/gui/tooledit_fr.txt French doc adaptation to po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7a95063
[17:32:59] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a 81369e4 06linuxcnc 10(5 files) French doc update and adaptation to po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=81369e4
[19:15:32] <skunkworks> well - isn't that pretty...
http://electronicsam.com/images/KandT/testing/Screenshot%20from%202015-02-26%2018:50:45.png
[19:20:10] <skunkworks> micges: still seeing massive acc/vel violations...
[19:24:33] <skunkworks> (just running line segments - 3d_chips)
[19:26:52] <skunkworks> I am using my axis config with max jerk set to 1000..
[19:29:09] <skunkworks> at max jerk of 100 it runs pretty slow but doesn't seem to violate
[19:29:49] <skunkworks> I do see the vel readout on the screen go negative some times...
[19:29:58] <skunkworks> which seems a bit odd
[19:30:09] <PCW> yeah I have accel and jerk set up pretty high at have big glitches
[19:30:16] <PCW> and have
[19:30:21] <skunkworks> nope - still violats at a max jerk of 100
[19:37:22] <skunkworks> PCW: good program to test...
http://electronicsam.com/images/KandT/testing/spreadsheet2.ngc
[19:37:47] <skunkworks> (it has arcs so probably not on the jerk branch)
[19:38:51] <PCW> Thanks will try for normal testing
[19:39:01] <skunkworks> it scales and rotates...
[20:05:01] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk 598b5f6 06linuxcnc 10src/emc/jerk_tp/jerk_tp.c jerk_tp: fix calculations when we got tiny values for stages cycles count * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=598b5f6
[20:34:06] <skunkworks> zlog
[20:38:39] <micges> skunkworks: PCW found first bug ;)
[20:38:53] <skunkworks> micges: did the configs help?
[20:39:42] <micges> fighting with arc now, but I'll test them now
[20:43:21] <micges> skunkworks: got it running, thanks
[20:46:22] <micges> I don't see any violations on simple programs, will check more after arc will be fully operational
[20:48:56] <micges> skunkworks: but I see wrong calculations
[20:49:13] <skunkworks> ?
[20:49:58] <micges> on jerk code
[20:50:19] <skunkworks> ah
[21:07:35] <skunkworks> micges_: the last push seems to fix the issue at 100 max jerk but 1000 still has a ton of violations
[21:09:03] <micges_> skunkworks: yeah I've done too little tests with variety of ini file parameters, working on this now
[21:14:22] <micges_> 'nite
[21:15:50] <skunkworks> night!
[21:52:29] <Tom_itx> PCW, 6I24.zip not found on server...
[21:56:02] <Tom_itx> i bet it's the same as the 5i24
[21:56:27] <Tom_itx> pcw_home, 6I24.zip not found on server...
[21:58:09] <pcw_home> same as 5i24
[21:58:14] <Tom_itx> yeah
[21:59:08] <Tom_itx> do you select 5i24.ucf or 6i24.ucf for it?
[22:01:41] <pcw_home> 6I24.ucf
