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