Back
[00:00:04] <seb_kuzminsky> pcw_home: i think master fails to build packages on trusty because trusty lacks libgnomeprint
[00:00:50] <seb_kuzminsky> i started to (heh) delete all our libgnomeprint usage but cradek corrected me
[00:05:34] <pcw_home> hmm I wonder why they dropped it
[00:06:56] <seb_kuzminsky> because gnome
[00:07:41] <seb_kuzminsky> http://i.imgur.com/vlowrGf.jpg
[00:09:30] <pcw_home> I knew these newfangled dynamic linked libraries would come a cropper
[00:09:45] <seb_kuzminsky> heh
[00:20:56] <seb_kuzminsky> http://i.imgur.com/NVF5xC6.jpg
[01:14:43] <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
[01:14:43] <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
[01:14:44] <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
[01:14:58] <seb_kuzminsky> jepler, cmorley: seb/2.6/checkglade adds the same glade check to gscreen as jepler added to stepconf
[01:15:02] <seb_kuzminsky> 2 id collisions
[01:15:06] <seb_kuzminsky> good night
[01:18:16] <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>
[01:18:20] <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>
[01:18:23] <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>
[01:24:11] <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>
[01:24:15] <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>
[01:24:52] <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>
[01:25:12] <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>
[01:25:31] <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>
[01:25:42] <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>
[01:26:34] <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>
[01:34:11] <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>
[01:34:11] <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>
[03:16:52] <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
[03:18:42] <cmorley> If someone could test 2.6 stepconf on debian 7.... I tested with mint 13 ... I'm going to bed night
[07:17:57] <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
[07:51:06] <skunkworks> jepler, still running uspace
[07:51:28] <skunkworks> been 7 days so far
[08:09:35] <jepler> skunkworks: great news
[08:10:16] <skunkworks> jepler, Great work!
[08:28:37] <jepler> seb_kuzminsky: oh, except only a tiny minority of the duplicate IDs were fixed by cmorley's commit
[08:32:08] <skunkworks> I thought cradek posted a utillity that would fix that
[08:32:25] <cradek> no, you're confusing me with someone competent
[08:32:32] <jepler> cradek had a grep or something
[08:35:57] <skunkworks> <cradek> jepler, seb_kuzminsky:
http://pygtk-id.blogspot.com/2009/06/replace-duplicate-widget-name-in-glade.html
[08:40:20] <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.
[08:40:46] <jepler> in the case that the python source refers to a widget name, this won't owrk
[08:40:49] <jepler> work
[08:41:06] <jepler> say you create a file in glade, look at the xml, and see that your label is "label1"
[08:41:19] <jepler> you want to change the text on it at runtime, so you write something involving builder.get_object("label1")
[08:41:37] <jepler> we can't change the Python, so if we change label1 to label1-in-file1 automatically, it breaks
[08:41:56] <cradek> if we massage the label to thegladefilename-label1 that's a simple one-time change in the python
[08:42:33] <cradek> they are already unique per-file, right? so filename-existinglabel is unique globally
[08:42:41] <cradek> and stable
[08:42:54] <jepler> that page skunkworks just pasted indicates that some versions of glade made duplicates within the same file
[08:43:05] <cradek> well that's very silly
[08:43:10] <jepler> that is not the problem we're dealing with, however
[08:46:29] <jepler> we might as well have one builder per xml file then
[08:46:33] <jepler> if we're going to change all the python
[08:46:47] <jepler> so instead of self.builder.get('item from page stepx') we'd have self.stepx.get('item')
[08:48:10] <jepler> http://emergent.unpythonic.net/files/sandbox/0001-stepconf-Try-to-work-better-with-duplicate-IDs.patch
[08:48:42] <jepler> this uses one builder per file. get_object looks through all files, throwing an exception if the name's not unique
[09:17:19] <cradek> jepler: I forgot how badly this all worked:
http://emergent.unpythonic.net/01165199941
[09:17:31] <jepler> cradek: there's a reason I'd rather delete it all and forget it ever happened
[09:27:36] <cradek> > The Pluto-P is an inexpensive ($60) FPGA board
[09:27:53] <cradek> the 5i25 makes this look silly
[09:28:30] <pcw_home> or the 7I90
[09:30:31] <pcw_home> or buy a lattice ICE40-1k for ~$5 and plop it on a a board
[09:33:45] <kwallace> The FPGA programming scares me away.
[09:34:55] <pcw_home> ucontrollers scare me away (fixed pin functions???????)
[09:36:08] <kwallace> touché
[09:36:33] <cradek> 5i24 is interesting - what's the price?
[09:36:37] <cradek> (not on the list)
[09:37:24] <pcw_home> it should be on the list (or at the store)
[09:37:43] <CaptHindsight> http://store.mesanet.com/index.php?route=product/product&product_id=298
[09:38:21] <cradek> store!
[09:38:28] <cradek> I was not aware of this
[09:39:43] <pcw_home> $119 for the 5I24-16
[09:39:44] <cradek> the 7i90 has more plugs than the 7i43, and is cheaper
[09:39:59] <cradek> you have new stuff every time I look
[09:40:22] <pcw_home> and the 7I90 can be a ss remote!
[09:40:46] <skunkworks_> so it is a more compact/less expensive 5i20? (5i24)
[09:41:18] <pcw_home> yeah or a 72 I/O 5I25
[09:41:35] <skunkworks_> neat
[09:41:41] <pcw_home> 6I24 is coming
[09:41:52] <pcw_home> (PCIE version)
[09:42:42] <cradek> do you program 5i24 like 5i25, with mesaflash, instead of at startup?
[09:43:05] <CaptHindsight> they make working on RTAI less attractive
[09:43:18] <pcw_home> Yeah its pretty much exactly a 5i25 with a bigger FPGA.more I/O pins
[09:43:59] <pcw_home> mesaflash already works with it
[09:44:16] <skunkworks_> pcw_home: you are awesome!
[09:44:42] <pcw_home> Nah just lazy, the boards are really all the same
[09:44:50] <skunkworks_> heh
[09:45:21] <skunkworks_> I hope between linuxcnc and your other customers - you are more than comfortable.
[09:46:25] <pcw_home> like the 5I25 (and 7I80 family) the 5i24 now supports FPGA reload without needing to power cycle or reboot
[09:47:11] <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?
[09:47:22] <pcw_home> (thanks to Michael G for adding that)
[09:48:41] <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
[09:49:25] <pcw_home> the 7I90 manual has the protocol
[09:49:42] <jepler> the SPI clock is restricted to being on GCLK pins?
[09:49:50] <pcw_home> yes
[09:50:38] <pcw_home> I could make a non gclock version but it would likely be slower
[09:51:15] <CaptHindsight> what's the max SPI clock speed on the 7i90? 50 or 100MHz?
[09:51:23] <pcw_home> currently it works at 50 Mbits/sec
[09:51:59] <pcw_home> if the host could generate a continuous clock I can do 100 MBits/sec
[09:53:25] <jepler> in the 7i43u.ucf file I have, there are some pins called SPI* -- does it have SPI?
[09:53:54] <pcw_home> the 7I43 has SPI I/O to access its flash EEPROM
[09:53:57] <jepler> ah
[09:54:08] <jepler> not relevant in this context
[09:54:59] <skunkworks_> what are GCLK pins use for?
[09:55:24] <skunkworks_> normally
[09:55:43] <CaptHindsight> maybe it's time to hack a ARM Chromebook's for its SPI
[09:55:46] <pcw_home> but TopHostMot2GCSPI.vhd shoud work with a 7I43 with a proper .ucf file
[09:56:28] <pcw_home> Those are global clocks (clock spines) that have low skew across the FPGA chip
[09:57:28] <jepler> pcw_home: seems unlikely there's a GCLK on the parallel port header
[09:57:55] <jepler> I don't see EPP control signals in the ucf file
[09:59:06] <pcw_home> let me look at the schematic
[10:01:00] <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?
[10:01:55] <lair82> I set ARC_BLEND_ENABLE to zero ad re-ran the program and runs fine.
[10:02:34] <lair82> It only does it on the first run of the program, all consecutive runs after that it ran fine.
[10:02:42] <jepler> lair82: does the problem occur with your test program and the sample config sim/axis/lathe.ini ?
[10:03:05] <jepler> (yuck)
[10:03:52] <lair82> I didn't try any other configs due to it running fine with arc blending disabled.
[10:04:31] <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..
[10:05:48] <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
[10:06:25] <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 %
[10:06:32] <pcw_home> unfortunately no GCLK pins on the parallel interface (but 4 on GPIO)
[10:10:12] <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)
[10:11:16] <cradek> lair82: each of those is 3/4 of a circle. did you mean them to be 1/4 of a circle?
[10:12:23] <pcw_home> Most of the SOCs SPI interfaces have wide SPI clock settings so you just need to see how fast it can go
[10:14:00] <jepler> pcw_home: I haven't even started to get a handle on that end of things
[10:14:28] <pcw_home> thats the ugly non portable side...
[10:14:37] <jepler> no doubt
[10:17:46] <cradek> lair82's code, which works fine for me in sim/axis/lathe:
http://pastie.org/9444468
[10:18:00] <pcw_home> If you had pins to spare a FPGA board could be made with selectable I/O voltage for the SPI interface bank
[10:19:19] <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.
[10:20:04] <jepler> # CONFIG_SPI_SPIDEV is not set
[10:20:17] <jepler> too bad, spidev looks like it makes most of spi devices available in userspace
[10:20:21] <jepler> https://www.kernel.org/doc/Documentation/spi/spidev
[10:21:30] <cradek> lair82: do you mean the arcs show up as straight lines?
[10:21:55] <pcw_home> SPIDEV would be nice at least for initial poking about
[10:22:23] <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..
[10:22:41] <jepler> I also see lair82's program as a circle repeated 3 (?) times
[10:22:44] <jepler> bbl
[10:22:46] <ssi> jepler: it shouldn't be terribly hard to write an rt kernel space component that uses spi
[10:22:49] <cradek> lair82: I don't understand your problem report yet
[10:22:52] <ssi> I did something similar on beagle
[10:23:10] <jepler> ssi: linuxcnc for rt-preempt runs all in userspace though
[10:23:20] <ssi> either way
[10:23:33] <ssi> the spidev stuff is mostly just for the devfs access
[10:23:36] <cradek> [I booted the newest image live, and built and ran a comp, without installing any packages]
[10:23:53] <skunkworks_> jepler: what kind of latency are you getting on that board?
[10:23:56] <skunkworks_> cradek: Yay!
[10:23:56] <ssi> it's just a devfs wrapper on top of the ioctls
[10:25:38] <skunkworks_> cradek: andy will be very happy (well - maybe somewhat happy) :)
[10:27:00] <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.
[10:27:09] <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 %
[10:27:31] <lair82> I will post the pics on the forum then post the link here
[10:37:01] <skunkworks_> lair82: I get this on lathe sim...
http://electronicsam.com/images/KandT/testing/Screenshot%20from%202014-08-04%2010:16:11.png
[10:37:14] <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
[10:38:21] <jepler> that one at least looks like a diamond in preview
[10:38:37] <skunkworks_> lair82: do you have any tolerance set? it looks like normal blending...
[10:38:51] <lair82> no tolerances are set,
[10:39:07] <jepler> but for me in sim/axis/lathe.ngc, the backplot matches the preview
[10:39:15] <skunkworks_> *normal blending / low acceleration..
[10:39:23] <jepler> skunkworks_: I don't have a preempt-rt kernel built yet, so I don't have a latency figure worth publishing
[10:39:30] <jepler> bbl again
[10:40:10] <skunkworks_> because the new tp reaches a higher velocity - it probably blends the last segment higher.
[10:41:02] <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?
[10:41:43] <lair82> Its only the very first run of the program that it does this
[10:42:40] <skunkworks_> hmm - can you post your configs?
[10:42:51] <lair82> Will do,
[10:45:47] <CaptHindsight> is linuxcnc.org down? not even a ping right now
[10:46:13] <seb_kuzminsky> it's down for me too
[10:46:41] <seb_kuzminsky> i can ssh in
[10:46:44] <seb_kuzminsky> but not http
[10:47:03] <seb_kuzminsky> oh wait, now its back with http
[10:47:12] <skunkworks_> lair82: is this an english or metric machine?
[10:47:26] <lair82> english
[10:47:35] <skunkworks_> ah - ok - so big...
[10:47:46] <skunkworks_> (I thought it was metric from the lenghts..
[10:47:51] <skunkworks_> let me play
[10:48:01] <jepler> I also tucked in a G21 to make it run in sim lathe
[10:49:12] <jepler> OK, duplicated here
[10:49:26] <jepler> the first blend on the left is much bigger than the second
[10:50:14] <jepler> showing two runs:
http://emergent.unpythonic.net/files/sandbox/lair82b.png
[10:50:45] <cradek> does it violate a tolerance setting?
[10:50:54] <jepler> no idea
[10:51:04] <jepler> but under whatever setting, wouldn't you expect the same thing every time?
[10:51:15] <seb_kuzminsky> i would
[10:51:22] <cradek> yeah, I'd expect it
[10:51:51] <jepler> no valgrind diagnostics in rtapi_app
[10:51:59] <jepler> so it's not "simply" something uninitialized
[10:52:02] <cradek> I have a feeling that when you start the program you start moving but you don't know all the future program yet
[10:52:25] <jepler> cradek: but that's different the next time you run the same program from the start?
[10:52:43] * cradek shrugs
[10:54:12] <ssi> it's just a devfs wrapper on top of the ioctls
[10:54:17] <ssi> mischn sry
[10:54:46] <cradek> whoah, that's a big blend
[10:54:52] <cradek> (in the forum post)
[10:55:06] <skunkworks_> It is because you have the extra entry move when you first start..
[10:55:24] <jepler> skunkworks_: that's a good point, hmm
[10:55:39] <skunkworks_> if you put g0x0z0 at the end - it does the first path over and over
[10:55:44] <cradek> I'd still like to know if it violates tolerance
[10:55:55] <skunkworks_> there is not tolerence.. so no.
[10:56:09] <cradek> I don't know what behavior you're supposed to have now, with unspecified tolerance
[10:56:33] <jepler> what skunkworks_ says I confirm too: the behavior at that left corner is dependent on the start location
[10:57:06] <skunkworks_> if you add a tolerance - say .05" it follows that.. every time
[10:57:35] <jepler> and I agree with that as well (I added G64 P.1 Q.1)
[10:57:43] <skunkworks_> but that would be a question for rob.. I don't see it as an issue yet..
[10:58:37] <lair82> But why does it run fine all consecutive passes?
[10:58:52] <cradek> read above
[11:00:06] <jepler> I'm prepared to agree it's surprising and counterintuitive
[11:00:11] <lair82> Are you referring tho this "It is because you have the extra entry move when you first start"
[11:00:29] <cradek> yes
[11:00:38] <cradek> so it does behave the same way every run
[11:00:41] <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
[11:01:23] <lair82> It scared the shit of me, a turret weighing over 3000lbs going the wrong way at 150 IPM
[11:02:25] <lair82> It runs properly after the first run, the first time is messed up, all consucutive passes are fine.
[11:02:36] <skunkworks_> did master change the coloring so that you don't see if the planner falls back to parabolic blending?
[11:02:49] <skunkworks_> (used to be yellow)
[11:02:49] <lair82> "consecutive"
[11:02:53] <skunkworks_> but I don't see any now.
[11:02:58] <cradek> yes the coloring hack broke rapid override, so I had to remove it
[11:03:10] <skunkworks_> ok
[11:03:33] <cradek> it miscolored by lying about the type of move (rapid or feed)
[11:03:52] <cradek> which is a lie that is problematic :-)
[11:04:09] <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")
[11:04:25] <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)
[11:04:31] <jepler> lair82: it appears to be dependent on the starting location, not whether it is "the first time"
[11:04:47] <skunkworks_> so you could get different behavior depending on how the program ran
[11:04:59] <cradek> skunkworks_: just from eyeballing the shape, I am pretty sure this surprising blend is a circular blend
[11:05:00] <jepler> there are clearly two different blends you can get
[11:05:41] <lair82> Ok I will buy that, what would be the best case way o handle this from a gcode programming standpoint?
[11:05:48] <cradek> skunkworks_: (I can't tell on the little ones)
[11:05:49] <jepler> lair82: program a tolerance
[11:05:55] <skunkworks_> G64 Px.xxx
[11:06:37] <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
[11:06:52] <lair82> Could I put that in my INI so it is always in effect?
[11:07:06] <jepler> put it in each part file
[11:07:20] <jepler> put all important modal codes in the prologue of each part file
[11:07:38] <skunkworks_> It is an odd blend though...
[11:07:43] <skunkworks_> compared to the others..
[11:08:18] <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.
[11:08:50] <skunkworks_> the little blend is circular too.. it looks like.
[11:09:12] <skunkworks_> lair82: that is good - looks of good testing then :)
[11:09:40] <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.
[11:09:59] <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
[11:10:16] <cradek> is that the case?
[11:10:20] <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?
[11:10:31] <jepler> the new TP is supposed to go faster
[11:10:36] <jepler> it's supposed to follow the programmed tolerance
[11:10:38] <cradek> and that does not look like a crash
[11:10:46] <jepler> if there's no programmed tolerance, I don't see how you can argue the path is wrong
[11:12:06] <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.
[11:12:42] <cradek> we all agree it is surprising
[11:12:49] <cradek> you are the only one who is sure it is wrong
[11:13:05] <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.
[11:14:20] <jepler> I'll say this about the last blend: it keeps up velocity perfectly
[11:14:35] <jepler> unlike the other two blends, where you can observe a velocity dip; in the case of the first blend, about 50%
[11:15:04] <lair82> If it was a rapid move, oh well, but a G01 feed move is why I have issue with it.
[11:15:20] <cradek> if you add some more (long?) moves before and after this program, you might get big blends and constant velocity everywhere
[11:15:35] <jepler> http://emergent.unpythonic.net/files/sandbox/lair-velocity.png
[11:16:00] <lair82> It does look nice,
[11:16:16] <lair82> The backplot that is,,,
[11:17:53] <lair82> We have never programmed a tolerance on any of the machines, and they run beautifully, without incident, regardless of speed
[11:18:04] <jepler> with g64 p.1 specified, the blends are not quite identical.
http://emergent.unpythonic.net/files/sandbox/lair-velocity-g64-p.1.png
[11:23:07] <skunkworks> if you add more segments to the beging of the program - they all start to blend the large amount...
[11:23:14] <skunkworks> begining
[11:23:29] <skunkworks> (g1 moves)
[11:23:45] <jepler> because the new planner has to "warm up"?
[11:23:53] <skunkworks> I think so..
[11:24:10] <jepler> I put it in a loop and after the first time around, the big blend also shows up on the right
[11:26:34] <skunkworks> it takes time to read-ahead iirc
[11:26:43] <skunkworks> like a few segments at the begingin
[11:29:37] <skunkworks> maybe how fast it gets the segments?
[11:41:56] <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.
[11:42:02] <skunkworks> jepler, I bet then the velocity smooths out also
[11:42:20] <skunkworks> it is probably making the radius to keep at 150ipm.
[11:43:13] <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
[11:43:25] <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?
[11:44:42] <jepler> memleak: we do not want ubc-3 merged into any branch of linuxcnc
[11:44:45] <ssi> is there an ini setting for a default and/or maximum tolerance?
[11:45:13] <cradek> ssi: no but it seems like maybe there should be. perhaps add a feature request in the tracker?
[11:45:13] <memleak> jepler im not merging in ubc-3, im specifically only merging in the xenomai-specific code.
[11:45:57] <jepler> memleak: OK, in git "merge" has a specific technical meaning and I assumed you were using it in that technical sense.
[11:46:06] <ssi> I can do that
[11:46:30] <memleak> no im talking about a partial re-write of the xenomai code and getting xenomai support added.
[11:46:35] <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.
[11:46:49] <cradek> adding xenomai support means expanding uspace, right? then it clearly needs to be based on master
[11:47:09] <memleak> ok.
[11:47:22] <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
[11:48:06] <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."
[11:48:09] <memleak> i was thinking about sharing it with the RTAI support, not so much uspace.
[11:49:02] <cradek> are you talking about kernel xenomai or userspace xenomai?
[11:49:04] <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.
[11:49:20] <ssi> kwallace2: yeah that could be used
[11:49:24] <kwallace2> Oops.
[11:50:12] <jepler> so similarly I don't think a feature request for a "default" tolerance makes much sense
[11:50:37] <jepler> because a previous MDI or part program that says G64 P100 would override a "default"
[11:50:56] <ssi> https://sourceforge.net/p/emc/feature-requests/123/
[11:50:56] <cradek> by default, I mean what tolerance should be used when in plain g64 mode, aka g64 p0, aka the default mode
[11:51:18] <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!)
[11:51:21] <memleak> whats the difference?
[11:51:43] <ssi> ah so G64 is modal, so it'll persist between programs?
[11:51:45] <jepler> cradek: oh, that might make some sense then, but you still have to program a tolerance in each part program
[11:52:16] <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.
[11:52:37] <jepler> memleak: xenomai kernel space doesn't have math support, does it?
[11:53:03] <jepler> ubc copied in a libc with a nondistributable license and I had the impression it was for xenomai :-/
[11:53:08] <jepler> er, a libm
[11:53:36] <memleak> whats the default when using xenomai in ubc3? its userspace right?
[11:53:51] <jepler> I think support for both is in there
[11:53:55] <jepler> but .. don't quote me
[11:54:14] <memleak> there is.
[12:02:50] <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)
[12:03:26] <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
[12:03:33] <cradek> ssi: I added my thoughts, thanks for creating it
[12:03:38] <ssi> sure thing
[12:04:19] <memleak> i'd like to merge xenomai support from before new rtos code was added in, so 2.6 would be easier.
[12:04:50] <memleak> i can just throw it in as a new thread along side RTAI and that would be pretty easy i think.
[12:05:01] <cradek> I don't see how you start from before uspace
[12:05:24] <memleak> the same way RTAI works without uspace.
[12:05:44] <cradek> xenomai kernel mode is going to have the math problem
[12:05:57] <memleak> unless libm gets added?
[12:06:30] <cradek> is kernel mode better than user mode?
[12:06:40] <memleak> thats what i want to know..
[12:06:55] <memleak> better you mean in regards to latency yes?
[12:07:18] <cradek> I have no idea. I'm asking why you're making that decision, when user mode would seem to have fewer big obstacles
[12:08:19] <memleak> well if im going for uspace i'd use xenomai 3.x (based off PREEMPT_RT)
[12:08:24] <cradek> user mode seems downright easy (and very easy to decide to merge into master) if you base it on the uspace work
[12:08:46] <memleak> only problem is that im more familiar with kernel, not uspace..
[12:09:55] <memleak> what changes would have to be added for xenomai userspace support if the branch of xenomai uses the preempt_rt kernel patches?
[12:12:00] <cradek> all I know is from jepler's emails, Subject: [Emc-developers] "jepler/rtos-uspace": a new POSIX realtime branch
[12:12:30] <memleak> http://git.xenomai.org/xenomai-forge.git/tree/README.INSTALL?h=next#n62
[12:14:03] <jepler> if the kernel is PREEMPT-RT then I don't think linuxcnc needs xenomai
[12:14:10] <memleak> oh..
[12:14:32] <memleak> but if IPIPE is used then you need extra linuxcnc code?
[12:15:07] <jepler> xenomai based on ipipe? yes (though didn't xenomai have an implementation of rtai apis in there as a "skin"?)
[12:15:25] <memleak> it does yes.
[12:15:45] <memleak> ok so for IPIPE xenomai (2.X) what would need to be done, in summary?
[12:16:11] <memleak> userspace..
[12:17:09] <memleak> just hook in xenomai.c and xenomai.h with necessary rtapi changes? (and of course ./configure) ?
[12:17:38] <jepler> it will not work simply by copying files from ubc3
[12:17:53] <memleak> i understand that.
[12:18:09] <jepler> in src/rtapi/rtapi_uspace.hh there is 'struct RtapiApp'
[12:18:11] <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 ..
[12:18:50] <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)
[12:19:35] <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
[12:19:39] <jepler> bbl, it's lunchtime here
[12:20:10] <memleak> thats it?
[12:20:11] <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..
[12:20:22] <jepler> good luck, I'll try to answer specific problems when you have them.
[12:22:26] <memleak> but basically all xenomai userspace code could go in the uspace files? i dont need to change much else?
[12:31:59] <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.
[12:33:04] <lair82> We are looking into if we can change our post processor to automatically include it in our programs.
[12:33:19] <cmorley> ahh better idea probably
[12:41:03] <ssi> lair82: did you see the note above about the RS274NGC_STARTUP_CODE ini variable?
[12:41:10] <ssi> lair82: you can default the machines that way it looks like?
[12:42:29] <memleak> would it make any sense for xenomai with preempt-rt kernel patch have any better latency results than preempt-rt standalone?
[12:42:32] <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
[12:43:58] <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.
[12:44:07] <skunkworks> sure
[12:44:17] <memleak> skunkworks, was that to me?
[12:44:31] <skunkworks> memleak, no.. (that all is above my pay grade..)
[12:44:38] <memleak> XD ok sorry.
[12:52:12] <mozmck> memleak: that's what I have wondered. seems like an extra layer that would just add more overhead.
[12:52:37] <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?
[12:52:50] <seb_kuzminsky> i mailed the glade-developers list about our problem and asked for their input
[13:10:06] <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
[13:10:12] <jepler> by faking a builder that knows about all IDs
[13:10:57] <jepler> if you have multiple builders, you have to look up the object in the right builder
[13:11:55] <seb_kuzminsky> ahh, python, what are we going to do with you? + objects = [o for o in objects if o]
[13:12:31] <jepler> would you have preferred objects = filter(None, objects) as being clearer?
[13:12:51] <seb_kuzminsky> i have no preference
[13:13:14] <seb_kuzminsky> thanks for writing that
[13:13:38] <seb_kuzminsky> i'm waiting to hear back from glade-developers & see what they recommend
[13:14:52] <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
[13:15:21] <seb_kuzminsky> that's why all the stepconf ids look like "object type" + "small integer"
[13:16:22] <jepler> yup, I really get the impression that one builder, multiple files is their idea of a sane workflow
[13:16:30] <jepler> er, don't get the impression
[13:17:09] <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)
[13:18:01] <skunkworks_> http://linuxcnc.org/index.php/english/forum/10-advanced-configuration/27368-new-trajectory-planner-testersprograms-wanted?start=180#49500
[13:24:11] <jepler> ugh, no "pin 1" marks on the odroid's I/O headers
[13:24:13] <seb_kuzminsky> jepler: 0001-stepconf-Try-to-work-better-with-duplicate-IDs.patch looks like a really good solution to me
[13:25:30] <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
[13:25:41] <jepler> yes
[13:25:41] <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
[13:25:58] <jepler> skunkworks_: yeah that's about like what I saw
[13:26:12] <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
[13:26:32] <jepler> well, the only downside I've thought of so far
[13:27:13] <jepler> clearly we need to get GUI testing into linuxcnc in somebody's spare time
[13:28:00] <seb_kuzminsky> that would be good
[13:28:53] <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...
[13:29:09] <seb_kuzminsky> no battery, no case
[13:29:12] <jepler> OK
[13:29:14] <seb_kuzminsky> totally ghetto
[13:29:53] <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
[13:30:40] <jepler> on another subject: "uspace" package vs non-realtime kernels and vs realtime kernels and configs with base threads
[13:31:11] <jepler> the "uspace" package always has a setuid rtapi_app, so it'll use the realtime scheduling priority .. but not meet deadlines
[13:31:24] <jepler> .. so everybody who starts a sim config will get errors
[13:31:59] <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
[13:32:11] <jepler> I'm looking for opinions about what to do about these two things
[13:32:32] <jepler> in the first case, probably check for RT and not use realtime scheduling in this case
[13:32:50] <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"?
[13:34:13] <jepler> .. sim configs would set this flag, real configs wouldn't
[13:54:54] <memleak> jepler, how would i go about finding the "right xenomai calls for everything (all the 'virtual' functions, like task_start for instance)"
[13:55:47] <memleak> cant i copy that stuff from ubc-3 or no?
[13:57:14] <jepler> well for instance you can see that rtapi_task_start simply calls App().task_start
[13:57:41] <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
[13:57:59] <memleak> ah i see.
[13:58:10] <jepler> (in uspace_rtapi_app.cc:
[13:58:10] <jepler> int rtapi_task_start(int task_id, unsigned long period_nsec)
[13:58:11] <jepler> {
[13:58:11] <jepler> return App().task_start(task_id, period_nsec);
[13:58:11] <jepler> }
[13:58:13] <jepler> )
[14:05:22] <memleak> if a function is prefixed with __ does that mean inligned?
[14:05:56] <jepler> no. typically a leading _ indicates it is for internal use only
[14:06:11] <memleak> ah
[14:06:20] <jepler> what function in particular?
[14:07:11] <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.
[14:07:43] <memleak> just in general because a lot of the IPIPE changes consist of adding a lot of _ before functions
[14:07:55] <memleak> and thats the only change sometimes..
[14:08:40] <jepler> memleak: so if they have a realtime version of sprintf, they would call it _sprintf ?
[14:08:53] <jepler> that's .. unique and charming
[14:08:54] <memleak> exactly.
[14:08:56] <skunkworks_> (it also says 'cannot gain I/O privileges - forgot 'sudo make setuid'?')
[14:10:27] <jepler> skunkworks_: most of my remarks were about the situation where you did "make setuid" or you installed a package
[14:10:34] <skunkworks_> ah
[14:10:36] <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
[14:10:54] <skunkworks_> but you will get realtime delays - right?
[14:11:34] <jepler> yes
[14:12:22] <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
[14:13:07] <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 ?
[14:14:46] <jepler> memleak: no particularly good reason, I guess.
[14:15:15] <jepler> it's not exactly a header file .. it's some source code that is common to the ulapi and rtapi parts of uspace
[14:16:00] <jepler> it does depend on some rtapi headers being included already
[14:31:32] <memleak> this is going to take me awhile im going to take a break for a bit. my head hurts.
[14:31:41] <jepler> take care
[14:32:37] <memleak> ill definitely keep working on it though, its really fun, just mentally challenging. im glad i have your help
[14:58:27] <CaptHindsight> kernel 3.16 just released, lots of new ARM SOC support
[15:48:44] <cradek> http://thread.gmane.org/gmane.linux.distributions.emc.devel/13698
[15:48:53] <cradek> I don't know what he thinks those should be, or why
[15:50:33] <cradek> oh maybe that's ubc3 stuff
[15:50:52] <jepler> yes when I search for those filenames I tend to come up with machinekit stuff
[15:51:11] <cradek> seems like his expectations are somehow wrong
[15:51:19] <cradek> unfortunately he doesn't say what he's trying to do
[15:52:01] <jepler> fwiw this limits.d thing looks better than appending to limits.conf
[15:52:05] <cradek> yep
[15:52:27] <cradek> I'm sure that's from pre-.d days
[15:52:31] <jepler> probably so
[15:52:35] <cradek> if someone cares, he should fix it in master
[15:53:25] <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..
[15:53:50] <jepler> though .. I can see the contrary point of view
[15:56:11] <jepler> confirmed that shmdrv is some machinekit-only thing
[15:56:29] <PCW> its helpful when testing hardware to have a stream of incoming packets to see how far they get...
[15:57:11] <PCW> or looking for packet loss %
[15:58:02] <jepler> once the machine's up (or maybe just if it arps?) kfreebsd's ping will keep running just like linux ping
[15:58:49] <PCW> but you cant wiggle wires to see when its starts working...
[15:58:58] <cradek> I'm not seeing that in real freebsd's ping
[15:59:40] <jepler> cradek: interesting
[15:59:41] <jepler> $ ping 10.0.2.61
[15:59:41] <jepler> PING 10.0.2.61 (10.0.2.61): 48 data bytes
[15:59:41] <jepler> ping: sending packet: Host is down
[15:59:41] <jepler> $
[16:00:06] <cradek> [cradek@storage ~]$ ping 10.0.2.61
[16:00:06] <cradek> PING 10.0.2.61 (10.0.2.61): 56 data bytes
[16:00:08] <cradek> .....
[16:00:26] <jepler> is 10.0.2.61 on the local network?
[16:00:27] <cradek> do you even have a route to that address?
[16:00:30] <jepler> yes, I do
[16:00:32] <cradek> no
[16:00:39] <jepler> try something on the local network that doesn't arp
[16:00:54] <cradek> aha
[16:01:04] <cradek> it says "host is down" but then doesn't exit
[16:01:14] <cradek> it looks like it will keep going forever
[16:01:26] <cradek> 33 packets transmitted, 0 packets received, 100.0% packet loss
[16:01:29] <jepler> so still it looks like debian-kfreebsd's own brain damage
[16:01:33] <jepler> that's good to know
[16:01:55] <PCW> same in NetBSD:
[16:01:57] <PCW> ----test8.mesanet.com PING Statistics----
[16:01:59] <PCW> 97 packets transmitted, 0 packets received, 100.0% packet loss
[16:02:15] <jepler> PCW: did you consider raw ethernet for 7i80? if so, I am curious what you felt the pros and cons were.
[16:04:09] <jepler> it would seem to let you avoid a modest amount of overhead for the IP and UDP framing
[16:05:36] <jepler> I'm guessing there are some cons that outweigh a "modest" savings but I don't know what they are.
[16:11:33] <PCW> You mean just raw packets (no UDP wrapper?)
[16:11:38] <jepler> yes
[16:13:04] <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
[16:15:19] <jepler> IP header of 20 bytes, UDP header of 8 bytes is pretty small potatoes
[16:15:31] <PCW> there's a 64 byte minimum packet size anyway so for little packets it makes very little difference
[16:17:16] <jepler> on the mailing list, Charles S. suggested that raw sockets might have some benefit for realtime, but that remains unclear to me.
[16:17:43] <ssi> PCW: Got parts in the mail today; thanks! :)
[16:18:26] <PCW> It might reduce the levels of kernel traversal so might help overhead/latency somewhat
[16:19:09] <PCW> ssi welcome! (its a do it yourself kit)
[16:19:45] <ssi> hehe yes :)
[16:22:00] <jepler> PCW: yeah, now how to measure latency from send() to first bit on the wire..
[16:22:31] <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
[16:22:33] <PCW> not sure if this is because some long transfers are done during startup or its a resolution issue with SO_RCVTIMEO
[16:23:20] <jepler> according to tcpdump, it was on the order of 200-300us before a read request got its response packet
[16:23:28] <jepler> the RCVTIMEO is smaller than that by an order of magnitude iirc
[16:23:31] <jepler> wasn't it 10 or 20?
[16:24:46] <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)
[16:25:13] <jepler> you could try with select()
[16:25:23] <PCW> so thats something of a mystery
[16:25:27] <jepler> that usleep polling loop makes my molars itch too
[16:25:36] <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
[16:25:50] <PCW> yeah the less kernel interaction the better
[16:27:17] <jepler> 00:00:00.000000 IP 192.168.1.121.27181 > 192.168.1.1.53356: UDP, length 16
[16:27:20] <jepler> 00:00:00.000019 IP 192.168.1.1.53356 > 192.168.1.121.27181: UDP, length 24
[16:27:24] <jepler> OK, my memory's wrong. It's more like 20us than 200us
[16:27:27] <jepler> that's good
[16:28:02] <PCW> if you have a scope you can check the7I80s timing (TP1 is RXPKT time, TP2 is TXPKT time, time between is parsing time)
[16:28:58] <PCW> (that how i noticed the extra packet)
[16:30:50] <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?
[16:31:03] <jepler> I seem to be overlooking it; all I know how to get is the whole IP packet
[16:31:27] <PCW> Naw I just edited out the header
[16:31:32] <jepler> ah
[16:32:49] <PCW> tcpdump works remarkable well on a running RT linuxcnc system
[16:34:55] <PCW> I think the Ethernet powerlink people make use of libpcap as a lower overhead raw packet interface
[16:53:35] <jepler> [pid 6419] sendto(6, "\203B\0\20\201B\0\r", 8, 0, NULL, 0) = 8
[16:53:35] <jepler> [pid 6419] ppoll([{fd=6, events=POLLIN}], 1, {0, 200000000}, NULL, 8) = 1 ([{fd=6, revents=POLLIN}], left {0, 199912704})
[16:53:38] <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
[16:54:27] <jepler> can replace the loop with a ppoll to wait for a packet to arrive
[16:54:49] <jepler> hmm 200ms is probably not the desired timeout
[16:58:13] <jepler> [pid 6612] 0.000107 sendto(7, "\203B\0\20\201B\0\r", 8, 0, NULL, 0) = 8 <0.000014>
[16:58:16] <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>
[16:58:19] <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>
[16:58:22] <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>
[16:58:25] <jepler> [pid 6612] 0.000053 sendto(7, "\201\302\0\16\0\0\0Z", 8, 0, NULL, 0) = 8 <0.000014>
[17:01:28] <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
[17:01:54] <jepler> probably realtime is broken while running under strace!
[17:03:49] <PCW> There's still a lot of jitter and overhead in the recv especially
[17:05:04] <PCW> not sure whether its just inherent in preemt-rt or if theres some CPU or IRQ affinity magic that would help
[17:05:26] <jepler> IRQ affinity may be a good point
[17:05:43] <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
[17:06:32] <jepler> huh, three interrupts for eth1
[17:06:45] <PCW> the jitter on my test system is better that the Atom MBs anyway
[17:07:33] <jepler> you're talking about jitter looking at the testpoint on the 7i board?
[17:08:32] <PCW> Well actually no I was looking at the recvtime and txtime parameters
[17:16:19] <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
[17:17:39] <jepler> the distribution is clearly affected by this choice
[17:19:28] <jepler> it looks like my ppoll change dropped read time markedly
[17:20:17] <PCW> yeah that looks a lot better than mine (is it still working?)
[17:20:38] <jepler> well that's a good question! I'm remote so I can't see whether inputs are actually working :-P
[17:21:07] <PCW> let me try that patch here
[17:21:53] <jepler> reverting my patch, read.time is above 500k
[17:22:21] <jepler> I can't possibly have written it 10x faster
[17:22:45] <PCW> (I can check with a stepgen system with feedback it will bomb if the position feedback is from the wrong sample)
[17:22:59] <jepler> yeah that'd sure work
[17:23:28] <PCW> how do you apply the patch?
[17:23:38] <jepler> download the file with wget or simiar
[17:23:51] <jepler> then "git am 0001-...patch"
[17:24:14] <PCW> ahh git am
[17:24:20] <jepler> it's obvious now, isn't it?
[17:24:39] <PCW> in src directory or one level above?
[17:24:48] <jepler> it actually figures that out for you
[17:25:08] <PCW> well thats nice...
[17:32:28] <PCW> Doesn't work for me (I think its just falling through
[17:33:43] <jepler> yeah
[17:36:01] <jepler> I am surprised: hm2_eth ... num_stepgens=1 will load even when there are no stepgens in the idrom
[17:36:05] <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
[17:36:32] <seb_kuzminsky> jepler: that's your patch frmo earlier
[17:36:46] <jepler> seb_kuzminsky: OK
[17:36:50] <seb_kuzminsky> i like it and i think we should push it to 2.6 and release 2.6.1 post haste
[17:37:03] <seb_kuzminsky> but i want cmorley to sign off on it first
[17:37:12] <seb_kuzminsky> cmorley: how does that look to you?
[17:39:39] <jepler> PCW: yeah obviously it wasn't working right when I took those traces I posted
[17:40:10] <PCW> those did look a bit optimistic...
[17:40:18] <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
[17:40:21] <jepler> -#define RCV_TIMEOUT 200000
[17:40:24] <jepler> +#define RCV_TIMEOUT 250000
[17:40:42] <jepler> still, it should be some kind of poll/select-type operation rather than a delay
[17:40:51] <PCW> yeah
[17:40:59] <PCW> what CPU?
[17:41:11] <jepler> 3.16GHz core2 duo
[17:41:28] <PCW> so 600k is ~200 usec
[17:41:42] <jepler> yeah
[17:42:21] <PCW> not sure what all is included in readtime
[17:43:23] <jepler> hmm .. after one read times out, there would always be a packet waiting in a buffer to be read on the next iteration
[17:44:04] <PCW> if it was not lost
[17:44:26] <PCW> (say because of a CRC error)
[17:44:32] <jepler> I'm thinking about the case where the RCV_TIMEOUT was too low
[17:44:46] <jepler> I had strace'd it and saw that it worked -- sendto, ppoll, recv
[17:44:54] <PCW> error recovery is always a sticky subject
[17:45:12] <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
[17:45:53] <PCW> yes (well that argues for the 2 packet mode eventually)
[17:46:10] <PCW> so the read packet is always available
[17:48:26] <jepler> bbl
[17:48:30] <jepler> thanks for the time
[17:48:38] <PCW> Thank you
[19:50:51] <jepler> per_cpu_ptr(conf->percpu, cpu)->scribble = scribble;
[19:57:06] <seb_kuzminsky> somebody shoot the guy who invented lvalue macros that look like functions
[19:58:41] <seb_kuzminsky> jepler: your multifilebuilder does the right thing even without cmorley's id anti-collision patch (as expected)
[20:01:30] <jepler> seb_kuzminsky: hey cool
[20:30:47] <jepler> this odroid kernel tree has ~2500 commits since the last commit on "real" kernel git
[20:31:22] <jepler> a lot of them have ubuntu thumbprints on them, but the commits aren't in the history of raring or precise's kernel git under the same IDs
[20:31:42] <jepler> Merge tag 'v3.8.13.26' of git://kernel.ubuntu.com/ubuntu/linux into odroid-3.8.y
[20:32:03] <jepler> or else I just haven't found the right ubuntu kernel git yet
[20:32:40] <jepler> but anyway .. only 3 files conflicted when trying to do this: Merge tag 'v3.8.13.14-rt31-rebase' into odroid-3.8.y
[20:36:04] <jepler> can cross-building a kernel with make-kpkg possibly be this easy ??
https://romanrm.net/a10/cross-compile-kernel
[20:39:24] <CaptHindsight> jepler: yes, it magically works
[20:41:39] <CaptHindsight> CodeSourcery was the other magic tool chain
[20:45:53] <jepler> and it's done already?
[20:47:53] <CaptHindsight> for Allwinner
http://linux-sunxi.org/Toolchain
[20:51:28] <jepler> now how do I build a "uInitrd"?
[20:52:34] <jepler> well here are some docs, let's try following them .. looks like this step has to be done on the device
[21:09:20] <jepler> hmph. it doesn't boot and I've already misplaced the special serial cable so I can't check the console for "obvious problem here" type messages :-/
[21:13:34] <CaptHindsight> jepler: are you using a cubie2 or?
[21:15:38] <CaptHindsight> http://olimex.wordpress.com/2013/11/05/building-the-ultimate-debian-sd-card-for-linux-with-kernel-3-4-for-a20-olinuxino-micro/
[21:15:58] <CaptHindsight> https://www.olimex.com/forum/index.php?topic=3023.msg12658#msg12658 Patching kernel with RT
[21:26:38] <cradek> seb_kuzminsky: reminder:
http://timeguy.com/gitweb?p=linuxcnc.git;a=log;h=refs/heads/proposed
[21:35:26] <jepler> CaptHindsight: odroid u2
[21:41:23] <CaptHindsight> jepler: oh, no idea for exynos, the details for building u-boot across ARM soc's varies
[21:43:14] <CaptHindsight> it's tough since initializing ARM SOC's varies so much between devices, there's nothing close to a standard like with x86
[21:43:18] <jepler> maybe I'll see something useful on the serial console once I find the right USB adapter (it's an inconvenient 1.8v serial, I only have 3.3v and 5v handy besides the one I mislaid)
[21:44:02] <jepler> doesn't get far enough into the boot to write anything to /var/log/kern.log, so it's clearly falling over quite early
[21:45:47] <CaptHindsight> it might be stuck in u-boot
[21:54:11] <jepler> triple-checked the uboot boot.txt, compared file listings of initrd, didn't turn up anything obvious
[21:54:18] <jepler> I'll be climbing the walls until I can see the console
[21:54:21] <jepler> or maybe sleeping
[21:59:24] <KGB-linuxcnc> 03Chris Radek 052.6 5c3b88a 06linuxcnc 10src/emc/usr_intf/touchy/touchy.py Touchy: Disable macro button if there aren't any macros defined * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5c3b88a
[21:59:42] <seb_kuzminsky> cradek: i was just looking at your proposed branch
[21:59:49] <cradek> seb_kuzminsky: I keep changing it
[22:00:09] <seb_kuzminsky> the touchy fix is obviously good, thanks for merging it... the splash screen one i've got mixed feelings about
[22:00:09] <cradek> it's just that one commit we've talked about briefly before
[22:00:26] <cradek> yeah I'm not thrilled about it either
[22:00:45] <seb_kuzminsky> it's jarring to see [AXIS_2]MAX_LIMIT != 0.000
[22:00:57] <cradek> I later noticed it only needs a few mm, instead of the full 1inch I put in there
[22:01:04] <seb_kuzminsky> it feels like a glitch in the matrix
[22:01:29] <CaptHindsight> http://www.digikey.com/product-detail/en/TTL-232RG-VREG1V8-WE/768-1070-ND/2441359 CABLE USB SERIAL 1.8V WIRE 100MA
[22:01:52] <cradek> do you think there's a better way to get the splash screen to run by default?
[22:02:07] <seb_kuzminsky> i wish it were enough to have those comments there that tell the user what to do, but apparently it's not, lots of people have reported that "it doesn't work"
[22:02:23] <cradek> I agree with all of that
[22:02:44] <CaptHindsight> http://www.pololu.com/product/1308 CP2104 USB-to-Serial Adapter Carrier but you have to snip a trace and supply your own 1.8V, but it's only $6
[22:03:19] <cradek> jepler: just hook up the output to your 3.3v-in convertor. who cares if you can type?
[22:04:53] <seb_kuzminsky> i also don't like how all configs still fail, except for sim/axis/axis.ini :-(
[22:05:16] <KGB-linuxcnc> 03Jeff Epler 052.6 ebc0785 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=ebc0785
[22:05:56] <seb_kuzminsky> maybe a pre-touched-off var file would be better? that too is wrong, but at least it would work for all configs
[22:06:56] <seb_kuzminsky> that commit there ^^^ is jepler's fix for gtk-builder id collisions in stepconf, i verified it works on lucid & wheezy
[22:07:19] <seb_kuzminsky> i'm ready for 2.6.1, maybe later tonight, anyone want to sneak anything in at the last second?
[22:07:49] <cradek> seb_kuzminsky: I think we don't install var files at all, because they are created when they are needed
[22:08:46] <seb_kuzminsky> yeah :-/
[22:08:48] <seb_kuzminsky> bbl
[22:09:00] <cradek> with one inept exception: /usr/share/doc/linuxcnc/examples/sample-configs/sim/gmoccapy/gmoccapy_plasma/plasma.var.BAD
[22:10:02] <cradek> # generated by gladevcp.persistence.create_default_ini() on Sat Jan 18 13:04:31 2014
[22:10:14] <cradek> what the is this even
[22:12:16] <jepler> cradek: thanks for the idea, but janky shrouded header resists alligator clips and standard .1 male jumper wires and I want to go to bed instead of frying anything
[22:12:36] <cradek> that's smart
[22:14:27] <cradek> I guess gmoccapy saves its preferences in a file named something.var
[22:14:39] <cradek> that seems like a really bad idea
[22:26:04] <cradek> seb_kuzminsky: I rewrote proposed with a smaller max.
[22:52:14] <cradek> seb_kuzminsky: I've never heard anybody complain about any of the other configs not running the splash screen. the one you get when you keep mashing enter is the one to fix.
[22:55:08] <seb_kuzminsky> yeah, agreed
[22:55:24] <seb_kuzminsky> i think your solution is the least worst of the options i can think of
[22:55:34] <cradek> yay I guess
[22:56:10] <seb_kuzminsky> i added a comment to the ini
[22:56:15] <KGB-linuxcnc> 03Chris Radek 052.6 51f96e5 06linuxcnc 04configs/sim/gmoccapy/gmoccapy_plasma/plasma.var.BAD Remove mistaken file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=51f96e5
[22:56:15] <KGB-linuxcnc> 03Chris Radek 052.6 33450db 06linuxcnc 10configs/sim/axis/axis.ini Let the splash screen run with default varfile * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=33450db
[22:56:15] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 4964890 06linuxcnc 10configs/sim/axis/axis.ini comment the funny Z max in sim/axis/axis.ini * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4964890
[22:57:00] <cradek> perfect
[22:58:53] <cradek> yay stepconf
[23:02:33] <seb_kuzminsky> the noob user still needs to know "F1, F2, Ctrl-Home, R", but that's definitely a lower bar than re-zeroing G54...
[23:05:39] <seb_kuzminsky> bummer, 2.5 doesn't merge cleanly into 2.6
[23:06:15] <seb_kuzminsky> > grep '^<<<<' src/po/fr.po | wc -l
[23:06:15] <seb_kuzminsky> 2634
[23:06:35] <cradek> oh my
[23:06:52] <cradek> do you have the magic po-file merging set up?
[23:06:58] <cradek> I think there's a trick that helps
[23:09:58] <cradek> 0397cb1 is a mess
[23:11:30] <cradek> I can't find what I'm thinking of
[23:11:42] <seb_kuzminsky> 2.6 last changed fr.po via weblate in 2012
[23:12:03] <cradek> just take the 2.5 side and move on?
[23:12:34] <seb_kuzminsky> that seems right
[23:12:43] <seb_kuzminsky> imma run that by francis tisserant
[23:15:40] <seb_kuzminsky> 2.5 has... a pncconf fix for > 5 sserial firmwares, and some docs fixes
[23:15:58] <seb_kuzminsky> and updated french docs
[23:16:23] <seb_kuzminsky> i think that can wait for 2.6.2 (which can come as soon as the fr.po thing is resolved, doesn't have to be a long wait)
[23:17:27] <cradek> I think there's a good solution for this po merge thing. jepler might know it.
[23:17:42] <seb_kuzminsky> jepler's like stackoverflow incarnate
[23:17:46] <cradek> I agree you don't have to wait, if you feel like making 2.6.1. I think fixing stepconf is critical and should be released asap
[23:17:54] <seb_kuzminsky> me too
[23:18:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.6 ec9aed5 06linuxcnc 10VERSION 10debian/changelog update changelog and VERSION for 2.6.1 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ec9aed5
[23:18:43] <KGB-linuxcnc> 03Sebastian Kuzminsky 05signed tags 4ea9bf0 06linuxcnc 03v2.6.1 LinuxCNC v2.6.1 (tagged commit: ec9aed5) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4ea9bf0
[23:19:37] ChanServ changed topic of
#linuxcnc-devel to:
http://linuxcnc.org | Latest release: 2.6.1
[23:19:47] <cradek> yay!
[23:20:26] <seb_kuzminsky> :-)
[23:21:05] <cradek> what rhymes with buildbot? I feel like writing a poem for it.
[23:21:21] <seb_kuzminsky> heh
[23:21:21] <cradek> or release
[23:22:41] <seb_kuzminsky> i keep wanting to machine a little thank-you widget to the buildbot people, and the rtai people, but i keep not finding the time for it
[23:23:16] <seb_kuzminsky> maybe a turner's cube with "thanks to buildbot, from linuxcnc" engraved on it
[23:26:10] <seb_kuzminsky> i should learn to hold my pushes on the evening leading up to a release...
[23:26:38] <cradek> I wish you could tell buildbot to just forget this one and move on
[23:26:53] <seb_kuzminsky> hmm yeah that's be good
[23:27:17] <seb_kuzminsky> well hey there is
[23:27:20] <seb_kuzminsky> imma push it
[23:27:28] * seb_kuzminsky pushed it
[23:27:45] <seb_kuzminsky> ugh, i think that was a mistake
[23:28:35] <seb_kuzminsky> hm actually that looks ok
[23:29:16] <cradek> that's a nice trick to remember
