Back
[00:45:37] <seb_kuzminsky> http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas
[01:05:04] <archivist> heh /me lurks in #brlcad
[01:05:23] <archivist> and I did not know or spot that
[11:32:23] <skunkworks> zlog
[12:27:20] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a ac65775 06linuxcnc 03docs/src/gcode/o-code.fr.po 10docs/src/gcode/o-code.txt 10docs/src/gcode/o-code_fr.txt French doc adaptation to po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ac65775
[12:27:20] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a 4f4885c 06linuxcnc 03docs/src/gcode/other-code.fr.po 10docs/src/gcode/other-code.txt 10docs/src/gcode/other-code_fr.txt French doc adaptation to po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4f4885c
[12:27:21] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a b493f8a 06linuxcnc 10docs/src/examples/gcode.txt 10docs/src/examples/gcode_fr.txt French doc adaptation to po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b493f8a
[12:27:24] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a 0f79d7d 06linuxcnc 03docs/src/examples/gcode.fr.po French doc adaptation to po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0f79d7d
[12:27:28] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a 39fc63e 06linuxcnc 10(6 files in 2 dirs) French doc adaptation to po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=39fc63e
[14:46:16] <seb_kuzminsky> aww yeah! we got accepted into GSoC 2015!
http://www.google-melange.com/gsoc/org/list/public/google/gsoc2015
[14:46:34] <seb_kuzminsky> this means (i think) we'll get a student to work on a linuxcnc project this summer
[14:46:50] <Tom_itx> is that good?
[14:46:58] <seb_kuzminsky> mmmmaybe
[14:47:01] <seb_kuzminsky> i think so
[14:47:12] <Tom_itx> hope you get a smart one
[14:47:25] <seb_kuzminsky> heh yeah
[14:48:08] <Tom_itx> no selfies or cell phones allowed!
[14:51:09] <Tom_itx> i don't see linuxcnc in the list..
[14:52:29] <CaptHindsight> \0/
[14:52:46] <CaptHindsight> last year lots of projects got turned down
[14:54:10] <CaptHindsight> Tom_itx:
http://www.google-melange.com/gsoc/org2/google/gsoc2015/brlcad
[14:54:22] <CaptHindsight> under their umbrella
[15:34:06] <skunkworks> Great work seb_kuzminsky
[15:59:09] <seb_kuzminsky> it's a big experiment, i've never participated in gsoc before
[15:59:40] <seb_kuzminsky> i'm friends in the real world with a guy who works with the brl-cad folks, he connected us
[15:59:43] <seb_kuzminsky> we'll see how it goes
[16:01:26] <cradek> > has the world's oldest source code repository.
[16:01:31] <cradek> o rly?
[16:01:41] <cradek> that's really cool if so
[16:02:10] <seb_kuzminsky> and i thought *our* code was crufty
[16:13:58] <wortley> Hi.
[16:16:10] <cradek> the oldest source repositories I have at my fingertips are from 83 and 86
[16:16:28] <cradek> I kind of doubt 79 is the oldest one in the world...
[16:16:41] <cradek> depends on what you call a repository, I'm sure
[16:17:47] <CaptHindsight> I know several that have participated in GSOC
[16:18:06] <CaptHindsight> writing the proposals is the most work for the mentors
[16:18:30] <CaptHindsight> and some students just need some nudging or redirection at times
[16:18:40] <seb_kuzminsky> i mostly relied on our not-terrible feature-request tracker on sourceforge
[16:19:19] <seb_kuzminsky> plus that kernel deb building project that i've been trying to offload since before i started it ;-)
[16:22:52] <seb_kuzminsky> i used to work at the university, putting students back on track is nothing new
[16:41:45] <wortley> seb_kuzminsky: If you want to see that crazy pointer thing it is at
http://linuxcnc.org/index.php/english/forum/24-hal-components/28851-spi-bus-generic-driver-and-st-l6480#56416
[16:50:07] <wortley> ANYONE: Could I theoretically call write_port from the hal_parport module within a driver to force it go faster?
[16:51:47] <wortley> I know that it would kinda be messing up the scheduler, but perhaps it wouldn't be disastrous.
[16:53:40] <seb_kuzminsky> wortley: i'm pretty sure it's not safe to call that function on the same port from multiple threads
[16:54:37] <seb_kuzminsky> is the crazy pointer thing a way to get data from one comp to another? You want to get a bunch of bytes from a spi-client comp into a spi-driver comp?
[16:54:43] <wortley> If I were to attept it, I would be calling it from within base-thread, which would be the same thread. Do you think that COULD be okay?
[16:55:05] <wortley> yes, that's it.
[16:55:06] <seb_kuzminsky> uh maybe
[16:55:10] <seb_kuzminsky> it still sounds crazy
[16:55:34] <seb_kuzminsky> i thought the point of this was to divorce the spi driver from the parport? and do it over hal nets instead?
[16:55:37] <wortley> the pointer thing, or the parallel port write thing?
[16:56:13] <seb_kuzminsky> the whole spidriver-doesnt-have-a-parport-inside-it thing
[16:56:15] <wortley> You are write -- and I plan to keep it that way. I am not desparate yet. And i haven't tuned my box to see how fast I can set the base-thread.
[16:56:44] <wortley> so the parport thing is just curiousity at this point while I am learning about kernel modules.
[16:56:56] <wortley> I plan to keep it abstraced like it is today.
[16:56:57] <seb_kuzminsky> pcw and i suggested that you write a spi-parport driver, which would have exclusive access to the parport, so it would be allowed to do whatever it wants with the parport without confusion and craziness
[16:58:05] <seb_kuzminsky> i think your goal is to have one comp that gets bytes "somehow", and runs the spi wire-protocol on hal pins (which you'd typically net to parport pins)
[16:58:11] <wortley> Ok -- What about the interface to the clients that I have implement by passing pointers on pins.
[16:58:26] <seb_kuzminsky> and you'd have another comp that knows about a particular spi device, and feeds the spi driver (somehow) with the bytes it wants to clock out to that spi device
[16:58:29] <wortley> Yes - you are clear on my goal.
[16:58:41] <seb_kuzminsky> bbl
[16:58:58] <mozmck> why not pass the data on the pins instead of a pointer?
[16:59:20] <wortley> too many pins. 32 in, 32 out, pointers, flags...
[16:59:30] <wortley> That's if 32 byte buffers are enough.
[17:00:15] <wortley> I know, I'm trading a lot of pins for doing something crazy with pointers, which doesn't seem rational.
[17:00:38] <wortley> but really all of this is just baby steps to the right, non-crazy solution.
[17:02:08] <wortley> Also, the pointers give me data structure direct access, which cleaned up the code a lot.
[17:03:25] <wortley> I coud envision a new kind of hal pin struct that is a pointer with perhaps a linked list of children that need to exit before it can be freed or something.
[17:04:57] <wortley> I'm exploring how to talk to kenel functions and read parameters and such, but I am still learning.
[17:05:37] <mozmck> A hal pin is just a pointer to shared memory anyhow, so I would think you could make a buffer in shared memory and use that
[17:06:33] <mozmck> I've done things similar to your pointer passing before. In that case there really was no other good option.
[17:07:00] <wortley> Hence my passing of pointers like I did -- I let the component generator hal_malloc it for me -- Cast the pointers to unsigned ints, passed them via nets, put them back into pointer. Fun!
[17:07:17] <mozmck> yep!
[17:07:31] <wortley> What I did is asking for trouble. It gives people a pin they can tie to something and panic their kernel.
[17:08:05] <wortley> If they haven't wired up their servos properly it tears their head off.
[17:09:50] <wortley> Of course, it will probably happen before even a single base-thread completes, so they will just be wondering what happened and probably be fine.
[17:14:48] <seb_kuzminsky> i can think of two non-crazy options
[17:15:05] <seb_kuzminsky> 1. invent a new kind of hal object called a fifo, that does what you want
[17:15:18] <seb_kuzminsky> 2. use an in-kernel api between your two components to pass the data
[17:15:26] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk 2930f9b 06linuxcnc 10src/emc/jerk_tp/jerk_tc.h 10src/emc/jerk_tp/jerk_tp.c 10src/libnml/posemath/_posemath.c 10src/libnml/posemath/posemath.h jerk_tp: add seamless blending to planner, based on code from yishinli * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2930f9b
[17:15:40] <seb_kuzminsky> the hostmot2 system has an in-kernel api to register fpga boards with the higher-level driver and it works fine
[17:29:17] <micges> skunkworks: ^^
[17:31:30] <skunkworks> ooh..
[17:33:18] <wortley> seb_kuzminsky: I will try out the in-kernel API think -- Anyone looked into implementing the machinekit ring buffers?
[17:35:10] <wortley> seb_kuzminsky: I have looked at the ring.h and hal_ring.h stuff from machinekit, and I even got it to include, but I am still slowly wrapping my head around it.
[17:39:36] <PCW> Parallel port works as expected on Gigabyte J1800D2H with wheezy/ linuxcnc 2.6.7
[17:40:17] <micges> PCW: thanks
[17:44:51] <PCW> Also ASRock Q1900-ITX works as expected with 2.6.4 (usb boot from wheezy iso image)
[17:49:10] <skunkworks> micges: back to pretty huge violations
[17:49:56] <micges> I know, looking for it, but seems that basic blending works
[17:51:25] <skunkworks> neat
[17:51:59] <micges> after whole day battle with blending I very would like to port jerk code to CAB
[17:52:19] <micges> Rob's planner is just so fast ;)
[17:53:25] <micges> I mean it hold current vel on very high level
[17:55:22] <adam3999> Hey pcw thanks for looking at those systems
[17:55:43] <adam3999> I'm still having an issue with my Q1900M with 2.4.6 and .7 on wheezy
[17:55:53] <PCW> NP thats all the JXXXX mbs i have
[17:56:03] <PCW> weird
[17:56:30] <adam3999> I'll be back in the shop in a few hours if there is any troubleshooting info I can send your way
[17:56:59] <adam3999> I mentioned to micges last night that I was able to see inputs from my mx3660 with a separate parallel port testing app
[17:57:19] <adam3999> So I think it's related to Hal or something else in the software stack
[17:57:47] <skunkworks> micges: yes - it is pretty impressive.. :)
[18:03:35] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk 299f559 06linuxcnc 10src/emc/jerk_tp/jerk_tp.c jerk_tp: remove vel/acc glitches between segments while blending is enabled * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=299f559
[18:03:50] <micges> yay!
[18:07:49] <PCW> The combination of CAB and limited jerk should really fly on profiling /fast cutting type apps
[18:08:55] <micges> 3d printing
[18:09:59] <PCW> robotics also (and yes wobbly 3D printers)
[18:11:26] <PCW> almost always a win to not excite vibrations in you machine
[18:12:19] <micges> yeah
[18:13:23] <micges> my test programs runs 25% longer but with 1/3 max acc comparing to CAB tests
[18:13:35] <micges> so surely less stress
[18:17:08] <PCW> Yeah, Ive also seen that the following error spikes due to stepped acceleration mean that people dont tune for the full machine performance
[18:20:01] <skunkworks> micges: Is there some way to activate blending? I don't see any
[18:20:11] <micges> g64 P0.1
[18:20:24] <PCW> Certainly gentler (you would not have happy passengers if you drove with unlimited jerk)
[18:20:27] <micges> witohut Q
[18:36:59] <kb1bdw> .
[18:37:43] <kb1bdw> .
[18:38:28] <mwortley> .
[18:39:40] <skunkworks> micges: faster - the normal overages still
[18:40:15] <micges> skunkworks: same as you told me yesterday?
[18:40:24] <skunkworks> yes
[18:40:29] <micges> thanks
[18:42:45] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk f119173 06linuxcnc 10src/emc/jerk_tp/jerk_tp.c jerk_tp: handle aborting motion during move * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f119173
[18:44:12] <micges> really starts working, I was worried this moment will never happen
[19:00:43] <skunkworks> micges: awesome!
[19:00:47] <skunkworks> Great work
[19:01:30] <micges> thanks
[19:08:31] <PCW> Wonderful to see this starting to work
[19:15:44] <PCW> fairly amazing for preemt-rt:
[19:15:46] <PCW> http://ibin.co/1tUeHa2Voo4A
[19:18:18] <micges> with io load or cpu load?
[19:18:31] <PCW> Thats with HD video playing
[19:18:55] <micges> wow
[19:19:13] <PCW> I suspect RTAI is only a bit better if at all
[19:21:15] <micges> err don't have enough space to build kernel
[19:21:45] <PCW> The 3.18 kernel is definately better
[19:22:44] <PCW> dont know is you saw that earlier plot, go 30 usec latency with preemt-RT on a laptop with 3.18
[19:23:23] <micges> very good numbers
[19:23:58] <PCW> Yeah very noticeable improvement
[20:23:10] <zeeshan> hi developers
[20:23:25] <zeeshan> could someone help point where in the source code is the peck drill cycle handled?
[20:29:24] <cradek> from memory only: interp_convert and interp_cycles
[20:32:22] <zeeshan> youre right
[20:33:37] <zeeshan> i wonder how hard it would be to superimpose a vibration to a regular g01
[20:33:45] <zeeshan> in a particular direction
[20:33:58] <zeeshan> for chip breaking
[20:34:44] <cradek> we do have a chip break (not full retract) cycle
[20:34:56] <zeeshan> g73.. right?
[20:34:58] <cradek> or do you mean not just drilling?
[20:35:01] <zeeshan> yea not just drilling
[20:35:04] <cradek> if you say so :-)
[20:35:18] <zeeshan> so like if you're turning along the z direction
[20:35:36] <zeeshan> you wanna superimpose a sinusodial forced function about that position
[20:35:46] <cradek> interesting
[20:35:58] <cradek> I've sure used cycles in all directions on the lathe
[20:36:19] <cradek> (with L repeat I mean)
[20:36:44] <cradek> you could sure use g73 for turning
[20:36:56] <cradek> it's not sinusoidal but it would break chips
[20:37:06] <zeeshan> i wanted to try to look at the code
[20:37:09] <zeeshan> and see what kind of functio nit is
[20:37:13] <zeeshan> it seems like its a square wave function
[20:37:20] <zeeshan> well trapezoidal
[20:37:28] <zeeshan> cause of accel/decel of the motor
[20:37:30] <cradek> the plane agnosticism is the only thing tricky about the cycles code
[20:38:04] <cradek> you can't chip break the usual way, by using the right feed and the right insert?
[20:38:31] <zeeshan> you can
[20:38:39] <zeeshan> but it'd be nice to use vibrations
[20:38:47] <zeeshan> cause then you could use a generic insert for different materials
[20:39:05] <zeeshan> like as you know, the chip breaker is meant for a certain material , feed
[20:39:08] <zeeshan> and doc
[20:39:12] <cradek> yeah, it sounds neat to try
[20:39:38] <zeeshan> i got taught "fundamentals of chip control" today
[20:39:39] <Tom_itx> is this for a lathe?
[20:39:51] <zeeshan> and he was saying that chip control is a major problem for turning and drilling only
[20:39:56] <zeeshan> for milling, not so much
[20:40:01] <zeeshan> cause of the nature of the interrupted cut
[20:40:07] <cradek> oh of course
[20:40:55] <cradek> you could fake it up in hal with siggen and ... um is it called offset?
[20:41:02] <cradek> if you just want to try it
[20:41:11] <zeeshan> and then showed a video of a sinusoidal vibration super imposed along the axial path of the turning direction
[20:41:14] <cradek> it'd be much harder to add it to motion
[20:41:18] <zeeshan> and holy cow, it was a night and day difference
[20:41:24] <zeeshan> yes i'd like to just try it for now
[20:41:28] <zeeshan> proof of concept type of thing
[20:41:42] <cradek> then write simple hal, don't dig in the code
[20:41:59] <zeeshan> i was trying to dig in the code to see what kind of movement g73 was using
[20:42:12] <zeeshan> i guess i could scope it :)
[20:42:13] <cradek> it's all straight feeds and rapids
[20:42:40] <zeeshan> you know one cool thing about vibrations?
[20:42:47] <zeeshan> the chip breaker starts to work worse and worse
[20:43:34] <zeeshan> as the tool wears, so you could start playing with frequencies to compensate
[20:43:42] <zeeshan> ill try it out
[20:43:58] <zeeshan> my lathe is likely too slow to do anything useful
[21:29:48] <adam3999_> evening
[21:44:26] <adam3999_> hey pcw
[21:45:17] <pcw_home> Hi
[21:46:13] <adam3999_> going to boot up my mill pc with a fresh 2.6 live iso/usb drive and try and troubleshoot my lpt port again
[21:46:22] <adam3999_> this has got me stumped...