Back
[01:26:41] <skunkworks> Thanks!
[01:26:52] <SWPadnos> sure. let's see how long it lasts this time
[01:27:36] <SWPadnos> morfic, I agree that an IDE (or more specifically an editor/build environment that makes navigating through code and testing changes easy) is very helpful
[01:28:03] <morfic> i will have a "where was I?" going on :)
[01:28:10] <SWPadnos> I would love to have something like Borland C++ 3.5 on Linux, and I think the answer is "you do have that, silly, you just have to learn how to use it" :)
[01:28:41] <SWPadnos> and configure it
[01:30:09] <Jymmm> * Jymmm smacks SWPadnos with the Borland C++ manual
[01:30:16] <SWPadnos> OUCH!
[01:30:19] <morfic> i think this is where i am at, code::blocks looks cool, anjuta promises to import from git (but then says i have no backend for this, same if trying from sources), i'll rtfm of anjuta and code::blocks and see which one makes me happy faster, with more screen realestate, they both look promising
[01:30:30] <Jymmm> SWPadnos: Dude, it comes with a BIG ASS POSTER to setup =)
[01:30:38] <SWPadnos> that used to be called the "programmers weight lifting pack"
[01:31:05] <Jymmm> SWPadnos: Nah, it's all on a stack of cd's now (was).
[01:31:28] <SWPadnos> I actually have a couple of versions of the full manual set, taking up a few shelves here :)
[01:31:33] <Jymmm> SWPadnos: I'll show you next time your this way.
[01:31:44] <SWPadnos> I have the CD documentation too
[01:31:58] <SWPadnos> I have several versions of BC++ and BC++ Builder
[01:32:12] <SWPadnos> and Pascal, and maybe even a Delphi thrown in somewhere
[01:32:42] <Jymmm> SWPadnos: Yeah so do I, I used to work for them, and no it wasn't completely free. You earned points each month and could use them to get stuff.
[01:32:49] <SWPadnos> cool
[01:33:04] <SWPadnos> too bad Kylix and friends didn't take off for Linux
[01:34:43] <SWPadnos> I really liked the ability to write custom post processors to interpret the output of external tools, and make it possible to jump to the source lines that caused the messages
[01:34:59] <SWPadnos> really made integrating stuff like the PIC and AVR assemblers easy
[01:35:35] <SWPadnos> I had function keys set up that could assemble the project, then link, convert to intel hex, and program the chip
[01:38:52] <morfic> so anjuta only importa autoconf/automake projects
[01:39:57] <SWPadnos> emc is a fairly complex set of projects and languages. I'd be surprised if an IDE could do a good job of making a project out of it
[01:42:32] <morfic> it is a little creative mix, yes
[01:49:36] <SWPadnos> morfic, it's not an IDE, but I have tried Source navigator, and though it could be useful
[01:49:42] <SWPadnos> http://sourcenav.berlios.de/
[01:51:42] <morfic> just added emc2 to code::blocks, while i couldn't build like this, it starts to look helpful
[01:51:48] <morfic> gonna checkout sourcenav
[01:52:13] <morfic> it skips all .comp, .py, .d files, but adds all .c, .h, .cc, .hh
[01:53:01] <SWPadnos> oh, we use a somewhat uncommon (but more correct) methodology for makefiles as well
[01:53:18] <SWPadnos> so even IDEs that try to follow makefiles may or may not work so well
[01:54:19] <morfic> makefiles is something (from limited googling) IDEs do not care for all too much
[01:55:19] <morfic> but i can jump between .cc and .hh for now, find declarations and jump to those, seems to help despite the "can not build it from IDE" limitation
[01:55:25] <SWPadnos> yeah, they store all that data in the "project file", instead of the nice plaintext usable-from-the-command-line makefile
[01:57:40] <morfic> i'm a mix of optimist and realist (i may be stretching the true meaning of realist there, a little, just some)
[01:58:07] <morfic> so i am not like "OMG! CAN:T IMPORT!", but trying never hurts
[01:59:32] <SWPadnos> sure
[02:00:05] <SWPadnos> incidentally, search the net a little for ctags and vim (or emacs), you can really do a lot with either combination
[02:00:49] <morfic> vim and people who do not type with 10 fingers do not mix
[02:01:01] <SWPadnos> heh
[02:01:18] <SWPadnos> I'll bet there's a ctags plug-in for kate
[02:01:36] <SWPadnos> http://kde-apps.org/content/show.php/Kate+CTags+Plugin?content=47743
[02:01:38] <SWPadnos> yep :)
[02:06:27] <morfic> http://www.zerorealm.org/cb-emc2.png a little crowded on my little laptop lcd
[02:07:45] <SWPadnos> yeah, you need another 400 pixels or so of height
[02:09:12] <morfic> going min 1680x1050 (taking my lcd home from work) or going 1920x1080 (new lcd, with benefit of a few pixels more for photo editing)
[02:09:37] <morfic> it's nice to jump to declarations/implementations this easily
[02:10:58] <morfic> while i wait for parts for pc to arrive, i should get out a pad and a pen and draw up what i think i want as data structure for the segments
[02:11:01] <SWPadnos> huh, here's one I hadn't heard of:
http://kde-apps.org/content/show.php/Monkey+Studio?content=49089
[02:11:17] <SWPadnos> which segments?
[02:11:52] <morfic> segments on a lathe shape
[02:12:02] <SWPadnos> ah
[02:12:03] <morfic> basically lines and arcs
[02:12:10] <SWPadnos> right, G70/71
[02:12:34] <morfic> no G70 from me, sorry, G71/G72, yes :) , disclaimer: some day
[02:12:48] <SWPadnos> err, right :)
[02:13:07] <SWPadnos> as a code browsing assignment, I'd suggest looking at how the interpreter handles block numbers Nxxx
[02:17:23] <morfic> SWPadnos: that will be fun part too, making P10 Q80 work (shape from N10 to N80)
[02:17:37] <SWPadnos> yep ;)
[02:17:58] <SWPadnos> I'm pretty sure EMC just tosses the N numbers right now
[02:18:02] <morfic> so good, the file says, no side effects, should be a breeze then :>
[02:18:56] <SWPadnos> heh
[02:19:03] <morfic> which would help me if it tosses them, maybe, use them as search tags
[02:19:17] <SWPadnos> sort of
[02:19:23] <morfic> to choose position in the file at N10
[02:19:42] <SWPadnos> in theory though, "N 2 1 0 0" is the same as "N2100" or "N 21 00"
[02:20:03] <morfic> then read each line until N80, after completing G71, continue after N 8 0
[02:20:13] <morfic> i should ignore whitespace the same
[02:20:27] <SWPadnos> yeah, you probably won't have access to it actually
[02:21:01] <SWPadnos> you'd likely want to do your work after the parser has already done its variable substitutions, math, and other whatnots
[02:21:02] <morfic> * morfic thinks he will find himself going further and further "backwards" changing things to make what he wants work
[02:21:26] <SWPadnos> I believe there's an array of values that gets populated with all the words that are present, possibly including N
[02:21:31] <SWPadnos> heh
[02:23:10] <morfic> that would make things easy then, to work on such an array, by the amount of would could should, you see i have not gotten to point of "up to here this happens, then that happens, so i put my stuff between this and that"
[02:23:41] <SWPadnos> sure
[02:24:02] <SWPadnos> I'm probably trying to be too helpful too early :)
[02:24:32] <SWPadnos> you may want to look at the NURBS patches as well - those deal with multiple lines of G-code to create motion (I think)
[02:24:51] <SWPadnos> I don't believe there are any other movement codes that take more than one line to describe in full
[02:24:55] <morfic> you keep it vague on a "i bet you didn't find how we do things, so watch out for ASDFG" level
[02:25:30] <SWPadnos> I don't know the specifics, but I do think there will be things that will trip you up in there
[02:25:30] <morfic> i think you are right, start of curve, points and end from what little i snapped up somewhere
[02:25:55] <morfic> i think NURBS is something i will want to look into when we have a EMC2 running lathe and go on to the mill
[02:26:09] <SWPadnos> so all I can do is suggest that you look at how those things are handled, since it will be important, and may not be conducive to the functionality you want
[02:26:22] <SWPadnos> yeah, I think that's how it goes
[02:26:25] <morfic> surfacing should be a whole lot better with NURBS compared to thousands of .0002 long G1 segments
[02:26:27] <voxadam> What are the benefits of NURBS?
[02:26:44] <SWPadnos> and nothing much happens until you get to the end, or at least 3 or 4 or 5 points into the curve definition
[02:26:55] <SWPadnos> non-circular arcs
[02:27:16] <SWPadnos> in relatively little G-code
[02:27:40] <morfic> some seem to use it for font stuff, i see it useful in faster 3D surfacing
[02:27:49] <voxadam> Probably very helpful with high end mold work.
[02:28:02] <SWPadnos> sure, model a mouse and see how big the G-code ends up
[02:28:17] <morfic> less motion blocks is less acceleration/deceleration if i am not mistaken
[02:28:49] <SWPadnos> should be, but I think the underlying implementation of the NURBS code is actually to split it up into arc segments ;)
[02:28:55] <morfic> ha
[02:29:39] <voxadam> Kind f a dammed if you do, damed if you don't situation.
[02:30:04] <morfic> well, 10 arc segments to replace 1000 line segments is still an improvement, even 100 arcs to 1000 lines would be
[02:31:03] <morfic> what i am looking at i can imagine blend with less than 100 arcs, some of the contours we turn onto valve plugs have less than 10 points and they seem to be made from a single curve
[02:31:23] <SWPadnos> even better, 10 lines of NURBS G-code to replace 300 lines of arc G-code or 1000 lines of G-code lines
[02:31:27] <morfic> unless they designed it poorly and one of the arcs has center point above the part, then it's obvious
[02:32:18] <morfic> SWPadnos: i was talking about the implementation using arcs, code length i am not worried about as much as start/stop on g1 segments
[02:32:48] <SWPadnos> yeah, it's not too important until you get to an acceleration or block processing limit
[02:34:00] <morfic> the code is sort of a daisy cutter for me, long year of no C++ coding, and all i see is C style void passing around pointers, shock and awe is still big
[02:34:12] <morfic> s/year/years/
[02:36:47] <SWPadnos> heh
[02:37:01] <SWPadnos> and there's a lot of code
[02:37:35] <SWPadnos> don't let your eyes or brain go buggy looking at the C++ parts, it's not exactly a shining example of good C++ coding practises
[02:38:32] <SWPadnos> (some of the C++ code was originally written in the mid-90s, and may have pre-dated a language standard, let alone any accepted practice)
[02:39:34] <SWPadnos> well, it's night time for me again. see you later
[02:39:48] <morfic> thanks
[02:40:18] <morfic> i won't let it scare me off, it might make me miss deadline should my boss start worrying about it, but that's about it
[02:40:27] <morfic> SWPadnos: 'night
[02:46:14] <cradek> haha, 'C shock and awe'
[02:46:27] <morfic> hey!
[02:57:28] <morfic> i hope SWPadnos was referring to the std::vector qc
[03:09:13] <mozmck> what packages should I remove on the livecd to make room for emc?
[03:10:07] <mozmck> In the one I did before I removed openoffice and gnome-games, and installed abiword and gnumeric instead which work fairly well for documents and spreadsheets.
[03:10:09] <SWPadnos> games?
[03:10:20] <cradek> definitely games
[03:10:52] <cradek> mozmck: just to make it a little harder for you, it'd be terrific if you could add
http://timeguy.com/cradek/01276453959
[03:11:34] <mozmck> oh, nice! That won't be hard at all.
[03:11:36] <SWPadnos> no 64-bit version? :)
[03:11:57] <cradek> mozmck: can you remove the non-rt kernel package?
[03:12:15] <mozmck> I was thinking about maybe adding qcad and heekscad...
[03:13:05] <mozmck> cradek: yes, that was my plan. That will also keep peoples systems from upgrading kernels to a non-rt automatically.
[03:13:25] <cradek> you need still more room though?
[03:13:46] <mozmck> When you remove the non-rt and add the rt it winds up about the same...
[03:13:55] <cradek> duh
[03:14:00] <mozmck> :)
[03:14:05] <cradek> dpkg-query -W --showformat='${Installed-Size;10}\t${Package}\n' | sort -k1,1n
[03:15:00] <mozmck> I did something like that before, and I think openoffice was near the top. That's why I went with abiword and gnumeric. But I was putting qcad and heekscnc on that one.
[03:15:40] <cradek> I for one never use openoffice - I would never miss it - but I don't know how typical that feeling is
[03:15:58] <cradek> same for all the social-networking type stuff
[03:16:11] <cradek> evolution
[03:17:03] <mozmck> yeah, the social-networking is probably a good one to kill.
[03:17:35] <mozmck> If I can without removing too much else. Seems like it removes the notification applet when you do that.
[03:18:17] <mozmck> evolution is what I use for email, but how many are emailing from their cnc controller?
[03:18:49] <cradek> I sure don't claim to know how people use the emc/linux install
[03:19:05] <cradek> this is the eternal struggle
[03:19:46] <mozmck> yep. I can see wanting to email a file from the machine, and for sure use IRC :)
[03:23:48] <SWPadnos> you might be able to lose an icon theme or two
[03:30:07] <morfic> mozmck: get rid of gnome, that saves space
[03:32:09] <morfic> it may take a moment to exactly only get rid of what you do not use of gnome when you run someting like IceWM instead, but it would make a great livecd to run on low mem systems as well well as all else
[03:41:26] <cradek> mozmck: do you have any language packs for languages emc doesn't have?
[03:41:58] <mozmck> I don't know... what do you mean?
[03:42:55] <cradek> I mean on the cd - for instance emc doesn't have a hindi translation - so if you have the hindi language pack on your cd, you can delete it with no harm done to emc users
[03:43:06] <cradek> (I have no idea if they're on there)
[03:43:30] <cradek> just trying to think of things we know we don't need
[03:43:52] <mozmck> oh, I don't know. Where do I look for that? I just have the standard .iso I'm starting with...
[03:44:45] <mozmck> actually, when you install 10.04 it download language packs if you have a net connection. I'm not sure what they are for though - maybe openoffice?
[03:45:07] <cradek> pretty sure they'd show as installed packages
[04:10:56] <KimK> mozmck: when you have time (yeah, right) it would be great if you could add a deb of the mesa firmware. The pico USC doesn't have it's own package, right?
[04:11:38] <mozmck> I don't know. I'll have to ask someone what to do about the firmware too.
[04:12:38] <KimK> OK, thanks, we appreciate all your hard work on this. Sorry I don't know enough to help. Maybe in 2 years?
[04:16:17] <KimK> And the TTT cutter does run back and forth (top to bottom), and then all around the edge before moving on.
[04:19:04] <voxadam> Is there any reason that things like operator panel buttons (jogs, MPG, etc...), coolant control, feed override, and other such controls can't be handled by a non-realtime task over something like Modbus?
[13:44:09] <cradek> voxadam: [from last night] MPG must be read in realtime, either using a spare hardware encoder counter or some fast input in the base thread, like a parport
[13:44:36] <cradek> other user interface type stuff doesn't have to be realtime (and isn't, even if it's hooked to realtime IO)
[15:07:01] <ries_> ries_ is now known as ries
[15:15:05] <ries_> ries_ is now known as ries
[18:08:47] <jepler> * jepler finds a whole series of bugs in hal_input related to unknown keys :-/
[18:09:15] <cradek> did you get your myzoomyslider to work?
[18:09:30] <jepler> yes
[18:09:41] <jepler> now it's key-418 and key-419 for the two directions
[18:11:54] <jepler> as far as I can tell it's just 3 positions, even though it feels like it slides continuously
[18:12:53] <skunkworks> myzoomyslider?
[18:13:27] <cradek> jepler: that feature is what we call marketing
[18:13:55] <cradek> "Church officials say it will cost $700,00 to resurrect the giant Jesus."
[18:13:58] <jepler> skunkworks: this keyboard has a thing marked "Zoom" which can slide up or down
[18:14:12] <jepler> skunkworks: for no particular reason I tried it with hal_input.
[18:14:17] <cradek> punchline overload today
[18:14:56] <cradek> sorry, so OT
[18:15:39] <skunkworks> oh. my keyboard has a volume control on it that would be cool for a jog wheel... ;) although the keyboard is wireless - so I don't know if that is a good idea.
[18:17:04] <skunkworks> like this
http://cgi.ebay.com/Dell-Wireless-Keyboard-and-Mouse-Works-PS3-/400127524956?cmd=ViewItem&pt=LH_DefaultDomain_0&hash=item5d2975805c
[18:19:18] <jepler> testers?
http://emergent.unpy.net/files/sandbox/0001-hal_input-Make-keys-with-unknown-names-work.patch
[18:20:03] <jepler> hopefully it doesn't break anything .. and if you got the "Unexpected event' message from hal_input (and some key, button, or axis didn't work) this might fix it
[18:24:56] <skunkworks> so - what does the slider do? if it is just a key press?
[18:25:15] <jepler> it's two keys, one for up and one for down (no key for centered)
[18:25:37] <skunkworks> ah - ok
[18:28:02] <skunkworks> cradek: it was funny :)
[19:22:38] <andypugh> How does RTAPI_MP_ARRAY_STRING know what modparam to look in? Does the Python "know" the variable name? I am having trouble getting it to work, the returned string is different every time and only contains 4 characters of the 8 I want. (Perhaps it returns single characters only?)
[19:25:55] <cradek> andypugh: if you comp --preprocess your file, you can see the generated C
[19:26:08] <cradek> ... and then you could compare it to another driver that takes a string argument, like hm2
[19:26:44] <andypugh> Ah, yes, hm2 is a good choice as that gets a long string.
[19:27:01] <cradek> yeah, super long :-P
[19:27:08] <jepler> actually hm2 doesn't use RTAPI_MP_ARRAY_STRING
[19:27:14] <jepler> streamer and sampler both do
[19:30:15] <jepler> and I dashed out a little test program:
http://pastebin.ca/1883792
[19:30:36] <jepler> test with something like halcmd: loadrt as cfg=hello,world,how,are,you
[19:30:56] <jepler> it'll print the strings (on dmesg if it's an rtai system, on terminal if it's sim) and then fail to load
[19:33:10] <andypugh> OK, close to what I was doing, with significant differences :-)
[19:54:09] <andypugh> Does it seem reasonable to only allow one custom hall-pattern for all instances of bldc_hall?
[19:54:57] <andypugh> I think that is how stepgen works?
[19:57:06] <jepler> you can have a different step type for each stepgen, but the recently-added custom table is just a single table for all stepgens that select the "custom" step type
[19:57:18] <jepler> I suspect that the number of people who require more than one step_type are few
[19:58:14] <andypugh> Yes. I suspect that there might be a lot more demand for custom hall patterns.
[19:59:00] <andypugh> At the moment you can set the pattern used with a pin, and that chooses it from the master table.
[20:00:01] <andypugh> But I have a low confidence that my master table is complete, and so allowing only one custom pattern might be limiting.
[20:01:06] <andypugh> I am thinking of making it such that each instance needs a config string (8 characters 0-6)
[20:02:00] <andypugh> But then I have to figure out how to load the right config string into each instance.
[20:06:42] <jepler> would that force the user to always specify the table in the loadrt line?
[20:07:08] <jepler> I feel compelled to note that 66666666 is a decimal number that fits in an int, and so is 0x66666666.
[20:08:00] <jepler> .. maybe you don't need strings at all
[20:10:27] <jepler> (but I'm not sure whether strings are really a problem vs there's just some piece of the puzzle that hasn't fallen into place yet)
[20:12:34] <andypugh> Yes, it would force them to specify it in loadrt.
[20:15:41] <andypugh> I might not need a string. Initially I thought I needed to make them specify a 6-bit pattern for all 16 combinations. Then I realised that not all 6-bit patterns are valid, so that could be encoded to codes 0 to 6 for the valid codes, (or XABCDEF perhaps) and then I realised that the second 8 are the reverse of the first, so they can be derived too.
[20:16:05] <andypugh> I could just make it work with my motors, and see if anyone else ever tries to use it.
[20:18:26] <jepler> do you have a link that describes the ways in which the hall sensors can vary?
[20:20:02] <andypugh> Page 6 here.
[20:20:03] <andypugh> http://www.datasheetcatalog.org/datasheet/nationalsemiconductor/DS008679.PDF
[20:20:29] <andypugh> But also the datasheet for my motors is different, and so is the manual for my drives
[20:23:03] <jepler> permutation of the HS columns can be accomplished by changing the HAL connections; inversion of an HS can be accomplished by connecting the in-not pin instead of the in pin
[20:25:39] <jepler> so it's tempting to think you only need 2 types
[20:25:42] <jepler> 30 and 60 degree
[20:25:43] <andypugh> Maybe that's the trick. Have a permutation table of inversion and swaps
[20:27:11] <andypugh> One datasheet I have suggests just trying all the permutations until one works.
[20:27:18] <jepler> I mean to do the permutation and inversion outside the component altogether by making the right hal connections
[20:27:19] <cradek> ha
[20:28:08] <andypugh> 30 and 60 look the same if you invert 1 and 2
[20:28:58] <jepler> you mean 1 and 3?
[20:29:08] <andypugh> Yes.
[20:29:10] <andypugh> Sorry
[20:29:52] <andypugh> But that table isn't complete.
[20:33:02] <jepler> what's a table that you can't get by swapping and/or inverting the HSx columns?
[20:34:10] <andypugh> I don't know now. I thought Bodine did, but that looks to be the 30 degree pattern
[20:34:17] <andypugh> (300, I mean)
[20:35:02] <jepler> compared to the table I 30 degree, the 300 degree is HS3, !HS1, !HS2
[20:35:36] <andypugh> Yes, all those tables are permutations, I think.
[20:36:56] <andypugh> I am having trouble caring, to be honest, especially as I just wrote-off my dinner by mis-measuring the water.
[20:37:14] <jepler> :-(
[20:37:31] <jepler> talk to you later, then
[20:39:13] <andypugh> I just threw the Falafel soup down the toilet, I will have to find something else.
[20:39:34] <cradek> hmm, that sounds good (pre-toilet)
[20:40:39] <jepler> not if you were hoping for falafel
[20:41:51] <cradek> now I'm sad, not because of your falafel, but because our good falafel place in lincoln is gone years ago
[20:42:15] <andypugh> They were out of stock of pre-made, so I ordered something which turned out to be a mix. Add 170ml of water, stir, form into balls, fry in oil. For some reason I thought a wine glass was 50ml.
[20:42:26] <cradek> argh.
[20:43:08] <andypugh> I wasn't going to be able to deep-fry anyway, or not without wasting an awful lot of olive oil for a one-off.
[20:43:23] <cradek> yeah frying is always a problem that way
[20:43:32] <cradek> it doesn't work unless stuff can float, but jeez that's a lot of oil
[20:44:08] <andypugh> I was going to try baking them, so perhaps I just saved myself some time.
[20:44:20] <andypugh> Anyway, back to the issue at hand.
[20:49:10] <andypugh> I reckon there are 6 possible columns, and 20 combinations of those. Is it worth 320 bytes just to have them all in the driver all the time?
[20:52:41] <andypugh> It's kind-of nice to run through all the combinations by changing a pin until the motor starts to spin, whereas editing the HAL to run through the combinations is likely to be painful.
[20:58:44] <CIA-2> EMC: 03jthornton 07v2.4_branch * racc8e11689a4 10/docs/src/gcode/main.lyx: file name requirements for called files, g2/3 offsets in g18
[21:34:26] <alex_joni> andypugh: why not have 6 pins?
[21:34:34] <alex_joni> and feed the configuration directly?
[22:11:33] <andypugh> alex_joni: Sorry, I was away. I am not sure how you mean.
[22:21:21] <andypugh> I think I got it wrong, with 6 possible columns to chose 3 of in any order it is 120 permutations.
[22:21:22] <andypugh> http://users.telenet.be/vdmoortel/dirk/Maths/permutations.html
[22:26:18] <jepler> there are additional restrictions -- for any pair of columns their contents are never the same or the exact opposite. After you pick the first column there are not 1 but 2 excluded choices; after you pick the second, there are 4 excluded choices. That gives 6*4*2 = 48 total combinations.
[22:26:55] <jepler> That's the same count you get if you view it as a permutation of 3 columns (3*2=6 choices), plus optional inversion of each column (2*2*2=8 combinations of inversions), 6*8=48
[22:27:28] <jepler> but column swapping and inverting can be done in HAL, leaving a single fixed table in the component itself
[22:27:57] <jepler> column swapping is the same as swapping two nets, and inverting is the same as connecting to the in-not pin instead of the in pin
[22:28:07] <andypugh> It can be done in HAL, but working through the 48 combinations to find the right one might be tedious.
[22:30:10] <andypugh> I suppose that the component will be useful for spindle motors and suchlike, the sinusoidal version isn't a complete replacement.
[22:30:32] <jepler> (do the 48 choices also suffice to fix transposed motor windings?)
[22:31:01] <andypugh> I think so. You get the reverse combinations.
[22:31:21] <jepler> intuitively it seems so to me as well
[22:33:31] <jepler> bbl again
[22:33:33] <andypugh> So, 48 x 16 bytes (for the reverse pattern lookup). Is that affordable?
[22:33:57] <jepler> for a fixed table? use a megabyte and it probably doesn't hurt anything
[22:34:09] <andypugh> It doesn't need to be in the shared memory, does it?
[22:34:16] <jepler> no
[22:34:28] <andypugh> I'll try to generate it in Excel then.
[22:34:51] <jepler> otherwise I can probably write it in python
[22:34:55] <jepler> but really, bbl..
[22:42:31] <voxadam> Does the spindle orient sensor need to be handled by RT I/O?
[22:46:55] <voxadam> I'm assuming that because it's essentially a home switch it needs to be treated like any other axis, I'm wrong on a regular basis though.
[22:51:45] <alex_joni> voxadam: depends how it works
[22:52:03] <alex_joni> if you want to look at it and stop the motor a certain msec's later, then it surely needs RT
[22:52:34] <alex_joni> if you just want to look at it, and you want to stop at the next indexed position after it's been tripped, then maybe it's not crucial to have it RT
[22:52:51] <alex_joni> but it's most likely you want it RT and connected to ladder
[22:53:02] <alex_joni> <- off to bed
[22:53:06] <voxadam> I would rigid tapping need RT handling.
[22:53:09] <voxadam> ?
[22:53:15] <alex_joni> oh, surely
[22:53:25] <alex_joni> I thought spindle orient for ATC
[22:53:34] <alex_joni> for tapping you need an encoder
[22:53:55] <voxadam> Thanks.
[22:54:12] <alex_joni> you need both velocity/position/direction and an index mark once per rotation
[22:54:47] <voxadam> So a non-RT orient is sufficient for ATC?
[22:55:29] <voxadam> A non-RT orient is okay for rigid tapping when combined with a RT encoder?
[23:50:47] <jepler> somebody (dgarr?) mentioned not being able to build emc2 on 10.04 with mozmck's packages. It looks like ubuntu wants to upgrade linux-headers-2.6.32-22 and I bet that gets rid of the rtai-patch-specific headers
[23:50:55] <jepler> sorry if this was covered at the time, I didn't pay it much attention
[23:53:56] <jepler> for now I'll see if this stops breaking it by upgrade:
http://pastebin.com/1iQDtD9s
[23:54:23] <jepler> (along with normal stuff like removing other kernel-related packages so I also don't get totally new kernel versions)
[23:55:03] <voxadam> Is the PDF documentation not updated along with the HTML docs?
[23:55:29] <jepler> voxadam: it should be; did you notice a problem?
[23:56:51] <voxadam> It's hard to tell... the two sources aren't exactly laid out the same.
[23:57:24] <jepler> no, unfortunately they're not
[23:57:54] <voxadam> One major problem with the PDF docs is that long lines are truncated.
[23:59:24] <voxadam> Section 17.4.3 in the Integrator Manual mentions a file...
[23:59:32] <voxadam> emc2/src/hal/drivers/m5i20/REG<truncated>
[23:59:39] <voxadam> I can't find that file in the source tree.
[23:59:44] <jepler> what URL are you looking at for the pdf manual?
