Back
[02:14:05] <adam3999> Evening
[05:40:42] <wortley> Good morning
[07:41:13] <wortley> ANYONE: Been ripping my hair out trying to use multiple C files to build a component with component generator. It is possible?
[07:41:32] <micges> no
[07:43:16] <wortley> micges: What about getting #defines as input to variable definitions? i.e. variable unsigned bananas [NUMBANANAS];
[07:43:47] <wortley> Seems like the header file includes happen after defiining the variables, which surprised me.
[11:33:33] <archivist> jmks blosxom blog seems off the web
[11:41:56] <archivist> although his domain is alive
[11:44:09] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a 81367b9 06linuxcnc 10docs/src/gcode/gcode.fr.po 10docs/src/gcode/gcode.txt 10docs/src/gcode/gcode_fr.txt French doc adaptation to po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=81367b9
[11:44:09] <KGB-linuxcnc> 03Francis Tisserant 05seb/master/po4a 48aca82 06linuxcnc 03docs/src/gcode/m-code.fr.po 10docs/src/gcode/m-code.txt 10docs/src/gcode/m-code_fr.txt French doc adaptation to po4a * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=48aca82
[12:35:07] <seb_kuzminsky> hm, maybe i can use canterp for parsing the input for standalone-motion
[12:44:45] <Tom_itx> so was the J1800 an isolated incident of the wheezy iso?
[12:45:47] <Tom_itx> parport thing...
[13:00:28] <pcw_home> I'll check my Gigabyte J1800 tommorow, might be a byproduct of dumping the probe_parport thing
[14:12:09] <adam3999_> hey guys is there an easy way to keep the 2.6 stable and 2.8 devel branch on the same system?
[14:12:54] <cradek> use packages for 2.6; build master as run-in-place
[14:14:10] <adam3999_> ah ok, was wondering if it could be done through the deb packages
[14:16:24] <cradek> nope
[14:16:35] <cradek> debs aren't really good at that
[14:16:41] <cradek> you can install one or the other
[14:17:36] <adam3999_> sounds good, i dont mind building from source
[15:52:52] <adam3999_> hey guys i have a wheezy 2.6 system that is running fine. i just built 2.8 pre1 from source but it's complaining about the rt system and won't start
[15:53:14] <adam3999_> i've tried manually running /etc/init.d/realtime stop, unload, load, etc.. no dice
[15:55:20] <pcw_home> Probably means the linuxcnc build doesn't match the rt kernel type
[15:56:02] <adam3999_> hm
[15:56:05] <adam3999_> running linuxcnc 3.4-9-rtai-686-pae #1 SMP PREEMPT
[15:56:06] <pcw_home> you can build 2.8 for RTAI or Preemt-RT
[15:56:13] <adam3999_> ah
[15:56:21] <adam3999_> is that a switch for configure
[15:56:34] <pcw_home> so you are running a RTAI kernel
[15:56:43] <adam3999_> yep
[15:56:49] <pcw_home> so need a RTAI linuxcnc build
[15:57:11] <adam3999_> i just did a git clone linuxcnc.git
[15:57:20] <adam3999_> is there a separate repo, or a build switch for this one?
[15:57:25] <pcw_home> I always copy-paste from the README file
[15:57:41] <pcw_home> (1 level above src)
[15:57:59] <adam3999_> ./configure --with-realtime=uspace
[15:58:02] <adam3999_> looks like i missed that
[15:58:31] <pcw_home> thats for a preemt-rt kernel
[15:58:53] <adam3999_> oh oh, i see
[15:58:58] <adam3999_> In the source directory, build LinuxCNC:
[15:58:59] <adam3999_> [for rtai]
[15:58:59] <adam3999_> ./autogen.sh
[15:58:59] <adam3999_> ./configure
[15:59:04] <adam3999_> hm, that is what i did originally
[16:03:52] <adam3999_> rebuilding haha i did a make clean in my haste
[16:28:04] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk b33a19b 06linuxcnc 10src/emc/jerk_tp/jerk_tp.c jerk_tp: improve debug output while running longer programs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b33a19b
[16:32:56] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk 74c486c 06linuxcnc 10src/emc/jerk_tp/jerk_tp.c jerk_tp: improve debug output while running longer programs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=74c486c
[16:32:56] <KGB-linuxcnc> 03Michael Geszkiewicz 05micges/master/limited_jerk e9b949b 06linuxcnc 10src/emc/jerk_tp/jerk_tp.c jerk_tp: another fix to calculations of stages cycles counts * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e9b949b
[16:33:42] <micges> skunkworks: shouldn't overshooting position now
[16:34:14] <adam3999_> hey micges hows it going
[16:34:48] <adam3999_> i verified my BIOS settings in that Q1900M motherboard and ran a different parallel port testing app (non dependent on hal) and i can see those parallel port inputs
[16:35:08] <adam3999_> so looks like it is with wheezy, hal or some other part of the software stack
[16:59:12] <micges> hmm
[16:59:19] <micges> does this test app is gpl
[16:59:20] <micges> ?
[17:05:40] <adam3999_> micges, i used this tool:
http://yyao.ca/projects/ParallelPortLinux/
[17:06:24] <adam3999_> i can read my limit switches through my MX3660 with that utility
[17:06:34] <adam3999_> but no luck with any of the HAL utilities like ptest or the hal meter
[17:08:38] <micges> I'll ask guy to check his j1800 with this tool
[17:08:51] <adam3999_> thanks
[17:09:23] <adam3999_> i'm using the Asrock Q1900M with J1900 cpu, latest bios with lpt port set to ECP/EPP-1.9 mode
[17:09:50] <micges> ok
[17:10:18] <adam3999_> i think pcw_home was going to take a look at it as well
[17:10:31] <adam3999_> let me know if you guys need any other info i'm in the shop all day today
[18:32:41] <skunkworks> micges: really looking good so far
[18:53:50] <micges> skunkworks: that's great
[19:02:17] <skunkworks> high jerk numbers still cause overages..
[19:02:44] <skunkworks> not as bad though.. 470 when set to 400in/sec^2
[19:06:30] <pcw_home> really high jerk numbers might get to full accel in less than a thread period so need to be bounded (or warned against)
[19:10:32] <Tom_itx> is the J1900 better than the J1800? i notice the J1900 board runs at 2Ghz but the J1800 runs at 2.41Ghz
[19:12:44] <skunkworks> 1800 iirc is 2 core - 1900 4 core
[19:13:16] <Tom_itx> do you have a favorite brand of ram?
[19:13:39] <Tom_itx> i generally get kingston but newegg has alot of gskill advertised
[19:14:17] <skunkworks> I buy whatever is on sale at newegg
[19:14:21] <skunkworks> :)\
[19:15:10] <skunkworks> micges: so the original jerk implimentation wasn't quite there yet?
[19:16:45] <skunkworks> pcw_home: in my simple mind - that should all be figured out...
[19:17:08] <micges> skunkworks: never doesn't full works for me
[19:17:44] <micges> didn't*
[19:19:41] <skunkworks> micges: well yours is working much better
[19:20:12] <micges> skunkworks: yeah I've got simmilar overages
[19:20:25] <skunkworks> 50in/s^ ,10in/s ,jerk 1000 I get a slight overage of 50.6
[19:20:57] <micges> on arais I've got vel/acc correct even better than in mine, but got always position errors
[19:21:43] <micges> but last fixes makes req vel and real vel very close
[19:22:59] <micges> skunkworks: I think we've got overages becouse of arcs, jerk must be calcuated for them
[19:24:43] <skunkworks> micges: I ge similar overages in 3d_chips.. (made of short line segments..)
[19:25:20] <micges> ah so something more
[19:26:26] <micges> I see it
[19:26:27] <micges> ID 7 | END | TARGET 3.000000000000 | PROGRESS 3.069398545935 | OVERSHOOT -0.069398545935
[20:05:36] <skunkworks> So - how does this follow actual path?
[20:06:55] <micges> it jumps after end of segment to reqested positon
[20:07:22] <micges> then you've got vel/acc overages
[20:12:08] <skunkworks> I meant - is it following the same path as the non-jerk planner?
[20:12:48] <skunkworks> or does jerk add more deviation from path?
[20:13:05] <micges> ah
[20:13:42] <micges> jerk mdifications touches only acc/vel part of planner, path generating is the same as old non jerk one
[20:27:53] <skunkworks> micges: there doesn't seem to be any sort of blend between segments. is that right?
[20:28:42] <micges> not yet
[20:28:47] <skunkworks> ah - ok
[20:29:14] <skunkworks> thought maybe I just didn't understand it ;)
[20:29:15] <micges> TODO: blending, pausing, aborting, feedoverride
[20:29:42] <skunkworks> heh - short list.. - then Add into circular arc blending?
[20:29:45] <skunkworks> :)
[20:30:24] <micges> rather no...
[20:31:10] <skunkworks> a bit much?
[20:31:19] <micges> I mean I see it will be difficult
[22:54:06] <KGB-linuxcnc> 03Dewey Garrett 052.7 9e5a425 06linuxcnc 10configs/sim/axis/moveoff/moveoff_display_7.xml 10src/hal/components/moveoff.comp moveoff.comp: allow_backtracking_enable_change * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9e5a425
[23:25:15] <steve_stallings> --skunkworks asked--
http://www.pmdx.com/PMDX-411 -- steves_logging: will this work with linuxcnc? ;) cool product.
[23:25:30] <steve_stallings> The PMDX-411 is a buffered intelligent device that communicates over USB. As such it requires motion data more than 1 servo cycle in advance of the actual motion in order to not run out of data.
[23:25:38] <steve_stallings> Typically we run 100 mS to 25 mS of buffer. The current architecture of LinuxCNC does not have a way feed a motion device data more than one servo cycle at a time.
[23:25:47] <steve_stallings> It has been done by one company making plasma cutters, but it was a custom modification of LinuxCNC. One of the goals in MachineKit was to make this type of operation possible, but I don't think it has been done yet.