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