Back
[01:11:41] <CIA-35> EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: get rid of more unused stuff in nml
[01:11:41] <CIA-35> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/ (emcsh.cc shcom.cc xemc.cc): get rid of more unused stuff in nml
[01:11:41] <CIA-35> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: get rid of more unused stuff in nml
[01:11:50] <CIA-35> EMC: 03jepler 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh emcops.cc): get rid of more unused stuff in nml
[02:11:52] <cradek> cool, kruft removal
[02:12:04] <SWPadnos> heh, I was thinking the same thing
[02:12:13] <SWPadnos> just not as loudly
[02:56:18] <jepler> hopefully I'm right that stuff is unused :-P
[02:56:25] <jepler> but I can't see where it would have any effect
[11:40:22] <CIA-35> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/main.lyx: index cleanup
[11:56:48] <CIA-35> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/axis.lyx: adding menu desc
[12:51:06] <alex_jon1> alex_jon1 is now known as alex_joni
[12:58:30] <jepler> cradek: I'm glancing at the code for probing and I don't see how coordinate systems are handled. Does it set 506x always in the machine coordinate system, regardless of whether the gcode is in inch or mm units?
[13:04:20] <cradek> no, I'm pretty sure it uses all active coordinate systems/offsets/units
[13:04:32] <cradek> but if the code says otherwise, I'm obviously wrong
[13:07:51] <jepler> settings->parameters[5061] = GET_EXTERNAL_PROBE_POSITION_X();
[13:07:53] <jepler> all I see is this
[13:08:38] <cradek> yes, keep following that
[13:13:08] <SWPadnos> ooooh, a treasure hunt!
[13:13:08] <cradek> in this case, it's only two tags deep
[13:13:08] <SWPadnos> argh. you people with your well-configured editors always win these hunts :)
[13:13:08] <cradek> ha
[13:13:08] <cradek> too bad about the cutter comp thread (again)...
[13:13:08] <SWPadnos> heh
[13:13:08] <cradek> it's always a train wreck
[13:13:08] <SWPadnos> I thought Ken had some good points atually
[13:13:08] <cradek> yes he definitely does
[13:13:08] <jepler> my "that's a crazy division of concerns" detector went off too soon and wouldn't let me look inside GET_EXTERNAL_PROBE_POSITION_X
[13:13:08] <SWPadnos> like "is the inside radius specified?"
[13:13:08] <jepler> I should have remembered what code I was looking at
[13:13:08] <jepler> anyway testing code shows that it's in the coordinate system active at the time the probe took place
[13:13:08] <cradek> SWPadnos: it's easy to answer though - if it is specified, you have to use a tool that size or smaller - if it isn't, it doesn't matter
[13:13:08] <SWPadnos> makes sense - it seems like you'd want to move somewhere, maybe set a base position (possibly based on a probed point), then probe relative to that
[13:13:08] <cradek> jepler: oh good
[13:13:08] <Lerman> I think I remember seeing a manual where the G1 could have an Rword (I think) that let you specify the radius of the connection to the next line.
[13:13:11] <SWPadnos> interesting
[13:13:22] <cradek> Lerman: I've seen that too. I think BOSS has it. I have never used it but it would make hand-coding radiused corners very easy.
[13:13:35] <Lerman> Another word could be used instead to specify the chamfer to the next line. I thought that is a neet idea because of what cradek beat me to.
[13:13:49] <SWPadnos> heh
[13:14:00] <Lerman> It might have been Haidenhein (spelling).
[13:14:06] <cradek> yes, it's pretty tedious to figure out those arcs by hand.
[13:15:15] <Lerman> And right now, that's the only way to do it on EMC (for internal corners with cutter comp).
[13:15:16] <cradek> unfortunately, doing it is another you-have-to-know-the-future problem
[13:15:30] <cradek> yep
[13:16:18] <cradek> and it's easy to get internal corners. if you have a program of the nominal tool path and you put a reground cutter in, and put -0.010 in your tool table, everything is "inside" corners
[13:16:30] <Lerman> Add one more "line" of buffering to the interp.
[13:16:40] <cradek> yes I had to do that in my branch.
[13:16:44] <cradek> (it sucks)
[13:17:39] <Lerman> At what level did you add it? In the interp, or canon, or where?
[13:17:44] <cradek> but it's worse than that. imagine a (currently valid) program that moves into an inside corner, then moves up and down a few times, then turns flood on and mist off, then changes spindle speed, then continues
[13:18:01] <cradek> inside interp. I did not move ccomp out of the interp.
[13:18:35] <Lerman> Yup. It's not just one line that has to be buffered. It's one motion command.
[13:19:12] <Lerman> Oops. moving up and down are also motion commands and you can have N of them.
[13:19:16] <SWPadnos> no, it's "the next motion command that needs to be compensated"
[13:19:39] <cradek> yep
[13:19:56] <cradek> that's what I mean about the hard part not being done yet :-/
[13:20:59] <Lerman> It would be interesting to try some of those hard cases on a Fanuc and see how it does. Any bets on whether it gets all the cases right?
[13:21:22] <SWPadnos> I bet no!
[13:21:24] <cradek> I wouldn't bet either way
[13:21:32] <cradek> I can try them on my BOSS though, I'd bet on that
[13:25:14] <Lerman> Consider the case of using a slotting cutter. Run it along the side of a block. Then run it up and down (cutting material above and below the slot). Finally, go back to the same height and continue the slot.
[13:26:24] <SWPadnos> oh, so it isn't just a useless pathological case
[13:26:26] <SWPadnos> nice!
[13:27:31] <Lerman> Nasty.
[15:36:31] <alex_joni> jepler: can I ask you to try something? I need to run atm, but I'll be back..
[15:37:01] <jepler> alex_joni: ok I'll do it if I can
[15:38:15] <alex_joni> I generated an obj of the machine base from Greg Michalski (from the emc-list)
[15:38:21] <alex_joni> was wondering if it loads in vismach
[15:39:25] <alex_joni> http://eneas.juve.ro/~juve/emc/base.obj
[15:39:32] <alex_joni> * alex_joni needs to run.. bbl
[15:41:29] <jepler> no, the parser doesn't like it
[15:41:30] <jepler> ValueError: invalid literal for float(): vertices
[15:42:13] <jepler> that format is not remotely the same as the one I taught vismach to parse
[15:42:43] <jepler> vismach knows ascii stl files
[16:03:27] <jepler> http://emergent.unpy.net/files/sandbox/notright.png -- hm my quickly-written obj parser isn't quite right
[16:03:42] <SWPadnos> no, but it is cool
[16:05:14] <cradek> that does not look like a plausible machine design.
[16:05:36] <SWPadnos> 6000-axis, with scraped ways
[16:05:38] <jepler> I thought I'd just switched the normal and vertex coordinates, but that doesn't fix it ..
http://emergent.unpy.net/files/sandbox/notright2.png
[16:06:29] <SWPadnos> it seems logical that vn is vertex normal and v is vertex
[16:07:44] <SWPadnos> I don't quite get the face definitions though, unless I'm reading them "rotated" one vertex
[16:08:53] <SWPadnos> are you off by 1? it looks like the vertices are numbered from 1, not 0
[16:09:34] <jepler> no, I'd already solved that problem
[16:09:51] <jepler> the problem was that I was putting both vertices and normals into the array of vertices, because both "v" and "vn" lines satisfy the condition 'line.startswith("v")'
[16:10:01] <SWPadnos> heh
[16:10:05] <SWPadnos> http://www.royriggs.com/obj.html
[16:12:20] <jepler> http://emergent.unpy.net/files/sandbox/mayberight.png
[16:12:34] <SWPadnos> ah yes
[16:13:04] <jepler> the surfaces don't quite seem to be lit right..
[16:13:48] <jepler> http://emergent.unpy.net/files/sandbox/asciiobjexample.py
[16:13:59] <CIA-35> EMC: 03jepler 07TRUNK * 10emc2/lib/python/vismach.py: rudumentary reader for .obj 3d meshes
[16:17:52] <jepler> * jepler debates about a change to the interpreter:
http://emergent.unpy.net/files/sandbox/rs274-introspection.patch http://emergent.unpy.net/files/sandbox/introspection.ngc
[16:18:16] <jepler> it allows programs to check the state of the interpreter -- so you can read the current position, or find out the active "group 1" modal code, and so on
[16:22:39] <Lerman> jepler: Took a quick look. That's the right idea. If we are going to do something like this, I'd like to see a complete list defined. I would probably reserve some block of parameter numbers. I was thinking that values over 10,000 should be reserved for this stuff.
[16:23:10] <Lerman> Then we should add a wiki page listing the currently defined parameters.
[16:24:14] <cradek> does 'case a ... b:' really work?
[16:24:23] <cradek> I thought this was pseudocode
[16:24:38] <Lerman> Things like the last gcode, the last mcode, etc should be included. cradek: NO it doesn't (at least not in C).
[16:24:53] <jepler> cradek: it's a gcc extension
[16:25:00] <cradek> neato
[16:25:51] <cradek> what would the last gcode/last mcode be used for?
[16:26:14] <cradek> (and is there always a "last" one?)
[16:26:36] <SWPadnos> it seems there is, for a given compile of the interpreter
[16:27:01] <SWPadnos> I think (without looking) that G99.9 is the last G code, and M199 is the last M code
[16:27:09] <cradek> I guessed he meant last-executed
[16:27:14] <cradek> but your guess may also be right
[16:27:17] <SWPadnos> oh :)
[16:27:23] <cradek> Lerman: which do you mean?
[16:27:32] <Lerman> It's stuff that the interpreter cares about and knows about. I could write some common subroutines that care about whether the last arc was cloockwise or counter closkwise. cradek is correct.
[16:27:35] <SWPadnos> you're probably correct
[16:27:42] <Lerman> last === most recently executed.
[16:28:11] <jepler> with this patch, #5401 holds the active modal motion code, so an O-subroutine could save it at the top and restore it before exit if for some reason that's desirable
[16:29:21] <Lerman> To me, introspection means that anything the interpreter cares about should be available to the gcode program. (But, hey, let's be reasonable.).
[16:30:14] <Lerman> I don't think we need the gcode to be able to access the list of all of the named parameters. (gcode only deals with a single data type, so names wouldn't work, anyway)
[16:30:20] <jepler> for instance to move the quill up to machine Z0 without changing the active motion code: #19=#5401 / G0 G53 Z0 / G[#19/10]
[16:31:38] <Lerman> jepler: Yup. That's why we want/need introspection.
[16:32:53] <cradek> I worry about how much more 'public interface' this gives us.
[16:33:10] <cradek> adding a feature without breaking (potential) old programs might be much harder
[16:33:31] <cradek> we often add stuff to these groups
[16:33:49] <jepler> well .. I won't check it in right this second
[16:34:22] <jepler> Lerman: but feel free to use it if you think it's on the right track
[16:34:51] <Lerman> That's why I would pick a range of variables of greater than 10,000. In case we ever want/need to extend the range from 5400 to higher, it would be nice to have some space that won't conflict with existing stuff.
[16:35:17] <jepler> I started around there because that's where variables with predefined meaning are living already
[16:35:27] <jepler> god help anyone who actually uses variables 1...5000!
[16:35:52] <jepler> or, put another way, 5000 variables should be enough for anybody
[16:36:11] <Lerman> I figured that. Well, if you are writing code to do some variable pitch threading and want to make it table driven, you might need lots of continuous space. :-)
[16:36:16] <cradek> no, I guess I wasn't clear enough. If we expose all of this and a user writes a program that depends on checking for length comp with gmodes[8]=430 or whatever the test is, when I added G43.1 I would have possibly broken his program because now gmodes[8] can have a new value
[16:37:00] <cradek> so how can I ever add anything to group 8, or any group for that matter?
[16:38:23] <Lerman> But if he never used G43.1, gmodes[8] would never have that value, so it shouldn't cause him any trouble. And if he did use G43.1, he's the one who broke his code; not you.
[16:39:30] <cradek> either that is not a good example, or my concern is silly
[16:42:07] <Lerman> Your concern is reasonable. If I may paraphrase, you are concerned that adding features to the language and/or environment shouldn't break existing code.
[16:44:02] <cradek> yes, and previously this only meant that the emitted machine behavior had to stay the same - with so much introspection, it seems like there are a lot of new ways we can break programs
[16:46:12] <SWPadnos> the example may be better constructed as "what if the user checks for modes==43.1, and another mode is added, like G43.2, which also has length comp enabled"
[16:48:06] <Lerman> Again: if he doesn't use G43.2, his code will never see it. If he does use G43.2, he needs to fix his code.
[16:49:02] <Lerman> The tougher example is what if he writes a wizard or subroutine library that does this stuff. A user of the library might use G43.2 and the library writer might not be prepared for it.
[16:49:03] <SWPadnos> if the introspection is inside some machine config files, then the code that may use new functions has nothing to do with the code that controls how the machine works
[16:49:25] <SWPadnos> wow - I have no memoruy of typing the word "introspection"
[16:49:56] <Lerman> There must be a fault in your own introspection subroutines. :-)
[16:50:06] <SWPadnos> must be - I blame the programmer
[16:50:41] <Lerman> Sure, blame your mother. That's the modern way. You young folks ... :-)
[16:50:51] <SWPadnos> heh
[16:51:41] <Lerman> (rayh and I should start a pool on how long it will take you to come up with an "old geezer" comment.)
[16:51:56] <SWPadnos> oh, I have a few already, I just didn't type them ;)
[16:51:59] <SWPadnos> that I can recall
[16:52:12] <Lerman> They can keep till next 'Fest'.
[16:52:28] <SWPadnos> now I can't remember. I just turned 40, so Alzheimer's is setting in
[16:55:33] <SWPadnos> I'd have to say that named variables are the way to go - they're more resistant to unrelated changes
[16:56:16] <Lerman> Yup. Easier to write the code and to read it, also.
[16:57:33] <SWPadnos> you can also expose the information to libraries or specific language bindings, using the same variable names
[16:57:56] <SWPadnos> whereas most languages are annoyed when you try to say something like "5000=1" ;)
[16:59:34] <Lerman> named o-words are also a big help in writing readable code
[18:05:36] <rayh> Hi ken. I'm pretty certain that folk think "old geezer" a lot quicker than they say it.
[18:05:56] <SWPadnos> young geezer just doesn't cut it
[18:06:11] <rayh> Not the same. Hi Steven.
[18:06:16] <SWPadnos> hi
[18:06:43] <rayh> Working to expand the fire pit and picnic area by the lake a bit.
[18:07:18] <rayh> Get ready for next years "Henry fest and Bratwurst cookout."
[18:08:13] <LawrenceG> rayh, cool... I'll start pedalling your way... hope I'm not late
[18:08:28] <rayh> Should be early.
[18:08:56] <rayh> About 2.5k miles.
[18:09:43] <LawrenceG> I have been having some fun porting some of the cp1 mops into python filter programs for emc2
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Simple_EMC_G-Code_Generators
[18:10:03] <rayh> Hey that's great.
[18:10:22] <rayh> I still use that stuff.
[18:10:38] <LawrenceG> I cant believe it was so long ago we wrote that stuff!
[18:10:44] <rayh> Ran some Bezels a couple weeks ago.
[18:11:00] <rayh> It was a long time ago.
[18:11:16] <LawrenceG> cool.... I have a few to do for a retro tube radio I am building
[18:11:33] <rayh> Thanksgiving break here in USA, if I remember right.
[18:12:10] <rayh> I've got a tube stereo receiver out in the shop.
[18:12:34] <rayh> Wish I had speakers that could really take advantage of it.
[18:12:39] <LawrenceG> the new code has a display window so it helps in the design tweaking
[18:13:00] <rayh> That is a real good improvement.
[18:13:03] <LawrenceG> cp1 was better for building several components into a design
[18:13:05] <rayh> Thanks for the work.
[18:13:22] <rayh> I'll expect you at the bbq. More details later.
[18:14:04] <LawrenceG> yea... I wish fest was closer as well....
[18:19:09] <SWPadnos> LawrenceG, have you seen these:
http://www.velokraft.com/+products.htm
[19:00:57] <LawrenceG> SWPadnos, looking
[19:01:15] <SWPadnos> (you mentioned pedaling, so I thought you might be interested)
[19:02:44] <LawrenceG> very cool looking bikes....
http://www.velokraft.com/-nc.htm the Ferrari of bikes!
[19:02:56] <SWPadnos> yeah, the nocom is very cool
[19:03:42] <LawrenceG> wonder how many people would drive off the road looking at you as they passed on the hiway!
[19:03:52] <SWPadnos> yeah, off the road through you ;)
[19:04:12] <LawrenceG> pedal and carry a BIG stick
[20:12:34] <alex_joni> jepler: for some reason I remembered you added .obj to vismach
[20:12:44] <alex_joni> the object I got was STEP which I converted to .stl
[20:12:55] <alex_joni> and afterwards I converted that to .obj
[20:12:55] <alex_joni> :)
[20:13:05] <jepler> hi again alex_joni
[20:13:18] <alex_joni> * alex_joni looks for the .stl
[20:14:48] <alex_joni> http://eneas.juve.ro/~juve/emc/X3%20CNC%20Conversion-Final-rev1(AP214)-base.stl
[20:15:01] <alex_joni> jepler: can you paste a snip how you read it from vismach?
[20:15:11] <jepler> 403: Forbidden.
[20:15:35] <jepler> 11:13:35 <jepler>
http://emergent.unpy.net/files/sandbox/asciiobjexample.py
[20:16:34] <alex_joni> try again
[20:17:54] <jepler> the stl version looks much better
[20:18:20] <jepler> it can be read with AsciiSTL: base = Rotate([Translate(
[20:18:20] <jepler> [Scale([AsciiSTL("base.stl")], 2.5, 2.5, 2.5)], -121/2., -156/2., 30)],
[20:18:23] <jepler> 90, 1, 0, 0)
[20:18:27] <jepler> I don't think AsciiSTL is in 2.2 though
[20:18:38] <alex_joni> I have TRUNK all over the places
[20:18:54] <alex_joni> any reason for the scale?
[20:19:21] <jepler> no
[20:19:31] <alex_joni> ah, ok :)
[20:20:22] <jepler> http://emergent.unpy.net/files/sandbox/base_stl.png
[20:20:42] <alex_joni> looks good
[20:20:59] <jepler> I think that the obj version had some inappropriate rounding of normals done on it or something
[20:21:18] <jepler> or maybe I was applying the wrong normals, who knows
[20:21:19] <alex_joni> the model I got has a lot of details though.. so I need to figure out how to reduce the number of parts
[20:21:35] <alex_joni> I think the converter (MeshLab) did some funky stuff on it
[20:21:55] <alex_joni> MeshLab is quite a nice opensource program for manipulating face-3D mdoels
[20:22:06] <alex_joni> it knows a lot of formats
[20:24:55] <alex_joni> it's supposed to run on linux too
[20:24:59] <alex_joni> http://meshlab.sourceforge.net/
[22:14:27] <jepler> darn, I thought O-word subroutines from external files was in 2.2 but I guess it's not
[22:43:05] <skunkworks> cradek: I thought some pccard par ports worked..
[22:46:06] <cradek> that would be news to me
[22:46:19] <jepler> skunkworks: alex_joni has gotten one to work but it was hackish. I think that fundamentally pcmcia is OK (it's like an ISA or PCI bus) but we don't have the setup code and the kernel drivers won't work because they claim the ports.
[22:46:32] <skunkworks> ok
[22:46:44] <jepler> but for a new user, the better answer is "it doesn't work"
[22:46:58] <skunkworks> heh ;)
[23:35:44] <Lerman> jepler: are you still here?
