is jepler around?
here I am
back home jmk?
is a huge number of warnings expected while building the docs?
I think there are quite a few
particularly during the HTML documentation building
thats what I saw
the only problem I'm aware of as such is that some images are just wrong...
it also doesn't handle footnotes well
ray had talked about looking at another converter as well -- tth
I've been kinda doing nothing so far
I just was asking in case I was missing some required tool
if the warnings are normal I'll just ignore them for a while
you can compare to the online version I'm building to see whether it's wrong differently..
that machine is supposed to be set up "right"
I saw the warnings while I was test building the acemi patches, not sure I want to dive into html docs issues tonight
I can understand that
there was an interesting discussion earlier today about toolchange
I was almost a part of it
what are your thoughts about it?
I'm not sure I understand what Ray is thinking
I don't _think_ he wants to code toolchangers in C, but at the same time it sounds like that what he's saying
I really need to learn more about the higher level stuff
my knowledge of g-code is pathetic, considering I work as a developer on a cnc controller
well lean on me if that helps
gcode is quite simple. you should just pretend like you know it.
that's another good plan
I did, and you got AXIS as a result
are there variables that contain the current position of the tool?
heh, "current" can be a complex idea because of lookahead
I was just thinking of something simple like going from the current position straight up to a safe position, the moving x and y to a tool change pos, then doing the change, moving in x and y back to the original position, then straight down to the previous spot
gotta save the old coords to do that
at the canon level that's pretty easy
using a g-code macro would mean g-code needs to be able to save the old coords
I don't even know the syntax for g-code vars
is it ?
#1 #2 #999
#1234 = #curr_x
#1235 = #curr_y
etc for z
G0 Z0 (straight up)
G0 x0 y0 (move to toolchange pos)
brb, coffee's ready
misc stuff (do the change)
G0 X#1234 Y#1245
I get the idea
(you'd have to put some g53s in there)
tool length comp?
but gcode seems to be the obvious way to program machine motion
g53 means global coord system
and then back to the current coords when done
damn modal stuff - anything you change during the macro needs to be restored - messy
yes making the macros right is maybe going to be a challenge
we may end up changing the interp some to make it better
normally writing the macros would be the task of the machine builder
<half baked>maybe some kind of state stack</half baked>
while he may not know C, he's gonna be better at g-code programming than the typical part programmer
and lots better than me
this will be another case where we'll have some useful examples
the stack thing is kind of interesting
have to figure out what state to save
gsave; g21; g0g53x99; grestore
yeah that's an obvious hard part
do you save the entire set of variables? or just a few modal codes, or something inbetween
at first I'm tempted to say you save everything that's modal
you'd also want to turn off radius comp
wonder if you can even change tools with comp on
SWP: that would be something to do in the macro code
it's easy to mess up with comp on
decising what to save is a core issue
but you'd want to restore that mode as well (unless it's invalid during toolchange)
as far as doing I/O during the macro...
the spec says that the axes should be in the same position after the change
that seems nuts to cradek and me, and it's not what the code does now
what if some subset of the #vars was mapped to hal pins?
(it doesn't move after the change has taken place)
I thikn that also includes tool length, IIRC
jmkasunich: that's interesting but what about motion/io synchronization? you'd have to *stop* each time you read or write those, or have them not synchronized at all
maybe the spec was anticipating the 23rd century toolchange, where the teleport the old tool out and the new one in without moving the spindle
but tool lengths might differ
synch is gonna be a mess however its done
as might a radius. I think in a previous discussion, we looked it up and found that the spec says that the axis positions will be the same, regardless of various tool compensations
you just have to stop, like probe does
somebody suggested a "wait for pin" g-code
wait for variable #
that covers input sync
but we'd also need "wait for motion to finish, then set var #foo"
synchronized sets are not hard
the more I think about it the less I like using #vars as I/O though
well ok they are
its like assembly language on a microcontroller.....
ok, most of these addresses are just ram, but that one is the serial port, and this one over here is some digital I/O, and that one is the counter-timer latch value...
yeah I was just grinding my teeth thinking about btsfc etc (skip if set)
_without_ the benefit of symbolic names
ugh ugh ugh
liking it less and less
ooh time to watch tv
let's just forget I mentioned it
what's on tv?
I still think it's the way to do it
battlestar galactica on dvd
nothing is going to make gcode not suck
regardless, it's still the best way to program machine motion
or something like it
the G-code interpreter is too stupid (by design) to allow for more "interesting" programming forms, such as words with more than one character
well IMO if we want symbolic names for vars, there's no reason not to put them in the interp too
unless anything else is an E code, or it's in a comment
#<anything not starting with a digit>?
(E being the only missing letter, I think)
do what with #<non-num> ?
symbolic names for vars
that's only part of the problem
the other is operations, like set I/O, wait for I/O, pause, error etc.
small steps ;-)
I usually think from the ground up, rather than from the current implementation over
there are all sorts of gcodes available
then I do almost none of the programming, so I usually shut up ;)
I don't think _any_ modern programmer would build a language like g-code today
nope, though it isn't bad for what it's designed to do
ray did bring up an issue about macros - what if an abort or an error happens in the middle?
we're just discussing things well beyond that set
jmkasunich: you stop
and how do you recover?
I don't think that's a hard question
it can be
what do you mean recover?
how do you "recover" if you abort during a g1 cut?
the answer is it depends what you were doing
I dunno, how do you recover?
you look at where you stopped, and then you do the right thing
that works fine when you can see the g-code
sometimes you jog in a certain direction
what if you are half way through an internal toolchange macro (that you probably can't see)
well again it depends
if you were in the 'go up' part, you don't do anything
if your tool is halfway into the clamp, you have to deal with that
the short answer is that you _can't_ exepect the machine operator to know what the right thing is
you sure as hell can't expect emc to know
that's for a human to deal with
the machine builder needs to know
IMO emc's only job is to stop moving
that's the most compatible with continuing on from where you left off as well
there was a non-trivial chunk of the mazak manual explaining how to recover from an inadvertant power down or other stop during toolchange for example
right, and a human deals with it, right?
yes and no
for many situations, the machine logic is designed to recover
I'm really not trying to be difficult, I just think you're making a problem where there isn't one
it looks at all the prox switches and other sensors, figures out what is what, and gets the machine into a decent state
thats not emc's job at all
sounds like a kind of homing
but it _is_ something the macros or whatever we provide should be able to do
if the machine builder is smart enough
if emc is the motion controller/g-code interpreter, then it isn't emc's job
doing homing as a macro would be a very flexible approach
if emc is the whols system, then it may be (think ladder)
I'm taking the user view, emc is the whole shebang
right - I agree (though you just said it isn't emc's job ... )
but this isn't a new problem that's come about because of macro talk
it is, but only to provide the mechanisms by which an integrator can make the right thing happen
sorry, I was a little unclear
if I program T10 and pull the plug while it's between pockets, it's the same problem
our job is to provide a frameworks, the machine builders job is to provide the machine specific logic and motion
macros are one way of providing those mechanisms, but only if they can (eventually) integrate all necessary aspects
so it's not "what to do at abort" it's "what to do to get the machine into a known state when it starts up"
and the mazak has logic such that when you put the plug back in, it will move to a pocket if it stopped halfway between
(the original control that is)
now I still don't understand how this is related to toolchange macros
it is related, but only if you leave "toolchange" out of the picture ;)
I guess I'm just trying to enumerate the things that need done in machine logic
so we can decide if "macros" are an appropriate implementation
ie, macros with motion and IO may be useful for any of the tasks that Ray calls "Machine Logic"
I think thats where classic emc and something like Fanuc go separate ways
I think macros are a fine solution, as long as they can do everything needed
classic emc has all the machine logic in C code
fanuc has no machine logic hardcoded, its all programmed by the machine builder
mostly ladder I think, but there have to be hooks for other stuff like motion
we've moved some machine logic out of C and into hal/CL
but not enough to do what is needed
specifically - we need motion
we sort of have that
are you thinking of ladder?
there are g-codes for synchronized I/O
which let you toggle a bit when the preceding motion starts (or something like that, gotta read the spec)
actually, synchronized O, not I
it may not be fully implemented right now, but I think thats a smop
I guess we don't have I
other than the specialized inputs provided by iocontrol
right, and those are in C
but they are generic
CL is used to customize them
but if you want to move, then set a bit, wait for a bit, move some more, set another bit, wait for another bit, move again, etc, you need better I/O in g-code
I suppose they're generic enough for most G-code, but you can't really make a specialized M-code with them, because there aren't 100 sets of M-code request/done pins
[17:38:01] <jepler> http://emergent.unpy.net/files/sandbox/hallelujah-shaped-component.png
how does it work?
is the shape info contained in the component?
there's a look-up file in the python program which finds the shape
it's based on the component name
anything not in the table becomes a rectangle?
how does it decide which pins go where?
it can place them freely, so I guess you'd say it's in the shape description
but in the two I've implemented so far, the logic is shared with the rectangular components, but the output side is offset
I don't follow
the shape description says "put in0 above in0" etc
in0 above in1 that is
that's whatever order comes from halcmd, actually
for the ones you've done so far its a no-care
as long as its consistent
actually, for the comparator, one input is inverting and one is non-inverting
someday the shape might have a + and -, I guess you draw the shape to match the ordering from halcmd
I haven't gotten around to putting the "+" and "-" in the symbol
you have a whole programming language to decide what to do
understood the + and - not in there
dunno what your last statement meant
is the shape a chunck of code that can draw anything? or a series of vertex coords that can draw one and only one polygon, or something in between?
you can write a bit of Python code that says: when you see something that starts 'ddt.' then invoke this code to draw it
corners, pins, and drawing instructions are all in pixel coordinates?
or is there a coarser grid for part placement, pins, and such?
and the canvas size is the window? or bigger with scrolling?
a somewhat coarser grid for placing blocks and pins might be nice (but thats a refinement, not a core item)
yeah, agreed on both counts
* jmkasunich goes back to pounding dowels into holes
hey a stepgen fix!
is that what was causing the jump after an estop?
sounds like it
at least thats what MichelG found
you'll put it in v2_0_branch too then?
it would have showed up instantly if I ever disabled stepgen0 while leaving stepgen1 on
yeah I can do that
did you release 2.0.4 yet?
I haven't merged the toolchange fixes either