Back
[02:13:27] <SWPadnos> odd
[02:13:43] <SWPadnos> siggen is peak-to-peak for the triangle output, but not the others
[02:14:14] <SWPadnos> oh, and cosine, but not sine
[02:14:21] <jmkasunich> what?
[02:14:35] <SWPadnos> unless I'm an idiot and the halscope scales aren't the same
[02:14:37] <jmkasunich> nfw sine and cosine don't have the same amplitude
[02:14:39] <SWPadnos> * SWPadnos whistles offscreen
[02:15:29] <SWPadnos> it seems silly, but I think those should be peak-to-peak
[02:15:44] <SWPadnos> the amplitude should be the total excursion
[02:15:56] <jmkasunich> V = amplitude * sin(2*pi*freq*time)
[02:16:15] <jmkasunich> thats the way sine waves have been defined since time immemorial
[02:16:31] <SWPadnos> well, that's true enough
[02:16:58] <SWPadnos> the square wave also has a +/- excursion though, so it has a 2x excursion
[02:17:07] <SWPadnos> 2 x amplitude
[02:17:13] <jmkasunich> so does sine
[02:17:17] <SWPadnos> yes, they all do
[02:17:22] <jmkasunich> the all have 2x peak-to-peak
[02:17:25] <jmkasunich> they
[02:17:37] <jmkasunich> which seems perfectly reasonable to me ;-)
[02:17:45] <SWPadnos> yes, consistency is great :)
[02:18:15] <SWPadnos> a cool thing I noticed when trying to change he vertical scale - alt+wheel applies alpha to a window if you have desktop effects enabled
[02:18:16] <cradek> tmp1 = siggen->index * (2.0 * 3.1415927);
[02:18:18] <SWPadnos> it's very cool
[02:18:18] <cradek> uhh
[02:18:35] <SWPadnos> that's 2*pi for the angle, not the amplitude
[02:19:03] <cradek> do floats really have such little resolution that that's good enough?
[02:19:15] <SWPadnos> maybe one more digit, but yes
[02:19:25] <jmkasunich> "that" being the value of pi?
[02:19:27] <cradek> huh
[02:19:31] <SWPadnos> that's why multi-word data types come up from time to time ;)
[02:19:33] <cradek> yes
[02:19:45] <cradek> I choked more at first, assuming tmp1 was a double
[02:20:53] <cradek> index * (44 / 7)
[02:21:06] <SWPadnos> heh
[02:21:27] <SWPadnos> I'd use 3.141592653589, but that's just me
[02:21:30] <jmkasunich> cradek: keep in mind that the error doesn't accumulate
[02:21:47] <SWPadnos> considering the granularity of index, I'm sure it's not a problem
[02:21:52] <cradek> yeah, no big deal
[02:22:35] <jmkasunich> siggen is one of the oldest comps - I bet we have a #define for PI in rtapi_math.h or some such thing
[02:22:54] <SWPadnos> M_PI and M_2PI or similar
[02:23:09] <jmkasunich> there was a time when siggen (I think it was siggen) had its own sin() implementation ;-)
[02:23:22] <SWPadnos> taylor to the "rescue" :)
[02:23:24] <cradek> wow
[02:23:44] <jmkasunich> no FP or math libs in the kernel
[02:24:05] <SWPadnos> no M_2PI, but M_PI and M_PIl are defined
[02:24:36] <jmkasunich> rev 1.1:
[02:24:37] <jmkasunich> to the math library */
[02:24:37] <jmkasunich> #define PI 3.1415927
[02:24:37] <jmkasunich> double sin(double x)
[02:24:37] <jmkasunich> {
[02:24:57] <jmkasunich> oops, only got part of that
[02:25:06] <jmkasunich> /* FIXME - these are here because rtapi doesn't yet handle linking
[02:25:06] <jmkasunich> to the math library */
[02:25:24] <SWPadnos> that still uses FP registers though, which would require context save help
[02:25:51] <jmkasunich> we've had FPU support since the beginning - RTAI handles that for us
[02:26:02] <SWPadnos> it didn't until EMC came along ;)
[02:26:07] <jmkasunich> what we didn't have was library functions like sin, cos, floor(), etc
[02:26:35] <SWPadnos> ah - those are intrinsics on any CPU currently supported, but I suppose an old 486SX could have needed emulation
[02:27:29] <jmkasunich> intrinsic or not, invoking sin() in a C program doesn't work unless you have some library to implement it
[02:27:41] <jmkasunich> even if the implementation is inline assembly to issue the FPU instruction
[02:28:00] <SWPadnos> oh, sure. that's definitely true
[02:29:00] <SWPadnos> hmmm. how does an "extern inline" function work in a header file?
[02:29:10] <SWPadnos> http://cvs.linuxcnc.org/cvs/emc2/src/rtapi/rtapi_math_i386.h?rev=1.4
[02:29:15] <jmkasunich> no idea
[02:29:16] <jmkasunich> FM
[02:29:16] <SWPadnos> like atan2 and acos
[02:35:21] <SWPadnos> cradek, did you spot anything heinous in the paper?
[02:35:49] <jmkasunich> Dang, I coulda sworn I had some 1-1/2" roundbar
[02:35:51] <cradek> just starting it
[02:35:58] <SWPadnos> ah, ok. thanks
[02:36:16] <jmkasunich> got 1-1/4", 2", and a short piece of 1-3/4, but no 1-1/2
[02:37:36] <cradek> is this a final version?
[02:38:49] <SWPadnos> hopefully very very close
[02:39:13] <SWPadnos> problem(s)?
[02:39:15] <cradek> ok I'm seeing some typesetting/grammar/spelling problems. I will keep track.
[02:39:26] <SWPadnos> hmmm. I wonder
[02:39:52] <SWPadnos> typesetting I can imagine. grammar and spelling - well let's just say I wouldn'twant to pit anyone against my mother there ;)
[02:39:54] <cradek> (I ask because if you were not done editing I would not bother)
[02:40:07] <cradek> haha
[02:40:09] <SWPadnos> heh - any suggestions appreciated
[02:40:27] <cradek> too bad I can't send a patch to a pdf
[02:40:36] <SWPadnos> I can send you the odt as well
[02:40:45] <cradek> you have ``hard'' and ''soft'' (mismatched smartquotes)
[02:41:01] <cradek> you have "to insure" when you mean "to ensure"
[02:41:08] <SWPadnos> I wonder how that happened. I don't even know how to type the former
[02:41:28] <SWPadnos> oh. I guess this isn't quote the latest. that was changed to "assure"
[02:41:33] <SWPadnos> -quote
[02:41:42] <SWPadnos> err s/quote/quite/
[02:41:45] <SWPadnos> damn
[02:42:31] <SWPadnos> interesting - there was a space between the quote and soft, so it used the closing style. thanks
[02:42:52] <cradek> I don't understand the latency definition
[02:42:54] <SWPadnos> ah. another instance of insure - thanks
[02:43:34] <cradek> is it the difference between scheduled start time and actual start time?
[02:44:00] <SWPadnos> event to handler execution is what I was trying to convey
[02:44:24] <SWPadnos> in our case, this is always from the timer interrupt until RTAI code starts executing
[02:44:49] <SWPadnos> I guess jitter is the more important, since constant latency is nulled out by tuning
[02:44:51] <cradek> I don't understand what latency is well enough to suggest better words
[02:44:51] <SWPadnos> hmmm
[02:45:14] <SWPadnos> ok. then I should figure out a way to explain it to you, and put that in the paper :)
[02:45:47] <SWPadnos> I guess I had several instances of "insure", where "ensure" or "assure" would have been better
[02:47:09] <cradek> compound adjective "higher level" should be hyphenated
[02:47:52] <CIA-30> EMC: 03seb 07TRUNK * 10emc2/docs/man/man1/bfload.1: This removes support for old-style command-lines, and adds a manpage.
[02:47:53] <CIA-30> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/bfload.c: This removes support for old-style command-lines, and adds a manpage.
[02:48:24] <SWPadnos> ok
[02:48:53] <cradek> I would have written "different types of machineS, such as..." but I'm not sure it's wrong your way
[02:49:53] <cradek> section What is real-time? has a ? but section What is EMC doesn't
[02:50:09] <SWPadnos> which do you prefer?
[02:50:40] <SWPadnos> I left machine as singular, but changed it to mills or lathes, so singular makes more sense
[02:51:05] <SWPadnos> hmmm. acutally, that should be "such as a mill or lathe"
[02:51:26] <cradek> without, I think, so you don't have to artificially punctuate the fragments used as headers throughout for consistency
[02:52:08] <SWPadnos> ok. removed all section punctuation
[02:52:16] <SWPadnos> ^^title
[02:53:12] <cradek> your title says Realtime but throughout you say real-time. I think you should choose one (I don't know which)
[02:53:51] <SWPadnos> good point. I made sure they're all the same in the text, but missed the section headings/title
[02:54:02] <SWPadnos> I don't know which (if either) is more correct
[02:54:21] <cradek> I never know how much feedback people want when they ask me to read something. Is this helpful or just pedantic?
[02:54:32] <SWPadnos> both :)
[02:54:51] <SWPadnos> I'm pretty pedantic, so I appreciate the comments
[02:55:03] <SWPadnos> I've just been working on it too much to be able to see it any more
[02:55:14] <cradek> I sure understand that
[02:55:46] <SWPadnos> maybe it'll be a good addition to the docs on linuxcnc.org. I think a lot of users don't know where it all began
[02:55:56] <SWPadnos> or developers for that matter ;)
[02:55:56] <cradek> that would be cool
[02:56:41] <SWPadnos> I'll look again at what has to be done to publish it - I may need to remove refernces to ESC, and I know I have to wait until after the conference
[02:57:49] <SWPadnos> on a separate note, I found a diff tool for openoffice files. I don't know if it can be easily used on the CVS server, but if so it would allow CVS maintenance of pretty much any OO doc - spreadsheets, text, presentations, whatever
[02:58:32] <SWPadnos> it could be an alternative to the lyx docs at some point (though I don't know how to make man pages with OO)
[02:58:46] <cradek> conversions from cartesian .. to and from joint
[02:58:57] <cradek> "from ... to and from" causes me to stumble here
[02:59:11] <cradek> between?
[02:59:17] <SWPadnos> yes. hmmm
[02:59:53] <SWPadnos> between cart ... and joint.
[02:59:55] <cradek> in that same place you use G-code without saying what it is
[03:00:07] <SWPadnos> yeah, I know. my mother pointed that out as well
[03:00:12] <cradek> I don't know what knowledge you can assume
[03:00:17] <SWPadnos> me either :)
[03:00:34] <SWPadnos> I think a fair amount on the hardware/software end, and not much on the machining end
[03:01:01] <SWPadnos> I'll add ", the predominant machining language" to the parenthetical remark
[03:01:05] <cradek> between world coordinates (in which the motion of the machine is programmed by the user) and joint coordiantes (the positions ...)
[03:01:46] <SWPadnos> hmmm
[03:01:52] <cradek> yeah I agree, either briefly explain it, or avoid it altogether if it's irrelevant
[03:02:12] <SWPadnos> between cartesian space (the ?world coordinates? used by machine programmers)
[03:02:14] <SWPadnos> ...
[03:03:20] <cradek> at the top of page 5 I notice your search-and-replace doesn't preserve case
[03:03:25] <SWPadnos> heh
[03:03:43] <cradek> amazing that software still fails at stuff like that in 2008
[03:04:01] <SWPadnos> search and replace of what?
[03:04:07] <cradek> real-time
[03:04:21] <SWPadnos> ah - there it is
[03:04:31] <cradek> in this case, it starts a sentence - I assume it was capitalized before you search-and-replaced it
[03:04:41] <SWPadnos> likely true
[03:05:05] <cradek> wow, LynxOS, I had no idea
[03:05:14] <SWPadnos> heh
[03:05:36] <SWPadnos> LynxOS + a Delta Tau PMAC controller, on a split backplane VME or similar system
[03:06:10] <cradek> I don't know who "they" are in paragraph 3 (and they wanted)
[03:06:38] <SWPadnos> ah. ok
[03:06:44] <SWPadnos> that presents a problem :)
[03:07:12] <SWPadnos> I guess "the developers" works instead of they
[03:07:32] <cradek> yep, that'll fix it
[03:08:28] <cradek> high-end software (another compound adj)
[03:09:15] <SWPadnos> ko
[03:09:17] <SWPadnos> ok
[03:09:42] <cradek> in "Where we are now" I am confused about "We", you have just mentioned both consumers and small businesses
[03:10:35] <cradek> It is now possible to do all PID ...?
[03:11:32] <cradek> it's pretty pedantic but I like to avoid the overly-friendly "where we are" cliches
[03:11:50] <SWPadnos> "we can" changed to "it is now possible to do ..."
[03:11:52] <SWPadnos> heh
[03:12:03] <cradek> you could talk in terms of the state, status, etc
[03:13:03] <SWPadnos> "The current state of EMC2"
[03:13:24] <SWPadnos> that would fit with a past/present/future sequence
[03:13:34] <cradek> I like that
[03:14:00] <cradek> "high-end servo controller"
[03:14:42] <cradek> ouch (just got to the price)
[03:14:42] <SWPadnos> heh
[03:14:42] <SWPadnos> you can see why Matt had a problem with it ;)
[03:14:42] <jmkasunich> on that "all the PID" sentence, I was just thinking that it flows better without "all"
[03:16:19] <jmkasunich> "It is now possible to do the PID calculations for .... in an average PC."
[03:17:34] <SWPadnos> ok
[03:17:34] <jmkasunich> is this audience expected to know what PID means?
[03:18:03] <SWPadnos> I think so,
[03:18:23] <SWPadnos> I spelled out the words somewhere (I'll make sure it's the first use).
[03:18:24] <jmkasunich> I can't think of any other conflicting definitions of that acronym either
[03:18:48] <SWPadnos> http://acronyms.thefreedictionary.com/PID
[03:19:07] <jmkasunich> you did spell it out prior to the use in the sentence I was looking at, so no worries
[03:19:09] <SWPadnos> process ID :)
[03:19:18] <jmkasunich> duh
[03:19:24] <SWPadnos> ok. if anyone doesn't know at the presentation, I'll explain it
[03:19:26] <jmkasunich> although that one is rarely capitalized
[03:19:31] <SWPadnos> there are whole classes on it at ESC
[03:19:57] <cradek> another pet peeve is the apologetic use of "issues" when "problems" (or "bugs") is more precise
[03:20:09] <SWPadnos> heh
[03:21:20] <SWPadnos> hmmm
[03:21:22] <cradek> I recently ran a current emc2 on rtlinux. this was 1-2? months ago
[03:21:28] <SWPadnos> really?
[03:21:30] <SWPadnos> cool
[03:21:30] <jmkasunich> are there going to be visual aids for your presentation? slides, etc?
[03:21:35] <cradek> really :-)
[03:21:41] <SWPadnos> yes. this is the paper, the presentation is a differnet animal
[03:21:49] <SWPadnos> which I have yet to corral :)
[03:22:19] <SWPadnos> there's a later section called "Where EMC2 stands today"
[03:22:28] <jmkasunich> for the 95% of the audience who has no idea what CNC is all about, a nice video clip of a machine doing its thing would be educational
[03:22:31] <SWPadnos> but I think the stuff in that section "where are we now" should stay where it is
[03:22:39] <cradek> did you mean to capitalize What Was Wrong With? none of the other headers are this way (and I think it's bigger too)
[03:22:44] <SWPadnos> we'll have Jymmmm's machine in there doing some machining :)
[03:22:51] <jmkasunich> ah, ok
[03:23:35] <SWPadnos> the major section heads are All Capitalized And Larger Font, the others only have an Initial capitalized word
[03:23:42] <cradek> ok
[03:23:58] <jmkasunich> re: that "what was wrong" thing - the TOC shows the document structure, but it doesn't include the subsections under that heading
[03:23:59] <SWPadnos> or at least that's what I intended. I'll check that
[03:24:17] <SWPadnos> I may have them set to Heading 3, which I excluded from the TOC
[03:24:20] <jmkasunich> I assume you want the heading styles to match the structure in the TOC
[03:24:34] <SWPadnos> they do, it's automatic (if I use the correct styles)
[03:24:48] <cradek> I think NML is Neutral Messaging Language...?
[03:24:53] <jmkasunich> yes
[03:24:56] <jmkasunich> what is he calling it?
[03:24:58] <SWPadnos> not according to the NIST page
[03:25:00] <cradek> Machining
[03:25:06] <SWPadnos> Neitral Machining Language
[03:25:09] <SWPadnos> s/i/u/
[03:25:14] <cradek> interesting
[03:25:36] <jmkasunich> http://www.isd.mel.nist.gov/projects/rcslib/
[03:25:54] <jmkasunich> The NML Programmer's Guide (C++ Version)
[03:25:54] <jmkasunich> Describes the use of the Neutral Message Language(NML) components of the library
[03:26:21] <SWPadnos> hmmm. lemme check where I got machining from - it may have been a thinko from Will
[03:27:07] <jmkasunich> http://ostatic.com/102724-software-opensource/rcslib
[03:27:31] <cradek> This is a far easier method of installation; <- semicolon, not comma
[03:27:53] <jmkasunich> cradek was an english teacher in an earlier life ;-)
[03:29:34] <jmkasunich> just thought of something you might want to tack onto the end of the paragraphs about steppers (end of page 6, start of 7)
[03:30:33] <jmkasunich> halfway down page 6 you mention that EMC went from $10K hw to $1400, after going into the stepper details you should probably say that steppers and parport resulted in another order of magnitude cost reduction
[03:30:50] <cradek> good idea
[03:32:40] <SWPadnos> oh, very good point
[03:33:16] <SWPadnos> more actually, since the drives and motors are less expensive, but the interface hardware is also unnecessary
[03:33:33] <jmkasunich> the $1400 number doesn't even include drives
[03:33:39] <SWPadnos> nope
[03:33:44] <jmkasunich> so you can almost say cost goes from 1400 to near zero
[03:33:53] <SWPadnos> nor any motors. I think that was the cost of a STG card
[03:34:02] <cradek> STG were $888 iirc
[03:34:05] <SWPadnos> plus a used junk PC
[03:34:34] <jmkasunich> I'll let you decide how to say it, the point is to say the words "parport", "no special hardware" and "really cheap"
[03:35:33] <cradek> I wonder how classicladder is capitalized on his pages
[03:35:44] <SWPadnos> heh
[03:35:50] <jmkasunich> ClassicLadder
[03:36:05] <jmkasunich> actually, Classic Ladder
[03:36:14] <jmkasunich> http://membres.lycos.fr/mavati/classicladder/
[03:36:22] <seb_kuzminsky> jmkasunich: are you ok with the bfload commit i just did, removing old-style command-line support in TRUNK?
[03:36:29] <jmkasunich> yes
[03:36:31] <seb_kuzminsky> cool
[03:36:46] <jmkasunich> I'm more ambivalent about changing 2.2
[03:36:49] <seb_kuzminsky> i realize its your code and i dont want to step on anyones feet
[03:36:54] <seb_kuzminsky> yeah 2.2 is still an open issue
[03:36:55] <SWPadnos> I'm pretty sure nothing was using it, though I could have gotten the grep options wrong :)
[03:37:17] <jmkasunich> "nothing" = non of our sample configs
[03:37:22] <SWPadnos> right
[03:37:23] <jmkasunich> we don't know what users were doing
[03:37:24] <seb_kuzminsky> SWPadnos: i looked too and i agree, but that's just what's in cvs, not what users in the wild & wooly are doing
[03:37:24] <cradek> we never remove stuff from a release branch. only bug fixes
[03:37:29] <jmkasunich> we don't want to break a user's config
[03:37:56] <seb_kuzminsky> maybe 2.3 will come out and solve this problem
[03:37:59] <cradek> new drivers are the only exception we tend to make, because it's easy to see that they are isolated
[03:37:59] <jmkasunich> IMO, the issue is not "should we remove support for the old way in 2.2", that is a no brainer - the answer is NO
[03:38:01] <SWPadnos> I don't know what driver would have needed it. the released m5i20 driver had the bitfile hardcoded in, and didn't care about bfload
[03:38:09] <seb_kuzminsky> or maybe i'll merge it into 2.2 with a different name, leaving bfload in 2.2 alone
[03:38:19] <jmkasunich> the question is, why do we want to add the new way to 2.2?
[03:38:24] <SWPadnos> unless someone finished up the 5i2x driver and neglected to mention it, I don't think it's an issue :)
[03:38:48] <SWPadnos> I don't think it's necessary in 2.2, unless the 7i43 and generic 5i2x driver get added as well
[03:38:49] <seb_kuzminsky> jmkasunich: i'm hoping to add a hostmot2 driver to 2.2, and it'll need a bunch of new board supported by bfload
[03:39:09] <jmkasunich> ok, that puts a new complexion on thing
[03:39:10] <jmkasunich> s
[03:39:20] <seb_kuzminsky> i'm near to committing preliminary support for hostmot2 on 7i43 and 5i20
[03:39:32] <seb_kuzminsky> the rest of the Anything I/O boards will follow
[03:39:44] <cradek> you guys should talk about this when jepler is around - he's the 2.2 release manager
[03:39:47] <jmkasunich> there is a precedent for adding a new driver to a "stable" branch, the logic being that it can't possibly hurt people who weren't using it before
[03:40:08] <seb_kuzminsky> right, and removing features from a stable branch is a no-no, i agree completely
[03:40:17] <SWPadnos> I'm pretty sure jepler said it was OK with him to add drivers, but it is definitely a question for him to answer
[03:40:22] <seb_kuzminsky> i'm just not sure if bfload is a feature anyone can use
[03:40:33] <seb_kuzminsky> is m5i2x usable?
[03:40:36] <jmkasunich> no
[03:40:42] <seb_kuzminsky> if not, bfload has no users i think
[03:40:48] <SWPadnos> unless someone finished it and didn't tell us
[03:40:58] <jmkasunich> I started it, then it kind of fell apart over the summer
[03:41:07] <seb_kuzminsky> that happens
[03:41:18] <seb_kuzminsky> i agree with cradek, we should ask jepler
[03:41:32] <jmkasunich> there was a time when the version of hostmot that is (was?) embedded in the driver had some issue (with the last 4 encoders IIRC)
[03:41:36] <seb_kuzminsky> though your input (jmk & swp) is probably the most important
[03:41:42] <jmkasunich> at that time, PeterW released new bitfiles
[03:42:10] <jmkasunich> it _is_ possible to invoke the old driver without having it load the embedded bitfile, the assumption being that you manually loaded the fixed one first
[03:42:20] <seb_kuzminsky> (it's strange for me to do so much deciding on irc, where real-time synchronization is needed, vs mailing lists)
[03:42:25] <jmkasunich> I still don't think bfload was used for that - there was another loader utility
[03:42:33] <seb_kuzminsky> jmkasunich: right, m5i20cfg
[03:42:41] <jmkasunich> seb_kuzminsky: actually, the list is probably the better place
[03:42:41] <cradek> it's so very fast, if everyone is here
[03:42:46] <jmkasunich> we just find that IRC is faster
[03:42:47] <seb_kuzminsky> maybe i should ask the emc-users list?
[03:43:12] <jmkasunich> don't ask the users list
[03:43:32] <jmkasunich> you can never be sure the person using bfload is reading the list
[03:43:36] <seb_kuzminsky> sure
[03:44:07] <seb_kuzminsky> maybe for bfload to a different name in 2.2?
[03:44:18] <jmkasunich> IMO, since anybody using the existing hostmot bitfile (or corrected versions of it) is either letting the driver load it or using m5i20cfg, we can do whatever we want with bfload
[03:44:31] <jmkasunich> I don't like the differnet name thing at all
[03:44:40] <seb_kuzminsky> s/for/fork/
[03:44:54] <seb_kuzminsky> too confusing to have so many similar programs around?
[03:44:55] <jmkasunich> that means if anybody does use it (including for your new driver), they will have to change later when they go to 2.3
[03:44:59] <SWPadnos> no. and that doesn't even count the issues with CVS and renaming files
[03:45:04] <SWPadnos> s/issues/problems/ :)
[03:45:07] <seb_kuzminsky> heh
[03:45:22] <jmkasunich> approach 1) put a version of bfload in 2.2 that accepts old and new command lines
[03:45:39] <jmkasunich> approach 2) replace the version of bfload in 2.2 with one that only accepts new command lines
[03:46:02] <jmkasunich> in either case, the trunk/2.3 version would only use new command lines
[03:46:17] <SWPadnos> we currently have approach 1 in 2.2 CVS
[03:46:21] <jmkasunich> approach 1 has the downside of some messy code in that version of bfload
[03:46:27] <SWPadnos> so let's just leave it
[03:46:46] <seb_kuzminsky> 3) make a new program called anyio-program (forked from bfload), add it to 2.2 and 2.3, optionally remove bfload from 2.3
[03:46:49] <jmkasunich> we do? I thought 2.2 still had the original bfload only
[03:46:57] <SWPadnos> (and remove from TRUNK, as is already done)
[03:47:00] <SWPadnos> oh, maybe
[03:47:00] <seb_kuzminsky> i havent touched bfload in 2.2
[03:47:02] <SWPadnos> ok
[03:47:06] <SWPadnos> nevermind me :)
[03:47:17] <jmkasunich> I don't like 3
[03:47:24] <jmkasunich> what is the benefit?
[03:47:40] <seb_kuzminsky> backward compatibility with a clear upgrade path
[03:48:16] <SWPadnos> I think that's better handled by having the hybrid code in 2.2 bfload
[03:48:25] <jmkasunich> approach 1: the (hypothectical) person using bfload today sees no change in 2.2, new users can use the new syntax, the old style users have to change a line or two when 2.3 comes out
[03:48:32] <seb_kuzminsky> the hybrid code is kind of gross imo
[03:48:57] <jmkasunich> approach 2: the hypothetical guy needs to change his config now, everybody goes forward with the new command lines, no changes in 2.3
[03:49:08] <cradek> SWPadnos: that's all my comments, I got through it
[03:49:16] <SWPadnos> ok. thanks a bunch.
[03:49:21] <cradek> welcome
[03:49:28] <SWPadnos> now I just have to scroll back and see what I've not done :)
[03:49:31] <jmkasunich> approach 3: the hypothetical guy gets to use old style bfload thru 2.2, but then has to change to a completely different (named) program
[03:49:51] <jmkasunich> and we wind up with three bitfile loaders (at least for a while)
[03:50:00] <jmkasunich> two is a bit much, three is nutz
[03:50:04] <SWPadnos> I changed that section heading (where we are now) to "Changes in the computing landscape" - it was more about the hardware than EMC
[03:50:36] <seb_kuzminsky> i agree there are too many
[03:50:42] <seb_kuzminsky> one program to bind them all
[03:50:45] <jmkasunich> heh
[03:50:54] <SWPadnos> bind(9)
[03:51:18] <jmkasunich> I like bfload with both command styles for 2.2, and new only for 2.3, AND the manual in 2.2 should immediately tell folks that old style is deprecated
[03:51:19] <seb_kuzminsky> approach 4) dont put hostmot2 support into 2.2, wait for 2.3, change bfload then
[03:51:43] <jmkasunich> in particular, the docs for the newly supported boards should use the new syntax, so the people who start using it because of those boards do it right from the beginning
[03:51:47] <seb_kuzminsky> advanced warning of the upcoming change, good idea... could put a warning msg on stdout too
[03:52:05] <SWPadnos> delaying until 2.3 is also reasonable
[03:52:33] <jmkasunich> that depends on when 2.3 comes out, and how many people are eagerly awaiting the 7i43
[03:52:56] <seb_kuzminsky> i've been approached by two people who want hostmot2 asap
[03:52:56] <SWPadnos> the old 5i20 driver should be retired at some point, since hostmot2 has a superset of its capabilities
[03:53:22] <SWPadnos> I'm not sure that can happen in 2.3, but 2.4 is a good candidate
[03:53:30] <jmkasunich> does hostmot rename a bunch of hal pins?
[03:53:39] <jmkasunich> hostmot2 I mean
[03:53:45] <seb_kuzminsky> SWPadnos: right, add hostmot2 and deprecate hostmot in 2.3, remove hostmot in 2.4
[03:54:02] <seb_kuzminsky> i'm embarassed to say i dont know what hostmot(1) names the pins
[03:54:10] <jmkasunich> that makes two of us
[03:54:16] <SWPadnos> m5i20*, I think
[03:54:25] <seb_kuzminsky> i tried to follow the Canonical Device Interface where appropriate, and the software components where CDI was inconclusive
[03:54:28] <seb_kuzminsky> or absent
[03:54:34] <jmkasunich> when we make a major rev, we post a wiki page listing every ini/hal file change that is needed to upgrade
[03:54:53] <jmkasunich> it won't be nice if that page is hundreds of items ;-(
[03:55:00] <SWPadnos> yep, m5i20.<boardid>.whatever
[03:55:17] <SWPadnos> a sed script can do driver changes like this though
[03:55:22] <seb_kuzminsky> i'm using hm2_<BoardType>.<BoardId>.whatever
[03:55:31] <SWPadnos> s/m5i20/anythingIO/g
[03:55:43] <jmkasunich> if it's sed-able, then thats not bad
[03:55:49] <jmkasunich> we can even put the sed script on the wiki page
[03:55:50] <seb_kuzminsky> but the whatevers i'm not sure about...
[03:55:59] <SWPadnos> http://cvs.linuxcnc.org/cvs/emc2/src/hal/drivers/hal_m5i20.c?rev=1.17
[03:56:05] <SWPadnos> there are a lot of whatevers there :)
[03:56:08] <jmkasunich> the whatevers are the ones that worry me
[03:56:15] <seb_kuzminsky> yeah, hostmot* is pretty big...
[03:56:39] <jmkasunich> we all agree that phasing out hostmot_1 is NOT a 2.3 thing
[03:56:45] <seb_kuzminsky> jmkasunich: yes
[03:56:51] <SWPadnos> I don't know that I would include the board type in the name, but I'm not sure
[03:56:52] <seb_kuzminsky> no rush getting rid of stuff that works
[03:57:21] <seb_kuzminsky> SWPadnos: it's useful if you have both a 7i43 and a 5i20, for example
[03:57:27] <SWPadnos> hmmm. maybe m<boardtype>.instance.whatever
[03:57:44] <SWPadnos> that would be m5i20 for a 5i20, which would keep current names the same
[03:57:55] <SWPadnos> they would have different instance numbers
[03:57:59] <jmkasunich> well, hostmot2 isn't the only firmware that can ever go in a m5i20
[03:58:07] <seb_kuzminsky> SWPadnos: i chose hm2_ instead of m in case some non-mesa board can run hostmot2 in the future
[03:58:10] <SWPadnos> even without the board type
[03:58:18] <jmkasunich> hm2_5i20 and hm3_5i20 allow for future development
[03:58:21] <SWPadnos> you can't do that
[03:58:32] <SWPadnos> or at least it's not appropriate/polite to do that
[03:58:37] <seb_kuzminsky> do what?
[03:58:45] <SWPadnos> use hostmot2 on non-mesa hardware
[03:58:47] <jmkasunich> yeah, you replying to seb or me
[03:58:54] <SWPadnos> sorry
[03:58:55] <seb_kuzminsky> sure, why not? it's gpl/bsd
[03:59:00] <seb_kuzminsky> pcw wants it out there
[03:59:19] <jmkasunich> I think its "not polite" rather than "can't"
[03:59:21] <SWPadnos> well, it's GPL because we asked for that, but it was originally intended for use on mesa hardware
[03:59:33] <SWPadnos> yes, impolite to promote its use on non-mesa hardware
[03:59:44] <seb_kuzminsky> pcw originally wanted to use 3-clause bsd for hostmot2
[04:00:00] <seb_kuzminsky> that's way less restrictive than gpl
[04:00:03] <SWPadnos> ok. if that was his original intent, then it would be polite :)
[04:00:26] <seb_kuzminsky> i think it's unlikely anyone will port it to new hardware, but i dont think it would be improper if they did
[04:00:32] <seb_kuzminsky> but jmk's point is good
[04:00:40] <SWPadnos> ok. no problem then
[04:00:46] <seb_kuzminsky> it's not a 5i20 (or whatever) driver, it's a hostmot2-on-5i20 driver
[04:00:50] <SWPadnos> sure
[04:01:20] <SWPadnos> actually, it's a hostmot.<id> - the hardware doesn't matter
[04:01:32] <seb_kuzminsky> SWPadnos: the hardware does sort of matter
[04:01:36] <SWPadnos> there needs to be a way of telling the driver which order to use
[04:01:42] <jmkasunich> the only problem with embedding all that into the names is that you can't take a hostmot2-on-5i20 hal file and use it with hostmot2-on-7i34 without editing it
[04:01:49] <seb_kuzminsky> you have have multiple boards, you want to know which one you're talking to hal about
[04:01:52] <SWPadnos> not to HAL. it certainly matters to bfload and the driver
[04:02:02] <jmkasunich> SWPadnos: it matters to HAL two
[04:02:04] <jmkasunich> too
[04:02:14] <SWPadnos> hold on a sec
[04:02:27] <jmkasunich> if my encoder is hooked to board #1, I need to be able to know that the pins I'm hooking to are on board 1
[04:02:28] <seb_kuzminsky> it'd be cool if halcmd could do cpp-like string-replacement macros
[04:02:47] <jmkasunich> it can, sort of
[04:02:57] <SWPadnos> I'm saying that there needs to be a way of insuring that the sequence you want is maintained, but that as far as signals go, it's a hostmot regardless of what hardware or which order it's in
[04:02:57] <jmkasunich> if the strings are in env vars, or in the ini file ;-)
[04:03:18] <SWPadnos> yes, you can do one-level indirection
[04:03:41] <SWPadnos> and it does work to have an ini var like [JOINT_0]DRIVER=m5i20.0
[04:03:58] <seb_kuzminsky> cool
[04:04:06] <seb_kuzminsky> i haven't gotten to ini files yet :-)
[04:04:27] <SWPadnos> and then connect a pin with net joint0pos axis.0.motor-pos-cmd [JOINT_0](DRIVER).pwm.0.value
[04:04:52] <SWPadnos> I don't remember exactly where you have to put the parens - I think it's how I did it
[04:05:04] <seb_kuzminsky> cool, that seems to alleviate the renaming problem somewhat
[04:05:17] <SWPadnos> yes, except that no ini file actually does that ;)
[04:05:18] <jmkasunich> you can also do $(5i20_DRIVER).0.encoder.0.scale 1000 to use env vars
[04:05:36] <seb_kuzminsky> jmkasunich: sweet! i didnt know that!
[04:05:47] <jmkasunich> man halcmd, SUBSTITUTION section
[04:06:01] <SWPadnos> hmmm. I thought there was another replacement type, but I can't remember what it is
[04:06:17] <jmkasunich> its not a well publicized or heavily used feature
[04:06:26] <seb_kuzminsky> then it's just the different pin namings between the hostmot-on-5i20 and the hostmot2-on-5i20 that's problematic?
[04:06:29] <SWPadnos> I guess I should have written manpages or something ;)
[04:06:45] <seb_kuzminsky> bah manpages. I wrote my first one tonight and i hated it
[04:06:48] <SWPadnos> you should use the same "whatevers" as other drivers do
[04:06:53] <seb_kuzminsky> fscking groff
[04:06:57] <SWPadnos> pwm.0.value for the input
[04:07:04] <SWPadnos> encoder.nn.count
[04:07:06] <SWPadnos> etc.
[04:07:15] <seb_kuzminsky> the other drivers dont seem to be standardized... there's the CDI, and i've followed that where appropriate
[04:07:15] <jmkasunich> the "whatevers"
[04:07:27] <SWPadnos> check the the canonical naming conventions first, and hte m5i20 driver second
[04:07:29] <jmkasunich> yeah, the drivers are less standardized that we'd like
[04:07:49] <jmkasunich> if hostmot 1 differs from canonical, I'd favor the canonical
[04:07:53] <seb_kuzminsky> me too
[04:08:20] <SWPadnos> yes - hence canon first and hostmot second if not found :)
[04:08:29] <jmkasunich> the more they differ, the more reason to keep hostmot1 thru 2.4 and even later - if somebody's machine is making parts, they shouldn't have to screw with it
[04:08:52] <seb_kuzminsky> i agree - though if they're making parts, they maybe shouldnt upgrade...
[04:08:59] <seb_kuzminsky> easier said than done sometimes, i know
[04:09:19] <jmkasunich> well,. they may want to get other improvements - like g-code language improvements, traj planner fixes, etc
[04:09:48] <jmkasunich> I think of hostmot2 as _another_ supported board, not a replarement for a supported board
[04:09:59] <jmkasunich> replacement
[04:10:26] <jmkasunich> it just happens to be $0 if you already have hostmot1
[04:11:19] <seb_kuzminsky> did we decide on the fate of bfload? put a hybrid (old/new) version into 2.2, remove old support in 2.3?
[04:11:33] <jmkasunich> that would be my preference
[04:11:34] <SWPadnos> cradek, how old was the RTLinux+EMC2 install you recently used?
[04:11:48] <jmkasunich> the hybrid should print a warning when used with old syntax
[04:11:56] <SWPadnos> I agree with that plan
[04:12:35] <jmkasunich> that ensures that no possible current user will see his config stop working until he upgrades to 2.3
[04:12:56] <jmkasunich> the hybrid bfload is a bit crufty isn't it?
[04:13:24] <seb_kuzminsky> yeah...
[04:13:32] <seb_kuzminsky> 't ain't purdy
[04:13:51] <seb_kuzminsky> but that's okey
[04:13:53] <jmkasunich> but as long as it works... we won't have to do much with it down the road
[04:14:14] <seb_kuzminsky> i'll go do that... brb
[04:14:15] <jmkasunich> I bet its nicer to read than the original m5i20cfg
[04:14:32] <SWPadnos> heh
[04:29:23] <seb_kuzminsky> oh wait, I should ask jepler before committing this to 2.2... i'll send him an email if he doesnt show up soon
[04:46:08] <seb_kuzminsky> jepler: are you here?
[04:46:43] <SWPadnos> he's unlikely to be around until tomorrow. he tends to go to bed early
[04:46:59] <SWPadnos> (and it's not even all that early for him)
[04:47:31] <seb_kuzminsky> ok
[04:58:57] <seb_kuzminsky> http://highlab.com/~seb/bzr/emc2/local-2.2
[04:59:12] <seb_kuzminsky> bzr branch off upstream 2.2 with bfload updates
[05:08:56] <seb_kuzminsky> goodnight all
[13:13:09] <skunkworks_> logger_dev: bookmark
[13:13:09] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-04-10.txt
[14:33:23] <CIA-30> EMC: 03seb 07TRUNK * 10emc2/src/hal/utils/ (epp.c epp.h): Added copyright notice and GPL license.
[15:33:39] <alex_joni> SWPadnos: I think it was a fairly recent TRUNK cradek used
[15:33:48] <SWPadnos> ok
[15:33:52] <alex_joni> you sure talk a lot
[15:33:57] <SWPadnos> :P
[15:34:01] <alex_joni> (not you personally)
[15:34:02] <alex_joni> :P
[15:34:11] <alex_joni> but I spent about 20 minutes reading back
[15:34:29] <alex_joni> I stopped doing that on #emc, but in here I like to do it
[15:34:42] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/offs-split-apart.png http://emergent.unpy.net/index.cgi-files/sandbox/offs-split-apart.ngc
[15:35:36] <alex_joni> looks great
[15:37:36] <jepler> of course it's wrong for the very next case I test..
[15:38:01] <alex_joni> at least it's right for one ;)
[15:38:28] <cradek> alex_joni: used for what?
[15:38:45] <cradek> jepler: I think that's really exciting
[15:39:33] <alex_joni> cradek: SWPadnos asked what version of emc2 you used on RtLinux lately
[15:39:45] <alex_joni> and I assumed you missed his question
[15:40:59] <cradek> oh
[15:41:07] <cradek> it was a recent trunk
[15:41:22] <cradek> the rtlinux was 3.2-pre2 or whatever I installed back in the bad old days
[15:42:05] <cradek> I got it running with xemc. python and lots of other things were too old and I didn't feel like fixing all that.
[15:42:34] <alex_joni> but I bet tkemc should work
[15:43:29] <cradek> seems like it didn't. but I was only interested in the rtlinux question.
[15:44:14] <cradek> actually I think I was wondering if it still worked on 2.4 kernels, after one of ****'s FUD storms
[15:44:18] <cradek> (hi ****!)
[15:44:30] <alex_joni> haha
[15:44:42] <alex_joni> bet that won't trigger his daily grep
[15:45:36] <skunkworks_> any advantage to rtlinux?
[15:45:47] <cradek> nope
[15:46:01] <skunkworks_> :) good enough for me
[15:47:15] <alex_joni> skunkworks_: it's old, outdated, and not really free nowadays
[15:47:27] <alex_joni> I don't think they have 2.6 patches at all
[15:47:36] <alex_joni> bbl
[15:47:38] <cradek> I think it used to be easier to build/install than rtai
[15:47:47] <cradek> that's why I used it at the time
[15:47:55] <cradek> now there is no reason to use it
[15:48:07] <alex_joni> it might have gotten better docs
[15:48:14] <alex_joni> RTAI was/is pretty bad
[15:59:12] <cradek> jepler: a pocket that exercises various things:
http://timeguy.com/cradek-files/emc/t3.ngc
[16:00:08] <cradek> oops, I have a better one
[16:05:41] <cradek> this is the one I meant:
http://timeguy.com/cradek-files/emc/t4.ngc
[16:11:33] <SWPadnos> cradek, so that was an old RTLinux install - not a more recent version of RTL
[16:12:36] <SWPadnos> hmmm. you still need to register at RTLinuxFree.com. what a PITA
[16:12:49] <cradek> yes it was a very old install. I don't know what versions have come out since then.
[16:13:03] <SWPadnos> I'm trying to find out, but not having much luck
[16:14:50] <jepler> wow they have carefully made sure that no software can be released under the Open RTLinux Patent License
[16:14:53] <jepler> morans
[16:15:01] <jepler> "The license requires that all applications using the free RTLinux download be GPL licensed, and also requires that application source code be made publicly available on the Web."
[16:15:33] <cradek> applications that use "use the download"?
[16:15:45] <cradek> use use use?
[16:16:09] <SWPadnos> it looks like the latest download is 3.2-wr
[16:16:12] <SWPadnos> whatever that means
[16:16:29] <cradek> pretty sure mine says 3.2-pre2
[16:17:52] <SWPadnos> I guess I'd assume that "wr" is later than "pre2", but it's unclear how much later
[16:18:14] <SWPadnos> oh, here's a good puzzle for the grammar nazi: punctuate the following words
[16:18:15] <jepler> what I'm saying is that GPL software is incompatible with a license that "requires that application source code be made publicly available on the Web".
[16:18:24] <SWPadnos> he had had had had had had had had been correct
[16:18:38] <cradek> jepler: I agree
[16:18:41] <SWPadnos> (capitalization may also be performed)
[16:18:56] <SWPadnos> that's true
[16:19:34] <SWPadnos> RTLinux (even the free version) is for 2.4 and 2.6
[16:19:38] <jepler> SWPadnos: regardless of whether there is a sentence diagram that seems to correspond to those words, that is not actually an english sentence.
[16:19:40] <SWPadnos> actually, the non-free is 2.6 only
[16:19:50] <SWPadnos> no, I didn't say it was a sentence
[16:20:04] <SWPadnos> but it can be puncutated to form one or more grammatically correct sentences
[16:21:10] <jepler> he had "had had had had had had had been correct" (written on a piece of paper)
[16:21:20] <SWPadnos> heh
[16:21:36] <SWPadnos> well, time to talk to my mother again. I'll bring the answer later :)
[16:21:37] <cradek> he had "had had had had had had had been", correct?
[16:21:46] <SWPadnos> heh
[16:22:01] <SWPadnos> you've got the right idea, but that's not the solution I'm looking for :)
[16:25:54] <jepler> I've got some other ideas, but they involve someone whose legal name is "Had Had Had" ..
[18:16:09] <cradek> if ((settings->cutter_comp_side != OFF) && /* ! "== ON" */
[18:16:09] <cradek> (settings->cutter_comp_radius > 0.0)) { /* radius always is >= 0 */
[18:16:20] <cradek> these comments are funny
[18:24:22] <fenn> jepler: maybe the rtlinux patent license is simply stupidity, not malice
[18:25:38] <fenn> it's widely recognized that it's difficult to write an open source license (even FSF has problems)
[18:58:52] <SWPadnos> answer: He had had "Had had had". "Had had" had been correct.
[18:59:21] <SWPadnos> the history of rtlinux shows that there may be some malice involved
[18:59:29] <SWPadnos> or not malice but greed
[18:59:59] <alex_joni> SWPadnos: might I bother you to send me a copy of that paper too?
[19:00:09] <SWPadnos> no bother. hold on a sec
[19:00:32] <SWPadnos> @robcon.ro?
[19:00:38] <alex_joni> yup
[19:03:45] <cradek> jepler: I think I figured out the format offs requires:
http://timeguy.com/cradek-files/emc/t4.ngc
[19:05:48] <cradek> huh, interesting that I can't load that ("nested comment found")
[19:05:57] <cradek> I thought ; comments didn't do that
[20:22:32] <CIA-30> EMC: 03alex_joni 07joints_axes * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: a minor hack (disabling axis extents) so that the scara config runs again. will look at fixing it properly later - along with the rest of the places where joints/axes are still mixed
[20:23:46] <alex_joni> jmkasunich: that last commit allows you to run the scara config
[20:23:55] <alex_joni> but a couple of things are still broken/not right
[20:24:02] <alex_joni> speeds seem completely off, etc
[20:50:50] <jepler> cradek: any chance you can regenerate that with an additional decimal point?
[20:50:55] <jepler> cradek: and pre-mirrored would be dandy too
[20:55:39] <cradek> http://timeguy.com/cradek-files/emc/t4.ngc
[20:57:50] <jepler> hm that didn't change anything
[22:59:07] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/more-pocketing.png
[22:59:19] <jepler> cradek: thanks for making that test code
[23:01:02] <cradek> that looks great!
[23:02:13] <jepler> it's carefully zoomed to not show the remaining bugs :-P
[23:02:34] <cradek> heh I was not going to ask...
[23:08:09] <cradek> however, I've tried several times to pan that image
[23:08:34] <SWPadnos> no zooming? :)
[23:08:39] <SWPadnos> or attempted zooming
[23:08:48] <cradek> not this time for some reason
[23:08:53] <cradek> one sec, let me go try again
[23:08:58] <SWPadnos> heh
[23:09:00] <cradek> nope, still doesn't pan
[23:10:36] <cradek> still no
[23:13:43] <SWPadnos> skunkworks, regarding that cnczone question: have him open halmeter and see if the iocontrol.0.coolant-flood pin goes high
[23:13:57] <cradek> (it will)
[23:14:07] <SWPadnos> if so, then he should look at the parallel port pin with halmeter
[23:14:18] <SWPadnos> I know it will, if he's got machine on/out of estop ...
[23:14:54] <SWPadnos> it's unclear how he's testing. MDI and halmeter should be good tools but it's hard to tell
[23:15:04] <cradek> bbl
[23:15:10] <SWPadnos> see you
[23:15:48] <skunkworks> Thanks
[23:16:15] <SWPadnos> I also couldn't really tell if he edited the correct HAL file
[23:16:22] <skunkworks> right
