Back
[01:50:27] <petev> I have an idea for the new architecture
[01:50:41] <SWPadnos_> noooooooooooo! ;)
[01:50:43] <petev> we can make it run with the current EMC without much trouble
[01:51:14] <jmkasunich> * jmkasunich runs away
[01:51:15] <petev> on the UI side, it shouldn't be too bad to make an NML server with the same interface as the RPC server stub
[01:51:30] <petev> then we can link against the RPC server or NML server
[01:51:38] <jmkasunich> these discussions are incredibly interesting and stretch my mind - feels goos
[01:51:40] <jmkasunich> good
[01:51:45] <jmkasunich> but also a terrible time sink!
[01:51:55] <petev> on the motion side, I can make several canonical machine derivations
[01:51:56] <petev> most of the code will be in the base class
[01:52:13] <petev> I will make a debug version, SHMEM version, and NML version
[01:52:36] <petev> this way we can completely replace task and all it's associated mess
[01:52:50] <petev> and it will be easy to remove the NML when desired
[01:53:09] <petev> I'm also thinking the lerman may be wasting his time
[01:53:25] <petev> I thought long and hard about g-code with subs, loops, etc.
[01:53:31] <cradek> I dare you to say this in front of ray...
[01:53:33] <petev> I don't think it's the way to go
[01:53:47] <petev> most people use CAM SW and that takes care of it
[01:53:49] <cradek> petev: he seems really determined
[01:54:04] <petev> thre doesn't seem to be any standard for it, so it will have to be hand coded
[01:54:15] <cradek> petev: but I don't use his changes because if I want to program loops or subroutines, I know a half dozen other languages that are better for it than gcode
[01:54:15] <petev> I think it's best to just have another interp option
[01:54:25] <petev> yes
[01:54:46] <petev> I'm thinking we pick one, like forth ;-), and make another interp for it
[01:54:55] <cradek> I hear people [ray] say that g-coders aren't programmers
[01:54:59] <cradek> he says it about himself too
[01:55:03] <petev> right
[01:55:08] <cradek> but then he'll spend hours figuring out g-code loops and subs
[01:55:14] <petev> so let's no muck the g-code up with non-standard stuff
[01:55:17] <cradek> which are the most obtuse kind of programming imaginable
[01:55:30] <petev> let's use a real language that is already defined for that
[01:55:40] <cradek> well that's what I think too.
[01:55:48] <petev> I got a scanner/parser running last night with flex/bison
[01:55:59] <petev> but I'm totally disgusted with the C++ support
[01:56:06] <cradek> jepler put a "filter" in axis
[01:56:09] <petev> I'm working on an antlr version today
[01:56:17] <petev> it looks very promissing
[01:56:23] <petev> what kind of filter?
[01:56:26] <cradek> you can use any program to take pseudo-g-code and output g-code
[01:56:38] <petev> that would work too
[01:56:40] <cradek> for instance we wrote a path optimizer that takes cues from (comments)
[01:56:44] <cradek> but you could use m4
[01:56:47] <petev> maybe run these other languages in the GUI
[01:56:50] <cradek> or python or lisp or anything
[01:56:54] <petev> yes
[01:57:04] <petev> I think that makes much more sense
[01:57:06] <cradek> the only drawback is the emc gui doesn't show the same thing you edit
[01:57:20] <petev> every control I looked at that had subs or loops did it different
[01:57:21] <cradek> (it only shows its output)
[01:57:46] <petev> I'm going to architect the interp so it can be changed on the fly
[01:57:51] <petev> we can experiment
[01:58:07] <cradek> I don't hand-write any but the simplest g-code; I don't see why anyone would want to
[01:58:12] <petev> I'm still not sure how the GUIs can be generic though
[01:58:15] <petev> agreed
[01:58:25] <petev> I never write g-code by hand
[01:58:35] <petev> the GUIs are line oriented because of g-code
[01:58:52] <petev> not sure how other languages will fit this unless we limit them
[02:00:31] <cradek> fit what?
[02:00:48] <petev> fit the line oriented ness of g-code
[02:01:03] <petev> may get a bit ugly if the GUI is not aware of the language
[02:01:10] <cradek> well it's already messed up with subroutines
[02:01:23] <petev> yeah, I'm totally ignoring that branch
[02:01:27] <cradek> ok
[02:01:30] <petev> hope it never gets merged
[02:01:51] <cradek> I suspect it will...
[02:01:54] <petev> it may be possible to make the filter idea work
[02:02:03] <petev> kinda like the #line directives
[02:02:04] <cradek> I think it's unneeded, but I don't see it as harmful
[02:02:22] <petev> the GUI could map back to the source if the filter supported it
[02:02:30] <SWPadnos_> one of the things that lerman wants is a "teach mode"
[02:02:51] <petev> not harmfull in the current EMC, but I don't want to re-implement the subs in the new stuff
[02:02:53] <SWPadnos_> loops and subs are excellent, expecially if you can take canned "macros" that use them, and make parts
[02:03:11] <petev> yes, but why not do that with a real language?
[02:03:18] <SWPadnos_> because machinist aren't programmers
[02:03:20] <petev> that's where all the comercial controls are going
[02:03:27] <SWPadnos_> consider a learning interface
[02:03:28] <cradek> SWPadnos_: scroll back a bit
[02:03:34] <SWPadnos_> I read back
[02:03:46] <cradek> machinists who write g-code ARE programmers
[02:03:51] <petev> swp: but labels, etc. are much more friendly
[02:03:57] <cradek> if they can make an arc, they can write a loop or subroutine in a HLL
[02:04:03] <petev> g-code is a nightmare for subs and loops
[02:04:19] <jmkasunich> cradek: machines who write G-code are not trained as programmers, nor do they think like programmers
[02:04:26] <jmkasunich> even tho they might be programming
[02:04:54] <cradek> jmkasunich: I don't understand the distinction you're trying to make
[02:05:02] <petev> jmk: but if they can learn loops and subs in g-code (which I see no standard) they can surely do it in a real language
[02:05:03] <cradek> jmkasunich: take a thought experiment with me:
[02:05:13] <SWPadnos_> sure, but a dialog to create a bolt pattern can make it very easy, and though I realize it could just write 17 copies of the same code, it would be nicer if it could output sub calls to do the threading, for instance
[02:05:30] <cradek> jmkasunich: we have a g-coder who wants to write a loop. he already knows g-code but not looping in g-code
[02:05:38] <petev> swp: so use the alternate programming language interface
[02:05:42] <cradek> jmkasunich: the way I see it, he can do that one of several ways
[02:05:43] <petev> why force g-code?
[02:05:50] <SWPadnos_> no - the machinist says - I want holes spaced 1 inch apart, over this 12x14 inch area
[02:06:03] <cradek> jmkasunich: he can use a HLL or he can learn the g-code way, which is very cryptic
[02:06:11] <SWPadnos_> it's step and repeat to a machinist, not a loop
[02:06:11] <jmkasunich> you guys are thinking like programmers
[02:06:41] <jmkasunich> I bet 50+% of the machinests won't even wonder if there is a better way, they'll just brute force it
[02:06:47] <cradek> SWPadnos_: ok, now he wants to make them in a circle of radius 1 every 10 degrees
[02:07:01] <cradek> SWPadnos_: now is it a loop?
[02:07:02] <SWPadnos_> step and repeat, but in a circular pattern
[02:07:14] <cradek> SWPadnos_: so we're going to put that in the g-code interpreter too?
[02:07:24] <SWPadnos_> you and I know it's a loop, but the machinist doesn't think of it that way
[02:07:40] <cradek> SWPadnos_: so what?
[02:07:48] <cradek> SWPadnos_: he can call it whatever he wants
[02:07:55] <SWPadnos_> so - emc is for machinists and machine operators to ise
[02:07:59] <SWPadnos_> use
[02:08:04] <SWPadnos_> not just programmers
[02:08:12] <SWPadnos_> unless that's not important
[02:08:22] <jmkasunich> if he wants a bolt hole circle, he'll open machinerys handbook to page 958 and enter the coordinates from the tabke
[02:08:25] <jmkasunich> table
[02:08:49] <cradek> jmkasunich: ok, now he wants a spiral
[02:09:02] <jmkasunich> he'll use CAD for that
[02:09:16] <jmkasunich> machinists are not programmers, they are not math experts
[02:09:47] <jmkasunich> they aren't gonna write a formula for spiral hole patterns and evaluate it for different values of R and theta
[02:10:04] <cradek> if they are not programmers, why do we need loops and subs in the interpreter? they can't understand how loops and subs work.
[02:10:12] <jmkasunich> and they aren't gonna write a g-code program that does that either
[02:10:30] <jmkasunich> 50_% of them don't want loops and subs in the interp
[02:10:36] <jmkasunich> 50+
[02:11:22] <jmkasunich> many cases that do want them will be calling subs that somebody else wrote, without much understanding of the fact that it is a sub
[02:11:30] <jmkasunich> its just another canned cycle to them
[02:11:45] <jmkasunich> g84 or whatever
[02:12:23] <SWPadnos_> actually, they do understand subs - it's "move to here, and put one of these at this location"
[02:12:36] <SWPadnos_> not "call fancy_shape()"
[02:12:45] <jmkasunich> right
[02:13:08] <cradek> I must have some brain lock here
[02:13:27] <cradek> I cannot understand why having something written in g-code (with its obtuse numbered variables and Onnn subroutines) makes it not programming
[02:13:34] <jmkasunich> you are designing an interpreter for programmers
[02:13:41] <cradek> I cannot understand this distinction
[02:14:00] <jmkasunich> just like I have been accused of desiging a control system (HAL) for engineers instead of integrators ;-)
[02:14:16] <jmkasunich> I never said it wasn't programming
[02:14:27] <jmkasunich> I said they aren't programmers
[02:14:32] <jmkasunich> there is a difference
[02:14:37] <cradek> can they learn it?
[02:14:47] <jmkasunich> ask Ray if he considers himself a programmer
[02:14:51] <cradek> I know he doesn't
[02:14:59] <cradek> BUT he can figure out the obtuse g-code subroutines - I saw him do it
[02:15:06] <jmkasunich> but he wrote tkemc, isn't that programming?
[02:15:13] <cradek> yes, it is
[02:15:17] <cradek> so what he says makes no sense
[02:15:29] <cradek> and because of it, I don't understand it
[02:15:33] <cradek> even though people repeat it constantly
[02:15:51] <SWPadnos_> I have a story for you
[02:15:54] <jmkasunich> there are concepts that you have been immersed in for many years
[02:15:58] <jmkasunich> you take them for granted
[02:16:03] <jmkasunich> non-programmers don't
[02:16:20] <SWPadnos_> I can't understand m4, and I'm a programmer by nature ;)
[02:16:23] <jmkasunich> they may figure out incredibly creative ways to make the machine do what they want,
[02:16:32] <SWPadnos_> I sure wouldn't want a machinist to have to use it
[02:16:40] <cradek> no, m4 sucks
[02:16:44] <jmkasunich> but that doesn't mean they are comfortable with the concepts
[02:16:49] <cradek> it's at least as obtuse as g-code
[02:16:54] <SWPadnos_> at least ;)
[02:17:29] <cradek> I've lost track of what we were originally talking about
[02:17:39] <SWPadnos_> we had a machinist who actually manually created an entire alphabet font in G-code subroutines
[02:18:17] <SWPadnos_> he would use some DOS editor, and load up any of the subs he needed (they had to be in the same file)
[02:18:27] <jmkasunich> we were talking about the applicibility of programming concepts for people who aren't really programmers
[02:18:54] <SWPadnos_> he would then use a series of blocks like "move to X,Y, call sub E, move X Y, call sub N", etc
[02:19:08] <cradek> SWPadnos_: that's programming, right?
[02:19:20] <SWPadnos_> yes, and that's ewhy subs should be in G-code
[02:19:25] <SWPadnos_> and loops
[02:19:28] <cradek> SWPadnos_: but could he do that same thing in a HLL?
[02:19:39] <jmkasunich> he'd have to learn the HLL first
[02:19:47] <SWPadnos_> he would make multiple parts by doing step-and-repeat on an entire part program
[02:19:48] <cradek> exactly, just like he had to learn "call sub N"
[02:19:50] <cradek> in g-code
[02:19:52] <jmkasunich> he learned g-code incrementally by using it
[02:20:06] <jmkasunich> your HLL will make him start over at square 1
[02:20:15] <SWPadnos_> I don't remember the exact syntax - this was a Bridgeport CNC
[02:20:30] <cradek> no, his program will look like g-code with some extra bits.
[02:20:42] <jmkasunich> then it is extended g-code, not a HLL
[02:20:50] <SWPadnos_> and no - he needed our help to connect the serial cable from his computer so he could drip-feed the CNC
[02:20:57] <jmkasunich> or are we quibbling over definitions?
[02:21:05] <cradek> I don't know
[02:21:13] <SWPadnos_> we probably are, but the original comment was that G-code shouldn't have subs or loops
[02:21:40] <cradek> in summary, I think if we need subs and loops, we should do them in a way that's not obtuse.
[02:21:40] <SWPadnos_> petev pointed out that every control he's used with those feeatures was different
[02:21:46] <cradek> we already all agree that there is no real standard
[02:21:53] <SWPadnos_> which I take to mean "every high level control has these features"
[02:21:56] <jmkasunich> I think there will be demand for extended g-code, and demand for a more formal HLL, but from two different groups of people
[02:21:58] <petev> talking to roltek about this now
[02:27:21] <SWPadnos_> note that G-code control statements don't preclude the use of another HLL to generate basic G-code
[02:27:36] <cradek> that's right
[02:28:27] <SWPadnos_> I'm under the impression that lerman's changes don't alter how "standard" g-code works, is that incorrect?
[02:28:32] <cradek> I was thinking that when I made my original comment about these changes being unnecessary but harmless
[02:28:46] <cradek> SWPadnos_: I think he does break some potentially-existing programs
[02:28:47] <SWPadnos_> ah - I may have skimmed over that one ;)
[02:28:55] <SWPadnos_> or is that the RUM changes?
[02:29:02] <cradek> SWPadnos_: not sure.
[02:49:07] <petev> boy, I started a storm over here
[02:49:21] <petev> Todd says there isn't much standard for the subs and looping
[02:49:43] <petev> he says most subs are done as separate programs and called up by program number
[02:50:03] <petev> He thinks Fanuc is the most widely known control
[02:50:05] <SWPadnos_> hm - that's doable, I think
[02:50:24] <petev> He says that's why guys don't want more than 1 control type in their shop
[02:50:31] <petev> too much learning curve
[02:50:59] <petev> he also says that his Fanuc does not let you re-start in the middle of a loop
[02:51:18] <petev> he says he has to use the editor and make mods before re-start for that
[02:53:46] <SWPadnos_> ok - that's a good baseline to start from
[02:54:05] <jmkasunich> we need to be capturing this stuff somewhere
[02:54:10] <SWPadnos_> I see no reason to restrict ourselves to the same caveats that other controls have though
[02:54:18] <SWPadnos_> the logger is doing so ATM
[02:54:37] <jmkasunich> ok
[02:55:08] <petev> I also asked about the way EMC will take a word like G, followed by an expression
[02:55:08] <petev> he said no way
[02:55:23] <petev> there are limited places where expressions are allowed
[02:55:30] <petev> what do you guys think of that?
[02:55:32] <cradek> #12=1
[02:55:35] <cradek> G#12 x1
[02:55:38] <cradek> emc does this?
[02:55:53] <petev> has anybody actually tried something like GSQRT2 ?
[02:56:10] <SWPadnos_> GSQRT[4] maybe ;)
[02:56:11] <petev> cradek: according to the docs, it's supposed to take this kind of stuff
[02:56:25] <cradek> wow/yikes
[02:56:41] <petev> yeah, sqrt 2 would be a valid g code, but it should parse it happily
[02:56:46] <SWPadnos_> that can be useful, but not necessarily to a machinist ;)
[02:56:49] <petev> would not
[02:56:55] <SWPadnos_> right
[02:56:59] <petev> sounds scary to me
[02:57:09] <cradek> just sounds silly to me
[02:57:15] <petev> you can acutally include param re-calls in there too
[02:57:22] <petev> even indirect param recalls
[02:57:46] <petev> so is this stuff I should scrap in the new grammar?
[02:57:50] <SWPadnos_> can you do #[#27]?
[02:58:02] <petev> yes, and don't need the []
[02:58:04] <SWPadnos_> actaully - that's really useful
[02:58:07] <petev> just ##27
[02:58:12] <cradek> petev: you're writing a new grammar?
[02:58:13] <SWPadnos_> cool - that's great
[02:58:31] <petev> I wrote a grammar from what Kramer's doc said EMC does
[02:58:33] <petev> already done
[02:58:38] <SWPadnos_> bad for people with bouncy keyboards though
[02:58:50] <petev> implemented in flex/bison, but nasty C++ support
[02:58:59] <petev> porting to antlr now and looks promissing
[02:59:11] <cradek> petev: what's your eventual goal?
[02:59:17] <SWPadnos_> so - you mean that flex/bison output crappy C++?
[02:59:50] <petev> I want to replace EMC task, interp, etc with a new emc task, an interp object, and a canonical machine object
[02:59:58] <petev> I want to fix all the world view issues
[03:00:15] <petev> adn clean up all the bypassing of canonical for machine stuff
[03:00:32] <cradek> that sounds exciting and scary
[03:00:37] <petev> I also want to partition stuff properly and use one format for config files, XML
[03:00:45] <petev> the current code is scarry
[03:00:54] <petev> it isn't really that bad
[03:01:04] <petev> I also want to fix the interp re-start problems
[03:01:05] <cradek> please tell me you're joking about xml
[03:01:10] <petev> no
[03:01:25] <petev> xml is for describing data, what don't you like about it?
[03:01:36] <SWPadnos_> for a really good time, mention XML with Jymmm in the chat :)
[03:01:40] <cradek> it's unsuitable for editing by humans
[03:01:45] <petev> I hate the way config code is scattered all over
[03:01:47] <cradek> humans write the config files
[03:02:01] <petev> not really, depends on the DTD
[03:02:15] <petev> and there are editors to make it nice, and heirachy to make it nicer
[23:38:08] <SWPadnos_> hi jmk
[23:38:23] <jmkasunich> hi
[23:38:31] <jmkasunich> back in a couple mina
[23:38:34] <jmkasunich> mins
[23:38:36] <SWPadnos_> ok
[23:46:23] <jmkasunich> * jmkasunich is back
[23:46:38] <jmkasunich> didja read Rays latest
[23:47:06] <jmkasunich> he's trying to make us stop acting like a bunch of hobbyists and treat emc as a product
[23:47:48] <SWPadnos_> heh - bastard - he'll probably be President soon ;)
[23:48:00] <jmkasunich> nah
[23:48:27] <jmkasunich> Alex suggested him as board president, and he declined, claiming that he is to argumentative for that job
[23:48:41] <SWPadnos_> heh
[23:49:00] <SWPadnos_> then I guess it's up to you :)
[23:49:33] <jmkasunich> I replied that we need to define the role of president, then pick the board member who best fits the definition
[23:49:44] <jmkasunich> if he's supposed to be a mediator, it isn't ray
[23:49:47] <SWPadnos_> top-down design again
[23:50:00] <jmkasunich> if he's supposed to be a muckraker, Ray's the dude
[23:50:17] <jmkasunich> muckraker probably isn't the right word
[23:50:24] <jmkasunich> stirrer-up of things
[23:50:34] <SWPadnos_> eh - close enough (hellraiser would be a little extreme)
[23:50:43] <jmkasunich> fits tho
[23:50:49] <SWPadnos_> so - got a problem with ppmc stepgens
[23:51:15] <jmkasunich> hi, I'm new here
[23:51:24] <SWPadnos_> hi - how do you like IRC?
[23:51:27] <jmkasunich> could someobody tell me about emc
[23:51:52] <jmkasunich> ok, whats the problem....
[23:51:52] <SWPadnos_> yes, it's a program that doesn't work, and too many people are spoiling the broth
[23:52:01] <SWPadnos_> the frequency is wrong
[23:52:12] <SWPadnos_> as measured by an oscilloscope
[23:52:27] <jmkasunich> I measured it here and it was OK
[23:52:34] <SWPadnos_> hm
[23:52:42] <jmkasunich> gimme a sec to power it up, maybe I missed something
[23:52:48] <SWPadnos_> for low frequencies, it's pretty close
[23:52:57] <SWPadnos_> higher frequencies are way off
[23:53:17] <SWPadnos_> I thought at first that it might be the pulse width getting added to the frequency count
[23:53:24] <jmkasunich> scope is warming up
[23:53:26] <SWPadnos_> but that doesn't seem to be it
[23:53:29] <SWPadnos_> ok
[23:54:14] <SWPadnos_> also - the setup time probably shouldn't be related to the pulse width - it's a reversal or direction change setup time
[23:54:43] <SWPadnos_> or a dir change -> step pulse delay
[23:55:59] <jmkasunich> ok, got it running
[23:56:04] <jmkasunich> what freq are you testing?
[23:56:19] <SWPadnos_> try something in the MHz range
[23:57:10] <jmkasunich> how many MHz
[23:57:15] <SWPadnos_> 1
[23:57:50] <jmkasunich> hmm, 715KHz
[23:57:56] <SWPadnos_> ok - same as me
[23:58:05] <SWPadnos_> (714 KHz)
[23:58:12] <jmkasunich> maybe I'm rounding the wrong way....
[23:58:19] <jmkasunich> look at the freq parameter
[23:58:47] <SWPadnos_> actually - it's calculating the divisor correctly - I added the divisor as a param
[23:58:48] <jmkasunich> ok, that is spitting out the right thing
[23:59:06] <jmkasunich> IOW, yet another case where Jon's hardware and Jon's docs don't match
[23:59:12] <SWPadnos_> could be
[23:59:15] <SWPadnos_> well - is
[23:59:41] <SWPadnos_> I'm fiddling around with the setup and pulse width params, to see if they make a difference
[23:59:42] <jmkasunich> looks like its dividing by 14 instead of 10