Back
[08:45:42] <skunkworks> andypugh, kinda early?
[08:46:14] <andypugh> I popped home from work to do some soldering.
[08:47:02] <andypugh> I needed some instrumentation for a “what happens if we drain all the coolant from this engine and floor it down the motorway, does the plastic oil sump actually melt? test.
[08:49:24] <CaptHindsight> what's the Tg of the polymer used for the sump?
[08:50:11] <andypugh> About 200C
[09:01:42] <archivist> or does a rod fly through the side first
[09:03:17] <archivist> from experience though, an engine gets tight/seizes
[09:06:33] <mozmck> plastic oil sump?
[09:08:10] <mozmck> maybe another test should be "what happens when you hit a bump and the oil sump breaks open draining the oil while you floor it down the motorway" :)
[09:09:57] <archivist> over here we have speed bumps, therefore a regular occurrence
[09:10:39] <mozmck> they have them here in parking lots in front of the stores, so it probably happens a bit here too.
[09:11:35] <mozmck> my brother-in-law did that and it threw a rod out the side of the crankcase. that was an '82 mercedes diesel
[09:14:03] <archivist> I learned about bits falling of about 1970, a fan blade fell off, so I bent the other one off to put it back in balance. entire water pump came of a few days later going through the radiator, ran total loss for a month or so until I found a donor car for parts
[09:48:08] <mozmck> I'm building a gscreen skin - based on the gaxis skin. Gremlin seems to not want to display many of the sample gcode files or other that I have.
[09:53:20] <CaptHindsight> should interesting since the engine will be 100C over the designed operating temp
[09:54:54] <CaptHindsight> is there enough conduction and convection cooling from the car driving to keep it under 200C? Will it seize up or will the plastic melt first?
[10:06:07] <mozmck> Ok, looks like if the tool table does not have a tool called for in the gcode gremlin will not display it.
[11:07:50] <cradek> my parport card came yesterday, so I'll update the lathe this weekend, yay
[11:08:02] <cradek> I should also put 2.7 on it
[11:19:17] <mozmck> I should update my router table from 2.3 sometime...
[11:20:54] <archivist> iI think my mill is still on 3.3 as well :)
[11:20:58] <archivist> 2.3
[11:26:59] <archivist> any pics yet of the lathe
[11:31:40] <cradek> you mean me? it's an old sherline with servos stuck on it and running touchy
[11:32:54] <cradek> the worst part of it is that I can either have the spindle encoder mounted OR use the drawbar (for WW collets etc), not both
[11:33:09] <cradek> and it's finicky to go from one to the other
[11:34:24] <archivist> make a disk encoder so you can use both
[11:35:13] <cradek> yeah I could surely fix it, but it's such a nice encoder...
[11:36:10] <cradek> actually it would probably be easier to elongerize the drawbar
[11:36:59] <archivist> I just found your encoder pic
http://timeguy.com/cradek-files/cnc/lathe/DSCN6300.JPG
[11:37:11] <cradek> that's the one
[11:38:11] <archivist> hehe and the drive :)
[11:38:18] <cradek> ?
[11:38:19] <seb_kuzminsky> we just un-mothballed a 5'x10' shopbot at the local hackspace, it's running 2.5.0, i'm excited to upgrade it to 2.7 soonish
[11:38:27] <cradek> sweet
[11:38:31] <archivist> http://timeguy.com/cradek-files/cnc/lathe/DSCN6299.JPG
[11:38:34] <seb_kuzminsky> err, 5' x 9'
[11:39:24] <cradek> archivist: lovely isn't it?
[11:40:30] <archivist> I approve considering how many clamps hold my "tool grinder" together
[11:41:09] <cradek> and this makes me laugh, but it sure does work:
http://timeguy.com/cradek-files/cnc/lathe/DSCN6292.JPG
[11:42:12] <archivist> my 5axis has stacked parts and ratsnest wiring too
[11:42:54] <archivist> time I did a similar mod to the starturn motor speed control
[11:43:06] <seb_kuzminsky> cradek: artisanal circuitry
[11:46:17] <cradek> exactly
[11:48:08] <cradek> the problem with linuxcnc is you have to be an EE to use it
[11:50:42] <archivist> it certainly helps to know electronics
[11:51:49] <archivist> but that goes for any control system implementation from scratch without paying through the nose for magic boxes
[11:52:34] <kwallace2> The problem with machining is you have to be a machinist to do it.
[11:54:21] <mozmck> What does DTG in the DROs stand for?
[11:54:28] <jepler> distance to go
[11:54:37] <mozmck> to what?
[11:54:54] <cradek> how far 'til the end of the move
[11:55:26] <mozmck> So it is only valid or shows during a move
[11:55:41] <cradek> yes if not moving it should show zero
[11:55:44] <jepler> not sure if it's changed with the new tp, but "end of the move" would include all motions merged by the naive cam detector
[11:55:54] <Tom_itx> what does it show if it's a non linear move?
[11:56:00] <Tom_itx> or multi axis move?
[11:56:33] <jepler> it's the path distance, so for an arc it shows arc length
[11:56:38] <cradek> Tom_itx: it depends. there's one that's one number, and that would show the arc length remaining. the multi-axis dtg shows a separate number for each axis, which can be negative
[11:56:55] <jepler> cradek: oh am I mistaken?
[11:57:01] <cradek> well we do it both ways
[11:57:20] <cradek> you're right for the "total" dtg readout
[11:57:27] <cradek> but there are separate ones also
[11:57:34] <Tom_itx> that's what i was wondering
[11:58:25] <cradek> so for something like a semicircle, one of the numbers would go up (away from zero) and then back to zero
[11:59:04] <Tom_itx> it really shouldn't ever be negative
[11:59:12] <Tom_itx> considering its 'distance to go'
[11:59:16] <cradek> for g0x1y0 g3x-1y0i-1j0, Y would go up to 1 and then back to 0
[11:59:50] <cradek> Tom_itx: the dictionary agrees with you but machinists don't
[11:59:51] <Tom_itx> it should be unsigned int in any case that i can think of
[12:00:12] <Tom_itx> what do they know?
[12:00:13] <Tom_itx> :)
[12:00:51] <cradek> the single-number dtg, which was written by a programmer and not a machinist, always shows a positive number
[13:01:36] <archivist> hmm we need the mill version of this image visible too
http://linuxcnc.org/docs/html/config/images/pncconf-diagram-lathe.png
[13:02:16] <andypugh> cradek: I can’t help feeling that there is something slighlty crazy in having an encder that is wider than your spindle motor.
[13:02:27] <archivist> or something similar on our pages to
http://www.cnc-toolkit.com/support.html
[13:03:19] <archivist> I must be crazy too because the starturn encoder is wider :)
[13:04:03] <andypugh> I went through a number of iterations but finally ended up with a commercial encoder geared 1:1 and mounted inside the headstock.
[13:04:29] <andypugh> Whereas the Mill has a resolver geared 1:1 because resolbvers are cooler.
[13:05:25] <archivist> the starturn has an original fitment disk which is a lot larger diameter but does leave the drawbar hole free
[13:28:37] <mozmck> heh! everyone should quit using the antiquated IRC:
http://www.linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/28998-linuxcnc-support/reply/57036
[13:31:18] <mozmck> On a similar note, a guy on the kicad channel who also dislikes forums in general, said that this one was actually really nice:
http://www.discourse.org/ here is a forum that uses it
https://forum.kicad.info/
[13:31:56] <mozmck> I believe he said you can use it like a mailing list.
[13:35:54] <archivist> odd forum error The page isn't redirecting properly Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
[13:36:31] <archivist> This problem can sometimes be caused by disabling or refusing to accept cookies., never none that on this box
[13:37:51] <mozmck> interesting, it works for me.
[13:38:19] <mozmck> I wouldn't have a problem with a forum if I can just use it from email and don't have to get on the forum :)
[13:39:04] <mozmck> I'm on one mailing list that uses google groups I think, and it works like that. Just looks like a mailing list to me, but it has a web interface as well.
[13:41:36] <archivist> you seem to have extended the correct url
http://www.linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/28998-linuxcnc-support is all I need
[13:42:50] <mozmck> Oh, for our forum link, I thought about a reply but decided not to :)
[13:43:58] <mozmck> It's the FLTK mailing list I'm on that is at googlegroups.
http://www.fltk.org/newsgroups.php You can subscribe by mail without having a google account (which I don't), and then it works just like a mailing list.
[14:09:04] <mozmck> I'm wanting to use a button to trigger an action in a custom HAL component. A HAL_Button is momentary, so if it is not pressed long enough the component will miss the signal. Is there an easy way to do this?
[14:09:31] <archivist> a latch
[14:11:21] <cradek> sounds like the whole button strategy is wrong
[14:11:38] <cradek> what you really want to know is if there's been a rising edge since you read the "button" last
[14:12:13] <cradek> yeah the button latches on, and when you read it the latch is cleared?
[14:12:18] <mozmck> rising edge? this is not a physical button...
[14:12:26] <mozmck> is there a latch component?
[14:12:55] <archivist> in software one sets a flag
[14:13:06] <cradek> probably, but it seems like it should be part of the button
[14:13:58] <andypugh> mozmck: There is a latch, and you could run it in the base thread, but just how short is this button press?
[14:15:09] <mozmck> Hmm, maybe I can do it in python in the button handler. Set an IO type HAL pin, so it can be unset by the other component.
[14:15:52] <andypugh> If I built uspace on a normal kernel because (hypothetically speaking) am an an imbecile. Would I need to re-make on a PREEMPT-RT kernel to get it to work in an actual realtime config?
[14:16:35] <andypugh> mozmck: By the time the button handler has seen it, it would seem that the “consumer” of the pin would have seen it.
[14:17:14] <mozmck> It's a button on the screen - I don't know how long it takes for the HAL pin behind it to update. The consumer is another userspace HAL component that reads it's pins about every 20ms
[14:22:57] <cradek> interestingly, hal I/O pins would be perfect for this
[14:23:12] <cradek> you set the pin true by poking the button, it sticks in
[14:23:27] <cradek> when the component reads it and finds a true, it sets it back to false, and the button pops out to show you it's been read
[14:24:18] <cradek> I bet a suitably smart person could add that kind of HAL_Button
[14:25:28] <cradek> you have the extra benefit of seeing how fast your component is consuming the buttonpokes (if it's reading once a second you won't be able to poke twice in a second and then be confused by your frobnicator only dispensing one widget)
[14:26:22] <andypugh> I am actually meddling with HAL buttons at the moment. The bit I am having most enjoyment from is pulling different button graphics from a common SVG file.
[14:26:35] <cradek> neat
[14:26:40] <andypugh> rsvg makes that pretty easy.
[14:27:31] <andypugh> http://pastebin.com/4t2Y8PfM in case it sounds useful.
[14:28:02] <andypugh> And I just noticed “make_shape”. That’s dead code (jim)
[14:30:08] <mozmck> cradek: thanks, that is what I was thinking.
[14:30:22] <mozmck> maybe I'll make a HAL_IO_Button or something
[14:30:35] <cradek> mozmck: it sure sounds like a good thing, doesn't it
[14:30:59] <mozmck> Does to me!
[14:33:40] <mozmck> I wonder if there would be any interest in Qt binding for linuxcnc at some point. gtk-2.0 is not supported any more I believe, gtk-3.0 is mess, and many projects are going over to qt nowadays.
[14:34:11] <cradek> oh probably
[14:34:40] <cradek> it makes me sad to accumulate even more dependencies, but the writing might be on the wall
[14:34:42] <mozmck> I've never used qt, but I think *everyone* I have read or talked to that have used it says it is great overall - especially if they have also used gtk :)
[14:35:22] <cradek> yes seems like it's the one that's currently in style
[14:35:24] <mozmck> true
[14:36:32] <cradek> long ago, one day when he was bored, I think jepler rewrote AXIS in qt, or maybe it was gtk
[14:36:40] <mozmck> I have never been fond of gtk myself. It's a real pain compared to other toolkits I've used (win32, fltk, wxwidgets)
[14:37:05] <cradek> heh wxwidgets, the one that's never been in style
[14:37:31] <mozmck> Someone wrote a Qt interface for machinekit, but I think it uses a lot of the new stuff in that.
[14:37:49] <mozmck> if you've ever written MFC code, wxwidgets is easy to learn.
[14:37:59] <cradek> nope not me
[14:38:00] <mozmck> Kicad uses wxwidgets.
[14:40:27] <mozmck> for small utilities I really like FLTK. you can statically link to it and it add about 400K to your binary. cross-platform, simple, and fast.
[14:42:18] <andypugh> What does “Note: Using POSIX realtime” indicate?
[14:46:33] <andypugh> I am wondering if ./configure is failing to spot the real-time-ness of my kernel
[14:46:58] <mozmck> I think it means linuxcnc is using uspace realtime
[14:47:12] <andypugh> Yes, but which one?
[14:48:09] <mozmck> Not quite sure how it works, but I think linuxcnc just has to set it's priority to get realtime if the kernel is preempt-rt, and if it is not then it doesn't work as well.
[14:48:39] <andypugh> Does 125,000 latency sound right for prempt-rt? I was hoping for better.
[14:49:46] <mozmck> I guess that depends on the hardware.
[14:50:01] <andypugh> Opening a web-browser just gave me 6,871,000 latency.
[14:50:02] <mozmck> PCW was saying that 50,000 was not too good.
[14:50:11] <mozmck> is that the rpi2?
[14:50:14] <andypugh> Yes
[14:50:14] <cradek> andypugh: that sounds pretty unusable
[14:50:17] <cradek> :-(
[14:50:37] <mozmck> I wonder if there are kernel settings that might help that.
[14:50:38] <cradek> did you do the make setuid?
[14:50:52] <andypugh> No, I didn’t do the setuid
[14:50:55] <mozmck> Oh, yes, that did make a difference in my testing last night.
[14:50:56] <cradek> I think it needs that to become realtimeish
[14:51:06] <andypugh> I thought that was only run-in-place?
[14:51:11] <cradek> oh right
[14:51:14] <cradek> what are you running?
[14:51:39] <memfrob> i'm getting 5ms in RTAI right now but with uexplained kernel locks
[14:51:42] <mozmck> did you do a 'make install' ?
[14:51:50] <mozmck> 5ms?
[14:52:08] <memfrob> indeed. lowest numbers i've seen yet
[14:52:14] <memfrob> (on my board)
[14:52:19] <cradek> you must mean a different unit
[14:52:26] <memfrob> us?
[14:52:31] <cradek> you tell us :-)
[14:52:53] <andypugh> cradek: I used —prefix=usr to get an installed version. Was that wrong?
[14:52:55] <memfrob> the unit latency-test uses
[14:53:02] <cradek> probably us (5,000 ns)
[14:53:13] <memfrob> yes that
[14:53:18] <cradek> andypugh: not so much wrong as untested and hard to uninstall
[14:53:44] <cradek> andypugh: pretty much we test rip, and packaged into a deb
[14:53:52] <andypugh> But rip is such a pain, you have to open a terminal every time
[14:54:27] <andypugh> Is there any clue in the configure output that the system has detected a realtime kernel?
[14:54:38] <memfrob> andypugh: /home/<your user>/.bashrc
[14:54:46] <cradek> I thought "create desktop shortcut" still worked if rip
[14:55:18] <cradek> and: my rip says 'Note: Using POSIX non-realtime'
[14:55:22] <cradek> andypugh: ^
[14:55:37] <andypugh> I thought (probably wrongly) that rip-environment only had any context at all inside a shell
[14:55:41] <cradek> a plain kernel, not setuid
[14:55:57] <andypugh> Ah. Well, that’s a shame then
[14:56:30] <cradek> it does seem like it all worked right if yours is saying that
[14:56:30] <andypugh> I don’t think 6mS latency with prreempt-rt was worth the time invested
[14:57:22] <cradek> that's a better result than this guy, who got freezes:
http://article.gmane.org/gmane.linux.rt.user/13057
[14:57:47] <mozmck> andypugh: you might try running from rip and run do make setuid
[14:58:04] <mozmck> in case the setuid did not get done right by make install
[14:58:30] <cradek> can't hurt, but I bet the message saying it works is right
[14:58:57] <mozmck> I think I got that message even before I ran make setuid
[14:59:03] <mozmck> but latency was much worse
[14:59:12] <cradek> hmm!
[14:59:31] <mozmck> can test it right now because I'd have to reboot
[15:00:01] <cradek> andypugh: perhaps try
https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO#Benchmarking
[15:02:15] <andypugh> If I _do_ create a run-in-place where does the code end up?
[15:02:23] <andypugh> In the git directory?
[15:02:36] <mozmck> I tried compiling that cyclictest, but it failed to find numa.h
[15:02:58] <cradek> yes it's all written inside the source tree itself
[15:03:04] <mozmck> in linuxcnc-dev/bin share, etc
[15:03:24] <andypugh> Which in this case is physically on a diferent machine and nfs-mounted
[15:03:51] <andypugh> (Not that is has to be)
[15:04:08] <andypugh> Bear with me, I may be gitting for some time
[15:05:06] <cradek> if hurting for space or time, git clone --depth 1
[15:09:54] <andypugh> mozmck: The bottom of the cyclictest page says what to o about numa.h
[15:18:51] <mozmck> ooh, I didn't see that.
[15:21:02] <cradek> andypugh: I guess my usual git clones are all on nfs too, but I never think about it
[15:21:26] <cradek> andypugh: my desktop has nfs home directory because zfs
[15:25:36] <andypugh> Are they pysically-remote nfs though?
[15:25:54] <cradek> well the basement
[15:26:21] <cradek> it's gigabit
[15:28:31] <mozmck> So is there a way to make gremlin show the toolpath even if all the tools are not found, and notify the user of the problem?
[15:28:55] <mozmck> What about doing a manual toolchange, do you need a tooltable for that?
[15:29:37] <cradek> if a tool is not found, that's an error, and running the gcode stops
[15:29:50] <cradek> whether manual or not, doesn't matter
[15:30:00] <jepler> t1 is an error if there's no entry in the tool table?
[15:30:05] <cradek> yes
[15:30:12] <jepler> it's been awhile since I have used linuxcnc, I didn't even know that
[15:30:40] <cradek> t789 => Requested tool 789 not found in the tool table
[15:36:38] <mozmck> So I need to figure out a way to let the user know that - other than just not displaying the toolpath
[15:38:35] <mozmck> If you are not using cutter compensation, why should it be an error if there is not an entry or wrong entries for the tools?
[15:51:36] <cradek> mozmck: there's an error, right? that's how you let them know, isn't it? there are lots of ways a program can fail
[15:51:41] <cradek> they should all give errors
[15:51:52] <cradek> maybe I don't understand something here
[15:53:09] <mozmck> It's probably me that doesn't understand a lot :)
[15:53:30] <mozmck> I don't know if there is an actual error when loading the gcode.
[15:53:46] <cradek> in AXIS there is
[15:53:51] <cradek> and the preview stops
[15:54:22] <andypugh> RPi channel discussion suggests that the Pi GPU can interrupt the ARM processor. Which is not a recipe for great latency.
[15:54:23] <cradek> because if you run it, it'll stop there and error - so that's a perfectly correct preview!
[15:59:51] <mozmck> ok, so axis does that, but gscreen-gaxis does not and gives no indication of the error other than in the terminal I started it from.
[16:00:17] <cradek> that feels a lot like a bug
[16:00:43] <mozmck> gscreen seems to need a bit of TLC
[16:04:57] <andypugh> A compiler warning, probably of no relevance:
[16:04:58] <andypugh> Compiling emc/task/taskmodule.cc
[16:05:23] <andypugh> tmp/ccKMWBKw.s: Assembler messages:
[16:05:23] <andypugh> tmp/ccKMWBKw.s:17468: Warning: swp{b} use is deprecated for ARMv6 and ARMv7
[16:05:53] <andypugh> I guess that ARMv-anything is not really a core LinuxCNC concern?
[16:05:57] <cradek> andypugh: I think that means there's a bug in your toolchain, not your code
[16:06:22] <jepler> if linuxcnc contains an __asm__ which directly specifes a swp{b} instruction, then it's a linuxcnc bug. otherwise, it's a toolchain bug.
[16:06:23] <cradek> unless you've got arm assembler hardcoded in taskmodule.cc which I bet you don't
[16:06:31] <jepler> http://stackoverflow.com/questions/13584091/arm-warning-swpb-use-is-deprecated-for-this-architecture
[16:07:04] <cradek> > I fixed the problem by upgrading to a newer version of GCC.
[16:07:06] <cradek> sigh
[16:07:11] <andypugh> I try to keep out of anything ending .cc :-)
[16:08:48] <andypugh> This gcc was installed at the weekend, so probably isn’t very old…
[16:09:33] <cradek> maybe 6 days is pretty old in the arm world
[16:11:48] <andypugh> I could hate Arm if it wasn’t the only bit of computer industry the UK has left.
[16:12:39] <cradek> I bet in 10 years they'll just work, like i386/amd64 systems do today
[16:12:43] <cradek> that will be nice
[16:13:10] <jepler> andypugh: I suspect that the cause is this:
https://svn.boost.org/trac/boost/ticket/5331
[16:13:36] <jepler> if raspbian is like debian wheezy, it has boost 1.49. emcmodule.cc does indirectly use boost smart_ptr
[16:15:02] <jepler> from my googling, when the swp instruction is encountered, it'll enter the kernel and be emulated
[16:15:19] <jepler> so it'll be slower but that's not important in taskmodule
[16:16:21] <andypugh> It seems unlikely that the Pi will be usable anyway.
[16:16:39] <jepler> I got linuxcnc non-realtime running on it. it didn't perform very well.
[16:16:45] <jepler> the odroid u3 is still far faster than the pi2
[16:17:16] <andypugh> I have the Pi2 running Preempt-RT. It still appears to be awful.
[16:17:27] <jepler> preempt-rt isn't going to make it perform better, that's for sure
[16:17:31] <jepler> build times are abysmal
[16:17:45] <jepler> there's too little RAM to take advantage of the multiple cores when building linuxcnc, so that's incredibly painful
[16:18:18] <andypugh> I was rather hoping that Preempt-rt would give better alatency than Posix, though.
[16:19:37] <jepler> yeah
[16:19:43] <jepler> I hear you
[16:20:22] <andypugh> I might see what the Udoo does with PREEMPT now that I am on a roll :-)
[16:20:38] <andypugh> That doesn’t have the wierd “GPU as Master” configuration.
[16:21:00] <andypugh> (THough that configuration might be why the graphics performace is good, and that of the BBB is awful)
[16:21:28] <andypugh> Maybe the Dream-Team is a BBB + PRU for Realtime and a remote Pi for the GUI…
[16:21:50] <andypugh> Or you could just use a cheap Atom board nad get on with making parts.
[16:21:52] <cradek> or an effing pc
[16:22:54] <andypugh> Hmm, maye use an aArduino to bridge the data from the BBB PRU to a Mesa FPGA card :-)
[16:23:14] <cradek> I got a great one for $20 from goodwill (dual core, including 3GB ram) but had to spend $25 to get a parallel port from newegg to run my pluto
[16:23:21] <jepler> andypugh: once you fix the latency problems in bbb's kernel spi driver, you could spi to a mesa fpga
[16:23:24] <jepler> no prus needed
[16:23:44] <andypugh> Does hm2_spi work by the way?
[16:24:02] <andypugh> I have seen the file in the directory but heard nothing of it.
[16:24:12] <jepler> hm2_spi works for me on the odroid u3 with preempt-rt, but I had to mdoify the kernel-side SPI code before it had good latency.
[16:24:22] <jepler> I worked on that nearly a year ago now
[16:24:30] <seb_kuzminsky> did the rt-preempt folks accept your spi-driver patch?
[16:24:38] <jepler> as far as I know, I'm the only one who's ever used, it, but so many things are like that
[16:24:47] <jepler> seb_kuzminsky: no, I didn't try very hard either
[16:28:22] <micges> jepler: your kernel spi driver modifications are on github?
[16:29:30] <jepler> micges: yes, they're the top few commits at
https://github.com/jepler/odroid-linux/commits/odroid-3.8.13-rt
[16:29:58] <jepler> I have been meaning to try with 3.18. I think that 3.18 has a devicetree for the u3 and of course it now has an rt patch
[16:30:18] <andypugh> Would it be totally stupid to consider a bit-banged EPP interface usinf RPi GPIO?
[16:30:49] <andypugh> 3.18.9 + rt-5 seems pretty smooth to patch and make.
[16:32:30] <andypugh> After my trials and tribulations with Udoo and Xenomai it came as a huge surprise to just watch the patch take with no messing about.
[16:33:11] <andypugh> (It makes me wonder why it is a patch at all, and not just a compile flag)
[16:33:50] <jepler> andypugh:
http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ suggests that C can toggle I/O pins at 22MHz, probably around the same on pi2
[16:34:23] <jepler> so it's not implausible to manage single-digit MB/s in software EPP
[16:35:21] <andypugh> Which is probably all you need for 7i43 and friends.
[16:35:55] <andypugh> But after compiling run-in-place and sudo make setuid I _still_ have 7.5mS latency, so that seems like “experiment over” to me.
[16:36:21] <jepler> :-/
[16:36:25] <jepler> opposite of fun times
[16:39:38] <andypugh> Pi2 is Arm7. RTAI supports Arm7.
[16:39:46] <jepler> andypugh: if it says 'Note: Using POSIX realtime' then you're not going to get real-er time without changing the kernel.
[16:39:52] <andypugh> But I doubt that RTAI would be any better really.
[16:40:21] <andypugh> jepler: I already changed the kernel. You mean changing it some more?
[16:40:23] <jepler> were the m------k-- people promoting xenomai for pi? I forget.
[16:40:45] <jepler> andypugh: yeah, finding whatever is bad and fixing it. not something to undertake on a friday night
[16:41:18] <andypugh> I think the bad thing is that the GPU preempts the Arm whenever it wants to access memory.
[16:41:20] <jepler> .. looks like, based on this probably-stale page
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RaspbianXenomaiBuild
[16:41:58] <jepler> (those images of course could not work on pi2)
[16:47:58] <jepler> see you guys
[16:48:17] <andypugh> Goodnight
[16:48:51] <andypugh> memfrob: Any thoughts on RTAI on Pi?
[16:49:41] <andypugh> (Actually, not worth considering as that doesn’t support hm2_eth)
[16:49:55] <memfrob> rtai barely supports arm
[16:50:43] <memfrob> and rtai has to be made for each arm board, specifically the timer
[16:51:23] <memfrob> rtai is fail for anything non-x86
[16:57:23] <memfrob> that's why i dropped anything non-x86 in rtai
[17:26:24] <memfrob> builing xenomai for arm boards though is really easy, toughest part is getting the kernel to boot.
[17:26:54] <memfrob> strip down as much as possible for low latency, add performance hacks and such, adjust power management yada yada and hope it loads
[17:27:08] <andypugh> But then LInuxCNC won’t run on it...
[17:28:29] <memfrob> true but linuxcnc could use some rtapi work.
[17:29:10] <memfrob> it could really use a direct ipipe handler, no need for xenomai or rtai.
[17:29:41] <mozmck> guess I stepped in it now :)
http://www.linuxcnc.org/index.php/english/forum/38-general-linuxcnc-questions/28998-linuxcnc-support
[17:29:58] <memfrob> that should be the long term fix because right now i'm the only dev for rtai for linuxcnc, linuxcnc doesnt support xenomai without using mhaberler's stupid branches, and preempt-rt has bad performance
[17:30:48] <memfrob> and i'm not always going to be able to re-write all of paolo's stuff but i've been pacing myself carefully but i dont think i can fix the issues i'm having with the new magma branch.
[17:31:14] <memfrob> so rtai may just need to be dropped if i can't fix it and nobody else will. *checks thread*
[17:32:11] <mozmck> what is it about paolo's stuff that needs fixing/re-writing for linuxcnc?
[17:32:28] <memfrob> pretty much everything.
[17:33:00] <memfrob> i'm lucky if i can ever get upstream magma to compile.
[17:33:26] <mozmck> hmm, I haven't tried in quite a while
[17:33:53] <memfrob> the only good working branch that works with linuxcnc right now is my master branch at github.com/ntulinux/rtai
[17:34:21] <memfrob> dev branch i'm still working on but i dont know for how much longer considering i've hit a dead end
[17:35:49] <memfrob> i'm diffing it one more time (4th try) in an effort to try and notice any changes to explain my kernel crases, if not, that's it.
[17:36:06] <memfrob> every time i diff the trees i see nothing that stands out.
[17:36:57] <memfrob> math support, scheduler, kernel patches, inlining and compiler flags are the main things that need to be changed
[17:39:19] <memfrob> the rest is all code clean-up so it's easier for me to re-write the tree and get a better understanding of what's going on.
[17:39:45] <memfrob> bbl
[18:08:26] <PCW> decent RTAI latency:
[18:08:27] <PCW> http://ibin.co/1vWM6bCQvh3l
[18:16:14] <skunksleep> Someone gave us a i3 computer that seems to have awesome latency
[18:16:25] <skunksleep> Levino
[18:18:40] <PCW> I suspect (but am to cheap to find out) that say a H81 or H97 based MB and almost any Pentiium/I3/I5/I7 would be very good
[18:19:26] <jepler> give it a few more years and we won't be able to put linux on PCs anyway.
http://arstechnica.com/information-technology/2015/03/windows-10-to-make-the-secure-boot-alt-os-lock-out-a-reality/
[18:19:34] <jepler> we can all just go home at that point
[18:19:35] <jepler> yay
[18:22:03] <PCW> I suspect that would backfire at this late date
[18:28:26] <mozmck> I hope so. Seems like Microsoft is up to old tricks.
[18:28:51] <jepler> we can meet back here in two years and see whether one of dell, hp, or lenovo has shipped a Windows 10 PC with Secure Boot mandatory...
[18:29:49] <mozmck> dell seems to have a pretty active linux group, and you can get a dell laptop with linux pre-loaded.
[18:31:18] <PCW> everything just worked on used dell I got to test preemt-rt/hm2_eth
[18:32:47] <jepler> jon e has long favored used dells iirc
[18:33:46] <mozmck> I made a HALIO_Button. I used a togglebutton because I don't think you can set a regular GtkButton active like that?
http://pastebin.com/0JnxaZyp
[18:34:10] <mozmck> ignore the configure and config.in changes :-/
[18:35:01] <PCW> This was a latitude E6420 $190 4G 320G HD Win7 Pro 2.5 GHz second gen I5
[18:35:47] <PCW> decent preemt_rt performance unless you pull the charger
[18:37:06] <mozmck> So is that 4us max latency shown?
[18:38:03] <PCW> Thats not a laptop :-)
[18:38:49] <mozmck> ok, but I'm not sure if I'm reading the histogram correctly.
[18:39:30] <PCW> Thats a cheap but recent desktop motherboard (Asrock H97) and a Pentium G3258 (cheap Haswell type dual core)
[18:40:08] <mozmck> not bad.
[18:40:50] <PCW> I cant remember the laptops numbers for RTAI but they were about 40 usec after running hd videos all day in preemt-RT
[18:41:15] <PCW> (so fine for hm2_eth)
[18:48:06] <mozmck> PCW: are you using isolcpus or set_affinity for preemt-rt?
[18:48:21] <PCW> no
[18:48:59] <mozmck> ok
[18:57:01] <PCW> when I started i fussed with IRQ affinities some but never got noticeable improvement in latency
[18:57:02] <PCW> (but I could have made some mistake and you really need some kind of automated long term testing to see real differences)
[19:05:28] <memfrob> has anyone here actually tried windows 10 tech preview?
[19:06:10] <memfrob> im waiting for the first D3d12 game and i was going to give it a whirl in my r9 290 gpu
[19:19:21] <mozmck> I stay away from windows as much as I can. When I have to run it I'm on XP still
[19:24:22] <Tom_itx> memfrob i had a chance to but declined. it's alot like 8
[19:24:37] <Tom_itx> menus open up to a program list like 8
[19:24:40] <memfrob> i run 8.1 with classic shell
[19:24:46] <memfrob> avoids that problem ;)
[19:25:01] <Tom_itx> i got 7 instead
[19:25:44] <Tom_itx> local pc guy had a copy of it i could have looked at
[19:26:35] <memfrob> i got infected too much on 7. antivirus hurts my frame rates and 8.1 seems to be just fine without much security
[19:27:35] <memfrob> so every month i install eset, run a deep scan, then uninstall :)
[19:31:14] <mozmck> seb_kuzminsky: If my HALIO_Button looks good, can it go in 2.7?
[19:52:47] <mozmck> logger[psha]:
[19:52:48] <logger[psha]> mozmck: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2015-03-21.html
[19:53:05] <mozmck> logger[mah]:
[19:53:05] <logger[mah]> mozmck: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2015-03-21.html
[19:53:36] <mozmck> zlog
[20:01:42] <andypugh> what _was_ shereprobe for, and is it useful?
[20:02:01] <andypugh> (sphereprobe)
[20:12:09] <andypugh> Interesting, it seems that the otherwise-functional Rpi RT-PREEMPT kernel does lock up as advertised. Which really slows-down kernel builds :)
[20:12:51] <mozmck> I bet!
[20:13:21] <mozmck> I'm not sure what yoshimitsuspeed wants - linuxcnc does have a forum.
[20:14:22] <andypugh> he wants a forum that the devs read
[20:14:49] <andypugh> (Which is not an unreasobable request)
[20:15:27] <memfrob> what's his question? maybe i know the answer?
[20:15:43] <memfrob> or.. someone else here does?
[20:15:43] <mozmck> except for the time involved. something like discourse or googlegroups might work, because you can use them exactly like a mailing list.
[20:16:18] <mozmck> He says 2.7 runs slower than 2.6 or something like that.
[20:16:19] <memfrob> andypugh: when and where does it lock up? anything interesting in dmesg?
[20:16:38] <andypugh> Hard to read dmesg when locked up…
[20:16:52] <memfrob> ah yes and you're all out of UARTs..
[20:17:13] <memfrob> when oes it lock up? at boot, compile time, rt load?
[20:17:39] <memfrob> *does
[20:18:00] <memfrob> you finally got the kernel past the boot loader / gpu firmware issue you were having?
[20:18:06] <andypugh> It seemed to be about an hour in, when compiling a slightly different kernel.
[20:18:23] <memfrob> are you using the stock kernel or the preempt rt kernel to compile it?
[20:18:44] <memfrob> it might be getting too hot. just a theory.
[20:18:54] <andypugh> memfrob: Yes, indeed, I have managed to prove that latency with Rpi2 + PREEMP-RT is truly dreadful.
[20:19:25] <andypugh> I was compiling in preemp-rt, I just swapped back
[20:19:30] <memfrob> can you post your kernel? maybe i can take a look and lower latency?
[20:19:40] <memfrob> *kernel config
[20:20:17] <andypugh> Well, I just swapped to a different power management and “periodic ticks” which I saw suggested
[20:20:39] <memfrob> i use the simple ticks..
[20:21:08] <memfrob> but hey give it a shot! different hardware anyways
[20:22:03] <andypugh> http://pastebin.com/JdjqfUYC
[20:22:15] <cradek> andypugh: I recall simulating a sphere (because it was an easy shape to program) when writing smartprobe.ngc, when adding the several probing primitives necessary for that kind of thing
[20:22:29] <cradek> andypugh: I'm surprised to see jepler listed as the author, so maybe my memory isn't perfect
[20:22:55] <memfrob> andypugh: what distro?
[20:22:56] <andypugh> I think I have found a use for nearly everything but that and sim-encoder
[20:23:00] <cradek> andypugh: but it's an object you can probe in simulation
[20:23:04] <cradek> heh
[20:23:20] <andypugh> memfrob: Raspbian
[20:23:44] <andypugh> sim-encoder feels like it should be useful, but it really isn’t ;-)
[20:24:12] <memfrob> rpi-3.18.y yes?
[20:24:22] <andypugh> 3.18.9
[20:24:36] <memfrob> branch name i mean
[20:24:40] <cradek> I think it was used to test (in simulation) the software encoder counter - when doing velocity estimation and that kind of fancy stuff
[20:25:01] <andypugh> memfrob: Yes, that branch
[20:25:04] <cradek> have you used encoder_ratio?
[20:25:19] <cradek> that's a funky one I've never touched
[20:25:50] <andypugh> cradek: I think I nearly used encoder-ratio once, but didn’t. I wanted to use sim-encoder but it didn’t do what I hoped.
[20:26:38] <andypugh> These feel like left-over test cases rather than useful bocks for users/integrators
[20:26:47] <cradek> yoshi just wants his free support to be available in the format most convenient to him, nothing strange there
[20:27:01] <cradek> yeah, sphereprobe certainly is that
[20:27:39] <cradek> maybe also sim_encoder, but probably not encoder_ratio
[20:28:12] <memfrob> andypugh ill look it over, thankd
[20:28:14] <memfrob> *thanks
[20:28:20] <cradek> maybe the manpages should say that (would be less severe than just removing them)
[20:29:03] <cradek> andypugh: do you really spend an hour every day clicking on things in the forum? if so THANK YOU for doing that
[20:30:27] <cradek> I scan a lot of the messages on the forum, especially if the subject looks interesting, but it's tedious to reply so I do it very rarely
[20:30:40] <cradek> (get them through an rss to email gateway)
[20:33:19] <andypugh> Most Frustrating comp is “lut5” because it is fantasticallly wonderful but hard to explain to folk who don’t think in bits why it is the answer to their question.
[20:33:51] <cradek> yeah - is there still the generator on the wiki somewhere?
[20:34:11] <cradek> lut5 is something only a mother^Wprogrammer can love
[20:34:38] <cradek> interestingly the forum does not yet have more messages than the emc-users list (not even counting the devel list)
[20:34:45] <cradek> that surprises me
[20:47:45] <andypugh> cradek: There is a generator in my google docs.
[20:48:36] <andypugh> https://docs.google.com/spreadsheets/d/1_VlL39jUOPpS8Tt9mpRK-eaSTS6C6PHBDoE3JitvLzs/edit#gid=0
[20:53:11] <cradek> neato
[21:01:18] <memfrob> andypugh: want me to compile it as well or just send a config?
[21:05:37] <andypugh> Do you have a Pi2? It would be interesting to compare notes, and I am good at creating non-booting kernels (as a confounding factor)
[21:05:49] <memfrob> i do not have a pi2
[21:06:13] <memfrob> but i am a kernel hacker :)
[21:12:07] <memfrob> are you building an initrd or just a stand alone kernel?
[21:18:05] <andypugh> Just a kernel image + modules. Rpi has a wierd system where the _GPU_ reads a file config.txt and chooses the kernel to boot.
[21:18:50] <andypugh> So, earlier today that file contained “kernel=zImage”
[21:27:40] <memfrob> does raspberry pi use ohci / ehci for USB?
[21:27:51] <memfrob> theres no good specs anywhere for it. i wish there were.
[21:28:16] <memfrob> I2C adapter, etc.
[21:34:22] <andypugh> I really have no idea. But have changed almost nothing in that config if that gives clues. I jist turned on RT-PREEMPT and switched to periodic ticks in timers.
[21:37:48] <memfrob> ext4 fs?
[21:40:38] <andypugh> Probably FAT32. I didn’t reformat the SD card. Does dd copy the format too? I would assume not
[21:42:14] <memfrob> rpi2 is dual core yes?
[21:43:11] <jepler> memfrob: quad
[21:43:24] <memfrob> just wanted to be sure its SMP :)
[21:45:27] <andypugh> Time for me to sleep. scroll-back will expire. memfrob can you send me a private chat for anything I need to see tomorrow morning?
[21:45:37] <memfrob> sure!
[21:45:57] <andypugh> I will leave this open, but I will be incommunicado
[21:53:54] <Tom_itx> there is zlog too
[21:55:57] <memfrob> andypugh: try this config: pastebin./Q15ZAFb9
[21:56:01] <memfrob> err
[21:56:07] <memfrob> pastebin.com/Q15ZAFb9
[21:56:19] <memfrob> two PCs, must type links by hand
[22:01:42] <memfrob> err made a mistake, updated link andypugh: pastebin.com/eayZB7P1
[22:30:04] <cradek> in AXIS in 2.7, while a single-stepped move is going, you can't pause (poking p does nothing); s then p does pause
[22:50:28] <cradek> hm and the time estimate is wildly wrong: F600 in the program, Properties shows "Feed distance: 7568 mm" and Run time 2.2 minutes. Pretty sure it should say 12.6min + whatever contribution from the rapids
