Back
[00:00:17] <cradek> I still don't know what goes on the flip side
[00:00:19] <jmkasunich> how much massaging are we gonna have to do to jepler's page to make a half-sheet double sided pdf with our URL and a few other details added
[00:00:35] <jmkasunich> will the reference fit on one side?
[00:00:39] <cradek> jmkasunich: not much - he did it once already
[00:00:39] <SWPadnos> that's a darned good question which I don't have the answer to
[00:00:40] <cradek> yes
[00:01:00] <jmkasunich> for the back, I have a few suggestions
[00:01:15] <jmkasunich> drawings showing the definitions of G2 and G3 arcs
[00:01:18] <SWPadnos> diagrams for G2/G3 was one
[00:01:19] <SWPadnos> heh
[00:01:23] <jmkasunich> drawings showing how tool offset works
[00:01:52] <SWPadnos> is the axis quick ref already on the G-code cheat sheet?
[00:01:58] <cradek> no
[00:02:32] <jmkasunich> I can do drawings in easycad, but export to anything other than a pdf is tricky - we want drawing objects that can be placed within a larger pdf
[00:02:51] <cradek> I can do postscript from autocad
[00:03:09] <cradek> (or hpgl)
[00:03:44] <jmkasunich> who has pdf authoring tools - to merge text and drawings?
[00:03:50] <cradek> not me
[00:04:02] <SWPadnos> not me
[00:04:05] <jmkasunich> I suppose lyx could do it (shudder)
[00:04:08] <SWPadnos> not me
[00:04:23] <cradek> not me
[00:04:55] <cradek> I could maybe do it in LaTeX assuming we have postscript to start with
[00:05:10] <cradek> but it has a way of giving crap pdf output sometimes
[00:05:17] <cradek> don't know if that's changed in the last, uh, decade
[00:06:38] <jmkasunich> http://www.scribus.net/
[00:06:43] <jmkasunich> ubuntu package exists
[00:06:49] <jmkasunich> does pdf output
[00:07:05] <jmkasunich> also, open-office wordprocessor might be up to the task
[00:07:43] <cradek> very true
[00:07:50] <SWPadnos> yep - one-click pdf export that actually works well
[00:08:05] <SWPadnos> it's the image imports that could get screwed up
[00:08:31] <cradek> I always forget about open office for some reason
[00:08:36] <SWPadnos> I can give Janet a call tomorrow to see the lead time.
[00:08:50] <SWPadnos> perhaps it's the stigma of big bloated software pavkages
[00:08:55] <SWPadnos> and packages
[00:08:57] <cradek> well there won't be any images, right?
[00:09:07] <cradek> I mean they'll be some kind of vector thing
[00:09:08] <SWPadnos> unless the G2/G3 diagrams get in there
[00:09:12] <SWPadnos> sure
[00:09:15] <jmkasunich> vector images, right
[00:09:26] <cradek> well let's try
[00:09:36] <cradek> I have to switch machines, brb
[00:09:38] <jmkasunich> if there is a left over 1" square, might be fun to stick chips in there
[00:12:07] <cradek> these are half sheets, so about 5x8?
[00:13:11] <jmkasunich> 5.5 x 8.5
[00:13:41] <cradek> printable area is less though I suppose
[00:13:58] <jmkasunich> the lamination needs to overhand the paper, I dunno if they are giving us half sheets of paper, and a little more laminate, or half sheet of laminate and a little less paper
[00:14:01] <SWPadnos> they can likely print to the edge
[00:14:07] <SWPadnos> but we don't want that, I imagine
[00:14:18] <jmkasunich> 5x8 gives a 1/4" all the way around
[00:14:34] <SWPadnos> half sheets printed, with oversized laminate afaik
[00:14:42] <jmkasunich> which seems fine to me - we're paying for the square inches, might as well use them
[00:15:12] <SWPadnos> I know they won't offset print these - it'll just be laser printed or similar
[00:15:23] <SWPadnos> that may mean that we don't have a full bleed
[00:15:30] <jmkasunich> yeah, there will be borders
[00:15:36] <jmkasunich> question is how big
[00:15:55] <jmkasunich> 1/4" seems reasonable - most modern printers can get pretty close to the edges
[00:16:22] <SWPadnos> I can ask. they may actually be able to do full bleed though - I don't know
[00:16:39] <jmkasunich> well, keeping a smallish border makes alignment less critical
[00:16:44] <SWPadnos> yep
[00:17:06] <jmkasunich> this is black on white, right?
[00:17:25] <SWPadnos> yes
[00:18:07] <jmkasunich> so for the drawings, we can use line width, and _maybe_ shades of gray, to distinguish between things like part shape and toolpath, etc
[00:18:40] <SWPadnos> gray will work, it'll just be dithered in the printer
[00:43:08] <tomp2> did anyone use the Altera FPGA toolset for linux? ( Quartus II web edition)
[00:45:06] <jepler> tomp2: I used the windows version -- I was under the impression that only paid versions were available for linx.
[00:45:08] <jepler> linux
[00:47:05] <jepler> https://www.altera.com/support/software/download/altera_design/quartus_we/dnl-quartus_we.jsp says "For Solaris or Linux support, purchase an Altera software subscription"
[00:51:07] <jmkasunich> jepler:
[00:51:08] <jmkasunich> app = Tkinter.Tk()
[00:51:08] <jmkasunich> app.title('FPGA Configuration Editor')
[00:51:08] <jmkasunich> app.grid_propagate(0);
[00:51:08] <jmkasunich> app.configure(width=800, height=600)
[00:51:19] <jmkasunich> resulting window is 305 x 267
[00:52:18] <cradek> http://timeguy.com/cradek-files/emc/arcs.eps
[00:54:02] <jmkasunich> looks educational
[00:54:16] <cradek> the outside box is 5x8"
[00:54:20] <tomp2> jepler: thanks, i saw that 'buy a subscription' thing too... :(
[00:54:22] <jmkasunich> R arcs blow up if R is less than (or too close too) 1/2 the dist from start to end
[00:54:24] <cradek> it's ugly, but I can't put a finger on why
[00:54:59] <cradek> also, I didn't make sure it's right, someone else should check it
[00:55:17] <jmkasunich> IJ arcs blow up if the IJ isn't equidistant from both start and end with some tolerance
[00:55:28] <jmkasunich> thats how I read it, as someone who has no clue how arcs work
[00:55:33] <jmkasunich> did I get it right?
[00:55:34] <cradek> that's right
[00:55:45] <cradek> also R arcs are a bad idea if the endpoints are close together
[00:55:45] <jmkasunich> then it must be a good drawing ;-)
[00:56:07] <jmkasunich> close relative to R?
[00:56:12] <cradek> yes
[00:56:24] <cradek> nearly a full circle and nearly a half circle are the bad cases
[00:56:46] <cradek> they get a bit unpredictable
[00:56:52] <tomp2> i'll try scribus if you'd like
[00:57:16] <jmkasunich> tomp2: if open-office will do the trick, we'd probalby prefer that
[00:57:51] <tomp2> ok, will look at oo and cradek's eps
[00:57:57] <jmkasunich> cradek: regarding the ugly... true, but I think thats the tradeoff for information density
[00:58:00] <cradek> thanks tomp2
[00:58:07] <jmkasunich> you got 6 possible arcs in there
[00:58:52] <tomp2> oo impress or wordprocessor?
[00:59:55] <jmkasunich> I'm displaying it at 3" x 1.5", and its quite readable on screen - paper should be better
[01:00:07] <cradek> I got a pdf with eps2pdf - is that why we are trying OO?
[01:00:28] <jmkasunich> can you merge text and multiple drawings and get the layout you want?
[01:00:57] <jmkasunich> oo gives you wysiwyg, fonts, etc
[01:00:59] <cradek> I could draw more stuff in autocad, but its fonts are ugly
[01:01:13] <cradek> I doubt I can merge/import anything
[01:01:18] <jmkasunich> we certainly don't want the entire g-code reference in acad fonts
[01:01:25] <jmkasunich> oo will do that nicely in a table I bet
[01:01:27] <cradek> no
[01:01:46] <cradek> the gcode reference is done, jepler generated perfectly good postscript
[01:01:50] <cradek> no need to rework that
[01:02:03] <jmkasunich> already scaled to fit a half-sheet?
[01:02:05] <cradek> we've only got to worry about the back side
[01:02:13] <cradek> yes he showed me a printout, and it was easily readable
[01:02:30] <cradek> jmkasunich: can easycad do better fonts? I could give you a dxf to fix up
[01:02:59] <jmkasunich> cad fonts are never nice
[01:04:50] <jmkasunich> typical easycad fonts:
http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/~checkout~/emc2/docs/src/hal/encoder-block-diag.eps?rev=1.1;content-type=application%2Fpostscript
[01:05:12] <jmkasunich> maybe they are nicer
[01:05:46] <cradek> yeah
[01:05:50] <jmkasunich> is your plan to do the entire thing as one drawing, 5x8"?
[01:05:53] <cradek> I won't be offended if you want to redraw it
[01:06:10] <cradek> I had no plan, except I thought I had a good idea for how to present the arc information
[01:06:32] <jmkasunich> ok, lemme put it differently ;-)
[01:06:52] <jmkasunich> how do we want to do this? one 5x8" drawing, or several EPS snippets that we lay out on a page?
[01:07:05] <cradek> I still don't have an answer to that :-/
[01:07:22] <cradek> I think I don't have/know the tools to do this
[01:07:56] <jmkasunich> if the back is gonna be 50% text and 50% drawing, I don't think we want it to be a drawing - writing paragraphs in a CAD tool sucks
[01:09:51] <cradek> well consider that file my suggestion as to how to present the arc information we want
[01:10:17] <jmkasunich> can you do something similar for tool comp? and lathe tool offsets/shapes?
[01:10:26] <jmkasunich> (I think there is something for the latter on the wiki)
[01:10:36] <jmkasunich> I'm exploring layout possiblities
[01:25:22] <jmkasunich> scribus docs author is opinionated: "No matter which way you spell it, a Tagged Image File Format is the file format for bitmap images. Period. End of story. Don't give me any arguments: I'll win."
[01:25:57] <cradek> that's one word for it
[01:28:09] <jepler> jmkasunich: I added "import Tkinter" and "app.mainloop()" to your python above, and I got a window that was around 800x600 pixels
[01:28:20] <jepler> * jepler disappears again
[01:28:32] <jmkasunich> hmm, then I'm obviously doing some thing wrong elsewhere
[01:29:06] <jepler> are you putting widgets into 'app' with 'pack' or 'grid'? if 'pack', then you need: app.pack_propagate(0)
[01:29:08] <jepler> that's the only gotcha I can think of
[01:29:42] <jmkasunich> bet thats it
[01:29:51] <jmkasunich> work_area = bwidget.ScrolledWindow(app, auto=Tkinter.BOTH);
[01:29:51] <jmkasunich> work_area.pack(expand=Tkinter.YES, fill=Tkinter.BOTH)
[01:30:20] <jmkasunich> you used grid in your example of making 20 widgets in a loop
[01:30:52] <jmkasunich> I haven't gotten that far, I will probably want grid when placing stuff in my work area, but maybe pack for menus and placing the work area in the main window?
[01:31:00] <jmkasunich> not sure, I'm really out of my depth
[01:31:41] <jmkasunich> changing app.grid.propogate to app.pack.... made it big
[01:31:54] <jmkasunich> but may not be what I want later
[01:31:53] <jmkasunich> thanks
[01:39:07] <jmkasunich> cradek: when you exported arcs.eps, did you specify the page size somehow?
[01:39:34] <jmkasunich> the image is 8x5, even tho you only drew on about 2.5x5 of it
[01:40:05] <cradek> I specified 1=1 scale
[01:40:16] <cradek> http://timeguy.com/cradek-files/emc/arcs2.eps
[01:40:57] <cradek> is this one wrong the same way?
[01:41:27] <jmkasunich> you're using more of the paper, thats good
[01:41:35] <jmkasunich> I think it might not matter
[01:41:44] <jmkasunich> * jmkasunich is scrabbling up the learning curve here
[01:43:13] <cradek> http://timeguy.com/cradek-files/emc/arcs3.eps
[01:43:17] <jmkasunich> are you using line weighs or width or something?
[01:43:20] <cradek> maybe this one is right?
[01:43:29] <cradek> I told it 5x8 paper size
[01:43:43] <cradek> yes I used some thicknesses
[01:43:50] <cradek> they do show up in evince...
[01:43:56] <cradek> (I've never used acad's ps out before)
[01:44:45] <jmkasunich> does dia do svg output?
[01:44:51] <jmkasunich> does dia suck to use?
[01:44:56] <cradek> what's dia?
[01:45:22] <cradek> there's always xfig but it sucks like all the other programs
[01:45:23] <jmkasunich> I think its a simple drawing tool
[01:48:07] <cradek> I'm trying to think of what other pictures a gcode user would want to see all the time
[01:48:22] <jmkasunich> the lathe tool stuff
[01:48:40] <jmkasunich> aren't there three parameters and 8 orientations or some such?
[01:49:15] <cradek> I don't know if that's in the same class as this stuff - you have to look at it when you set up the tool table, but it's not a gcode issue
[01:50:30] <cradek> a g76 diagram would be great, but I'm not sure I'm up to it
[01:51:16] <cradek> I'm not even sure a picture helps with that. Maybe the text explanation is better, since a picture would get so busy
[01:51:57] <jmkasunich> btw, is jepler's PS for the front online somewhere?
[01:52:22] <cradek> I bet not
[01:52:41] <jmkasunich> * jmkasunich pokes jepler
[01:52:41] <cradek> I think he just printed it from firefox, and maybe massaged the output a bit
[01:57:18] <cradek> I can't figure out how to get it onto one page
[01:57:33] <jmkasunich> get what. the g-code ref?
[01:57:41] <cradek> yeah
[01:58:22] <cradek> aha
[01:58:30] <cradek> http://timeguy.com/cradek-files/emc/gcode.ps
[01:59:18] <cradek> wonder if I can get rid of the stupid headers
[02:00:17] <cradek> yes, grab a new copy
[02:02:20] <jmkasunich> hmm, I notice that the coverage of O words is very limited
[02:02:35] <cradek> true
[02:02:38] <jmkasunich> probably not something that can be done justice to in 4x5"?
[02:03:53] <cradek> the basic syntax could be covered I bet
[02:35:40] <tomp2> 1st run a OO's Impress
http://imagebin.org/8833
[02:49:41] <jmkasunich> tomp2: I think cad does a nicer job, and can be scaled easier to fit
[02:51:51] <tomp2> i agree, dtp sux for cad drawings, while cad sucks for presentation, go figger ... cad is better suited for this task
[02:52:46] <tomp2> btw, that oo was fully scalable ( tho jaggy )
[02:53:34] <jmkasunich> cradek: when you wrote "G2+R" that means G2 with positive R ?
[02:53:40] <cradek> yes
[02:55:04] <jmkasunich> vmware is frustrating
[02:55:16] <jmkasunich> one of the nice things about easycad is that it is incredibly responsive
[02:55:25] <jmkasunich> in vmware, its not
[02:55:38] <jmkasunich> I'm forever clicking on the wrong thing because the mouse cursor is a fraction of a second behind
[02:55:51] <cradek> I was having mouse trouble too tonight
[02:56:13] <cradek> I think I'm going to try vmware with it connected to a real serial port, and use a mouse or tablet directly on that
[02:56:37] <cradek> jmkasunich: "G2 R-" etc. might be better
[02:58:34] <cradek> tomp2's penguin is cute though
[02:58:44] <jmkasunich> R- ?
[02:58:59] <cradek> yeah, since in the gcode you'd say something like R-0.1
[02:59:50] <jmkasunich> you are sure that your drawing is correct? positive R = take the shorter path, negative R take the longer one
[03:00:02] <cradek> to be clear: the four arcs would be G2 R+, G2 R-, G3 R+, G3 R-
[03:00:14] <cradek> yes :-)
[03:00:17] <jmkasunich> ok
[03:00:30] <jmkasunich> you expressed some doubts earlier (or I mis-read)
[03:00:42] <cradek> I was sure, but I also checked it
[03:00:46] <jmkasunich> ok
[03:01:16] <cradek> I was hoping someone else would check it, but nobody did
[03:01:37] <cradek> (because there could still be a thinko in it that I'm blind to)
[03:04:26] <jmkasunich> the I/J assume the XY plane, right?
[03:04:49] <jmkasunich> would it make sense to write (X, Y) instead of (or in addition to) END?
[03:05:01] <cradek> yes (to both)
[03:05:00] <jmkasunich> that way all letters in the command are shown on the dwg
[03:05:07] <cradek> right
[03:16:34] <jmkasunich> for a straightline entry move, you'd normally make the move toward an outside corner of your part, right?
[03:22:31] <cradek> I don't know what's normal, but often you come in at a corner, tangent to the edge
[03:22:39] <cradek> jmkasunich:
http://pastebin.ca/535564
[03:23:11] <cradek> I think this is as distilled as O words get
[03:23:30] <jmkasunich> the line numbers are used to match up while and endwhile?
[03:23:34] <cradek> yes
[03:23:48] <jmkasunich> make them different in each example
[03:23:53] <cradek> they are
[03:24:00] <jmkasunich> not the first 2
[03:24:03] <cradek> oh, not for looping
[03:24:39] <jmkasunich> what is the syntax for a condition?
[03:24:55] <cradek> http://pastebin.ca/535572
[03:25:41] <jmkasunich> I'm the perfect person to examine this, cause I don't know it
[03:26:02] <jmkasunich> the call sort of looks like it has positional parameters, is that true?
[03:27:03] <jmkasunich> if you provide 2 params, the over-rule the normal values of #1 and #2 for the duration of the subroutine?
[03:27:03] <cradek> conditionals are lt, gt, le, ge, eq, ne
[03:27:22] <cradek> the call does have parameters, and they do scope like you say
[03:27:30] <jmkasunich> and the operands for those are #vars or constants, right?
[03:27:47] <cradek> well they are expressions
[03:28:01] <jmkasunich> #34 lt 12.5
[03:28:02] <cradek> like [3], [2/3], [sqrt[2]], etc
[03:28:09] <cradek> right
[03:28:31] <jmkasunich> oh, the [] are part of the syntax, not part of your document notation
[03:28:33] <cradek> yes
[03:28:39] <jmkasunich> [#34 lt 4.5]
[03:28:57] <cradek> o100 while [#34 lt 4.5]
[03:29:03] <jmkasunich> what you've written will fit in 4" tall by 2" wide
[03:29:06] <cradek> #34=[#34-1]
[03:29:07] <cradek> o100 endwhile
[03:29:21] <jmkasunich> could you write something about expression syntax in another 4x2 box?
[03:29:50] <jmkasunich> * jmkasunich buries cradek with work
[03:30:04] <cradek> yargh
[03:30:09] <cradek> I have to be at work early too
[03:31:10] <jmkasunich> true
[03:31:17] <jmkasunich> do it at work tomorrow
[03:31:37] <jmkasunich> I will be up another couple hours, it would be nice if I could finish the page
[03:31:47] <jmkasunich> I don't know yet how to merge the text and drawings
[03:31:58] <jmkasunich> worst case, I do the text in cad
[03:34:52] <jmkasunich> http://jmkasunich.dyndns.org/pics/G42.png
[03:35:05] <jmkasunich> does that look right?
[03:35:28] <jmkasunich> solid is programmed move, dashed is actual, hash lines indicate part outline
[03:37:07] <jmkasunich> I'm really tempted to try to show entry and exit moves, including arcs for offsetting inside a concave pocket
[03:38:08] <jmkasunich> except I have I hunch I would make a nice pretty drawing that is wrong
[03:38:55] <cradek> jmkasunich:
http://timeguy.com/cradek-files/emc/operators
[03:39:40] <jmkasunich> atan takes two operands? or is it acting on the result of the divide, with no outer set of [] ?
[03:39:56] <cradek> jmkasunich: yes your entry is right, except maybe it should be a bit longer - needs to be more than a radius
[03:40:18] <cradek> atan is a special format, sort of takes two operands
[03:40:24] <jmkasunich> ok
[03:40:28] <cradek> it's actually like atan2(y,x)
[03:40:33] <jmkasunich> thought so
[03:40:41] <jmkasunich> but you actually write the / ?
[03:40:44] <cradek> it's the only "special" one
[03:40:56] <cradek> yes you have to write it just like it shows there - it's an error otherwise
[03:41:08] <jmkasunich> can you write SIN 30, or is it SIN[30]?
[03:41:13] <cradek> sin[30]
[03:41:39] <jmkasunich> so when do you not use []
[03:41:47] <jmkasunich> X3 doesn't of course
[03:41:55] <jmkasunich> X[3+#4] does
[03:42:06] <jmkasunich> X[SIN[30]] ?
[03:42:13] <cradek> yes
[03:42:23] <cradek> you use [] to get expression evaluation
[03:42:44] <cradek> and to mark off arguments to things
[03:43:01] <jmkasunich> IOW, the only time you don't need [] is when you have a single constant, and its being passed to a word like X, Y, etc
[03:43:19] <cradek> yeah I think so
[03:44:12] <jmkasunich> [#40 GT 12.5] or [[#40] GT 12.5] or [[#40] GT [12.5]] ?
[03:44:19] <cradek> any of them
[03:44:37] <jmkasunich> I would NOT have guessed that
[03:44:46] <cradek> even indirect: #[#40]
[03:45:12] <cradek> don't mistake me for an expert - if in doubt read the spec :-)
[03:45:24] <jmkasunich> we should have started this a week ago
[03:45:32] <cradek> month
[03:45:36] <jmkasunich> year
[03:45:50] <jmkasunich> hey, I know, lets do the cards next year
[03:45:57] <cradek> nope, I want this card now
[03:46:07] <jmkasunich> jk
[03:46:08] <cradek> I'd use it all the time
[03:48:12] <jmkasunich> damn, I wish I knew what I was doing
[03:48:33] <cradek> with what?
[03:48:49] <jmkasunich> offsets
[03:49:06] <jmkasunich> I'm drawing a square part with a square pocket (rounded corners)
[03:49:20] <jmkasunich> I want to show entry and exit moves inside and out
[03:49:31] <jmkasunich> inside will be arcs, since there are no convex corners
[03:49:37] <cradek> right
[03:49:58] <cradek> outside entry move is easy, you can come into one of the corners in a straight line like you drew
[03:50:07] <cradek> inside entry move will have to be an arc, radius bigger than the tool
[03:50:11] <jmkasunich> right, and exit looks the same
[03:50:28] <cradek> exit is nothing special - just move away from the part and turn comp off after you're away from it
[03:50:35] <cradek> I wouldn't even bother to show exits
[03:50:55] <jmkasunich> how does the tool return to the nominal path?
[03:51:00] <jmkasunich> in the move after you turn off comp?
[03:51:09] <cradek> the move after g40 puts it back on the path
[03:51:32] <jmkasunich> I want to show the moves, so I can mark the spots where you invoke G4x
[03:51:40] <cradek> ok
[03:52:16] <cradek> for exit then, show a move past the part, then g40, then another (straight) move over which the tool returns to the nominal path
[03:52:47] <jmkasunich> and inside I can straight or arc away, then G40, then straight
[03:52:53] <cradek> yes
[03:53:05] <cradek> in real life you'd probably move up and not screw with exiting inside the part
[03:53:21] <cradek> you'll have to arc away, since you can't make a corner
[03:53:34] <jmkasunich> right
[03:53:43] <jmkasunich> for the entry
[03:53:52] <cradek> (that's why it's easier to move up, since you can exit with a straight line later)
[03:53:58] <jmkasunich> the programmed move will be an arc greater than the tool radius
[03:54:02] <cradek> yes
[03:54:06] <jmkasunich> the actual move will be a tighter arc
[03:54:09] <cradek> yes
[03:54:13] <jmkasunich> ok, got it
[03:54:41] <cradek> that case is the one I drew
[03:54:48] <jmkasunich> I don't mind cadding till 2am if needed, but cadding till 2 am and having someone tell me I borked it up tommorrow would suck
[03:55:05] <cradek> yeah I definitely understand
[03:55:15] <jmkasunich> you drew a straight entry move didn't you?
[03:55:18] <cradek> yes
[03:55:22] <cradek> that's what you should do I think
[03:55:33] <jmkasunich> why? don't arc entry moves work now?
[03:55:38] <cradek> the arc is what gets to the part, and is fully compensated
[03:55:48] <cradek> yes they do, but I hear no other controllers do them :-)
[03:56:02] <jmkasunich> this isn't for other controllers
[03:56:03] <cradek> up to you
[03:56:03] <cradek> ok
[03:56:27] <cradek> I think our single arc entry is elegant
[03:56:36] <jmkasunich> so do I
[03:56:39] <jmkasunich> so I want to show it
[03:56:43] <cradek> ok
[03:57:01] <cradek> just don't show an exit with an arc - not so elegant
[03:57:39] <jmkasunich> exit will arc away, then G40, the line away
[03:57:40] <cradek> remember to move off the part before doing the g40, and after the g40, make a straight move with len > radius
[03:57:44] <cradek> right
[03:58:03] <cradek> you're going to be a gcode programmer whether you want to or not :-)
[03:58:18] <jmkasunich> if I ever get my machine built, I will
[03:58:48] <cradek> anything else before I sleep?
[03:59:04] <jmkasunich> I'm sure I'll think of something in an hour or so
[03:59:50] <cradek> I can proof or help more in the morning
[04:05:11] <jmkasunich> SWPadnos: can you find out what the printer needs? is one pdf for the front and a separate one for the back OK?
[04:05:39] <cradek> goodnight jmk
[04:05:56] <jmkasunich> goodnight
[04:06:33] <jmkasunich> SWPadnos: obviously thats an answer you can't get till tomorrow - but email it to cradek and I as soon as you can
[12:17:25] <rayh> Got a question on offsets and the var file.
[12:18:05] <rayh> Both tkemc and mini have an offset display where the user can enter values.
[12:19:12] <jepler> I'll try to answer your question, but be warned that my office's internet connection is going down for maintainance any minute now
[12:19:15] <jepler> so if I go silent that's why
[12:19:33] <rayh> When those values are made current, tcl makes a copy of the xx.var file, fixes the new values, writes the file to disk, and issues an emc_task_plan_init to bring the interpreter's variables into line.
[12:19:38] <rayh> Hi jeff.
[12:19:48] <rayh> thanks
[12:21:11] <rayh> Is there a way to turn the process around so that a G10 L2 (num) x y z is issued to fix interp vars and then write from the interp to the file?
[12:24:20] <rayh> Oh. I found Interp::save_parameters. Perhaps I can use this?
[12:38:13] <jepler> hi -- connection is back for the moment
[12:38:27] <jepler> in AXIS we do use G10 L2 to modify coordinate systems
[12:39:13] <jepler> I don't think we do anything special after mdi'ing the G10 L2
[12:39:49] <jepler> though maybe that's hidden inside the call to "reload_file" which recreates the preview according to the new coordinate system..
[12:40:18] <jepler> ensure_mode(emc.MODE_MDI)
[12:40:22] <jepler> clear_command = "G10 L2 P%c X0 Y0 Z0 A0 B0 C0\n" % num
[12:40:22] <jepler> c.mdi(clear_command)
[12:40:34] <jepler> ^^^ for instance, here's how we clear a coordinate system to get rid of any offset
[12:41:58] <jepler> hmm -- *something* we do makes the .var file on disk be updated, because that's how the offset is applied for the preview plot
[12:42:15] <rayh> Okay.
[12:43:04] <jepler> there are a number of mode changes and other calls here in axis .. I'm not sure which one is responsible for causing the .var file on disk to be updated.
[12:43:55] <rayh> Well at least we know it's being done.
[12:44:16] <jepler> is it important to tkemc to be able to read the .var file and see the right offsets?
[12:44:50] <rayh> Only if something like abort causes a read of the file.
[12:44:51] <jepler> if not, maybe you don't need to solve that portion of the problem
[12:45:30] <rayh> That seems to be where g92 gets some of it's pecularities.
[12:46:34] <rayh> You are right that the tk stuff does not change anything graphical based on changes to offsets.
[12:48:52] <jepler> it looks like the interpreter writes the var file in response to EMC_TASK_PLAN_SYNCH_TYPE
[12:50:27] <jepler> and also in emcTaskPlanExecute when it's an MDI command and "in position"
[12:51:50] <jepler> so basically I think the .var file is written as soon as you MDI a G10 L2, assuming the machine is not moving at the time, due to an earlier MDI command
[12:52:11] <rayh> Ah. That'll do it.
[12:52:31] <rayh> Thanks Jeff.
[12:53:00] <jepler> rayh: glad I could help
[13:10:34] <Guest947> Guest947 is now known as skunkworks_
[17:36:01] <jepler> oh no, there's a bit of drama in Galesburg:
http://www.metafilter.com/61766/You-Cheer-You-Lose-Your-Diploma
[17:37:27] <cradek> impotent authoritarians everywhere
[17:40:27] <cradek> CHEERS COULD HAVE COVERED THE APPROACH OF A TERROR ATTACK DON'T YOU PEOPLE KNOW THERE IS A WAR ON AND THEY ALMOST TOOK OUT JFK AIRPORT LAST WEEK 9/11 CHANGED EVERYTHING WHY DO YOU HATE AMERICA SO MUCH?
[17:40:29] <cradek> hahahahaha
[17:40:42] <jepler> indeed I laughed at that response too
[17:50:27] <SWPadnos> remember - cheer for your enemies, and they won't get diplomas!
[18:06:51] <jepler> SWPadnos: are you going to bring an AMD64 machine to fest that we can pork up with a realtime kernel?
[18:41:59] <SWPadnos> jepler, I'll have my dual Opteron amchine
[18:42:10] <SWPadnos> I don't think I'll be bringing a single-core unit though
[18:54:26] <jepler> the UP realtime kernel ran on my 2-core machine
[18:55:06] <SWPadnos> ok. we can try that, and also try to get one based on cradek's SMP build to work
[18:55:21] <jepler> what OS(es) on that machine?
[18:55:33] <jepler> seems like you said something about 64-bit feisty the other day
[18:55:35] <cradek> I can bring some hard disks
[18:55:35] <SWPadnos> cvs merge --smart cradek-smp + jepler-64bit :)
[18:55:44] <SWPadnos> that one has 6.06
[18:56:06] <SWPadnos> I have another with feisty, which is meant to be a fileserver, so I may not bring it
[18:56:24] <SWPadnos> that's a single-core Athlon64
[18:56:41] <jepler> I wonder when the next LTS will be -- 8.xx or 9.xx?
[18:57:00] <SWPadnos> every 3 years, I think
[18:57:15] <jepler> so around 9.06 you think
[18:57:15] <SWPadnos> so 904
[18:57:23] <SWPadnos> only if there's a dealy
[18:57:25] <SWPadnos> delay
[18:57:41] <jepler> I wonder if our "LTS only" position for emc will remain tenable until then
[18:57:41] <SWPadnos> the releases are supposed to be every April and October, but they were late last year
[18:57:45] <jepler> I see
[18:57:47] <SWPadnos> dunno
[18:58:11] <SWPadnos> note also that the "desktop support" is only 3 years - 5 years is for server only
[18:59:54] <jepler> dV/dT = I/C ?
[19:00:16] <SWPadnos> yes
[19:04:01] <jepler> too bad I forgot even the parts of my differential equations class I attended
[19:04:08] <SWPadnos> heh
[19:06:03] <cradek> differential equations: guess something with an e in it, check, repeat
[19:06:31] <SWPadnos> yeah, but how do you check your answer?
[19:06:43] <cradek> I don't remember
[19:06:47] <SWPadnos> :)
[19:07:15] <cradek> it's strange that I remember a lot of trig, a lot of calculus, little statistics, and no DE
[19:07:35] <SWPadnos> I don't know the titles of the few things I still remember
[19:07:45] <cradek> it seems related to how well I liked the class/teachers which is disturbing
[19:07:59] <SWPadnos> indeed
[19:08:15] <SWPadnos> and conversely, grades are dependent on how much the teacher likes you ...
[19:08:21] <cradek> all I can say is yay for the printing press
[19:08:33] <SWPadnos> yay for google calculator
[19:08:51] <jepler> does google calculator solve 'dv/dT = V/RC' ?
[19:09:00] <jepler> s/dv/dV/
[19:09:16] <SWPadnos> I don't think so
[19:09:21] <cradek> jepler: V = e^-kt, discuss
[19:09:33] <SWPadnos> I tried something with sqrt() in it, and it gave me a normal search
[19:09:45] <SWPadnos> I think that's e^-3/2kt
[19:10:14] <SWPadnos> or was that something else?
[19:11:48] <jepler> k ~ 3/2k
[19:12:02] <jepler> (for large values of k)
[19:12:16] <cradek> k ~ RC
[19:12:21] <cradek> so R=3, C=1/2
[19:12:22] <SWPadnos> 1==2, for some values of 1 (and 2)
[19:12:40] <cradek> if you need anymore help, let us know
[19:25:10] <jepler> emc needs some kind of generic "transfer function" component(s)
[19:25:27] <SWPadnos> hal_matlab
[19:26:23] <jepler> a bit more seriously, hal_polynomial order=3,4,...
[19:26:29] <cradek> loadrt hal_polynomial order=3
[19:26:38] <cradek> heh, that must be obvious
[19:26:48] <cradek> setp polynomial.0.a ...
[19:27:31] <cradek> anyone else think we should quit with the hal_* prefix?
[19:27:36] <jepler> yeah probably
[19:28:24] <cradek> for a while I thought I wanted something like that for my spindle pwm, but it turned out linear enough
[19:28:34] <cradek> I can see that it might be nice for some (obscure) things
[19:31:05] <cradek> I'd like to make a 2.1.6 release and new CD this week
[19:31:18] <cradek> any thoughts about the state of the 2.1 branch?
[19:31:21] <jepler> I agree, i'd like you to do that
[19:31:33] <jepler> I haven't deliberately introduced any bugs
[19:31:42] <skunkworks__> I think the motion carries
[19:31:47] <SWPadnos> me, me!
[19:31:50] <SWPadnos> oops
[19:31:57] <cradek> I'd also like it to be the last 2.1 release (but I always say that)
[19:32:25] <SWPadnos> do you suppose the features in TRUNK are good for 2.2, and we should discuss 2.3 things next week?
[19:33:04] <cradek> yes, probably
[19:33:06] <jepler> if only I could remember what was in TRUNK
[19:33:12] <jepler> I think I added some things
[19:33:17] <SWPadnos> all that extra stuff
[19:33:19] <cradek> I fixed some things
[19:33:30] <SWPadnos> I think I even added and/or fixed some things
[19:33:37] <SWPadnos> it must be very special now :)
[19:34:51] <cradek> I'm not using 2.1 for either machine - it's pretty useless for the lathe actually (tool table problems)
[19:37:00] <jepler> anyone know if there's stuff in the sf tracker that is serious and affects 2.1.5?
[19:38:18] <jepler> argh why can I never get what I want from 'cvs log'?
[20:03:17] <jepler> huh is this all we did since 2.1.5?
http://emergent.unpy.net/files/sandbox/emc-2.1.6-changes.txt
[20:04:13] <jepler> (generated by 'cvsps -b v2_1_branch -r RELEASE_2_1_5 --root :ext:cvs.linuxcnc.org:/cvs' emc2 since I can't get cvs log to do what I want)
[20:04:28] <cradek> yes I bet that's it
[20:04:31] <cradek> there isn't much
[20:04:47] <jepler> we're pretty sure the stuff for elson's boards is right now?
[20:04:50] <cradek> I asked Jon E to test ppmc index and make sure the sample config is updated
[20:05:04] <cradek> I decline to answer that except to say I asked him to let us know
[20:05:51] <jepler> well those changes seem to cover the items listed on the wiki as "known problems with this release"
[20:05:56] <jepler> Known problems in this release:
[20:05:59] <jepler> * The ppmc index pulse polarity is reversed
[20:06:02] <jepler> * tkemc keyboard shortcuts for incremental/continuous don't work right
[20:06:13] <cradek> excellent
[20:06:29] <cradek> it's looking like the end of the line
[20:06:57] <jepler> but in a good way, right?
[20:07:11] <jepler> Merging differences between 1.7.6.44 and 1.7.6.58 into changelog
[20:07:11] <jepler> rcsmerge: warning: conflicts during merge
[20:07:16] <jepler> hm I must have something in my local 2.1 tree
[20:07:21] <jepler> I wonder what it could be
[20:32:24] <maddash> for some reason, emctask.cc refuses to accept subsequent EMC_TASK_PLAN_OPEN packets after the first one: "emc/task/emctask.cc 270: interp_error: A file is already open". I already called EMC_TASK_PLAN_CLOSE, so is this a bug, or am I missing something?
[20:35:08] <jepler> I turned on debugging information while running tkemc.
[20:35:16] <jepler> I observe that it sends the following messages when I "open" a file:
[20:35:17] <jepler> Issuing EMC_TASK_SET_MODE -- (+504,+16, +16, +2,)
[20:35:17] <jepler> Issuing EMC_TASK_ABORT -- (+503,+12, +17,)
[20:35:17] <jepler> Issuing EMC_TASK_PLAN_OPEN -- (+506,+268, +18,/usr/local/jepler/src/emc2/nc_files/arcspiral.ngc,)
[20:35:20] <jepler> Issuing EMC_TASK_PLAN_SYNCH -- (+516,+12, +0,)
[20:35:58] <maddash> jepler: I did the same for keystick, too, and I saw that the keystick code only calls task_plan_open (and nothing else)
[20:36:31] <maddash> hm, that synch message looks interesting
[20:37:39] <jepler> It's not clear to me that EMC_TASK_PLAN_CLOSE actually does anything
[20:38:50] <maddash> that might explain why it's not showing up in my debug output
[20:39:50] <jepler> a little interactive session in Python with tkemc running shows that the ABORT may be what enables the subsequent open
[20:39:59] <jepler> >>> c.program_open("/users/jepler/emc2-src/nc_files/spiral.ngc")
[20:39:59] <jepler> >>> c.program_open("/users/jepler/emc2-src/nc_files/3D_Chips.ngc")
[20:40:03] <jepler> emc/task/emctask.cc 275: interp_error: A file is already open
[20:40:08] <jepler> >>> c.abort()
[20:40:08] <jepler> >>> c.program_open("/users/jepler/emc2-src/nc_files/3D_Chips.ngc")
[20:40:08] <jepler> >>>
[20:45:24] <maddash> hm, didn't notice that before. thanks.
[20:46:25] <jepler> the full Python session, not cleaned up for shorter paste into IRC:
http://pastebin.ca/537744
[20:47:11] <jepler> though the differences between the Python interface and the C++ interface are large (particularly with reslect to naming), a quick interactive Python session may be helpful in exploring what calls are needed to accomplish something -- without the need to re-link a C++ program
[20:56:40] <jepler> bbl
[21:11:17] <alex_joni> good night all
[21:16:16] <maddash> good night
