Back
[13:33:48] <KGB-linuxcnc> 03Norbert Schechner 052.6 7d581f3 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/notification.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_1_5_1 - solved bug not resetting the gmoccapy error pin * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7d581f3
[13:58:11] <cradek> norbert__: your push to 2.6 is just fine, thanks
[13:58:38] <seb_kuzminsky> PCW: thanks for the fixed-report
[13:58:40] <norbert__> cradek: Juhu I did it!
[13:59:02] <norbert__> cradek: how to get that now to master?
[14:00:04] <cradek> let me do it for you, one second
[14:00:20] <norbert__> Thank you!
[14:00:33] <KGB-linuxcnc> 03Chris Radek 05master 4471b83 06linuxcnc Merge branch '2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4471b83
[14:03:26] <cradek> PCW: I saw your message about 5i24 support being incomplete. it's perfectly fine for you to push a change like that yourself - do you need help with details?
[14:06:14] <pcw_home> Yes that would be helpful (Michael G was going to do this but he doesn't have a 5i24)
[14:09:51] <CaptHindsight> cradek: it looks like the camuints package works in 10.04 and 12.04 by just adding the repos, installing the package and adding 2 lines to the .INI
[14:10:30] <seb_kuzminsky> sweet
[14:10:34] <cradek> yay
[14:10:53] <CaptHindsight> it's all the plugins and extras that get tricky with having to compile some extra app or having different configs between ubuntu versions
[14:11:29] <cradek> PCW: how far are you getting before being stuck? do you have a development clone (from git clone ssh://...)?
[14:16:55] <pcw_home> I have never tried to set things up so I can push
[14:16:57] <pcw_home> Let me try to follow the instructions with the test computer
[14:17:09] <cradek> ok
[14:17:25] <cradek> a one-line change is perfect for a git virgin
[14:18:04] <cradek> you'll want to: git clone ssh://pcw@git.linuxcnc.org/git/linuxcnc.git
[14:18:38] <pcw_home> OK I will try in a bit
[14:18:42] <cradek> you'll need to be using the private half of the key whose public half you sent me
[14:19:06] <seb_kuzminsky> it's a tiny bit more than a one-line change: the MODULE_DESCRIPTION and manpage should be updated too, to say the 5i24 is supported
[14:19:10] <cradek> that's stuff in ~/.ssh
[14:19:25] * cradek kicks seb_kuzminsky under the table
[14:19:39] <seb_kuzminsky> oops, the manpage's list of supported anyio boards is out of date
[14:20:20] <seb_kuzminsky> ow!
[14:21:39] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 49f3930 06linuxcnc 10docs/man/man9/hm2_pci.9 doc: update list of supported boards in hm2_pci manpage * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=49f3930
[14:57:15] <KGB-linuxcnc> 03Chris Radek 05circular-blend-arc-rc4 5191783 06linuxcnc New branch with 411 commits pushed, 10162 files changed, 03223996(+), 043408(-) since master/4471b83
[14:57:49] <cradek> I sure like the new kgb
[14:58:45] <seb_kuzminsky> it's mo betta
[15:30:14] <PCW> Hmm wonder what Dabits index thump problem is...
[15:36:22] <cradek> I thought we tested all that...
[15:36:34] <cradek> hm, wonder if we should turn on -previous-target by default in 2.6
[15:36:57] <cradek> I think it's a more consistent setup with it on
[15:37:39] <PCW> I thought so too :-(
[15:38:53] <cradek> he has two pids summing on X...?
[15:39:04] <PCW> yes he has a funny situation with dual encoders
[15:39:05] <PCW> I think Jon Elson suggested tying the master encoders index to both encoder counters
[15:39:28] <PCW> which seems like it should work
[15:39:40] <cradek> yeah seems like
[15:40:14] <cradek> setp xscale_pid.FF0 1.0
[15:40:16] <cradek> that can't be right
[15:40:51] <cradek> in fact that might be the whole problem
[15:41:51] <cradek> I wonder if he has I that compensates for that bogus FF0 setting
[15:41:53] <PCW> FF0 doesnt make much sense unless you have a velocity in and out PID
[15:42:03] <cradek> right
[15:43:23] <PCW> maybe he has a nested PID situation not sure
[15:43:28] <cradek> he must've meant something else
[15:43:46] <cradek> he is not posting the whole config
[15:43:59] <cradek> so it's hard to guess...
[15:45:06] <PCW> Ill ask him to post his hal and INI files
[15:45:34] <PCW> a need to setup semi permanent test jig
[15:46:36] <seb_kuzminsky> i've sometimes thought about a semi permanent hostmot2 test machine connected to the buildbot
[15:47:04] <seb_kuzminsky> i've got a bunch of hostmot2 tests i wrote when i was first writing the driver
[15:47:13] <seb_kuzminsky> they all need funny test cabling harnesses
[15:48:29] <PCW> i have a boatload of those little Pittman DC motors with 500 line encoders from plotters but unfortunately they do not have index
[15:48:49] <seb_kuzminsky> some but not all of my pittmans have indexes
[15:49:25] <PCW> these all have 4 wire flat cables with 5V A,B,GND
[15:49:43] <seb_kuzminsky> i'd happily send mine to you if you set up a dedicated hostmot2-test buildslave ;-)
[15:49:45] <cradek> seb_kuzminsky: should we make -previous-target default to on in 2.6+?
[15:50:23] <seb_kuzminsky> i dont know enough to have an opinion, i'll accept the judgement of you && pcw on this
[15:50:33] <cradek> then yes
[15:50:37] <seb_kuzminsky> yes
[15:51:10] <PCW> known to behave better if you have any I term in your PID loop
[15:51:45] <cradek> if people don't want to retune, they can just add a line turning it off.
[15:52:12] <PCW> I wish it was as easy to fix iindex
[15:52:24] <cradek> what's wrong with index?
[15:54:10] <PCW> Ideally it should not propagate a step change in the commanded position
[15:55:23] <seb_kuzminsky> do you mean reported position?
[15:55:24] <cradek> sorry - do you mean you don't like the design of the canonical encoder, or do you mean there's a bug in an implementation somewhere?
[15:55:42] <PCW> Yes canonical
[15:57:30] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 65933c3 06linuxcnc 10docs/man/man9/motion.9 docs: fix motion(9) motion.in-position pin name * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=65933c3
[15:58:18] <KGB-linuxcnc> 03Chris Radek 052.6 39cd632 06linuxcnc 10src/hal/components/pid.c Default to on, as it makes tuning easier. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=39cd632
[15:58:37] <cradek> well, it works and everything is currently written to the existing design...
[15:58:44] <PCW> I understand why its the way it is (many hardware encoder counters only have an option to clear the count on index)
[15:58:46] <PCW> but that's no good for velocity estimation so more modern designs dont do this anymore
[15:59:23] <PCW> more modern encoder counters I mean
[15:59:24] <cradek> true - our velocity estimation was maybe pushed into the hardware drivers for this reason (although they can also do better because of timestamps)
[16:00:17] <cradek> do we have (uh) mainstream hardware drivers that don't do high a quality velocity estimation via timestamps? ppmc and mesa both do it I think.
[16:00:33] <cradek> who knows what stg/vti/whatever does
[16:00:38] <seb_kuzminsky> i also think both pico and mesa do
[16:00:48] <PCW> There's vital systems
[16:00:51] <seb_kuzminsky> dont know what gm does
[16:01:05] <cradek> I'm not seeing a problem to be solved
[16:01:30] <cradek> any driver can add velocity output that's safe across index, even if it's only a ddt
[16:03:05] <PCW> Just that there are a fair amount of workarounds in PID and other places for the fact that theres a sudden large jump in commanded position
[16:03:24] <cradek> it's true
[16:05:06] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 d897a13 06linuxcnc 10docs/man/man9/motion.9 docs: update motion(9) to match reality * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d897a13
[16:06:52] <PCW> large jumps in commanded position can be eliminated by using index differently
[16:06:53] <PCW> though this would require fairly basic changes in motion
[16:08:27] <cradek> I added a note about the pid change to UpdatingTo2.6
[16:08:36] <seb_kuzminsky> thx
[16:09:22] <seb_kuzminsky> prolly time for a 2.6.0~pre3
[16:09:45] <cradek> including for wheezy!
[16:09:50] <seb_kuzminsky> oof
[16:10:04] <cradek> my pie it is aloft
[16:10:23] <seb_kuzminsky> err, i guess i could make a wheezy-rtai-i386 buildslave without fixing the rtai-deb build system
[16:10:31] <seb_kuzminsky> ok
[16:10:42] <cradek> what's wrong with it?
[16:11:17] <seb_kuzminsky> it's all hacky and one-off, and not awesome like zultron's xenomai kernel builder
[16:12:11] <zultron> My ears are burning.
[16:12:12] <cradek> well nobody can be as awesome as zultron, but we all have to try our best anyway
[16:12:24] <seb_kuzminsky> big shoes to fill
[16:12:26] <cradek> oops
[16:12:29] <cradek> shhhh
[16:12:41] <zultron> seb_kuzminsky, I took a shot at adding RTAI to a reworked kernel package.
[16:12:50] <seb_kuzminsky> what now
[16:12:55] <seb_kuzminsky> awesome!
[16:12:59] <cradek> oooh
[16:13:04] <zultron> The basic flow is in place, but it has some minor problems that I don't have time to fix ATM.
[16:13:16] <cradek> I've been trying and failing to build a wheezy+rtai livecd
[16:13:32] <zultron> (funny you mention this, I just stopped yesterday...)
[16:13:35] <cradek> because the kernel debs I have are somehow weird. maybe just missing dependencies.
[16:13:45] <cradek> stopped what?
[16:13:45] <seb_kuzminsky> i'm staring at the uphill battle fo fixing the kernel.org debian/ directory in the dsc
[16:14:20] <zultron> Stopped working on the RTAI kernel. Need to mothball it for a while.
[16:14:34] <zultron> So, check these out (this will take a minute):
[16:14:36] <seb_kuzminsky> maybe i can pick it up - it's near the top of my todo list
[16:14:49] <cradek> yeah, maybe I can help too
[16:14:59] <zultron> https://github.com/zultron/kernel-rt-deb-autobuild/tree/rtai (the 'debian-linuxcnc-autobuilder' is renamed)
[16:15:46] <zultron> https://github.com/zultron/kernel-rt-deb2/tree/rtai (new kernel pkging based on Debian upstream, MUCH better stuff)
[16:15:46] <seb_kuzminsky> cloning....
[16:16:26] <zultron> https://github.com/zultron/rtai-deb (RTAI Debianization from upstream pkgs, hacked to work with ShabbyX)
[16:16:26] <cradek> PCW: I have no idea what he's talking about regarding mux/delay
[16:16:52] <zultron> https://github.com/zultron/RTAI (ShabbyX with a fix or so on top)
[16:17:30] <seb_kuzminsky> zultron: do you have a feeling for if shabby will merge that? i'd hate to have yet another rtai branch to think about
[16:17:34] <zultron> https://github.com/zultron/linux-tools-deb (linux-tools pkg supplies linux-kbuild, needed to build out-of-tree modules)
[16:18:12] <zultron> I think that's the whole list.
[16:18:46] <PCW> Yeah too complicated I think I would just add the two PID outputs and clear both encoders with the master index
[16:19:04] <zultron> Yeah, there was some ugliness where some autoconf files were hacked out and not replaced. Shabby said he'd accept a pull request, but I haven't gotten anything clean together.
[16:19:07] <cradek> PCW: yes exactly
[16:19:16] <zultron> Shabby's very good about accepting PRs.
[16:19:32] <cradek> PCW: you mean clear both hardware counters with an actual wire, right?
[16:19:33] <seb_kuzminsky> yeah, seems like it
[16:19:36] <seb_kuzminsky> that's great
[16:19:39] <PCW> Yes
[16:20:21] <seb_kuzminsky> zultron: what problems are you having with
https://github.com/zultron/kernel-rt-deb2/ ?
[16:20:26] <PCW> (well clearing is not really done at the hardware level, only latching the count at index)
[16:20:42] <zultron> Anyway, let me know if you need help with this stuff. The Debian packaging is WAY more sane than the horrible make-kpkg, but it's still a small learning curve.
[16:20:51] <cradek> PCW: yeah I only meant wire them together with wire
[16:20:59] <PCW> yeah
[16:21:54] <zultron> Let's see, mainly the rtai-config script isn't updated with the right ksrc paths/kver/etc. Surely an easy fix.
[16:22:32] <zultron> Then there was an SSE problem where I was testing on Wheezy amd64 that I'm also sure one of us has solved before.
[16:22:57] <zultron> I didn't get any further than that, and need to drop it for a while now.
[16:22:58] <cradek> oh that is sure a recurring smell
[16:23:04] <seb_kuzminsky> yeah
[16:23:13] <seb_kuzminsky> cool, thanks for sharing
[16:23:28] <zultron> I've personally fixed SSE-related bugs 2-3 times, and I know I'm not the only one. :P
[16:23:37] <cradek> yeah jepler has done it 2-3 times too I think
[16:24:04] <PCW> will linuxcnc master build under other RT systems than RTAI?
[16:24:18] <seb_kuzminsky> PCW: no, sorry :-(
[16:25:20] <cradek> it would make me happy if that became possible for 2.7
[16:25:28] <PCW> currently thats the easiest way to run our Ethernet cards (Preemt_RT)
[16:25:28] <seb_kuzminsky> we too
[16:25:36] <cradek> (and if 2.7 comes soon)
[16:25:38] <seb_kuzminsky> we got so close for 2.6
[16:25:56] <PCW> yeah must be a lot of loose ends
[16:26:05] <seb_kuzminsky> not that many, i think
[16:27:12] <PCW> Preemt_rt also has the advantage that you can run new motherboards (I'm running a 3.14 kernel here)
[16:27:53] <PCW> it will be a while for RTAI to catch up
[16:28:38] <PCW> not sure how rercent a kernel Xenomai supports
[16:29:02] <zultron> seb_kuzminsky, one other issue: this stuff can build both RTAI and Xenomai pkgs in a single run, using the 'feature set' functionality of the Debian packaging (same as the upstream PREEMPT_RT kernel).
[16:30:45] <zultron> You can turn those off; check the Makefile. Turning off e.g. Xenomai pretty much turns it off everywhere, except it leaves behind a Build-Dep: I haven't gotten to yet. Small deal, but just so you know....
[16:31:04] <zultron> s/turn those off/turn individual feature sets off/
[16:31:47] <seb_kuzminsky> sweet
[16:31:59] <seb_kuzminsky> i hope to get to it in the next handfull of days
[16:35:17] <cradek> thanks, both of you
[16:39:27] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 4dd14c1 06linuxcnc 10docs/man/man9/motion.9 docs: add missing motion.motion-type to motion(9) manpage * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4dd14c1
[16:48:40] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master c2f3675 06linuxcnc Merge remote-tracking branch 'origin/2.6' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c2f3675
[17:11:42] <KGB-linuxcnc> 03Michael Geszkiewicz 052.6 a8dfc9b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_pci.c hm2: add missing case for 5i24 support * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a8dfc9b
[17:11:42] <KGB-linuxcnc> 03Michael Geszkiewicz 052.6 a31beaa 06linuxcnc 10docs/man/man9/hm2_pci.9 10src/hal/drivers/mesa-hostmot2/hm2_pci.c doc: add 5i24 to list of supported boards in hm2_pci manpage and to MODULE_DESCRIPTION text * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a31beaa
[17:15:55] <seb_kuzminsky> yay!
[17:25:37] <seb_kuzminsky> thanks for the bugfix miv
[17:25:39] <seb_kuzminsky> micges:
[17:27:00] <micges> sure
[17:32:51] <skunkworks_> ready for the trip?
[17:32:52] <skunkworks_> http://electronicsam.com/images/house/Trip.JPG
[17:42:33] <PCW> skunkworks_ Etherhm2 at 2 KHz still up 4 weeks+ 24/7 on J1800
[18:05:14] <skunkworks_> PCW, awesome
[18:05:22] <skunkworks_> I have not had a chance to play with it yet
[18:06:24] <PCW> I think I may order the Gigabyte j1900 board with 2 GigE MACs and PCI
[18:07:28] <PCW> (I'm using a usb --> Ethernet adapter for normal network connectivity)
[18:09:48] <seb_kuzminsky> skunkworks_: wow, a garage with actual cars in it
[18:52:03] <skunkworks_> seb_kuzminsky: if you build it big enough...
[19:17:17] <kwallace> Hello, I have a ui.py file with ui hal pins. The ui pins and the component pins are connected in a .hal file and everything is wonderful. Except how can I connect a ui hal pin to a component parameter in my ui.py? I think I want to issue a "halcmd setp XXX", but is that the way to go, and how to best to do that in Python?
[19:36:11] <seb_kuzminsky> kwallace: there's no way to connect pins to parameters
[19:37:22] <kwallace> crud
[19:37:34] <seb_kuzminsky> params just dont work that way
[19:37:46] <seb_kuzminsky> what param do you want to set?
[19:38:10] <kwallace> edge width
[19:38:20] <seb_kuzminsky> you can shell out to 'halcmd setp XXX' like you said above...
[19:39:16] <kwallace> That seems clunky but I guess one does what one needs to do. Thank you.
[19:42:32] <seb_kuzminsky> there was an effort some time ago to turn parameters into pins, precisely for this reason
[19:42:37] <seb_kuzminsky> guess no one got to edge yet
[20:02:22] <kwallace2> seb_kuzminsky, (back from dinner) yeah I recall that too. I suppose it would not be hard to use the existing component to make a new one with only pins. Either way, it's only software, how hard could it be?
