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