Back
[09:27:31] <seb_kuzminsky> if we make a new fixed linux-image with pae enabled, it'll have a new abi number, so it can be installed at the same time as the old non-pae pae kernel
[09:27:53] <seb_kuzminsky> but the ner kernel image will need a new rtai-modules, and that would conflict with the old rtai-modules for the old kernel
[09:28:16] <seb_kuzminsky> so currently you can't have both versions installed at the same time
[09:28:39] <seb_kuzminsky> and mozmck is right, when you upgrade the kernel it pops up a window saying you have to restart
[09:29:41] <seb_kuzminsky> both the old 3.4-9 and the new 3.4-10 kernels are offered as options in the grub menu
[09:35:02] <seb_kuzminsky> if you forget to run 'debian/configure -r' and dpkg-checkbuilddeps you can forget to install the new kernel-headers, and then src/configure fails
[09:35:59] <seb_kuzminsky> because the rtai-config script says it needs the new headers but they're not there
[09:36:04] <seb_kuzminsky> so that's pretty good i guess
[09:49:05] <cradek> is the cure worse than the poison?
[09:49:18] <cradek> we could make the switch when we release 2.7
[09:59:21] <skunkworks> https://github.com/robEllenberg/linuxcnc-mirror/compare/feature/spiral-arc-handling-rebase
[09:59:29] <skunkworks> tgif
[10:03:05] <mozmck> The term "signal" as used in HAL seems to be more like what I normally hear called a "net" - or is my conception of it wrong?
[10:03:27] <cradek> nope, I think you have it
[10:04:30] <mozmck> ok, thanks. Maybe as I learn (re-learn because I forgot a bit!) HAL I'll write down some notes for possibly clarifying the documentation.
[10:05:08] <archivist> I suppose it is both, nets carry signals
[10:07:12] <mozmck> The terminology I'm used to is that the signal is the electrical state of the wire: high, low, or serial data or such.
[10:08:21] <mozmck> but my experience is admittedly rather small...
[10:23:11] <skunkworks> in one of the explainations of a signal - they use a wire analogy..
[10:23:33] <archivist> to me the net is the wire
[10:26:29] <mozmck> to me too, but as skunkworks says they do say that a signal is the equivalent of a wire
[10:30:04] <mozmck> I don't see much information on HAL functions: can you make functions in userspace components that can be run from HAL threads?
[10:33:01] <skunkworks> I don't think there are functions for userspace components.. just pins that get read and wrote to..
[10:34:34] <cradek> that's right
[10:34:46] <mozmck> It kind of looks that way, but I don't see anything that really says.
[10:34:50] <mozmck> oh, ok.
[10:34:57] <cradek> hal functions are all realtime
[10:35:16] <cradek> userland have to run their code at their leisure
[10:35:56] <pcw_home> I'll add 2+2 when I get around to it buddy
[10:36:21] <seb_kuzminsky> what cradek and skunkworks say is true, and mozmck's probably right that the docs dont explain that clearly
[10:36:36] <skunkworks> we are all right!
[10:36:41] <seb_kuzminsky> however, things are a bit muddled by the new "uspace" stuff in 2.7
[10:36:52] <seb_kuzminsky> there, "realtime" components run in "userspace"
[10:37:21] <seb_kuzminsky> the distinction really is: "realtime" components have hal functions that get added to hal threads via addf
[10:37:30] <mozmck> Ok, well I'm definitely going to start making notes. Seems like there needs to be a HAL component/driver developers manual as well.
[10:37:51] <seb_kuzminsky> "nonrealtime" components do not, they run as their own process in linux and can interact with hal via pins (& params) only
[10:38:10] <seb_kuzminsky> mozmck: that'd be helpful
[10:56:50] <seb_kuzminsky> i installed the 3.4-10 kernel and rtai-modules, rebuild linuxcnc, and it's passing the tests
[10:57:01] <seb_kuzminsky> and 'free' shows all 6 GB of memory
[11:13:52] <skunkworks> thank goodness - I was afraid I wouldn't be able to put more than 3gb of memory in my cnc... ;)
[11:19:36] <pcw_home> or have to endure the horror of swapping
[11:49:48] <seb_kuzminsky> heh
[11:50:30] <skunkworks> I miss jeff
[11:50:47] <seb_kuzminsky> i hope he comes back one day
[11:52:03] <skunkworks> monday? (I guess not hearing correctly doesn't quite work the same on the internet)
[11:52:37] <seb_kuzminsky> eh? speak up sonny
[11:53:28] <cradek> oh this reminds me of a terrible story
[11:53:49] <seb_kuzminsky> heh
[11:54:22] <mozmck> where is jeff?
[11:54:42] <seb_kuzminsky> mozmck: he announced in december he was taking a break from linuxcnc for a while
[11:54:56] <mozmck> oh, I missed that - that's too bad.
[11:54:59] <cradek> on rec.antique.radio (?) there was this guy who used webtv, but he said he could only read it when people typed in all caps, so they did
[11:55:12] <seb_kuzminsky> it's bad for linuxcnc but probably good for jeff :-)
[11:55:32] <seb_kuzminsky> cradek: that poor man
[11:56:05] <cradek> it was the 90s. some things were rough.
[11:56:20] <cradek> of course, other things were quite nice
[11:57:08] <seb_kuzminsky> i keep thinking the 90s were a decade ago, but they were actually two decades ago
[11:57:16] <seb_kuzminsky> https://www.youtube.com/watch?v=YcxylT1CBfU
[11:57:21] <cradek> ha
[11:57:36] <cradek> I'd make fun of you, except we're about the same age
[11:57:53] <seb_kuzminsky> you can still make fun of me
[11:58:13] <seb_kuzminsky> each winter i grow my beard out and each winter it's got more gray
[11:58:35] <mozmck> sounds familiar.
[11:58:38] <cradek> mine's quite gray now, and I like it
[11:58:40] <archivist> why only winter!
[11:58:43] <seb_kuzminsky> my daughter told me the other day my beard was getting too long and i should "shave an eating hole in the middle"
[11:58:55] <mozmck> haha!
[11:58:56] <cradek> haha
[11:59:06] <cradek> she's adorable
[11:59:21] <seb_kuzminsky> yeah i think i'll keep her :-)
[12:03:06] <seb_kuzminsky> ehm, so despite various bug-related emergencies, i think i'm nearly ready to release 2.7.0~pre3
[12:03:25] <seb_kuzminsky> anyone know of a reason to hold off? anyone working on something that needs to make it in?
[12:03:34] <cradek> what about feature/spiral-arc-handling-rebase
[12:03:41] <seb_kuzminsky> yeah, right, that
[12:03:47] <cradek> I've only read through it
[12:04:19] <cradek> I've only heard about it through skunkworks; I don't know if rob is wanting review, or if he wants one of us to merge it, or what
[12:04:33] <seb_kuzminsky> i looked at the branch before -rebase and gave some feedback, rob said he addressed some of the issues but i havent looked at it since then
[12:04:35] <cradek> he's pushed stuff directly, before
[12:04:45] <pcw_home> I need a subtle sserial bug fix added
[12:05:02] <cradek> pcw_home: can you go ahead and do it?
[12:05:15] <seb_kuzminsky> i think as long as ~pre3 is better than ~pre2 (which it already is), it's ok to release
[12:05:25] <pcw_home> micges has a patch Ill test today (its minor, basically status reporting)
[12:05:30] <seb_kuzminsky> we'll make sure there are no pending things about to get fixed before 2.7.0
[12:05:33] <skunkworks> you guys both should have gotten the email from a day or 2 ago..
[12:05:37] <cradek> ok
[12:05:41] <skunkworks> I just pushed a new branch to my github fork that addresses some of Seb's concerns:
[12:05:41] <skunkworks> Removed all of the interp warning stuff
[12:05:41] <skunkworks> Cleaned up some commit messages
[12:05:41] <skunkworks> As for the interp tests that fail, the reason that the "bad" arc used for the bad test is within the tolerances of of the new spiral fit. I'd have to see exactly what the issue is with the plug test, but I suspect it's of a similar nature.
[12:05:42] <skunkworks> -Rob
[12:05:56] <seb_kuzminsky> aha
[12:06:23] <cradek> he also fixed the slow arc thing I saw go by in the forum, it's in there
[12:06:24] <seb_kuzminsky> so he relaxed the arc radius tolerance and now a test that used to verify that too-spirally arcs were rejected, fails
[12:06:34] <seb_kuzminsky> what's the slow arc thing?
[12:06:47] <cradek> "my arcs are slow in 2.7 but fine in 2.6" is what I saw
[12:07:01] <seb_kuzminsky> it's great that he addressed that
[12:07:21] <cradek> I think this must have been a Z-is-much-slower type of machine
[12:07:34] <skunkworks> that could be.
[12:08:06] <seb_kuzminsky> in addition to rob ellenberg's arc work, there's a patch that arceye worked up that makes the tolerance an ini parameter and changes the defaults to better (?) values
[12:08:36] <seb_kuzminsky> i think after rob's stuff goes in i'll ask arceye to rebase his stuff on top (if it's still relevant
[12:09:41] <cradek> that sounds perfect
[12:10:12] <skunkworks> http://www.cnczone.com/forums/novakon-systems/254224-cnc-tormach-3.html#post1624546
[12:10:18] <seb_kuzminsky> do we know if the slow-arc guy has tested rob's new stuff? i'd guess not
[12:11:49] <seb_kuzminsky> skunkworks: aww, that's nice to hear :-)
[12:11:52] <seb_kuzminsky> bbl
[12:11:56] <cradek> hugs all around!
[12:14:06] <cradek> I wonder which discussion he saw where we raised all the right questions. that would be a really special and uncommon discussion.
[12:18:15] <mozmck> heh, same guy and thread: did not like Axis too well...
http://www.cnczone.com/forums/novakon-systems/254224-cnc-tormach.html#post1617446
[12:18:47] <skunkworks> you're not supposed to read anything else...
[12:18:53] <cradek> haha
[12:18:55] <mozmck> :)
[12:20:55] <cradek> > LinuxCNC is 10 times better than Mach3, 3 times more difficult to set up and 100 times more stable than Mach3.
[12:20:59] <cradek> is this "new math"?
[12:21:04] <mozmck> heh!
[12:21:34] <cradek> > As far as I'm concerned, EMC2 can't possibly be 100 times more stable. Frankly if MACH3 was SO UNSTABLE, it would be totally useless. There is also NO WAY that EMC2 is TEN TIMES better. Plus it is at least TEN TIMES MORE DIFFICULT to set up (not 3).
[12:21:41] <cradek> some people don't agree with the math
[12:21:49] <cradek> oh why oh why am I looking at a web forum
[12:21:54] <mozmck> I still need to figure out the main difference between gmoccapy and gscreen. We want a custom GUI, and I need to figure the best starting point.
[12:22:40] <mozmck> Looks like gmoccapy is (mostly) gscreen with graphical and layout changes?
[12:22:44] <cradek> everyone wants a custom gui :-/
[12:22:48] <cradek> what a distraction
[12:23:19] <mozmck> Well, it's not my decision...
[12:23:49] <mozmck> we do need some extra stuff for setting up and viewing information
[12:52:30] <JT-Shop> mozmck, you could start from scratch...
[12:53:08] <JT-Shop> http://gnipsel.com/linuxcnc/gui/index.html
[13:01:12] <mozmck> JT-Shop: thanks! I've seen your tutorial, and that may be what I do - I'll have to see.
[13:09:12] <Tom_itx> is mesaflash able to pull a bitfile from the card and save it to a file?
[13:09:29] <Tom_itx> didn't see that as an option...
[13:09:49] <Tom_itx> probably not that much of a request for that
[13:36:40] <seb_kuzminsky> JT-Shop: that's an impressive tutorial!
[13:37:28] <JT-Shop> seb_kuzminsky, thanks
[13:41:13] <CaptHindsight> JT-Shop: thanks for writing it!
[13:53:38] <JT-Shop> your welcome
[14:09:26] <mozmck> Why would norbert want a tool table handled by a database?
http://www.linuxcnc.org/index.php/english/forum/41-guis/26314-gmoccapy-a-new-screen-for-linuxcnc?start=1080#54606
[14:40:47] <PCW> tools in the cloud...
[14:46:09] <seb_kuzminsky> mozmck: this is something other people have talked about too, and i've never heard an explanation that made sense to me
[14:46:42] <seb_kuzminsky> the tricky bit about tool handling is what linuxcnc does with it on the inside, not how it's stored on disk
[14:51:17] <mozmck> Seems like I remember someone using Redis for something a while back - was it tool table?
[14:51:54] <seb_kuzminsky> for a while we had a copy of redis in the linuxcnc git tree, but no one ever committed any code that used it
[14:52:35] <mozmck> I see.
[14:53:15] <mozmck> mah mentions it here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RemappingStatus, but I can't follow half of what he is talking about.
[14:54:09] <seb_kuzminsky> ugh
[14:54:18] <seb_kuzminsky> he's talking about using redis for ipc i think
[14:55:09] <seb_kuzminsky> it's irrellevant, because he's not working on this project any more
[15:00:35] <mozmck> true.
[15:14:38] <PCW> OK sserial patch works, micges can commit when he has some time
[15:16:55] <seb_kuzminsky> great
[15:21:00] <PCW> I think it was just an oversight (not setting sserial run state false when its totally bollixed up)
[15:22:24] <seb_kuzminsky> i'll watch for that push to 2.7
[15:22:28] <PCW> Now the run state can be used to trigger a fault or EStop
[16:45:43] <archivist> the is a need for a database if you have a set of cutters you mount up on arbors like gear cutters, as the current limit on qty is too small for the full set of sizes
[17:16:47] <mozmck> archivist: what is the current limit on tool qty?
[17:17:56] <PCW> 10 amps
[17:20:41] <mozmck> 10 amps ? :)
[17:20:58] <mozmck> oh, is see, current limit
[17:21:35] <mozmck> "I see" that is
[17:21:36] <JT-Shop> lol
[17:35:05] <cradek> mozmck: you can set it to anything you want, but you may have to enlarge the tool channel in your nml file
[17:42:23] <mozmck> cradek: ok, I'm just trying to understand why some people are saying the tool table needs to be a database
[17:43:06] <mozmck> cradek: I don't really know anything about the tool table stuff (yet). I just saw this by norbert and was wondering about it:
http://www.linuxcnc.org/index.php/english/forum/41-guis/26314-gmoccapy-a-new-screen-for-linuxcnc?start=1080#54606
[17:46:16] <cradek> we have wear offsets (you can add tool offsets any way you want) in 2.6
[17:46:58] <cradek> it is NOT limited in tool numbers, but there is a (configurable) maximum number of entries
[17:48:35] <mozmck> ok, sounds good to me. I don't have anything with a toolchanger (yet) so haven't had to look at that.
[17:49:32] <cradek> so ... I'm surprised by some of his complaints
[17:50:01] <cradek> if he wants to work on a tool database he would ideally coordinate with and offer to help andy
[22:21:52] <cmorley> mozmck: gscreen is really an infrastructure for building a custom screen. The included screens are working samples. Gmoccapy was a gscreen 'skin' but now is a screen all on it's own. there is a minimal writeup of gscreen customizing in one of the manuals.
[22:23:42] <pcw_home> cmorley: rumor has it that the next mesaflash release will be able to make xml pinout files
[22:24:21] <cmorley> excellent. Who is gonna work on it? I have requests...:)
[22:31:48] <cmorley> mozmck:
http://www.linuxcnc.org/docs/2.7/html/gui/gscreen.html
[22:51:20] <archivist> mozmck, middle of the night for me, will try and write up something, but for a start look at some parameters for a hob
http://www.collection.archivist.info/archive/data/hob/index.html
[22:53:17] <archivist> if one has 50 hobs and another 100 plain gear cutters and whatever, there are a lot of things to remember, I have got a table in a db of the hobs we had at the last job that I used