EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: get rid of more unused stuff in nml
EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/ (emcsh.cc shcom.cc xemc.cc): get rid of more unused stuff in nml
EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/extensions/emcmodule.cc: get rid of more unused stuff in nml
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
cool, kruft removal
heh, I was thinking the same thing
just not as loudly
hopefully I'm right that stuff is unused :-P
but I can't see where it would have any effect
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/main.lyx: index cleanup
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/axis.lyx: adding menu desc
alex_jon1 is now known as alex_joni
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?
no, I'm pretty sure it uses all active coordinate systems/offsets/units
but if the code says otherwise, I'm obviously wrong
settings->parameters = GET_EXTERNAL_PROBE_POSITION_X();
all I see is this
yes, keep following that
ooooh, a treasure hunt!
in this case, it's only two tags deep
argh. you people with your well-configured editors always win these hunts :)
too bad about the cutter comp thread (again)...
it's always a train wreck
I thought Ken had some good points atually
yes he definitely does
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
like "is the inside radius specified?"
I should have remembered what code I was looking at
anyway testing code shows that it's in the coordinate system active at the time the probe took place
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
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
jepler: oh good
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.
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.
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.
It might have been Haidenhein (spelling).
yes, it's pretty tedious to figure out those arcs by hand.
And right now, that's the only way to do it on EMC (for internal corners with cutter comp).
unfortunately, doing it is another you-have-to-know-the-future problem
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
Add one more "line" of buffering to the interp.
yes I had to do that in my branch.
At what level did you add it? In the interp, or canon, or where?
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
inside interp. I did not move ccomp out of the interp.
Yup. It's not just one line that has to be buffered. It's one motion command.
Oops. moving up and down are also motion commands and you can have N of them.
no, it's "the next motion command that needs to be compensated"
that's what I mean about the hard part not being done yet :-/
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?
I bet no!
I wouldn't bet either way
I can try them on my BOSS though, I'd bet on that
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.
oh, so it isn't just a useless pathological case
jepler: can I ask you to try something? I need to run atm, but I'll be back..
alex_joni: ok I'll do it if I can
I generated an obj of the machine base from Greg Michalski (from the emc-list)
was wondering if it loads in vismach
[15:39:25] <alex_joni> http://eneas.juve.ro/~juve/emc/base.obj
* alex_joni needs to run.. bbl
no, the parser doesn't like it
ValueError: invalid literal for float(): vertices
that format is not remotely the same as the one I taught vismach to parse
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
no, but it is cool
that does not look like a plausible machine design.
6000-axis, with scraped ways
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
it seems logical that vn is vertex normal and v is vertex
I don't quite get the face definitions though, unless I'm reading them "rotated" one vertex
are you off by 1? it looks like the vertices are numbered from 1, not 0
no, I'd already solved that problem
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:05] <SWPadnos> http://www.royriggs.com/obj.html
[16:12:20] <jepler> http://emergent.unpy.net/files/sandbox/mayberight.png
the surfaces don't quite seem to be lit right..
[16:13:48] <jepler> http://emergent.unpy.net/files/sandbox/asciiobjexample.py
EMC: 03jepler 07TRUNK * 10emc2/lib/python/vismach.py: rudumentary reader for .obj 3d meshes
* 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
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
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.
Then we should add a wiki page listing the currently defined parameters.
does 'case a ... b:' really work?
I thought this was pseudocode
Things like the last gcode, the last mcode, etc should be included. cradek: NO it doesn't (at least not in C).
cradek: it's a gcc extension
what would the last gcode/last mcode be used for?
(and is there always a "last" one?)
it seems there is, for a given compile of the interpreter
I think (without looking) that G99.9 is the last G code, and M199 is the last M code
I guessed he meant last-executed
but your guess may also be right
Lerman: which do you mean?
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.
you're probably correct
last === most recently executed.
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
To me, introspection means that anything the interpreter cares about should be available to the gcode program. (But, hey, let's be reasonable.).
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)
for instance to move the quill up to machine Z0 without changing the active motion code: #19=#5401 / G0 G53 Z0 / G[#19/10]
jepler: Yup. That's why we want/need introspection.
I worry about how much more 'public interface' this gives us.
adding a feature without breaking (potential) old programs might be much harder
we often add stuff to these groups
well .. I won't check it in right this second
Lerman: but feel free to use it if you think it's on the right track
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.
I started around there because that's where variables with predefined meaning are living already
god help anyone who actually uses variables 1...5000!
or, put another way, 5000 variables should be enough for anybody
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. :-)
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=430 or whatever the test is, when I added G43.1 I would have possibly broken his program because now gmodes can have a new value
so how can I ever add anything to group 8, or any group for that matter?
But if he never used G43.1, gmodes 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.
either that is not a good example, or my concern is silly
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.
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
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"
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.
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.
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
wow - I have no memoruy of typing the word "introspection"
There must be a fault in your own introspection subroutines. :-)
must be - I blame the programmer
Sure, blame your mother. That's the modern way. You young folks ... :-)
(rayh and I should start a pool on how long it will take you to come up with an "old geezer" comment.)
oh, I have a few already, I just didn't type them ;)
that I can recall
They can keep till next 'Fest'.
now I can't remember. I just turned 40, so Alzheimer's is setting in
I'd have to say that named variables are the way to go - they're more resistant to unrelated changes
Yup. Easier to write the code and to read it, also.
you can also expose the information to libraries or specific language bindings, using the same variable names
whereas most languages are annoyed when you try to say something like "5000=1" ;)
named o-words are also a big help in writing readable code
Hi ken. I'm pretty certain that folk think "old geezer" a lot quicker than they say it.
young geezer just doesn't cut it
Not the same. Hi Steven.
Working to expand the fire pit and picnic area by the lake a bit.
Get ready for next years "Henry fest and Bratwurst cookout."
rayh, cool... I'll start pedalling your way... hope I'm not late
Should be early.
About 2.5k miles.
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
Hey that's great.
I still use that stuff.
I cant believe it was so long ago we wrote that stuff!
Ran some Bezels a couple weeks ago.
It was a long time ago.
cool.... I have a few to do for a retro tube radio I am building
Thanksgiving break here in USA, if I remember right.
I've got a tube stereo receiver out in the shop.
Wish I had speakers that could really take advantage of it.
the new code has a display window so it helps in the design tweaking
That is a real good improvement.
cp1 was better for building several components into a design
Thanks for the work.
I'll expect you at the bbq. More details later.
yea... I wish fest was closer as well....
LawrenceG, have you seen these: http://www.velokraft.com/+products.htm
(you mentioned pedaling, so I thought you might be interested)
very cool looking bikes.... http://www.velokraft.com/-nc.htm
the Ferrari of bikes!
yeah, the nocom is very cool
wonder how many people would drive off the road looking at you as they passed on the hiway!
yeah, off the road through you ;)
pedal and carry a BIG stick
jepler: for some reason I remembered you added .obj to vismach
the object I got was STEP which I converted to .stl
and afterwards I converted that to .obj
hi again 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
jepler: can you paste a snip how you read it from vismach?
11:13:35 <jepler> http://emergent.unpy.net/files/sandbox/asciiobjexample.py
the stl version looks much better
it can be read with AsciiSTL: base = Rotate([Translate(
[Scale([AsciiSTL("base.stl")], 2.5, 2.5, 2.5)], -121/2., -156/2., 30)],
90, 1, 0, 0)
I don't think AsciiSTL is in 2.2 though
I have TRUNK all over the places
any reason for the scale?
ah, ok :)
[20:20:22] <jepler> http://emergent.unpy.net/files/sandbox/base_stl.png
I think that the obj version had some inappropriate rounding of normals done on it or something
or maybe I was applying the wrong normals, who knows
the model I got has a lot of details though.. so I need to figure out how to reduce the number of parts
I think the converter (MeshLab) did some funky stuff on it
MeshLab is quite a nice opensource program for manipulating face-3D mdoels
it knows a lot of formats
it's supposed to run on linux too
[20:24:59] <alex_joni> http://meshlab.sourceforge.net/
darn, I thought O-word subroutines from external files was in 2.2 but I guess it's not
cradek: I thought some pccard par ports worked..
that would be news to me
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.
but for a new user, the better answer is "it doesn't work"
jepler: are you still here?