Back
[00:05:16] -!- Nick001-shop has quit [Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]]
[00:18:39] -!- kwallace2 [kwallace2!~kwallace@tmb-247.sonnet.com] has joined #linuxcnc-devel
[00:19:55] -!- kwallace has quit [Ping timeout: 255 seconds]
[00:26:49] -!- terabyte- has quit [Quit: terabyte-]
[00:33:01] -!- syyl has quit [Ping timeout: 256 seconds]
[00:34:28] -!- malcom2073 [malcom2073!~quassel@unaffiliated/malcom2073] has joined #linuxcnc-devel
[00:47:28] <jepler> cradek: the port must be left in a different state than at power-up. maybe EPP mode? maybe state of some output?
[00:52:12] -!- FreezingCold has quit [Read error: Connection reset by peer]
[01:01:02] <pcw_home> You do need the control pins set to the proper idle EPP state before starting EPP operations
[01:01:50] -!- FreezingCold has quit [Ping timeout: 250 seconds]
[01:02:46] <pcw_home> (EPP mode is weird, the EPP handshake works automatically but you can still twiddle the control output bits like PS2 mode)
[01:05:42] -!- swingley has quit [Ping timeout: 255 seconds]
[01:07:52] -!- syyl has quit [Ping timeout: 240 seconds]
[01:09:33] <jepler> pcw_home: iirc, the pluto-p programs in SPP mode then switches to EPP mode to run
[01:27:50] -!- rob_h has quit [Ping timeout: 250 seconds]
[01:29:30] -!- tjtr33 has quit [Quit: Leaving]
[01:36:40] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[01:47:52] -!- sylphiae has quit [Ping timeout: 240 seconds]
[01:54:02] -!- malcom2073 has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
[01:55:46] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[01:59:45] <cradek> jepler: I bet you're right. The piece of the puzzle I didn't recognize was that in normal operation (starting linuxcnc several times with the pluto powered on), the subsequent programmings may still fail, but you never notice because it's already programmed.
[02:06:29] -!- swingley has quit [Ping timeout: 244 seconds]
[02:09:59] <pcw_home> Looks like a problem with simulator builds on master (it builds uspace which naturally has real time errors on a normal system)
[02:11:58] -!- asdfasd has quit [Ping timeout: 255 seconds]
[02:12:47] -!- skunkworks_ has quit [Remote host closed the connection]
[02:15:10] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[02:15:56] <skunkworks> https://www.youtube.com/watch?v=EwtRWZidh1U
[02:18:25] -!- toner has quit [Remote host closed the connection]
[02:19:26] <skunkworks> logger[
[02:19:31] <skunkworks> logger[psha]:
[02:29:22] -!- AR_ has quit [Ping timeout: 245 seconds]
[02:38:34] -!- sumpfralle has quit [Ping timeout: 250 seconds]
[02:38:49] -!- archivist_herron has quit [Ping timeout: 256 seconds]
[02:51:41] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[02:55:50] -!- PetefromTn_Andro has quit [Quit: Bye]
[03:15:05] -!- Swapper_ has quit [Ping timeout: 256 seconds]
[03:15:58] -!- DaViruz_ has quit [Ping timeout: 260 seconds]
[03:29:15] -!- mutilator has quit [Ping timeout: 256 seconds]
[03:33:01] -!- knownasilya has quit [Quit: Connection closed for inactivity]
[03:39:24] -!- FreezingAlt has quit [Read error: Connection reset by peer]
[04:12:42] -!- Tecan has quit [Ping timeout: 245 seconds]
[04:27:52] -!- sylphiae has quit [Ping timeout: 240 seconds]
[04:29:15] -!- swingley has quit [Remote host closed the connection]
[04:41:27] <seb_kuzminsky> pcw_home: i think master fails to build packages on trusty because trusty lacks libgnomeprint
[04:42:12] <seb_kuzminsky> i started to (heh) delete all our libgnomeprint usage but cradek corrected me
[04:45:29] muti is now known as mutilator
[04:46:56] <pcw_home> hmm I wonder why they dropped it
[04:48:18] <seb_kuzminsky> because gnome
[04:49:03] <seb_kuzminsky> http://i.imgur.com/vlowrGf.jpg
[04:50:52] <pcw_home> I knew these newfangled dynamic linked libraries would come a cropper
[04:51:08] <seb_kuzminsky> heh
[05:00:08] -!- amiri has quit [Read error: Connection reset by peer]
[05:02:00] -!- Fox_Muldr has quit [Ping timeout: 250 seconds]
[05:02:18] <seb_kuzminsky> http://i.imgur.com/NVF5xC6.jpg
[05:04:46] -!- swingley has quit [Ping timeout: 264 seconds]
[05:07:57] -!- syyl has quit [Read error: Connection reset by peer]
[05:36:25] -!- ITChap has quit [Read error: Connection reset by peer]
[05:48:31] -!- MrSunshine has quit [Quit: Leaving]
[05:55:00] -!- kwallace2 [kwallace2!~kwallace@tmb-247.sonnet.com] has parted #linuxcnc-devel
[05:56:02] -!- phantoxeD has quit [Ping timeout: 260 seconds]
[05:56:06] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/checkglade fa73436 06linuxcnc 10src/emc/usr_intf/gscreen/Submakefile refactor gscreen Submakefile * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fa73436
[05:56:06] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/checkglade 09d9acc 06linuxcnc 10src/emc/usr_intf/gscreen/Submakefile gscreen: check for conflicts during build (non-fatal) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=09d9acc
[05:56:06] <KGB-linuxcnc> 03Jeff Epler 05seb/2.6/checkglade ada9d9d 06linuxcnc 10scripts/checkglade stepconf: make checkglade warnings fatal * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ada9d9d
[05:56:20] <seb_kuzminsky> jepler, cmorley: seb/2.6/checkglade adds the same glade check to gscreen as jepler added to stepconf
[05:56:24] <seb_kuzminsky> 2 id collisions
[05:56:28] <seb_kuzminsky> good night
[05:59:39] <linuxcnc-build_> build #435 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/435 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[05:59:43] <linuxcnc-build_> build #435 of 1402.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-amd64/builds/435 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[05:59:45] <linuxcnc-build_> build #91 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/91 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[06:02:09] -!- LeelooMinai has quit []
[06:05:33] <linuxcnc-build_> build #2279 of 1306.rip-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/2279 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[06:05:37] <linuxcnc-build_> build #2277 of 1300.rip-precise-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/2277 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[06:06:14] <linuxcnc-build_> build #2278 of 1200.rip-lucid-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/2278 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[06:06:34] <linuxcnc-build_> build #1480 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/1480 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[06:06:53] <linuxcnc-build_> build #2279 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/2279 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[06:07:04] <linuxcnc-build_> build #2279 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/2279 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[06:07:56] <linuxcnc-build_> build #2277 of 1900.clang-lucid-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1900.clang-lucid-rtai-i386/builds/2277 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[06:15:33] <linuxcnc-build_> build #2075 of 1901.clang-precise-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1901.clang-precise-amd64/builds/2075 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[06:15:34] <linuxcnc-build_> build #2284 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2284 blamelist: Jeff Epler <jepler@unpythonic.net>, Sebastian Kuzminsky <seb@highlab.com>
[06:20:51] -!- asah has quit [Quit: asah]
[06:24:50] pthorin_ is now known as pthorin
[06:26:02] -!- Tecan has quit [Ping timeout: 245 seconds]
[06:33:16] -!- ve7it has quit [Remote host closed the connection]
[06:56:14] -!- phantom has quit [Ping timeout: 260 seconds]
[07:16:03] -!- The_Ball has quit [Ping timeout: 240 seconds]
[07:41:26] -!- rob_h [rob_h!~robh@2.127.20.33] has joined #linuxcnc-devel
[07:42:01] -!- dhoovie has quit [Read error: Connection reset by peer]
[07:46:47] -!- mahtennek has quit [Remote host closed the connection]
[07:53:23] -!- ITChap has quit [Ping timeout: 264 seconds]
[07:55:52] -!- phantomD has quit [Ping timeout: 240 seconds]
[07:56:30] -!- mahtennek has quit []
[07:58:15] <KGB-linuxcnc> 03Cmorley 052.6 1f5f8d8 06linuxcnc 10(9 files) stepconf -fix bugs caused by widget id collision * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1f5f8d8
[08:00:05] <cmorley> If someone could test 2.6 stepconf on debian 7.... I tested with mint 13 ... I'm going to bed night
[08:08:40] -!- micges-dev [micges-dev!~x@aeia205.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[08:10:03] -!- ITChap has quit [Ping timeout: 255 seconds]
[08:15:13] -!- gonzo_ has quit [Read error: Connection reset by peer]
[08:28:51] -!- eeriegeek has quit [Quit: Leaving.]
[08:30:30] -!- sylphiae has quit [Ping timeout: 260 seconds]
[08:40:00] -!- micges-dev has quit [Quit: Wychodzi]
[08:44:22] -!- phragment has quit [Ping timeout: 240 seconds]
[08:56:13] -!- phantom has quit [Ping timeout: 256 seconds]
[09:05:12] -!- The_Ball has quit [Ping timeout: 245 seconds]
[09:06:35] -!- ITChap has quit [Ping timeout: 264 seconds]
[09:07:42] -!- swingley has quit [Ping timeout: 250 seconds]
[09:11:21] -!- kfoltman has quit [Quit: Ex-Chat]
[09:22:59] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[09:38:38] -!- ashcan_ has quit [Client Quit]
[09:56:49] -!- phantomD has quit [Ping timeout: 255 seconds]
[10:21:36] -!- ITChap has quit [Read error: Connection reset by peer]
[10:30:35] -!- skunkworks has quit [Ping timeout: 264 seconds]
[10:44:59] -!- SpeedEvil has quit [Ping timeout: 264 seconds]
[10:45:39] -!- Reventlov has quit [Quit: leaving]
[10:46:13] reventlov is now known as Guest99776
[10:46:43] Guest99776 is now known as Reventlov
[10:46:48] -!- Reventlov has quit [Changing host]
[10:52:44] -!- Benjamin23 has quit [Remote host closed the connection]
[10:56:33] -!- phantom has quit [Ping timeout: 240 seconds]
[10:59:49] -!- FreezingCold has quit [Ping timeout: 255 seconds]
[11:04:57] -!- ries has quit [Read error: Connection reset by peer]
[11:06:53] -!- ries has quit [Remote host closed the connection]
[11:34:25] -!- Reventlov has quit [Quit: leaving]
[11:35:01] reventlov is now known as Guest84030
[11:36:57] -!- Guest84030 has quit [Client Quit]
[11:37:37] reventlo1 is now known as Reventlov
[11:47:45] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:54:40] -!- Valen has quit [Quit: Leaving.]
[11:56:46] -!- phantomD has quit [Ping timeout: 260 seconds]
[11:59:19] <jepler> seb_kuzminsky: it looks like you have the addition of the id checking code to 2.6 in hand; let me know if you want me to do anything further about that
[12:00:00] BitEvil is now known as SpeedEvil
[12:02:55] -!- Solarlux has quit [Read error: Connection reset by peer]
[12:07:23] -!- Reventlov has quit [Quit: leaving]
[12:13:37] -!- putnik_ has quit [Changing host]
[12:19:10] -!- Komzzpa has quit [*.net *.split]
[12:19:11] -!- Khetzal has quit [*.net *.split]
[12:19:12] -!- cnc_ has quit [*.net *.split]
[12:19:14] -!- GlennS has quit [*.net *.split]
[12:19:15] -!- tumdedum has quit [*.net *.split]
[12:19:16] -!- putnik has quit [*.net *.split]
[12:19:19] -!- marvi has quit [*.net *.split]
[12:19:21] -!- Smidge204__ has quit [*.net *.split]
[12:19:23] tumdedum_ is now known as tumdedum
[12:22:00] -!- reventlov has quit [Quit: leaving]
[12:23:49] -!- Khetzal [Khetzal!~khetzal@sierra.khetzal.info] has joined #linuxcnc-devel
[12:24:31] Khetzal is now known as Guest28645
[12:27:14] phantom is now known as phantoxeD
[12:32:29] <skunkworks> jepler, still running uspace
[12:32:50] <skunkworks> been 7 days so far
[12:35:13] -!- GargantuaSauce_ has quit [Ping timeout: 255 seconds]
[12:50:12] -!- thomaslindstr_m has quit [Quit: Leaving...]
[12:50:58] <jepler> skunkworks: great news
[12:51:39] <skunkworks> jepler, Great work!
[12:51:43] -!- reventlov has quit [Quit: leaving]
[12:52:53] Guest28645 is now known as khetzal-
[12:56:56] -!- phantoxeD has quit [Ping timeout: 250 seconds]
[13:04:01] -!- GargantuaSauce has quit [Ping timeout: 255 seconds]
[13:09:59] <jepler> seb_kuzminsky: oh, except only a tiny minority of the duplicate IDs were fixed by cmorley's commit
[13:13:30] <skunkworks> I thought cradek posted a utillity that would fix that
[13:13:47] <cradek> no, you're confusing me with someone competent
[13:13:55] <jepler> cradek had a grep or something
[13:17:20] <skunkworks> <cradek> jepler, seb_kuzminsky:
http://pygtk-id.blogspot.com/2009/06/replace-duplicate-widget-name-in-glade.html
[13:21:43] <cradek> I do think making the IDs automatically unique as part of the build process would be ideal for stepconf. we could consider the existing glade files as inputs that have to be massaged. I have not tried to do it though -- it may be hard.
[13:22:08] <jepler> in the case that the python source refers to a widget name, this won't owrk
[13:22:11] <jepler> work
[13:22:28] <jepler> say you create a file in glade, look at the xml, and see that your label is "label1"
[13:22:41] <jepler> you want to change the text on it at runtime, so you write something involving builder.get_object("label1")
[13:22:59] <jepler> we can't change the Python, so if we change label1 to label1-in-file1 automatically, it breaks
[13:23:18] <cradek> if we massage the label to thegladefilename-label1 that's a simple one-time change in the python
[13:23:55] <cradek> they are already unique per-file, right? so filename-existinglabel is unique globally
[13:24:03] <cradek> and stable
[13:24:16] <jepler> that page skunkworks just pasted indicates that some versions of glade made duplicates within the same file
[13:24:27] <cradek> well that's very silly
[13:24:33] <jepler> that is not the problem we're dealing with, however
[13:26:14] -!- reventlo1 has quit [Client Quit]
[13:27:51] <jepler> we might as well have one builder per xml file then
[13:27:55] <jepler> if we're going to change all the python
[13:28:09] <jepler> so instead of self.builder.get('item from page stepx') we'd have self.stepx.get('item')
[13:29:06] -!- PetefromTn_ has quit [Ping timeout: 255 seconds]
[13:29:33] <jepler> http://emergent.unpythonic.net/files/sandbox/0001-stepconf-Try-to-work-better-with-duplicate-IDs.patch
[13:30:04] <jepler> this uses one builder per file. get_object looks through all files, throwing an exception if the name's not unique
[13:31:10] -!- mozmck has quit [Ping timeout: 240 seconds]
[13:31:13] -!- quiqua has quit [Ping timeout: 240 seconds]
[13:31:13] -!- dramz has quit [Ping timeout: 240 seconds]
[13:31:14] -!- zeeshan has quit [Ping timeout: 240 seconds]
[13:31:15] quiqua_ is now known as quiqua
[13:31:25] -!- DaViruz has quit [Ping timeout: 240 seconds]
[13:31:26] -!- somenewguy has quit [Ping timeout: 240 seconds]
[13:31:26] -!- copec has quit [Ping timeout: 240 seconds]
[13:31:27] -!- archivist has quit [Ping timeout: 240 seconds]
[13:31:32] -!- Vq has quit [Ping timeout: 245 seconds]
[13:31:54] copec_ is now known as copec
[13:32:24] -!- mozmck [mozmck!~moses@67.210.159.245] has joined #linuxcnc-devel
[13:32:28] -!- archivist [archivist!~archivist@host81-149-189-98.in-addr.btopenworld.com] has joined #linuxcnc-devel
[13:35:43] -!- skunkworks_ [skunkworks_!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[13:35:50] -!- malcom2073 [malcom2073!~quassel@unaffiliated/malcom2073] has joined #linuxcnc-devel
[13:38:54] -!- LeelooMinai [LeelooMinai!~leeloo@184.175.46.197] has joined #linuxcnc-devel
[13:52:18] -!- SpeedEvil has quit [Ping timeout: 250 seconds]
[13:53:20] khetzal- is now known as khetzal
[13:57:07] -!- phantom has quit [Ping timeout: 256 seconds]
[13:58:41] <cradek> jepler: I forgot how badly this all worked:
http://emergent.unpythonic.net/01165199941
[13:58:54] <jepler> cradek: there's a reason I'd rather delete it all and forget it ever happened
[14:02:05] -!- kwallace [kwallace!~kwallace@smb-191.sonnet.com] has joined #linuxcnc-devel
[14:05:54] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[14:08:58] <cradek> > The Pluto-P is an inexpensive ($60) FPGA board
[14:09:16] <cradek> the 5i25 makes this look silly
[14:09:52] <pcw_home> or the 7I90
[14:11:51] -!- swingley has quit [Ping timeout: 255 seconds]
[14:11:53] <pcw_home> or buy a lattice ICE40-1k for ~$5 and plop it on a a board
[14:14:42] -!- quiqua has quit [Quit: quiqua]
[14:15:07] <kwallace> The FPGA programming scares me away.
[14:16:17] <pcw_home> ucontrollers scare me away (fixed pin functions???????)
[14:17:30] <kwallace> touché
[14:17:55] <cradek> 5i24 is interesting - what's the price?
[14:17:59] <cradek> (not on the list)
[14:18:32] -!- Tecan has quit [Ping timeout: 245 seconds]
[14:18:47] <pcw_home> it should be on the list (or at the store)
[14:19:05] <CaptHindsight> http://store.mesanet.com/index.php?route=product/product&product_id=298
[14:19:43] <cradek> store!
[14:19:51] <cradek> I was not aware of this
[14:21:06] <pcw_home> $119 for the 5I24-16
[14:21:07] <cradek> the 7i90 has more plugs than the 7i43, and is cheaper
[14:21:22] <cradek> you have new stuff every time I look
[14:21:44] <pcw_home> and the 7I90 can be a ss remote!
[14:22:09] <skunkworks_> so it is a more compact/less expensive 5i20? (5i24)
[14:22:41] <pcw_home> yeah or a 72 I/O 5I25
[14:22:58] <skunkworks_> neat
[14:23:04] <pcw_home> 6I24 is coming
[14:23:14] <pcw_home> (PCIE version)
[14:23:45] -!- ravenlock has quit [Ping timeout: 256 seconds]
[14:24:04] <cradek> do you program 5i24 like 5i25, with mesaflash, instead of at startup?
[14:24:27] <CaptHindsight> they make working on RTAI less attractive
[14:24:40] <pcw_home> Yeah its pretty much exactly a 5i25 with a bigger FPGA.more I/O pins
[14:25:22] <pcw_home> mesaflash already works with it
[14:25:38] <skunkworks_> pcw_home: you are awesome!
[14:26:04] <pcw_home> Nah just lazy, the boards are really all the same
[14:26:12] <skunkworks_> heh
[14:26:43] <skunkworks_> I hope between linuxcnc and your other customers - you are more than comfortable.
[14:27:48] <pcw_home> like the 5I25 (and 7I80 family) the 5i24 now supports FPGA reload without needing to power cycle or reboot
[14:28:10] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[14:28:33] <jepler> pcw_home: so I got this "odroid" which has an SPI interface (1.8v). The mesa cards I have are 7i43, 5i20, and 7i80. I don't suppose you have a firmware that will make any of those boards talk SPI, do you?
[14:28:44] <pcw_home> (thanks to Michael G for adding that)
[14:29:50] -!- sylphiae has quit [Ping timeout: 255 seconds]
[14:30:04] <pcw_home> I have the firmware for a 7I90, it should be portable to any FPGA card, mainly needing a new UCF file and an available GCLK pin
[14:30:47] <pcw_home> the 7I90 manual has the protocol
[14:31:04] <jepler> the SPI clock is restricted to being on GCLK pins?
[14:31:12] <pcw_home> yes
[14:32:00] <pcw_home> I could make a non gclock version but it would likely be slower
[14:32:38] <CaptHindsight> what's the max SPI clock speed on the 7i90? 50 or 100MHz?
[14:32:45] <pcw_home> currently it works at 50 Mbits/sec
[14:33:21] <pcw_home> if the host could generate a continuous clock I can do 100 MBits/sec
[14:33:56] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[14:34:48] <jepler> in the 7i43u.ucf file I have, there are some pins called SPI* -- does it have SPI?
[14:35:16] <pcw_home> the 7I43 has SPI I/O to access its flash EEPROM
[14:35:19] <jepler> ah
[14:35:31] <jepler> not relevant in this context
[14:36:22] <skunkworks_> what are GCLK pins use for?
[14:36:46] <skunkworks_> normally
[14:37:05] <CaptHindsight> maybe it's time to hack a ARM Chromebook's for its SPI
[14:37:08] <pcw_home> but TopHostMot2GCSPI.vhd shoud work with a 7I43 with a proper .ucf file
[14:37:50] <pcw_home> Those are global clocks (clock spines) that have low skew across the FPGA chip
[14:38:11] -!- lair82 [lair82!616b5c34@gateway/web/freenode/ip.97.107.92.52] has joined #linuxcnc-devel
[14:38:51] <jepler> pcw_home: seems unlikely there's a GCLK on the parallel port header
[14:39:17] <jepler> I don't see EPP control signals in the ucf file
[14:40:18] -!- FreezingCold has quit [Ping timeout: 244 seconds]
[14:40:29] <pcw_home> let me look at the schematic
[14:42:22] <lair82> Good morning guys, I just loaded the latest version on master on a turning center, as of friday afternoon, and noticed something interesting with the new trajectory planer. On one of my test programs, a simple diamond shape, it takes a shortcut on the last corner, instead of following the programmed path. Where would be the best place to post some pics of what it is doing?
[14:43:17] <lair82> I set ARC_BLEND_ENABLE to zero ad re-ran the program and runs fine.
[14:43:56] <lair82> It only does it on the first run of the program, all consecutive runs after that it ran fine.
[14:44:04] <jepler> lair82: does the problem occur with your test program and the sample config sim/axis/lathe.ini ?
[14:44:27] <jepler> (yuck)
[14:45:15] <lair82> I didn't try any other configs due to it running fine with arc blending disabled.
[14:45:53] <jepler> lair82: can you try it now? ideally, you would be able to post just the gcode, and anyone would be able to reproduce the problem..
[14:47:10] <jepler> pcw_home: looks like a couple of the GCLKs are on the HD50 headers, so for playing around I could sure do it that way
[14:47:47] <lair82> G00 X-2.000 Z-10.000 G03 X-6.000 Z-6.000 I-4.000 K0.000 F150 G03 X-10.000 Z-10.000 I0.000 K-4.000 F150 G03 X-6.000 Z-14.000 I4.000 K0.000 F150 G03 X-2.000 Z-10.000 I0.000 K4.000 F150 M30 %
[14:47:54] <pcw_home> unfortunately no GCLK pins on the parallel interface (but 4 on GPIO)
[14:51:34] <jepler> pcw_home: as far as I/O level translation of the SPI signals, there's a cheap board based on TXB0104 I could get. Datasheet makes it sound like it should work at up to 25MHz SPI clock ("pulse duration 17ns" @ VCCa=1.8V, VCCb=3.3V)
[14:52:39] <cradek> lair82: each of those is 3/4 of a circle. did you mean them to be 1/4 of a circle?
[14:53:46] <pcw_home> Most of the SOCs SPI interfaces have wide SPI clock settings so you just need to see how fast it can go
[14:55:23] <jepler> pcw_home: I haven't even started to get a handle on that end of things
[14:55:50] <pcw_home> thats the ugly non portable side...
[14:55:59] <jepler> no doubt
[14:56:14] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[14:56:45] -!- BitEvil has quit [Changing host]
[14:57:03] -!- phantomD has quit [Ping timeout: 240 seconds]
[14:58:07] -!- kwallace2 [kwallace2!~kwallace@smb-216.sonnet.com] has joined #linuxcnc-devel
[14:59:09] <cradek> lair82's code, which works fine for me in sim/axis/lathe:
http://pastie.org/9444468
[14:59:22] <pcw_home> If you had pins to spare a FPGA board could be made with selectable I/O voltage for the SPI interface bank
[14:59:25] -!- kwallace has quit [Ping timeout: 244 seconds]
[15:00:42] <lair82> I rewrote the program, and am going to check it now, one of the programmers made that program last year for me, and that is one of the ones I tune my machines with. It shows up as a diamond with sharp corners on the live plot.
[15:01:26] <jepler> # CONFIG_SPI_SPIDEV is not set
[15:01:39] <jepler> too bad, spidev looks like it makes most of spi devices available in userspace
[15:01:43] <jepler> https://www.kernel.org/doc/Documentation/spi/spidev
[15:02:52] <cradek> lair82: do you mean the arcs show up as straight lines?
[15:03:18] <pcw_home> SPIDEV would be nice at least for initial poking about
[15:03:45] <skunkworks_> lair82: my first thoughts are that you have no tolerance defined - It will try to cut the corners as much as it can to keep the velocity up..
[15:04:04] <jepler> I also see lair82's program as a circle repeated 3 (?) times
[15:04:06] <jepler> bbl
[15:04:08] <ssi> jepler: it shouldn't be terribly hard to write an rt kernel space component that uses spi
[15:04:11] <cradek> lair82: I don't understand your problem report yet
[15:04:14] <ssi> I did something similar on beagle
[15:04:33] <jepler> ssi: linuxcnc for rt-preempt runs all in userspace though
[15:04:35] -!- BitEvil has quit [Quit: No Ping reply in 180 seconds.]
[15:04:42] <ssi> either way
[15:04:55] <ssi> the spidev stuff is mostly just for the devfs access
[15:04:58] <cradek> [I booted the newest image live, and built and ran a comp, without installing any packages]
[15:05:15] <skunkworks_> jepler: what kind of latency are you getting on that board?
[15:05:18] <skunkworks_> cradek: Yay!
[15:05:18] <ssi> it's just a devfs wrapper on top of the ioctls
[15:07:00] <skunkworks_> cradek: andy will be very happy (well - maybe somewhat happy) :)
[15:08:22] <lair82> I just re-ran it with the following code, and it did the same thing, WAY undershot the the final corner before heading back to the starting point. The first two corners are nice and tight, the third is way off.
[15:08:31] <lair82> G00 X-2.000 Z-12.000 G01 X-2.000 Z-12.000 F150 G01 X-6.000 Z-6.000 F150 G01 X-10.000 Z-12.000 F150 G01 X-6.000 Z-18.000 F150 G01 X-2.000 Z-12.000 F150 M30 %
[15:08:54] <lair82> I will post the pics on the forum then post the link here
[15:14:55] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[15:18:23] <skunkworks_> lair82: I get this on lathe sim...
http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-08-04%2010:16:11.png
[15:18:36] <lair82> Here is the link, its the last post to forum list about the new tp.
http://www.linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=180#49495
[15:19:43] <jepler> that one at least looks like a diamond in preview
[15:19:59] <skunkworks_> lair82: do you have any tolerance set? it looks like normal blending...
[15:20:14] <lair82> no tolerances are set,
[15:20:29] <jepler> but for me in sim/axis/lathe.ngc, the backplot matches the preview
[15:20:37] <skunkworks_> *normal blending / low acceleration..
[15:20:45] <jepler> skunkworks_: I don't have a preempt-rt kernel built yet, so I don't have a latency figure worth publishing
[15:20:52] <jepler> bbl again
[15:21:32] <skunkworks_> because the new tp reaches a higher velocity - it probably blends the last segment higher.
[15:22:24] <lair82> but why would any run of this program after the first one with the new TP enabled look like the bottom pic with it disabled?
[15:23:05] <lair82> Its only the very first run of the program that it does this
[15:24:02] <skunkworks_> hmm - can you post your configs?
[15:24:13] <lair82> Will do,
[15:26:04] -!- swingley has quit [Remote host closed the connection]
[15:27:09] <CaptHindsight> is linuxcnc.org down? not even a ping right now
[15:27:35] <seb_kuzminsky> it's down for me too
[15:28:03] <seb_kuzminsky> i can ssh in
[15:28:06] <seb_kuzminsky> but not http
[15:28:25] <seb_kuzminsky> oh wait, now its back with http
[15:28:35] <skunkworks_> lair82: is this an english or metric machine?
[15:28:48] <lair82> english
[15:28:57] <skunkworks_> ah - ok - so big...
[15:29:08] <skunkworks_> (I thought it was metric from the lenghts..
[15:29:13] <skunkworks_> let me play
[15:29:23] <jepler> I also tucked in a G21 to make it run in sim lathe
[15:30:34] <jepler> OK, duplicated here
[15:30:49] <jepler> the first blend on the left is much bigger than the second
[15:31:36] <jepler> showing two runs:
http://emergent.unpythonic.net/files/sandbox/lair82b.png
[15:32:07] <cradek> does it violate a tolerance setting?
[15:32:17] <jepler> no idea
[15:32:27] <jepler> but under whatever setting, wouldn't you expect the same thing every time?
[15:32:38] <seb_kuzminsky> i would
[15:32:45] <cradek> yeah, I'd expect it
[15:32:59] -!- dan2k3k4 has quit [Ping timeout: 264 seconds]
[15:33:13] <jepler> no valgrind diagnostics in rtapi_app
[15:33:21] <jepler> so it's not "simply" something uninitialized
[15:33:24] <cradek> I have a feeling that when you start the program you start moving but you don't know all the future program yet
[15:33:47] <jepler> cradek: but that's different the next time you run the same program from the start?
[15:34:05] * cradek shrugs
[15:35:34] <ssi> it's just a devfs wrapper on top of the ioctls
[15:35:39] <ssi> mischn sry
[15:36:08] <cradek> whoah, that's a big blend
[15:36:14] <cradek> (in the forum post)
[15:36:29] <skunkworks_> It is because you have the extra entry move when you first start..
[15:36:46] <jepler> skunkworks_: that's a good point, hmm
[15:37:01] <skunkworks_> if you put g0x0z0 at the end - it does the first path over and over
[15:37:07] <cradek> I'd still like to know if it violates tolerance
[15:37:17] <skunkworks_> there is not tolerence.. so no.
[15:37:31] <cradek> I don't know what behavior you're supposed to have now, with unspecified tolerance
[15:37:55] <jepler> what skunkworks_ says I confirm too: the behavior at that left corner is dependent on the start location
[15:38:28] <skunkworks_> if you add a tolerance - say .05" it follows that.. every time
[15:38:57] <jepler> and I agree with that as well (I added G64 P.1 Q.1)
[15:39:06] <skunkworks_> but that would be a question for rob.. I don't see it as an issue yet..
[15:40:00] <lair82> But why does it run fine all consecutive passes?
[15:40:14] <cradek> read above
[15:41:28] <jepler> I'm prepared to agree it's surprising and counterintuitive
[15:41:33] <lair82> Are you referring tho this "It is because you have the extra entry move when you first start"
[15:41:52] <cradek> yes
[15:42:00] <cradek> so it does behave the same way every run
[15:42:03] <jepler> but when you make a TP that takes multiple segments into account, you do get a "non-local" effect, where the path a few moves ago can change a blend at a given point
[15:42:45] <lair82> It scared the shit of me, a turret weighing over 3000lbs going the wrong way at 150 IPM
[15:43:47] <lair82> It runs properly after the first run, the first time is messed up, all consucutive passes are fine.
[15:43:58] <skunkworks_> did master change the coloring so that you don't see if the planner falls back to parabolic blending?
[15:44:11] <skunkworks_> (used to be yellow)
[15:44:11] <lair82> "consecutive"
[15:44:15] <skunkworks_> but I don't see any now.
[15:44:20] <cradek> yes the coloring hack broke rapid override, so I had to remove it
[15:44:32] <skunkworks_> ok
[15:44:55] <cradek> it miscolored by lying about the type of move (rapid or feed)
[15:45:14] <cradek> which is a lie that is problematic :-)
[15:45:31] <jepler> lair82: If I start the program with the tool at -2,-12 I get one behavior (the one you call "proper") and if I start it at 0,0 I get the other behavior (the one you call "wrong")
[15:45:48] <skunkworks_> because you could tell what was happing - begining and ending segment would usually fall back to parabolic blends (as begining segments needed to que up and ending segments didn't know if it was the end of the program or just que starvation.. - from my understanding)
[15:45:54] <jepler> lair82: it appears to be dependent on the starting location, not whether it is "the first time"
[15:46:09] <skunkworks_> so you could get different behavior depending on how the program ran
[15:46:21] <cradek> skunkworks_: just from eyeballing the shape, I am pretty sure this surprising blend is a circular blend
[15:46:22] <jepler> there are clearly two different blends you can get
[15:47:03] <lair82> Ok I will buy that, what would be the best case way o handle this from a gcode programming standpoint?
[15:47:10] <cradek> skunkworks_: (I can't tell on the little ones)
[15:47:12] <jepler> lair82: program a tolerance
[15:47:18] <skunkworks_> G64 Px.xxx
[15:48:00] <cradek> lair82: for production work on a big machine, I would not recommend using master. by all means help us test it, but maybe do it in simulation
[15:48:14] <lair82> Could I put that in my INI so it is always in effect?
[15:48:28] <jepler> put it in each part file
[15:48:42] <jepler> put all important modal codes in the prologue of each part file
[15:49:00] <skunkworks_> It is an odd blend though...
[15:49:05] <skunkworks_> compared to the others..
[15:49:40] <lair82> I hate to say it, but all three of our turning centers ( all over 40,000 lb machines) are running master, for the last year.
[15:50:12] <skunkworks_> the little blend is circular too.. it looks like.
[15:50:34] <skunkworks_> lair82: that is good - looks of good testing then :)
[15:51:03] <cradek> since 2.6 has been released, we're feeling more free to put new stuff in master. it's normal for master to be less stable right after a release. you might want to reevaluate with that knowledge.
[15:51:22] <jepler> though if you are already "depending" on a feature in master that is not in 2.6, that puts you in a bit of a bind
[15:51:38] <cradek> is that the case?
[15:51:42] <lair82> Isn't the new TP supposed to handle this, it sounds counter productive to half to program a tolerance in to avoid a crash of the machine?
[15:51:53] <jepler> the new TP is supposed to go faster
[15:51:58] <jepler> it's supposed to follow the programmed tolerance
[15:52:00] <cradek> and that does not look like a crash
[15:52:09] <jepler> if there's no programmed tolerance, I don't see how you can argue the path is wrong
[15:53:29] <lair82> I just say it is wrong because of what it did on the last cornering move it makes that doesn't match what it does on the first corner which is identical.
[15:54:04] <cradek> we all agree it is surprising
[15:54:11] <cradek> you are the only one who is sure it is wrong
[15:54:27] <lair82> It doesn't look like a crash now but down the road it would probably lead to one depending on the what you are running.
[15:55:42] <jepler> I'll say this about the last blend: it keeps up velocity perfectly
[15:55:58] <jepler> unlike the other two blends, where you can observe a velocity dip; in the case of the first blend, about 50%
[15:56:26] <lair82> If it was a rapid move, oh well, but a G01 feed move is why I have issue with it.
[15:56:42] <cradek> if you add some more (long?) moves before and after this program, you might get big blends and constant velocity everywhere
[15:56:57] <jepler> http://emergent.unpythonic.net/files/sandbox/lair-velocity.png
[15:57:16] -!- phantom has quit [Ping timeout: 255 seconds]
[15:57:22] <lair82> It does look nice,
[15:57:38] <lair82> The backplot that is,,,
[15:59:16] <lair82> We have never programmed a tolerance on any of the machines, and they run beautifully, without incident, regardless of speed
[15:59:26] <jepler> with g64 p.1 specified, the blends are not quite identical.
http://emergent.unpythonic.net/files/sandbox/lair-velocity-g64-p.1.png
[16:00:39] -!- spatialbrew has quit [Ping timeout: 256 seconds]
[16:04:30] <skunkworks> if you add more segments to the beging of the program - they all start to blend the large amount...
[16:04:37] <skunkworks> begining
[16:04:52] <skunkworks> (g1 moves)
[16:05:08] <jepler> because the new planner has to "warm up"?
[16:05:16] <skunkworks> I think so..
[16:05:32] <jepler> I put it in a loop and after the first time around, the big blend also shows up on the right
[16:07:57] <skunkworks> it takes time to read-ahead iirc
[16:08:05] <skunkworks> like a few segments at the begingin
[16:11:00] <skunkworks> maybe how fast it gets the segments?
[16:12:22] -!- skunkworks_ has quit [Ping timeout: 250 seconds]
[16:15:19] -!- PetefromTn_ has quit [Quit: I'm Outta here!!]
[16:23:18] <kwallace2> I've gotten used to specifying a tolerance (, almost). At first, I had trouble with threading and some of my pocket entry moves, but a tolerance fixes it. I'm wondering how CAM programs are going to handle the new policy.
[16:23:25] <skunkworks> jepler, I bet then the velocity smooths out also
[16:23:43] <skunkworks> it is probably making the radius to keep at 150ipm.
[16:24:35] <CaptHindsight> preempt-rt doesn't run graphics driver tasks through the scheduler, so I have a feeling that xenomai will be the only way to have low latency and hardware accell drivers at the same time
[16:24:47] <memleak> hi all, im going to merging in xenomai-specific changes from ubc-3 into linuxcnc, what branch do you think would be best to merge it into? master or 2.6?
[16:26:04] <jepler> memleak: we do not want ubc-3 merged into any branch of linuxcnc
[16:26:07] <ssi> is there an ini setting for a default and/or maximum tolerance?
[16:26:35] <cradek> ssi: no but it seems like maybe there should be. perhaps add a feature request in the tracker?
[16:26:35] <memleak> jepler im not merging in ubc-3, im specifically only merging in the xenomai-specific code.
[16:27:20] <jepler> memleak: OK, in git "merge" has a specific technical meaning and I assumed you were using it in that technical sense.
[16:27:29] <ssi> I can do that
[16:27:53] <memleak> no im talking about a partial re-write of the xenomai code and getting xenomai support added.
[16:27:57] <jepler> memleak: I am pretty sure that seb doesn't want any new RTOSes in 2.6; he declined when I asked whether uspace should go there.
[16:28:11] <cradek> adding xenomai support means expanding uspace, right? then it clearly needs to be based on master
[16:28:31] <memleak> ok.
[16:28:44] <jepler> memleak: and yes, if you are talking about a userspace xenomai port then it ought to be based on uspace, which is only in master branch
[16:29:28] <kwallace2> ssi: I do see this as an .ini option: "RS274NGC_STARTUP_CODE = G01 G17 G20 G40 G49 G64 P0.001 G80 G90 G92 G94 G97 G98 - A string of NC codes that the interpreter is initialized with."
[16:29:31] <memleak> i was thinking about sharing it with the RTAI support, not so much uspace.
[16:30:24] <cradek> are you talking about kernel xenomai or userspace xenomai?
[16:30:26] <jepler> but the RS274NGC_STARTUP_CODE is not executed before each part program, so if you think you can set tolerance for all part programs using it you will be disappointed.
[16:30:42] <ssi> kwallace2: yeah that could be used
[16:30:46] <kwallace2> Oops.
[16:31:31] -!- skunkworks_ [skunkworks_!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[16:31:34] <jepler> so similarly I don't think a feature request for a "default" tolerance makes much sense
[16:31:59] <jepler> because a previous MDI or part program that says G64 P100 would override a "default"
[16:32:18] <ssi> https://sourceforge.net/p/emc/feature-requests/123/
[16:32:18] <cradek> by default, I mean what tolerance should be used when in plain g64 mode, aka g64 p0, aka the default mode
[16:32:40] <jepler> (oh and btw it's a hoot to run lair82's program in an O repeat loop with the stupid tolerance setting of G64 P100 Q100 -- it goes backwards!)
[16:32:43] <memleak> whats the difference?
[16:33:05] <ssi> ah so G64 is modal, so it'll persist between programs?
[16:33:08] <jepler> cradek: oh, that might make some sense then, but you still have to program a tolerance in each part program
[16:33:38] <memleak> i was going to add in xenomai support in linuxcnc for when /usr/xenomai is installed with xenomai patched kernel, whatever term that is.
[16:33:59] <jepler> memleak: xenomai kernel space doesn't have math support, does it?
[16:34:25] <jepler> ubc copied in a libc with a nondistributable license and I had the impression it was for xenomai :-/
[16:34:30] <jepler> er, a libm
[16:34:58] <memleak> whats the default when using xenomai in ubc3? its userspace right?
[16:35:13] <jepler> I think support for both is in there
[16:35:17] <jepler> but .. don't quote me
[16:35:35] -!- mozmck has quit [Read error: Connection reset by peer]
[16:35:36] <memleak> there is.
[16:37:16] -!- mozmck [mozmck!~moses@67.210.159.245] has joined #linuxcnc-devel
[16:40:37] -!- zzolo has quit [Quit: zzolo]
[16:40:58] -!- jduhls has quit [Ping timeout: 260 seconds]
[16:44:12] <jepler> memleak: anyhow, whether userspace or kernel space you should do new rtos work in a way that it can be merged into master branch; I don't think seb's interested in merging new rtoses to 2.6 (he wasn't for me)
[16:44:49] <jepler> memleak: but in git with the "merging upwards" workflow that we follow, starting a branch from 2.6 does not mean it can't be merged to master, and the v2.6.0 tag is likely to be more stable (have less unrelated breakage) than a random commit on the master branch
[16:44:55] <cradek> ssi: I added my thoughts, thanks for creating it
[16:45:00] <ssi> sure thing
[16:45:41] <memleak> i'd like to merge xenomai support from before new rtos code was added in, so 2.6 would be easier.
[16:46:12] <memleak> i can just throw it in as a new thread along side RTAI and that would be pretty easy i think.
[16:46:23] <cradek> I don't see how you start from before uspace
[16:46:46] <memleak> the same way RTAI works without uspace.
[16:47:00] -!- dan2k3k4 has quit [Read error: No route to host]
[16:47:06] <cradek> xenomai kernel mode is going to have the math problem
[16:47:20] <memleak> unless libm gets added?
[16:47:52] <cradek> is kernel mode better than user mode?
[16:48:02] <memleak> thats what i want to know..
[16:48:17] <memleak> better you mean in regards to latency yes?
[16:48:41] <cradek> I have no idea. I'm asking why you're making that decision, when user mode would seem to have fewer big obstacles
[16:49:41] <memleak> well if im going for uspace i'd use xenomai 3.x (based off PREEMPT_RT)
[16:49:46] <cradek> user mode seems downright easy (and very easy to decide to merge into master) if you base it on the uspace work
[16:50:08] <memleak> only problem is that im more familiar with kernel, not uspace..
[16:51:17] <memleak> what changes would have to be added for xenomai userspace support if the branch of xenomai uses the preempt_rt kernel patches?
[16:53:22] <cradek> all I know is from jepler's emails, Subject: [Emc-developers] "jepler/rtos-uspace": a new POSIX realtime branch
[16:53:51] -!- jdh_ has quit [Quit: leaving]
[16:53:52] <memleak> http://git.xenomai.org/xenomai-forge.git/tree/README.INSTALL?h=next#n62
[16:55:25] <jepler> if the kernel is PREEMPT-RT then I don't think linuxcnc needs xenomai
[16:55:32] <memleak> oh..
[16:55:54] <memleak> but if IPIPE is used then you need extra linuxcnc code?
[16:56:30] <jepler> xenomai based on ipipe? yes (though didn't xenomai have an implementation of rtai apis in there as a "skin"?)
[16:56:47] <memleak> it does yes.
[16:57:07] <memleak> ok so for IPIPE xenomai (2.X) what would need to be done, in summary?
[16:57:33] <memleak> userspace..
[16:57:53] -!- phantomD has quit [Ping timeout: 256 seconds]
[16:58:31] <memleak> just hook in xenomai.c and xenomai.h with necessary rtapi changes? (and of course ./configure) ?
[16:58:46] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[16:59:01] <jepler> it will not work simply by copying files from ubc3
[16:59:16] <memleak> i understand that.
[16:59:31] <jepler> in src/rtapi/rtapi_uspace.hh there is 'struct RtapiApp'
[16:59:33] <cmorley> lair82: do you need the new tp feature for your lathes? I think you can turn it off in INI - maybe that would help your problem ..
[17:00:12] <jepler> you would implement a subclass of RtapiApp which uses the right xenomai calls for everything (all the 'virtual' functions, like task_start for instance)
[17:00:57] <jepler> and in uspace_rtapi_app.cc makeApp you would create an instance of your Xenomai class instead of Posix, if it's a Xenomai kernel
[17:01:02] <jepler> bbl, it's lunchtime here
[17:01:20] -!- sumpfralle has quit [Ping timeout: 250 seconds]
[17:01:32] <memleak> thats it?
[17:01:33] <jepler> there are other details and of course since this is the second subclass of RtapiApp you may discover that there is stuff that needs to be different than Posix but which isn't "virtual" in the base class..
[17:01:44] <jepler> good luck, I'll try to answer specific problems when you have them.
[17:03:49] <memleak> but basically all xenomai userspace code could go in the uspace files? i dont need to change much else?
[17:04:12] -!- GargantuaSauce has quit [Ping timeout: 255 seconds]
[17:05:04] -!- olivd has quit [Quit: Leaving]
[17:08:28] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[17:13:22] <lair82> cmorley , sorry I didn't chime back in, lunch time, I did turn it off for now, until the shop guys can get used to putting that into the pre-amble of the program.
[17:14:26] <lair82> We are looking into if we can change our post processor to automatically include it in our programs.
[17:14:42] <cmorley> ahh better idea probably
[17:17:22] -!- gambakufu has quit [Ping timeout: 255 seconds]
[17:18:54] -!- SpeedEvil has quit [Quit: No Ping reply in 180 seconds.]
[17:22:26] <ssi> lair82: did you see the note above about the RS274NGC_STARTUP_CODE ini variable?
[17:22:33] <ssi> lair82: you can default the machines that way it looks like?
[17:23:51] <memleak> would it make any sense for xenomai with preempt-rt kernel patch have any better latency results than preempt-rt standalone?
[17:23:55] <lair82> I did yes, but I'm not sure what they put in the pre-amble now, so I am going to keep it disabled for the time being. I finished the upgrade this morning, and while I was picking up my notebooks, the operator was standing there waiting to make some chips
[17:24:47] -!- zeitue has quit [Ping timeout: 245 seconds]
[17:25:20] <lair82> We already have quite a few gcodes in that section of the INI, but as the guys said the operator can override that going to MDI.
[17:25:29] <skunkworks> sure
[17:25:39] <memleak> skunkworks, was that to me?
[17:25:53] <skunkworks> memleak, no.. (that all is above my pay grade..)
[17:26:00] <memleak> XD ok sorry.
[17:31:02] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 20.0/20130329043827]]
[17:33:34] <mozmck> memleak: that's what I have wondered. seems like an extra layer that would just add more overhead.
[17:33:59] <seb_kuzminsky> cradek: i think you said you tried to use a gtk.Builder for each stepconf .glade file (instead of calling add_from_file() from within a single Builder), but you ran into problems, is that right?
[17:34:12] <seb_kuzminsky> i mailed the glade-developers list about our problem and asked for their input
[17:38:32] -!- sudobangbang has quit [Ping timeout: 245 seconds]
[17:51:28] <jepler> with this patch, stepconf works with multiple builders:
http://emergent.unpythonic.net/files/sandbox/0001-stepconf-Try-to-work-better-with-duplicate-IDs.patch
[17:51:34] <jepler> by faking a builder that knows about all IDs
[17:52:20] <jepler> if you have multiple builders, you have to look up the object in the right builder
[17:53:17] <seb_kuzminsky> ahh, python, what are we going to do with you? + objects = [o for o in objects if o]
[17:53:53] <jepler> would you have preferred objects = filter(None, objects) as being clearer?
[17:54:13] <seb_kuzminsky> i have no preference
[17:54:36] <seb_kuzminsky> thanks for writing that
[17:55:00] <seb_kuzminsky> i'm waiting to hear back from glade-developers & see what they recommend
[17:56:14] <seb_kuzminsky> cmorley informs me that when you create a new page in glade, it pre-populates all the object ids in a default way that's guaranteed to cause collisions, and you have to manually rename them everywhere if you want to avoid collisions
[17:56:43] <seb_kuzminsky> that's why all the stepconf ids look like "object type" + "small integer"
[17:57:34] -!- phantom has quit [Ping timeout: 250 seconds]
[17:57:44] <jepler> yup, I really get the impression that one builder, multiple files is their idea of a sane workflow
[17:57:52] <jepler> er, don't get the impression
[17:58:32] <jepler> and "that used to work 4 years ago" falls on deaf ears .. (which is true for us as well, witness our discussion of the new blending earlier today)
[17:59:01] -!- patrickarlt has quit [Remote host closed the connection]
[17:59:23] <skunkworks_> http://linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=180#49500
[18:01:42] -!- swingley has quit [Remote host closed the connection]
[18:04:57] -!- swingley has quit [Remote host closed the connection]
[18:05:33] <jepler> ugh, no "pin 1" marks on the odroid's I/O headers
[18:05:35] <seb_kuzminsky> jepler: 0001-stepconf-Try-to-work-better-with-duplicate-IDs.patch looks like a really good solution to me
[18:06:52] <seb_kuzminsky> it lets gtk.Builder enforce object id uniqueness within each .glade file, it removes the accidental cross-file object id collision problem we have now, and it doesn't force the devs to rename objects that aren't accessed by the python script
[18:07:03] <jepler> yes
[18:07:03] <skunkworks_> jepler: so then this is what happens if you run it more than once...
http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-08-04%2013:06:13.png
[18:07:20] <jepler> skunkworks_: yeah that's about like what I saw
[18:07:34] <jepler> seb_kuzminsky: the only downside is that, if your testing doesn't get 100% coverage of stepconf, there might be a conflicting ID that you didn't notice
[18:07:54] <jepler> well, the only downside I've thought of so far
[18:08:36] <jepler> clearly we need to get GUI testing into linuxcnc in somebody's spare time
[18:08:46] Tomashe1 is now known as Tomashe
[18:09:20] -!- swingley has quit [Remote host closed the connection]
[18:09:22] <seb_kuzminsky> that would be good
[18:10:16] <jepler> seb_kuzminsky: with your odroid, do you have the RTC battery and case? Did you find a good way to install it? Right now I place it on the bottom side over some SMD components near the 8-pin I/O connector, but I'm not sure it's not getting squished by the board & case...
[18:10:31] <seb_kuzminsky> no battery, no case
[18:10:34] <jepler> OK
[18:10:36] <seb_kuzminsky> totally ghetto
[18:11:15] <jepler> mine'll be ghetto real soon, the case also doesn't expose the headers so I'll be taking a drill or dremel to it if I get around to trying to set up hostmot2-spi
[18:12:03] <jepler> on another subject: "uspace" package vs non-realtime kernels and vs realtime kernels and configs with base threads
[18:12:34] <jepler> the "uspace" package always has a setuid rtapi_app, so it'll use the realtime scheduling priority .. but not meet deadlines
[18:12:46] <jepler> .. so everybody who starts a sim config will get errors
[18:13:21] <jepler> similarly, sim configs like lathe that have encoder counters use a base thread that is typically fast enough that even a proper RT kernel doesn't keep up -> more errors
[18:13:33] <jepler> I'm looking for opinions about what to do about these two things
[18:13:54] <jepler> in the first case, probably check for RT and not use realtime scheduling in this case
[18:14:12] <jepler> in the latter case, I'm not sure what to do. A flag you can use before creating the first thread which says "never warn about missed deadlines"?
[18:15:35] <jepler> .. sim configs would set this flag, real configs wouldn't
[18:19:13] -!- patrickarlt has quit [Remote host closed the connection]
[18:24:44] -!- djinni` has quit [Ping timeout: 240 seconds]
[18:36:16] <memleak> jepler, how would i go about finding the "right xenomai calls for everything (all the 'virtual' functions, like task_start for instance)"
[18:36:56] -!- sumpfralle has quit [Ping timeout: 244 seconds]
[18:37:09] <memleak> cant i copy that stuff from ubc-3 or no?
[18:38:36] <jepler> well for instance you can see that rtapi_task_start simply calls App().task_start
[18:39:03] <jepler> so it will be useful to study the ubc implementation of rtapi_task_start for xenomi userspace in order to write Xenomai::task_start
[18:39:22] <memleak> ah i see.
[18:39:32] <jepler> (in uspace_rtapi_app.cc:
[18:39:33] <jepler> int rtapi_task_start(int task_id, unsigned long period_nsec)
[18:39:33] <jepler> {
[18:39:33] <jepler> return App().task_start(task_id, period_nsec);
[18:39:33] <jepler> }
[18:39:35] <jepler> )
[18:44:59] -!- amiri has quit [Ping timeout: 264 seconds]
[18:46:45] <memleak> if a function is prefixed with __ does that mean inligned?
[18:47:18] <jepler> no. typically a leading _ indicates it is for internal use only
[18:47:34] <memleak> ah
[18:47:42] <jepler> what function in particular?
[18:48:34] <skunkworks> jepler, as far as sim.. I might not be understanding - I just built master on my laptop. I didn't do a sudo make setuid. when I start linuxcnc it says 'using posix non-realtime' and it seems to be working.
[18:49:05] <memleak> just in general because a lot of the IPIPE changes consist of adding a lot of _ before functions
[18:49:17] <memleak> and thats the only change sometimes..
[18:50:02] <jepler> memleak: so if they have a realtime version of sprintf, they would call it _sprintf ?
[18:50:15] <jepler> that's .. unique and charming
[18:50:17] <memleak> exactly.
[18:50:18] <skunkworks_> (it also says 'cannot gain I/O privileges - forgot 'sudo make setuid'?')
[18:51:50] <jepler> skunkworks_: most of my remarks were about the situation where you did "make setuid" or you installed a package
[18:51:56] <skunkworks_> ah
[18:51:58] <jepler> skunkworks_: in which case it's going to try to run with realtime, but if you don't have a realtime kernel it won't work out
[18:52:16] <skunkworks_> but you will get realtime delays - right?
[18:52:56] <jepler> yes
[18:53:41] -!- h_maximilian has quit [Remote host closed the connection]
[18:53:44] <jepler> this could happen because you're running a sim config with a 1ms period on a non-RT kernel, or because you're running a sim config with a base period (like lathe) with an RT kernel that's simply not that fast
[18:54:29] <memleak> jepler, just out of curiousity why did you add the include line for uspace_common.h to the bottom of uspace_rtapi_app.cc ?
[18:56:08] <jepler> memleak: no particularly good reason, I guess.
[18:56:37] <jepler> it's not exactly a header file .. it's some source code that is common to the ulapi and rtapi parts of uspace
[18:57:22] <jepler> it does depend on some rtapi headers being included already
[18:57:42] -!- phantomD has quit [Ping timeout: 260 seconds]
[18:58:25] -!- swingley has quit [Remote host closed the connection]
[19:10:17] -!- thomaslindstr_m has quit [Quit: Leaving...]
[19:12:54] <memleak> this is going to take me awhile im going to take a break for a bit. my head hurts.
[19:13:03] <jepler> take care
[19:13:59] <memleak> ill definitely keep working on it though, its really fun, just mentally challenging. im glad i have your help
[19:15:00] -!- lair82 has quit [Quit: Page closed]
[19:15:02] -!- lair82_ has quit [Quit: Page closed]
[19:16:48] -!- sumpfralle has quit [Quit: Leaving.]
[19:20:33] -!- skorasaurus has quit [Ping timeout: 255 seconds]
[19:21:44] phantom is now known as phantoxeD
[19:24:46] -!- Connor has quit [Read error: Connection reset by peer]
[19:25:32] -!- radish has quit [Ping timeout: 250 seconds]
[19:26:26] -!- Connor [Connor!~Connor@24.214.127.194] has joined #linuxcnc-devel
[19:26:51] -!- sumpfralle has quit [Client Quit]
[19:30:42] -!- sumpfralle has quit [Client Quit]
[19:32:31] -!- patrickarlt has quit [Remote host closed the connection]
[19:33:07] -!- thomaslindstr_m has quit [Read error: Connection reset by peer]
[19:39:04] -!- sumpfralle has quit [Ping timeout: 250 seconds]
[19:39:49] <CaptHindsight> kernel 3.16 just released, lots of new ARM SOC support
[19:45:23] -!- reventlov has quit [Quit: leaving]
[19:50:21] -!- reventlov has quit [Client Quit]
[19:53:48] -!- swingley has quit [Remote host closed the connection]
[19:57:18] -!- _1SheYode has quit []
[19:57:42] -!- phantoxeD has quit [Ping timeout: 245 seconds]
[20:00:21] -!- ashcan_ has quit [Client Quit]
[20:03:56] -!- tom_o_t has quit [Ping timeout: 240 seconds]
[20:11:35] -!- skunkworks has quit [Read error: Connection reset by peer]
[20:13:19] -!- skunkworks_ has quit [Ping timeout: 255 seconds]
[20:15:12] -!- Loetmichel has quit [Ping timeout: 245 seconds]
[20:15:56] -!- tom_o_t has quit [Changing host]
[20:16:43] -!- PCW [PCW!~chatzilla@99.88.10.65] has joined #linuxcnc-devel
[20:17:12] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[20:18:57] Cylly is now known as Loetmichel
[20:19:22] -!- sumpfralle has quit [Ping timeout: 260 seconds]
[20:26:00] -!- md-2 has quit [Remote host closed the connection]
[20:30:06] <cradek> http://thread.gmane.org/gmane.linux.distributions.emc.devel/13698
[20:30:16] <cradek> I don't know what he thinks those should be, or why
[20:30:36] -!- md-2 has quit [Ping timeout: 244 seconds]
[20:31:55] <cradek> oh maybe that's ubc3 stuff
[20:32:15] <jepler> yes when I search for those filenames I tend to come up with machinekit stuff
[20:32:34] <cradek> seems like his expectations are somehow wrong
[20:32:42] <cradek> unfortunately he doesn't say what he's trying to do
[20:33:23] <jepler> fwiw this limits.d thing looks better than appending to limits.conf
[20:33:27] <cradek> yep
[20:33:49] <cradek> I'm sure that's from pre-.d days
[20:33:53] <jepler> probably so
[20:33:57] <cradek> if someone cares, he should fix it in master
[20:34:47] <jepler> debian-kfreebsd's ping irritates me. If a host is down, it just says that and exits. but I want to use ping to find out when a host comes up..
[20:35:12] <jepler> though .. I can see the contrary point of view
[20:36:03] -!- sumpfralle has quit [Ping timeout: 240 seconds]
[20:37:34] <jepler> confirmed that shmdrv is some machinekit-only thing
[20:37:51] <PCW> its helpful when testing hardware to have a stream of incoming packets to see how far they get...
[20:38:33] <PCW> or looking for packet loss %
[20:39:25] <jepler> once the machine's up (or maybe just if it arps?) kfreebsd's ping will keep running just like linux ping
[20:40:11] <PCW> but you cant wiggle wires to see when its starts working...
[20:40:20] <cradek> I'm not seeing that in real freebsd's ping
[20:41:02] <jepler> cradek: interesting
[20:41:03] <jepler> $ ping 10.0.2.61
[20:41:03] <jepler> PING 10.0.2.61 (10.0.2.61): 48 data bytes
[20:41:03] <jepler> ping: sending packet: Host is down
[20:41:03] <jepler> $
[20:41:28] <cradek> [cradek@storage ~]$ ping 10.0.2.61
[20:41:28] <cradek> PING 10.0.2.61 (10.0.2.61): 56 data bytes
[20:41:30] <cradek> .....
[20:41:49] <jepler> is 10.0.2.61 on the local network?
[20:41:50] <cradek> do you even have a route to that address?
[20:41:52] <jepler> yes, I do
[20:41:54] <cradek> no
[20:42:01] <jepler> try something on the local network that doesn't arp
[20:42:17] <cradek> aha
[20:42:26] <cradek> it says "host is down" but then doesn't exit
[20:42:36] <cradek> it looks like it will keep going forever
[20:42:48] <cradek> 33 packets transmitted, 0 packets received, 100.0% packet loss
[20:42:52] <jepler> so still it looks like debian-kfreebsd's own brain damage
[20:42:56] <jepler> that's good to know
[20:43:17] <PCW> same in NetBSD:
[20:43:19] <PCW> ----test8.mesanet.com PING Statistics----
[20:43:21] <PCW> 97 packets transmitted, 0 packets received, 100.0% packet loss
[20:43:28] -!- TekniQue has quit [Ping timeout: 255 seconds]
[20:43:37] <jepler> PCW: did you consider raw ethernet for 7i80? if so, I am curious what you felt the pros and cons were.
[20:44:56] -!- skunkworks_ [skunkworks_!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[20:45:31] <jepler> it would seem to let you avoid a modest amount of overhead for the IP and UDP framing
[20:46:58] <jepler> I'm guessing there are some cons that outweigh a "modest" savings but I don't know what they are.
[20:47:32] -!- sumpfralle has quit [Ping timeout: 250 seconds]
[20:49:22] -!- balestrino has quit [Ping timeout: 240 seconds]
[20:52:55] <PCW> You mean just raw packets (no UDP wrapper?)
[20:53:00] <jepler> yes
[20:54:26] <PCW> I though for the few bytes used by the header, it would be convenient for customers to be able to use common and standard tools
[20:56:42] <jepler> IP header of 20 bytes, UDP header of 8 bytes is pretty small potatoes
[20:56:53] <PCW> there's a 64 byte minimum packet size anyway so for little packets it makes very little difference
[20:58:38] <jepler> on the mailing list, Charles S. suggested that raw sockets might have some benefit for realtime, but that remains unclear to me.
[20:59:05] <ssi> PCW: Got parts in the mail today; thanks! :)
[20:59:49] <PCW> It might reduce the levels of kernel traversal so might help overhead/latency somewhat
[21:00:31] <PCW> ssi welcome! (its a do it yourself kit)
[21:01:07] <ssi> hehe yes :)
[21:03:22] <jepler> PCW: yeah, now how to measure latency from send() to first bit on the wire..
[21:03:53] <PCW> I tried removing the recv polling (which make me itchy) and that works but I had to set a much longer timeout than expected
[21:03:55] <PCW> not sure if this is because some long transfers are done during startup or its a resolution issue with SO_RCVTIMEO
[21:04:42] <jepler> according to tcpdump, it was on the order of 200-300us before a read request got its response packet
[21:04:50] <jepler> the RCVTIMEO is smaller than that by an order of magnitude iirc
[21:04:53] <jepler> wasn't it 10 or 20?
[21:06:08] <PCW> I removed the loop, changed the fd policy to blocking and set the timeout (but i had to set it to like 5 ms or it would not work)
[21:06:35] <jepler> you could try with select()
[21:06:45] <PCW> so thats something of a mystery
[21:06:49] <jepler> that usleep polling loop makes my molars itch too
[21:06:59] <KGB-linuxcnc> 03Jeff Epler 05master 1dbcf2b 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hostmot2.c 10src/hal/drivers/mesa-hostmot2/setsserial.c hm2: Fix format string security warning * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=1dbcf2b
[21:07:12] <PCW> yeah the less kernel interaction the better
[21:08:33] -!- sumpfralle has quit [Read error: Connection reset by peer]
[21:08:39] <jepler> 00:00:00.000000 IP 192.168.1.121.27181 > 192.168.1.1.53356: UDP, length 16
[21:08:42] <jepler> 00:00:00.000019 IP 192.168.1.1.53356 > 192.168.1.121.27181: UDP, length 24
[21:08:46] <jepler> OK, my memory's wrong. It's more like 20us than 200us
[21:08:49] <jepler> that's good
[21:09:24] <PCW> if you have a scope you can check the7I80s timing (TP1 is RXPKT time, TP2 is TXPKT time, time between is parsing time)
[21:09:55] -!- FinboySlick has quit [Quit: Leaving.]
[21:10:07] -!- swingley has quit [Remote host closed the connection]
[21:10:20] <PCW> (that how i noticed the extra packet)
[21:12:12] <jepler> PCW: at one point you showed a tcpdump-style output which showed the udp payload bytes in hex. is there a flag to tcpdump for that?
[21:12:25] <jepler> I seem to be overlooking it; all I know how to get is the whole IP packet
[21:12:49] <PCW> Naw I just edited out the header
[21:12:54] <jepler> ah
[21:13:24] -!- Deejay has quit [Quit: bye]
[21:13:43] -!- tehcereal has quit [Quit: Leaving]
[21:13:51] -!- swingley has quit [Remote host closed the connection]
[21:14:11] <PCW> tcpdump works remarkable well on a running RT linuxcnc system
[21:16:17] <PCW> I think the Ethernet powerlink people make use of libpcap as a lower overhead raw packet interface
[21:17:29] -!- swingley has quit [Remote host closed the connection]
[21:21:45] -!- skorasaurus has quit [Ping timeout: 244 seconds]
[21:24:22] -!- sumpfralle has quit [Ping timeout: 250 seconds]
[21:27:42] -!- swingley has quit [Remote host closed the connection]
[21:28:10] -!- acdha has quit [Ping timeout: 250 seconds]
[21:31:31] -!- sirdancealot has quit [Quit: Ragequit]
[21:34:57] <jepler> [pid 6419] sendto(6, "\203B\0\20\201B\0\r", 8, 0, NULL, 0) = 8
[21:34:57] <jepler> [pid 6419] ppoll([{fd=6, events=POLLIN}], 1, {0, 200000000}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 199912704})
[21:35:00] <jepler> [pid 6419] recvfrom(6, "\376\347\177\0\377\377\377\0\377\377\377\0\0\0\0\0", 16, 0, NULL, NULL) = 16
[21:35:49] <jepler> can replace the loop with a ppoll to wait for a packet to arrive
[21:36:11] <jepler> hmm 200ms is probably not the desired timeout
[21:39:13] -!- zzolo has quit [Quit: zzolo]
[21:39:35] <jepler> [pid 6612] 0.000107 sendto(7, "\203B\0\20\201B\0\r", 8, 0, NULL, 0) = 8 <0.000014>
[21:39:38] <jepler> [pid 6612] 0.000048 ppoll([{fd=7, events=POLLIN}], 1, {0, 200000}, NULL, 8) = 1 ([{fd=7, revents=POLLIN}], left {0, 198743}) <0.000012>
[21:39:41] <jepler> [pid 6612] 0.000048 recvfrom(7, "\376\347\177\0\377\377\377\0\377\377\377\0\0\0\0\0", 16, 0, NULL, NULL) = 16 <0.000011>
[21:39:44] <jepler> [pid 6612] 0.000046 sendto(7, "\203\302\0\20\0\0\0\0\0\0\0\0\0\0\0\0\201\302\0@\0\0\314\4", 24, 0, NULL, 0) = 24 <0.000013>
[21:39:47] <jepler> [pid 6612] 0.000053 sendto(7, "\201\302\0\16\0\0\0Z", 8, 0, NULL, 0) = 8 <0.000014>
[21:42:50] <jepler> I'm not sure how much attention to give to these numbers, but they seem to say that it took 14us for sendto(), 48us from the start of sendto() to the start of ppoll(), 48+48+11us = 105us from the start of sendto to the start of sendto to the end of recvfrom
[21:43:16] <jepler> probably realtime is broken while running under strace!
[21:45:11] <PCW> There's still a lot of jitter and overhead in the recv especially
[21:46:27] <PCW> not sure whether its just inherent in preemt-rt or if theres some CPU or IRQ affinity magic that would help
[21:46:48] <jepler> IRQ affinity may be a good point
[21:47:05] <jepler> anyway, the change to use ppoll is
http://emergent.unpythonic.net/files/sandox/0001-hm2_eth-use-ppoll-to-wait-for-response-packet.patch
[21:47:54] <jepler> huh, three interrupts for eth1
[21:48:07] <PCW> the jitter on my test system is better that the Atom MBs anyway
[21:48:55] <jepler> you're talking about jitter looking at the testpoint on the 7i board?
[21:49:54] <PCW> Well actually no I was looking at the recvtime and txtime parameters
[21:53:54] -!- Gulpi has quit [Read error: Connection reset by peer]
[21:57:41] <jepler> I manually set IRQ affinity for the ethernet card via a /proc filesystem thing.
http://emergent.unpythonic.net/files/sandbox/rwtime-noaff.png http://emergent.unpythonic.net/files/sandbox/rwtime-aff.png
[21:59:01] <jepler> the distribution is clearly affected by this choice
[22:00:50] <jepler> it looks like my ppoll change dropped read time markedly
[22:01:40] <PCW> yeah that looks a lot better than mine (is it still working?)
[22:02:00] <jepler> well that's a good question! I'm remote so I can't see whether inputs are actually working :-P
[22:02:29] <PCW> let me try that patch here
[22:03:15] <jepler> reverting my patch, read.time is above 500k
[22:03:43] <jepler> I can't possibly have written it 10x faster
[22:04:08] <PCW> (I can check with a stepgen system with feedback it will bomb if the position feedback is from the wrong sample)
[22:04:21] <jepler> yeah that'd sure work
[22:04:50] <PCW> how do you apply the patch?
[22:05:00] <jepler> download the file with wget or simiar
[22:05:13] <jepler> then "git am 0001-...patch"
[22:05:36] <PCW> ahh git am
[22:05:42] <jepler> it's obvious now, isn't it?
[22:06:02] <PCW> in src directory or one level above?
[22:06:10] <jepler> it actually figures that out for you
[22:06:30] <PCW> well thats nice...
[22:07:39] -!- ravenlock has quit [Quit: Leaving]
[22:13:50] <PCW> Doesn't work for me (I think its just falling through
[22:15:05] <jepler> yeah
[22:17:23] <jepler> I am surprised: hm2_eth ... num_stepgens=1 will load even when there are no stepgens in the idrom
[22:17:28] <KGB-linuxcnc> 03Jeff Epler 052.6-stepconf-multiple-builders cd9b306 06linuxcnc 03lib/python/multifilebuilder.py 10src/emc/usr_intf/stepconf/stepconf.py stepconf: Try to work better with duplicate IDs * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cd9b306
[22:17:29] -!- JT-Shop has quit [Ping timeout: 256 seconds]
[22:17:42] -!- JT-Shop [JT-Shop!~john@162.72.138.27] has joined #linuxcnc-devel
[22:17:42] -!- jthornton has quit [Ping timeout: 245 seconds]
[22:17:43] -!- jthornton_ [jthornton_!~john@162.72.138.27] has joined #linuxcnc-devel
[22:17:54] <seb_kuzminsky> jepler: that's your patch frmo earlier
[22:18:08] <jepler> seb_kuzminsky: OK
[22:18:12] <seb_kuzminsky> i like it and i think we should push it to 2.6 and release 2.6.1 post haste
[22:18:25] <seb_kuzminsky> but i want cmorley to sign off on it first
[22:18:34] <seb_kuzminsky> cmorley: how does that look to you?
[22:21:01] <jepler> PCW: yeah obviously it wasn't working right when I took those traces I posted
[22:21:32] <PCW> those did look a bit optimistic...
[22:21:40] <jepler> PCW: I increased the receive timeout a bit and now it (A) may be working and (B) takes 600k cycles just like the old version
[22:21:43] <jepler> -#define RCV_TIMEOUT 200000
[22:21:46] <jepler> +#define RCV_TIMEOUT 250000
[22:22:04] <jepler> still, it should be some kind of poll/select-type operation rather than a delay
[22:22:13] <PCW> yeah
[22:22:21] <PCW> what CPU?
[22:22:33] <jepler> 3.16GHz core2 duo
[22:22:50] <PCW> so 600k is ~200 usec
[22:23:04] <jepler> yeah
[22:23:19] -!- Roguish [Roguish!~chatzilla@c-67-188-44-176.hsd1.ca.comcast.net] has joined #linuxcnc-devel
[22:23:43] <PCW> not sure what all is included in readtime
[22:23:56] -!- bertrik has quit [Remote host closed the connection]
[22:24:45] <jepler> hmm .. after one read times out, there would always be a packet waiting in a buffer to be read on the next iteration
[22:25:26] <PCW> if it was not lost
[22:25:48] <PCW> (say because of a CRC error)
[22:25:54] <jepler> I'm thinking about the case where the RCV_TIMEOUT was too low
[22:26:08] <jepler> I had strace'd it and saw that it worked -- sendto, ppoll, recv
[22:26:16] <PCW> error recovery is always a sticky subject
[22:26:34] <jepler> but I bet I was reading a packet that had been intended for an earlier servo cycle; that's why it was always available
[22:27:15] <PCW> yes (well that argues for the 2 packet mode eventually)
[22:27:32] <PCW> so the read packet is always available
[22:29:48] <jepler> bbl
[22:29:52] <jepler> thanks for the time
[22:30:00] <PCW> Thank you
[22:48:07] -!- Roguish has quit [Ping timeout: 245 seconds]
[22:52:47] -!- i_tarzan has quit [Ping timeout: 264 seconds]
[22:54:08] -!- kfoltman has quit [Quit: Ex-Chat]
[22:56:58] -!- sylphiae has quit [Quit: Leaving]
[23:00:21] -!- zzolo has quit [Quit: zzolo]
[23:13:47] -!- WalterN has quit [Ping timeout: 264 seconds]
[23:29:32] -!- lyzidiamond has quit [Remote host closed the connection]
[23:31:33] -!- skorasaurus has quit [Ping timeout: 240 seconds]
[23:36:52] -!- lyzidiamond has quit [Ping timeout: 250 seconds]
[23:43:33] -!- _balestrino has quit [Ping timeout: 240 seconds]
[23:59:40] -!- lyzidiamond has quit [Remote host closed the connection]
