Back
[00:00:43] <fenn_> say i have a gui written in python and i want to edit "preferences"
[00:00:53] <fenn_> does that involve stylesheets at all?
[00:01:03] <petev> I wouln't think so
[00:01:12] <petev> you would use a parser object
[00:01:27] <petev> you have the object open the file and then operate on it
[00:02:56] <fenn_> then display each little thing with widgets and objects that contain widgets?
[00:03:18] <petev> yes, that's what I would think for the custom GUI
[00:03:31] <fenn_> ok, changing gears..
[00:03:33] <petev> or we just use the tree based editors in the mean time
[00:03:54] <fenn_> i'm trying to get at your "grand scheme"
[00:03:59] <petev> ok
[00:04:23] <fenn_> are you planning on using xml for all data passing between the various modules of emc?
[00:04:30] <petev> no
[00:04:31] <petev> my grand scheme would be something like this
[00:04:42] <petev> there is a task object
[00:05:02] <fenn_> or more than one task objects?
[00:05:08] <fenn_> (on different machines)
[00:05:09] <petev> there are various types of servers for connecting to task
[00:05:17] <petev> no, just one task object
[00:05:33] <petev> we would have an NML server (yuk), and RPC server, etc.
[00:05:49] <petev> the servers are just wrappers to the API for remote access
[00:06:07] <petev> task would open the config tile
[00:06:19] <petev> it would create a parser object and load all the config
[00:06:42] <petev> task would then pass this parser object to the other objects in the system to init them
[00:07:11] <petev> there would be an interpreter object and a canon object at a minimum in user space
[00:07:31] <petev> task talks to both the interpreter object and canon object
[00:07:43] <petev> anything that the machine can do, goes through canon
[00:07:51] <petev> canon is basically a model of the machine
[00:08:29] <petev> jmk put together a drawing that shows some of the peices of this with remote interfaces, HAL, etc
[00:08:40] <fenn_> what happens when you edit the config file when the machine is running?
[00:08:54] <petev> I didn't really want to post it anywhere until there was some running code
[00:09:01] <petev> that is a good question
[00:09:20] <petev> right now a lot of the stuff gets used in HAL and you need to re-load the modules
[00:09:44] <fenn_> right because all the parameters are insmod arguments
[00:09:44] <petev> some of this is hard to get around as things can be passed at insmod time
[00:09:49] <petev> yes
[00:10:02] <fenn_> that needs fixin too
[00:10:15] <petev> also, most of hte config info gets loaded into internal vars and the config file never gets looked at again
[00:10:31] <fenn_> you mean currently? or thats the ideal case?
[00:10:40] <petev> so if we want changes to take place real-time, we have to re-architect a lot of stuff
[00:11:02] <petev> currently most of the info gets loaded at init
[00:11:16] <petev> u can change the file without effect until u re-start emc
[00:11:30] <fenn_> yeah it's pretty annoying
[00:11:37] <petev> I don't know if this is good or bad per say
[00:11:51] <petev> if you're tuning PID, I guess it's a pain
[00:11:51] <fenn_> i can see cases where you would want things to stay put
[00:11:57] <petev> yes
[00:12:04] <fenn_> like estop override configuration for example
[00:12:10] <fenn_> dont want a suit disabling your override
[00:12:21] <fenn_> er, enabling their override i mean
[00:12:25] <petev> yes, there are a lot of things that might be dangerous to change while running
[00:12:38] <petev> some stuff an end user shouldn't even be allowed to change
[00:12:53] <petev> most of the stuff in HAL I don't think a user should be able to touch
[00:13:01] <petev> that stuff is for the integrator
[00:13:09] <fenn_> the gui doesn't have to be run as root, so it could be done with file permissions
[00:14:05] <petev> perhaps, but it might be better to build in some other mechanism
[00:14:37] <petev> I think if the changes are too radical, they will be rejected
[00:14:49] <fenn_> thats too bad
[00:14:56] <petev> I think initially I probably have to make an NML server for task and an NML canon
[00:15:20] <petev> I would like to get rid on NML right away, but at least this way it's contained
[00:15:26] <petev> on/of
[00:15:48] <fenn_> with what you're describing it would really be more of "support for legacy gui's" than anything
[00:16:42] <fenn_> and the old interpreter
[00:17:11] <petev> yes
[00:17:21] <petev> the old interp, I don't know about
[00:17:36] <petev> that code is pretty messy and I don't know how to support it
[00:17:45] <petev> just sent u an email
[00:18:01] <petev> has some of the files with ideas we have discussed
[00:18:06] <fenn_> who is "we" anyway?
[00:18:19] <petev> me and a few other guys
[00:18:25] <fenn_> aw crap an ms word document?
[00:18:30] <lerman> My understanding is that the reason hal has to get this stuff at init is that it runs as kernel modules and they can't do file I/O worth a damn.
[00:18:32] <petev> kwrite
[00:18:48] <petev> lerman, very true
[00:19:02] <petev> but we have also discussed other methods to pass params to HAL code
[00:19:15] <petev> we don't want the HAL code to do file IO
[00:19:21] <lerman> I think I would put up a hunk of shared memory that it could access and let a user space 'thing' change the shared memory which hal could read.
[00:19:31] <lerman> petev is correct.
[00:19:42] <petev> the SHMEM is touchy
[00:19:58] <petev> I don't know how much u know about security and integrity
[00:20:03] <petev> but let me try this
[00:20:09] <lerman> That's what I've heard, but I don't know why.
[00:20:32] <petev> if the kernel code depends on data from user space, it's integrity can be no greater
[00:20:35] <lerman> AFAIK, shmem does have associated permissions.
[00:20:48] <petev> this is one of the things we want to fix with the current HAL
[00:20:55] <petev> no pointers in the SHMEM
[00:21:10] <lerman> Yup. You type faster than I do.
[00:21:16] <petev> we want to separate the HAL meta data into separate kernel mem
[00:21:52] <petev> to do a lot of this means re-writes to much of the HAL utils
[00:21:59] <petev> a HAL lib is in order
[00:22:08] <petev> also, we need a HAL server thread
[00:22:31] <petev> this is a bit of a problem with RTLInux right now as far as implementation
[00:22:32] <lerman> I built a hal like system around 35 years ago (using an Intel 8080) for a RT general purpose controller. Did analog, digital, pid, etc.
[00:22:56] <lerman> Why is that?
[00:23:06] <petev> BTW, what apporach did u take with the subs and loops?
[00:23:25] <petev> RTLinux doesn't have user/RT mutex or sem as far as we can tell
[00:23:37] <petev> they are RT only
[00:24:10] <petev> I would just scrap RTLinux, but cradek uses it and he's the chair ;-)
[00:24:18] <lerman> What did you mean by: BTW, what apporach did u take with the subs and loops?
[00:24:32] <petev> in implementation
[00:24:58] <lerman> What would you use instead of RTLinux? In implementation of what? (the interpreter changes?)
[00:25:05] <petev> did u add data structs to hold the loops, or do u re-read the file, etc.?
[00:25:16] <petev> most of us are using RTAI
[00:25:26] <petev> RTLinux got to commercial
[00:25:39] <petev> they patented stuff a caused a big fuss
[00:25:56] <lerman> Ahhh. I saved the position in the file (using ftell) and went back there (using fseek).
[00:26:16] <petev> ok, what about for the subs, same thing?
[00:26:21] <lerman> Then reparse the file from that point.
[00:26:28] <lerman> Same thing.
[00:26:40] <petev> ok, that should be fairly easy to do
[00:26:51] <petev> I started a new interp is why I ask
[00:27:03] <petev> I wanted to clean up the code and fix some other issues
[00:27:09] <lerman> It was. I did the whole thing in my spare time while I was on vacation in the Virgin Islands.
[00:27:17] <petev> cool
[00:27:23] <petev> have u used ANTLR?
[00:27:35] <lerman> Well, the code could sure use a clean up. What's ANTLR?
[00:27:54] <petev> its a top down LL(k) parser/lexer generator
[00:28:09] <petev> I used it for the new interp and it's nice
[00:28:26] <petev> I use the C++ output and it builds nice parser and lexer objects
[00:28:29] <lerman> Yuck. I generally hate the things -- YACC is a bitch to handle errors, etc.
[00:28:46] <petev> no, YAC is LALR(1), it's bottom up
[00:28:48] <lerman> Generally I've hand generated recursive descent parsers.
[00:28:59] <petev> top down LL(k) is much the way you code by hand
[00:29:07] <petev> you would be very happy with it I think
[00:29:10] <lerman> I don't have any problem with lex, though.
[00:29:28] <petev> if you hand generate, ANTLR automates that for u
[00:29:36] <lerman> Next time I need one, I'll take a look.
[00:29:45] <petev> forinstance, u get a method for each production in the grammer
[00:30:00] <petev> you can call any method to start parsing from there
[00:30:20] <lerman> I've pretty much concluded that the Macfarlane paper would be a decent way to go for TP...
[00:30:32] <petev> I started with YACC, but decided it wasn't going to be good for what we needed
[00:30:47] <petev> I still don't fully understand that paper
[00:30:54] <petev> josh posted about 5 more today too
[00:31:29] <petev> ANTLR will take EBNF and K can be whatever u want so it's pretty good
[00:31:59] <lerman> Well, I'm not much of a C++ person -- I much prefer Objective-C. I don't fully understand it, but I made it to the end and have started over. One key thing is that is can work in task (cartesian) space or in joint space -- and switch from one to the other (although it does stop in between).
[00:32:41] <fenn_> the interp can do stuff in joint space?
[00:32:47] <petev> yeah, I think we need to make a chart of the goals, then talk high level algorithms
[00:32:53] <lerman> Gee-- I seem to recall writing something that took a generic language description and wrote the methods.
[00:32:58] <petev> diving into the weeds and math, I get lost
[00:33:25] <lerman> No, the interp can't, but the Mcfarlane paper can.
[00:33:29] <petev> www.antlr.org
[00:33:40] <petev> I was very impressed, first time I used it
[00:33:52] <petev> always used YAAC, bison, etc. before
[00:33:58] <petev> or hand coded
[00:34:32] <petev> it does the lexer the same as the parser, but the tokens are the input chars
[00:34:41] <petev> it's nice, you put both in the same file
[00:34:48] <petev> also has code for AST
[00:34:49] <lerman> YACC is a bitch. Hand coded has worked well for me. I once worked on an Objective-C compiler that was hand coded.
[00:35:29] <petev> I don't mind YACC, but like you say, it's not good for error recovery or when you want to drive the parsing for a line at a time type stuff
[00:36:03] <lerman> I always wondered why the lexer should be separate from the parser. I concluded that there are some special algorithms that can make the lexer faster -- the actions are pretty much two types for a lexer.
[00:36:47] <petev> I can send u what I have if u want to take a look. It's not done, but u could get an idea of what's invlolved
[00:36:56] <lerman> There is residual code in the interp (not sure if it is in emc2) to show the locations of errors. I wrote it to help myself debug the interp changes.
[00:37:21] <petev> u don't mean that stack/name stuff do u?
[00:37:32] <lerman> Yeah -- I'm always interested in looking at other people's code. Although these days I'm more of a machinist than a programmer.
[00:38:16] <lerman> Yuck. No. I wrote something to keep track of the input line and output it on a parse error together with a line below it containing a pointer to the offending character.
[00:38:43] <petev> ok
[00:38:49] <lerman> Whoops -- that came out wrong. The error line would be output.
[00:41:13] <petev> ok, just sent you a tar ball
[00:41:38] <lerman> Last night we were talking about an approach that made sure it could stop within the look ahead distance. The Macfarlane paper does that. (I hadn't read that far at the time I suggested it). Mcfarlane puts the stop into place and then changes it as the lookahead determines that it isn't necessary. Also, Macfarlane is "on line" .
[00:41:43] <lerman> Thanks.
[00:41:46] <petev> the rs274ngc.g is the ANTLR input
[00:42:33] <petev> yeah, but did u understand all the math and her algo from the g-code input? It wasn't clear to me
[00:42:36] <lerman> Got it.
[00:42:42] <petev> although I'm not done reading either
[00:42:45] <fenn_> as far as on-line vs off-line trajectory planning, i think we should do both
[00:42:58] <petev> I think on-line is the first goal
[00:43:00] <fenn_> i.e. if there is no offline trajectory available, generate one online
[00:43:10] <petev> off-line for better performance should be secondary
[00:43:52] <lerman> There is a limit to how far a look ahead would be useful. Just make the look ahead length user settable -- either in inches or in segments.
[00:44:20] <fenn_> lerman you cant think of look ahead in terms of inches
[00:44:24] <petev> seems like the TP only needs to look ahead enough untill it can reach the desired velocity
[00:44:31] <lerman> Actually, looking ahead a given number of seconds might be better.
[00:44:35] <petev> so user should only need to spec velocity
[00:44:51] <fenn_> you have to think of lookahead in terms of segments or the calculation becomes unbounded
[00:45:03] <lerman> Reaching the velocity, isn't the issue -- stopping in time is the problem -- or slowing down enough.
[00:45:15] <petev> fenn: correct, but u bound it by slowing the velocity to the look ahead that u have
[00:45:43] <fenn_> how do you do that in 1 msec
[00:46:00] <petev> lerman: the velocity would be the min of g-code spec, or what is allowed by look ahead
[00:46:15] <lerman> No, it doesn't become unbounded because it is still done by looking at a few segments at a time. So, if you are stopped, you can look head a few hundred segment, queue them up and you are set to go in RT.
[00:46:36] <petev> there are 2 issues here
[00:46:52] <petev> how big the Q is and how much look ahead the TP has to process
[00:47:11] <petev> the TP doesn't need to look at more than is required to reach the desired velocity
[00:47:19] <petev> any more is a waste of CPU cycles
[00:47:39] <lerman> Well, the Q size impacts the latency. No, not a waste, because the info is saved for later.
[00:48:00] <petev> having the TP process more than is needed is the waste
[00:48:24] <petev> to use the driving example, I don't need a mile of visibility to do 10 MPH
[00:48:27] <lerman> The TP must process enough to know that at its current speed it can stop before it goes off the road.
[00:48:33] <petev> yes
[00:48:46] <petev> any more is a waste
[00:48:59] <petev> if the current speed is the desired speed
[00:49:23] <lerman> No, because the points added to the end are eventually used.
[00:49:36] <petev> ahh, but thats the Q, not the TP
[00:49:46] <lerman> Well, it DOES waste Q space -- but that's essentially free.
[00:50:13] <petev> yes, and I think the user space code should just run until there are no more buffers
[00:50:33] <lerman> BTW: the macfarlane paper DOES let the user specify 'tightness' -- how close a fit there is at the blend points.
[00:50:45] <petev> that's nice
[00:50:58] <lerman> There is no such thing as no more buffers when you have all of swap space available.
[00:51:08] <fenn_> why dont academic people ever publish any source code?
[00:51:13] <fenn_> we would be done by now
[00:51:14] <petev> no, right now there is a pool of buffers
[00:51:17] <lerman> Unless you mean that someone should specify how much buffer to use.
[00:51:22] <petev> it's not malloc type stuff
[00:51:46] <lerman> They don't publish it because someone funds the research and they wind up owning it.
[00:51:53] <petev> fenn: true
[00:52:19] <petev> or maybe it's all theory and no implementation
[00:52:29] <fenn_> no there are videos of a robot running that algorithm
[00:52:44] <petev> really, I didn't see any links to that
[00:53:15] <fenn_> http://batman.mech.ubc.ca/~ial/more.html
[00:53:45] <lerman> Well, the source isn't published, but macfarlane does show the performance versus an industrial implementation in the paper. The big difference is the fact that the accuracy is independent of requested speed. And it does not exceed specified constraints.
[00:54:27] <lerman> I believe that it is really quite good. I would certainly like to see it implemented.
[00:54:48] <fenn_> has anyone asked them for the source?
[00:54:59] <fenn_> i mean, maybe they just never published it because they are morons
[00:55:13] <lerman> The only concern I have is that macfarlane implemented on a DSP, I believe. I recall seeing a number like 480 multiplies per cycle.
[00:55:33] <petev> that might not be a big deal
[00:55:46] <petev> as long as we have the RT to do the calcs, we can re-code
[00:55:54] <fenn_> you have to switch a backslash to a forward slash to get those videos
[00:55:59] <lerman> I just checked the date -- 1999. So, it is 6 years old.
[00:56:49] <fenn_> in any case, someone besides me should write them.. i'm bad at that sort of thing
[00:57:27] <lerman> Hell, that's what a chairman of the board is for.
[00:57:43] <petev> I like the spilled drink demo
[00:57:46] <fenn_> yeah, or maybe another university professor
[00:58:16] <fenn_> you can see how ashamed the robot is
[00:59:51] <Jacky^> [JACK] cannot open server
[00:59:54] <Jacky^> arrrghhh
[00:59:57] <Jacky^> :(
[01:06:24] <lerman> petev: just looked at the grammar you wrote and didn't see GE, LE, LT, GT, EQ, NE. (Also the other new stuff I added.)
[01:06:55] <petev> no, I haven't seen you code, I went from kramers doc and fixe some stuff I did't like
[01:07:04] <lerman> But it sure looks simple. A lot nicer than not having a formal grammar.
[01:07:08] <petev> there was some nasties with expressions
[01:07:18] <petev> this grammer is a superset of kramer
[01:07:25] <petev> yes, it is simple
[01:07:35] <petev> I can add your stuff if I know what to add
[01:08:28] <CIA-12> 03jmkasunich * 10emc2/src/hal/utils/scope_vert.c: minor tweak to halscope vertical offset entry
[01:10:22] <lerman> Well, I got very lazy when I wrote this. I would like to add named labels. So: o this is a label: would be a legal o word. Remember that spaces are squished out and everything is down cased. I stick the colon in there to designate the end of an o_word. We could also add named registers. So #this is a register: would designate a named register.
[01:11:46] <petev> should there be some char for starting labels with to avoid confusion?
[01:11:57] <lerman> I'm still thinking about two problems with this: 1 -- How would we scope registers? If two subroutines used the same name, would they be the same register? 2 -- Right now, a label (o-word) can be passed as an arg.
[01:12:41] <lerman> The letter 'o' starts a label right now. The character # starts a register.
[01:12:47] <petev> are u saying u want the interp to assign the registers to params automatically?
[01:13:05] <petev> but # is for param access righ now
[01:13:39] <lerman> No. (or maybe yes) They wouldn't be params in the sense that they would not be written to files. But otherwise, they would act just like params.
[01:14:20] <petev> hmm, I think the whole idea of params is like registers, but they are non-volatile
[01:14:40] <petev> they get saved to file way too much now because of other issues
[01:14:55] <lerman> So, if in a main program, I wrote:
[01:14:57] <lerman> #foobar=7 and later in a subroutine, I wrote:
[01:14:58] <lerman> X#foobar, it would be equivalent to
[01:15:00] <lerman> X7
[01:15:40] <petev> right, but why not have to declare foobar first, at which time you would assign param storage for it
[01:16:32] <petev> to be honest, I would rather just make a whole new interp with different grammar for hand programming
[01:16:42] <petev> forceing hte g-code just gets ugly
[01:16:42] <lerman> But if inside the subroutine, I wrote:
[01:16:44] <lerman> #foobar=6,
[01:16:46] <lerman> There would be a new foobar scope defined and associated with that invocation of the subroutine (recursive subroutines would each get their own instance).
[01:16:48] <lerman> So, #xxx= declares the parameter in the present scope.
[01:17:15] <petev> yes, you are really trying to turn g-code into a procedureal language
[01:17:23] <petev> why not just create a new language?
[01:17:26] <lerman> I probably would, too. But I think there is some value to having the old features available for those who are currently gcode programmers.
[01:17:43] <petev> I'm saying have both, but as separate interps
[01:17:51] <petev> you load whichever you want to use
[01:18:32] <petev> the new interp code is object oriented and there is a base class that any type of interp can be derived from
[01:18:39] <lerman> Well, if you don't like or want the new features, you don't have to use them. This way, people who are familiar with gcode can use their old environment and just learn the new features they need. Think of it as incremental learning.
[01:18:44] <petev> I derived the rs274ngc from it
[01:19:16] <lerman> Well, the present emc2 code looks object oriented, but it isn't really.
[01:19:16] <petev> I hear you, but it seems very ugly and it's nothing like what fanuc does
[01:19:41] <petev> I don't even think it looks that object oriented
[01:19:54] <petev> yeah, it uses some C++, but that means nothing
[01:20:11] <lerman> Well, the interpreter is declared as a class. I think we agree.
[01:20:44] <petev> u can see how easy it would be to write a grammar for a new language with ANTLR, then it's a little code for the execute routine
[01:20:47] <petev> not all that bad
[01:20:59] <lerman> Yes, I see.
[01:21:09] <petev> then u could have real procedure calls, loops, conditionals flow, etc.
[01:21:23] <lerman> But defining a new language is somewhat more work. And getting people to use it is even harder.
[01:21:45] <petev> I think people will program in one of several ways
[01:21:54] <petev> 1) they use CAM and generate g-code
[01:22:09] <lerman> The changes I made do have real procedure calls, loops, conditionals flow, etc. They just look a little kludgy to a 'real' programmer.
[01:22:19] <petev> 2) it's a simple part and they can program by hand (g-code is ugly, something else would be better)
[01:22:50] <petev> 3) there is a conversational front end (like a wizard) and it takes params and generates g-code or whatever
[01:23:20] <petev> yes, I didn't mean to say you're stuff wasnt real, just that g-code is making it ugly
[01:23:26] <lerman> Yeah, I've been thinking about 3). I'll have to go back and look at the QT stuff.
[01:23:40] <petev> you can't just say for (x=0; x<5; x++)
[01:23:45] <petev> or something like that
[01:23:50] <lerman> Yes, I know what you meant -- I don't take offense.
[01:24:20] <petev> for #3, there is some old tcl code from EMC1 that does some of this
[01:24:34] <petev> u could probably steal the algorithms for a quick start
[01:24:42] <petev> I think it was called cp1
[01:24:52] <lerman> tcl is NOT on my list of languages I know or care to really learn.
[01:25:06] <petev> no, just take the algorithms to save time
[01:25:17] <petev> I don't know or want to learn TCL either
[01:25:23] <lerman> Well, I'd have to learn to read tcl.
[01:25:40] <petev> it's not that hard to read, at least I didn't think so
[01:26:04] <petev> the programs implemented things like bolt hole patterns, pocketing, etc.
[01:26:12] <petev> programs/program
[01:27:10] <lerman> I was thinking of a generic wizard. It puts up a picture with some parameter selectors. Then it generates code that calls pre written gcode subroutines. That way, anyone could add wizards with about no cost in learning qt or tcl. -- They would need to be able to program in lerman's version of gcode.
[01:28:17] <petev> that could be pretty slick, I would cosider each wizard a particular type of machining operation or MOP
[01:28:30] <lerman> The mach wizards would be my model. If you look at them, each puts up a picture and lets the user change values next to arrows that identify things like step over, etc.
[01:28:40] <lerman> Correct.
[01:28:56] <petev> ok, I haven't seen Mach, I should look
[01:29:10] <lerman> I think I've seen that Mach has around a dozen or so.
[01:29:29] <lerman> Yes. It's worth looking at -- esp. the wizards.
[01:29:41] <petev> yeah, you could probably just take the simple MOPs from a decent CAM like MasterCAM or somtehing
[01:31:02] <lerman> I need to learn how the tcl stuff, etc interfaces with the interpreter. Once I know how to stuff code into the system, the qt stuff will be pretty easy. The key is that we write the qt stuff in a generic manner so that you use a build (possibly just qt designer) to make the new screen.
[01:31:23] <petev> I can tell u that
[01:31:32] <petev> there is a file called emcsh.cc
[01:31:45] <petev> it extends the tcl interp with new emc specific commands
[01:31:57] <petev> tcl calls them, and they send NML to emc task
[01:32:08] <lerman> Yes, I've discovered that.
[01:32:18] <petev> I have some QT code that Paul did to send NML already
[01:33:02] <lerman> I'm planning on spending another week in the US Virgin Islands in March. I think my software project might be to build a generic wizard system.
[01:33:11] <petev> cool
[01:33:57] <lerman> I think someone else sent me some. But it would be nice if someone could put a link to it on the wiki. (I'm a great believer in wiki's -- I use one for a lot of my own notes and stuff.)
[01:37:12] <lerman> See:
http://www.artofcnc.ca/Mach2.6.11.pdf
[01:37:14] <lerman> search for wizard.
[01:40:03] <lerman> Page 3-9 shows a circular pocketing wizard. I would define this with a few lines of text. There would be a line with the path to an image containing the background. There would be a line with a path to the gcode subroutine that defined the wizard. Then, for each of the parameters to the subroutine, there would be x, y coordinates telling where on the image to put the value selector for that...
[01:40:05] <lerman> ...parameter.
[01:40:29] <fenn_> btw CP1 was just a wrapper for some programs written in c
[01:40:39] <lerman> pete: got your email.
[01:40:51] <Jacky^> G nite
[01:40:58] <Jacky^> Jacky^ is now known as Jacky^afk
[01:41:37] <petev> fenn: didn't know that
[01:41:44] <petev> do u see the C source?
[01:41:52] <Jacky^afk> Jacky^afk is now known as Jacky^
[01:41:53] <petev> lerman: looking at mach
[01:41:54] <Jacky^> :)
[01:43:13] <fenn_> i was talking to ray, and he said they just used jon e's stuff
[01:43:29] <petev> boy, Art has spent some time on the eye candy
[01:43:55] <fenn_> http://pico-systems.com/gcode.html
[01:44:13] <fenn_> art didnt write the wizards, it was some kid, brian i thin is his name?
[01:44:18] <lerman> Yes, he has.
[01:44:41] <fenn_> brian (?) said he was interested in porting them to emc
[01:44:47] <fenn_> dunno if that's worth anything to ya
[01:44:56] <petev> hmm, we should talk to him
[01:45:02] <petev> make him a developer
[01:46:02] <lerman> Well, once we (I) build the context, writing wizards is duck soup. First write the underlying subroutines in gcode. Then draw an image and put in the value selectors. The only hard part is getting the subroutines right. -- That is, putting in the right generality.
[01:46:13] <fenn_> heh master5 is a 4 axis controller - why isnt it called master4 then?
[01:47:05] <Jacky^> why ?
[01:47:22] <petev> what is it with gcc, the newer the version, the more crapy the error reporting it seems
[01:47:35] <lerman> Does anyone have a decent way to do a generic pocket consisting of arcs and lines? I'd settle for one that was limited to convex polygons.
[01:48:08] <lerman> Not because I need it, but because I'd like to find a good algorithm.
[01:48:10] <petev> lerman: aren't u just thinking of standard shap pockets?
[01:48:21] <Jacky^> fenn_: it maybe depen on version
[01:48:25] <petev> you're not thinking CAM AI type pockets are you?
[01:48:35] <Jacky^> nothing to see with axis used ?
[01:48:54] <fenn_> Jacky^: probably
[01:49:00] <lerman> Well, for a wizard, I'd settle for a circular pocket and for a rectangular pocket with arbitrary orientation. And that should be straightforward.
[01:49:07] <petev> yes
[01:49:16] <Jacky^> otherwise it shoulde be a bussiness move
[01:49:31] <lerman> I'm not familiar with CAM AI type pockets.
[01:49:59] <petev> I mean where the CAM follows some features in the model for the pocket shape
[01:50:33] <Jacky^> fenn_: sometime, to change a word mean to change the world
[01:50:44] <lerman> No, not talking about that.
[01:51:07] <petev> then what type of algo are u looking for?
[01:51:36] <fenn_> he just means make a pocket with an arbitrary polygonal outline
[01:51:47] <lerman> Well, suppose I specified a path in gcode. And then I wanted to remove everything inside the path.
[01:52:17] <lerman> fenn: correct -- except ideally, the 'polygon' would have arcs and lines.
[01:53:09] <Jacky^> * Jacky^ cant understand
[01:53:21] <Jacky^> you want to rewrite the math O_O
[01:53:51] <lerman> I've written code to do graphic fill, and those algorithms would work -- except for the fact that (1) they would spend a lot of time cutting air and (2) they are somewhat more complex than I would care to implement in the extended gcode I have available.
[01:54:11] <fenn_> why would they be cutting air?
[01:54:28] <fenn_> does this go around and around in a spiral?
[01:54:30] <petev> lerman, I think that's pretty much getting into the CAM stuff. The CAM usually has some ability to identify features, or u select a feature and apply a MOP to it
[01:55:19] <petev> fenn: depending on the shape, u can't just spiral
[01:55:35] <petev> if u modify the spiral, u will machine areas multiple times
[01:55:37] <fenn_> like a dogbone shape would have to traverse the middle of the bone multiple times
[01:55:43] <petev> yes
[01:55:45] <lerman> To pocket a circle, I could start at the center and spiral out. For a rectangle, I could do the same sort of thing. Although if the axis of the rect wasn't parallel to the axis of the machine, I would have to adjust for that.
[01:55:49] <petev> and modify the spiral too
[01:56:12] <lerman> At any rate, the two important cases, circles and rectangles are pretty straightforward.
[01:56:30] <petev> lerman: I don't think u can do complex pockets like this with a g-code sub
[01:56:40] <petev> u would have to generate custom g-code
[01:57:01] <lerman> Well, you could probably do a generic triangle.
[01:57:28] <fenn_> right now i'm needing triangular pockets with one side as an arc
[01:57:36] <petev> I think rectangle and circle are most common
[01:57:41] <petev> fenn, you need CAM
[01:57:44] <fenn_> i know
[01:57:45] <lerman> And you could make other polygons out of unions of triangles. (I don't think I would want to tesselate the polygon in gcode).
[01:58:16] <petev> just keep it simple, pocketing, facing, bolt holes, etc.
[01:58:20] <lerman> fenn: I think you could do that as a gcode subroutine.
[01:58:22] <petev> more than that and it CAM time
[01:58:54] <petev> lerman: what do u think of this
[01:58:58] <Jacky^> * Jacky^ sighs
[01:59:00] <petev> it might sound crazy
[01:59:09] <Jacky^> Jacky^ is now known as Jacky^afk
[01:59:10] <petev> but how about a Forth based interp
[01:59:11] <lerman> petev: but the nice thing about my approach is that anyone could add to the set of wizards by adding a new subdirectory with the wizards name and a few files.
[01:59:11] <fenn_> write a cam program? :)
[01:59:32] <Jacky^afk> it already exist !
[01:59:36] <petev> with that, the user can add fancy macros (uh forth words) to the dict any time
[01:59:40] <lerman> Hell, even most programmers can't understand forth.
[01:59:47] <fenn_> Jacky^afk: an open source cam program
[01:59:49] <petev> it's just like your HP calc
[01:59:52] <petev> it's easy
[02:00:03] <Jacky^afk> fenn_: thats a dream
[02:00:19] <fenn_> Jacky^afk: no, it's not... /msg me your email
[02:00:41] <Jacky^afk> good luck !
[02:00:45] <lerman> The problem with forth is that nay idiot can add a word to the dict. And a lot of them do. So, when you are done, you have a bazillion words that no one knows precisely what they do.
[02:01:17] <petev> true, but you can have the words on a wiki page for download or something
[02:01:17] <fenn_> Jacky^afk: look at the freesteel.co.uk blog
[02:01:27] <petev> don't have to just put garbage in the default dict
[02:02:56] <lerman> My object oriented programming experience taught me that it takes 10 times the effort to write a reusable class (to be used in a library) as it takes to just write the code for yourself.
[02:03:28] <fenn_> as long as you dont change your own code at all
[02:03:44] <petev> somewhat agree
[02:03:55] <petev> u do have to think about the interface more and make sure it's good
[02:04:06] <petev> but it's usually better code in the end too
[02:04:12] <lerman> I guess one other file to add to my wizard definition is the documentation that tells its limitations, etc. (Also its author, so you know who to blame)
[02:04:29] <petev> yep
[02:04:33] <Jacky^afk> fenn_: :)
[02:04:58] <petev> also, there is no reason why the back end has to be g-code if we have a more powerfull language
[02:06:19] <lerman> petev: true. No reason why we couldn't check the file type referenced by the wizard definition and pass the params to a script or c-program, or whatever.
[02:06:30] <petev> yep
[02:07:35] <lerman> Well, I think it's time to call it a night. It's been a pleasure chatting, as usual. Thanks.
[02:09:40] <petev> gnight
[02:10:58] <fenn_> so, what is the diff between a wizard and a subroutine with pretty pictures/gui sliders
[02:11:22] <fenn_> i mean, in the end the wizard will make a call to some function
[02:11:41] <petev> yep, it's just a GUI way to select function params to me
[02:15:22] <petev> fenn: why is G92 not considered modal?
[02:15:33] <petev> it remains in effect until u cancell it
[02:15:52] <fenn_> i dont really understand what g92 is supposed to do
[02:16:05] <fenn_> i think its the difference between "machine coordinates" and "world coordinates"
[02:16:12] <fenn_> but could be wrong
[02:16:23] <fenn_> what is a proper usage of g92?
[02:16:25] <petev> the way I understand it is it's an offset that is applied in all coord systems
[02:16:49] <fenn_> what is underneath g92? i mean what are you offsetting from?
[02:16:53] <petev> so you have the G54, 55, 56, etc. coord systems
[02:17:08] <petev> from whatever coord system is in use
[02:17:22] <petev> so the coord system defines the origin and G92 an offset
[02:17:30] <fenn_> what are they offsetting from then?
[02:17:39] <petev> the total offset from machine is the sum of them from what I can tell
[02:17:57] <fenn_> is it home position?
[02:18:12] <petev> yes, I assume home is the machine origin
[02:18:21] <fenn_> well, with home offset also
[02:18:37] <fenn_> this is such a basic thing it should be more obvious
[02:18:40] <petev> yeah, but that's burried in HAL no?
[02:18:54] <fenn_> i dont think its in hal
[02:19:02] <fenn_> maybe in motion.c
[02:19:12] <petev> I'm pretty sure jmk added the HOME_ params for the RT homing stuff
[02:19:20] <petev> yeah, motion is a HAL comp
[02:19:36] <fenn_> oh i didnt know that
[02:19:38] <petev> jmk, just doesn't like to say it much so people don't get irritated
[02:20:02] <fenn_> weird
[02:20:24] <petev> it used to tweak paul that HAL took over so much functionality
[02:20:37] <petev> IO is basically a HAL comp to
[02:20:41] <fenn_> yeah
[02:20:56] <petev> HAL API works in both user and RT space, and these sorta bridge the gap
[02:21:07] <petev> IO is mostly user
[02:21:16] <petev> motion, mostly RT
[02:21:30] <fenn_> "io" is a really ambiguous term
[02:21:39] <fenn_> doesnt really mean anything
[02:21:50] <petev> no, there is an IO module in EMC
[02:21:58] <fenn_> i know
[02:22:06] <petev> it's mostly a shell now with CL, but it's still there
[02:22:08] <fenn_> i mean, the name of the module is confusing
[02:22:22] <petev> it used to do the PLC type logic, but it was all hard coded
[02:22:43] <petev> there is the view of motion and IO
[02:22:54] <fenn_> i would like to work on emc3 so i dont feel l ike i'm gonna break something i dont understand
[02:22:56] <petev> IO is stuff like tool change, spindle lube, etc.
[02:23:22] <petev> yeah, we talked about having stable, testing, etc. like debian
[02:23:26] <petev> I think we should
[02:23:45] <fenn_> whats the difference between the way debian does it and the way kernel.org does it
[02:24:17] <fenn_> seems like we're doing something more like kernel.org since most changes will break everything
[02:25:00] <petev> not sure, I'm not familiar with what kernel.org does
[02:25:40] <fenn_> well, eventually everything in a testing release is frozen and then it is made into a stable release
[02:25:47] <fenn_> i.e. no new features
[02:25:57] <petev> right
[02:26:26] <petev> so as soon as we have an official first release of EMC2 we should start an unstable branch or something
[02:26:34] <fenn_> ok that's sensible
[02:26:44] <petev> then that one should go to testing just to fix bugs
[02:26:50] <fenn_> it will motivate me to work on emc2 at least
[02:26:51] <petev> new dev in a new unstable, etc.
[02:27:40] <petev> yeah, I think it will make a lot more people feel comfortable working on it
[02:28:10] <fenn_> fenn_ is now known as fenn
[02:28:26] <djb_rh> argh
[02:28:28] <djb_rh> wtf is a PLC?
[02:28:38] <fenn> a TLA
[02:28:41] <petev> programmable logic controller
[02:28:47] <petev> u know, ladder logic
[02:29:06] <djb_rh> I had this Greyline "Operator Workstation" fall into my lap
[02:29:11] <djb_rh> and I'm trying to figure out what I can do with it
[02:29:18] <fenn> a real plc will also handle conversion between different voltages and high current
[02:29:22] <petev> we have a SW PLC in EMC2
[02:29:23] <djb_rh> be that "use in another project" or just "sell it"
[02:29:39] <djb_rh> info seems sparse on this stuff on the web
[02:29:46] <fenn> does it run?
[02:29:49] <djb_rh> it's brand new and does power up
[02:29:54] <djb_rh> even has the manual
[02:29:58] <djb_rh> pinouts and everything
[02:30:00] <fenn> is it rs-232 or does it have a screen?
[02:30:10] <djb_rh> appears to have rs-232, rs-422, and rs-485
[02:30:13] <djb_rh> has a 4 line LCD
[02:30:18] <djb_rh> keypad, and LED output
[02:30:41] <fenn> might be useful
[02:30:56] <djb_rh> you can even make your own template for covering the LEDs
[02:30:59] <fenn> does your k&t use 24V limit switches and relays?
[02:31:15] <djb_rh> k&t?
[02:31:26] <fenn> oh sorry i was getting you mixed up with skunkworks
[02:31:29] <djb_rh> heh
[02:31:45] <fenn> your "machine" whatever it is
[02:32:06] <djb_rh> only machines I've got are a Bridgeport Boss 8 that I'm gonna convert to Pico control and a mini-mill and mini-lathe both going to pico control as well
[02:32:13] <djb_rh> with EMC, obviously
[02:32:25] <fenn> ok the pico can handle digital IO's at 5V and a few mA
[02:32:38] <fenn> (i think)
[02:32:45] <djb_rh> I think so, too
[02:32:50] <djb_rh> so what do I do with that?
[02:33:07] <petev> fenn, the pico uses plug in IO modules
[02:33:26] <petev> u just have to be careful because they don't all fit do to poor design
[02:33:39] <petev> the Opto22 and a lot of others don't fit well
[02:33:52] <fenn> ok nevermind then
[02:33:53] <petev> I think some of the Crydom ones work well
[02:34:28] <djb_rh> so what can I *do* with this little gem?
[02:34:42] <petev> automate your house or something
[02:34:47] <djb_rh> lol
[02:34:51] <djb_rh> got that part handled
[02:34:52] <djb_rh> :)
[02:34:59] <fenn> heh run your mill, dummy
[02:35:13] <djb_rh> there will be a computer sitting there for that!
[02:35:32] <fenn> limit switches are usually 24V because switch contact oxidation can interfere with lower voltages
[02:35:42] <fenn> and 24V is sorta standard for most industrial stuff
[02:36:09] <djb_rh> I've found the list of canned PLC protocols that can be programmed into this thing to support
[02:36:30] <djb_rh> none of them mean much to me
[02:36:41] <fenn> are they ladder languages?
[02:37:09] <djb_rh> stuff like "AB PLC/2 programming port", "GE CCM2 Protocol", "GE Series 1 Protocol"
[02:37:12] <djb_rh> there are about 20 more
[02:37:38] <djb_rh> company names on them like Mitsubishi, Siemens, Allen-Bradley, etc
[02:37:53] <fenn> sounds like ebay time to me
[02:38:17] <djb_rh> heh
[02:38:24] <djb_rh> I can't find anything even *close* to it listed on eBay
[02:38:26] <djb_rh> which seems strange
[02:38:31] <djb_rh> I must not be searching for the right thing
[02:39:20] <fenn> try looking under "control systems and PLC's"
[02:39:23] <fenn> :)
[02:39:57] <djb_rh> heh
[02:40:02] <djb_rh> if only
[02:40:23] <fenn> http://eolsurplus.com/PLC.html
[02:40:39] <fenn> there's your market price
[02:44:59] <djb_rh> it looks sort of like this one:
http://cgi.ebay.com/Siemens-Simatic-C7-634P-Control-System_W0QQitemZ7569941219QQcategoryZ97184QQssPageNameZWDVWQQrdZ1QQcmdZViewItem
[02:45:18] <djb_rh> few less buttons
[02:46:59] <fenn> yeah theres a picture on the eolsurplus page
[02:51:38] <fenn> sheesh.. artsoft leads people to believe that step-servo's are more "modern" than real servo drives
[02:53:18] <djb_rh> hmm
[02:53:29] <djb_rh> found an online place selling this unit for $500
[02:53:32] <djb_rh> and they buy stuff
[02:53:33] <djb_rh> hmm
[02:53:46] <fenn> doest mean anyone will buy it at that price
[02:53:52] <djb_rh> well no kidding
[02:53:56] <djb_rh> probably means they'd pay $100 for it
[02:54:14] <fenn> if you're really lucky
[02:54:33] <djb_rh> oh, I see that part you wanted me to see on that PLC page now
[02:54:42] <djb_rh> that's an earlier version of the same thing I have
[02:55:03] <djb_rh> apparently Cincinatti Electrosystems got bought by GE Fanuc or something
[02:55:06] <djb_rh> because mine is GE Fanuc
[02:55:43] <djb_rh> looks like the same thing in a different package
[02:57:07] <djb_rh> well, it became Total Control Products and *then* GE Fanuc
[02:57:11] <djb_rh> damn
[03:10:32] <fenn> i wonder if using a pci parallel port card can get you higher step pulse rates
[03:14:41] <SWP_Away> I'll check that sometime
[03:14:47] <SWP_Away> SWP_Away is now known as SWPadnos_
[03:16:51] <fenn> that would alleviate the need for a lot of stupid kludgy step-pulse generators
[03:17:55] <fenn> i was just thinking about why mach2 and emc share the same step pulse limitation
[03:18:07] <fenn> if it's isa bus latency then it makes perfect sense
[03:18:20] <SWPadnos_> I thikn it mostly is
[03:18:22] <SWPadnos_> think
[03:18:50] <SWPadnos_> but that's not the only thing
[03:18:57] <fenn> hopefully pci parallel port cards dont have a mini-isa bus on them
[03:19:03] <SWPadnos_> there's a minimum amount of information that has to be saved and restored for the context switch
[03:19:20] <fenn> shouldnt that scale with processor clock speed?
[03:19:24] <SWPadnos_> and, the processors themselves asren't made for microsecond-scale interrupt response
[03:19:41] <SWPadnos_> it does scale (the context switch time)
[03:20:08] <SWPadnos_> but, it doesn't necessarily scale with internal CPU speed, some of it can be related to bus speed
[03:20:15] <SWPadnos_> (memory bus speed)
[03:20:26] <fenn> but this is generally constant among all computers
[03:20:37] <fenn> within an order of magnitude
[03:20:41] <fenn> usually less
[03:21:18] <SWPadnos_> think about what memory has done for the last few years, for non maxed-out machines
[03:21:42] <SWPadnos_> it's gone from PC2100 to PC3200 (maybe)
[03:21:45] <fenn> first time i heard about memory speed was four or five years ago
[03:22:07] <SWPadnos_> yet the processor internal speeds have gone from 1.5GHz to 3.5 GHz
[03:22:44] <SWPadnos_> the memory transfer rates for "average" machines haven't changed nearly as much as the CPU clocks
[03:23:14] <fenn> has anyone compared memory bus speed and step rate?
[03:23:20] <SWPadnos_> I don't think so
[03:23:48] <SWPadnos_> most machines running Linux can't get better than 5-6 usec latency, and many are much higher (like 20)
[03:24:15] <fenn> what happens in that latency measurement? a context switch or what?
[03:24:26] <SWPadnos_> surprisingly, my 500MHz celeron machine has better latency than my Athlon XP 2200
[03:24:37] <SWPadnos_> actually - I'm not sure even how it's measured :)
[03:24:55] <fenn> it's probably like bogoMIPS.. 5usec to do absolutely nothing
[03:24:59] <SWPadnos_> I haven't seen scope traces of an interrupt line going in, and a parport pin showing that the interrupt is executing
[03:25:13] <fenn> oh there was one somewhere
[03:25:23] <fenn> on till's page
[03:25:46] <SWPadnos_> no - it's 5 usec to acknowledge to the interrupt controller that you've seen the interrupt, re-enable other interrupts (possibly), and do a context save and restore
[03:26:18] <fenn> http://www.isw.uni-stuttgart.de/personen/t_franit/echtzeitlinux/realtime.html
[03:26:19] <SWPadnos_> also, realize that not all instructions take a simgle cycle to execute
[03:26:34] <SWPadnos_> thanks
[03:29:57] <SWPadnos_> interesting - I may build one of those
[03:30:35] <fenn> why do you need a gadget to do that?
[03:30:56] <SWPadnos_> well - I could just hit the parport with a pulse generator, but this seems nicer
[03:31:02] <fenn> hmmm
[03:31:19] <fenn> look! an avr! it must be better.
[03:31:20] <SWPadnos_> it would be like trying to measure one part of a tape measure with another part of the tape measure
[03:31:29] <SWPadnos_> if you only used software
[03:31:50] <fenn> no i mean just pulse the int_request line with a square wave generator and scope both lines
[03:32:05] <SWPadnos_> yep - that's the other option
[03:32:30] <SWPadnos_> though this seems to turn off the int request line when the computer responds
[03:33:32] <SWPadnos_> the interesting thing to note is that was a 400MHz PII
[03:33:51] <SWPadnos_> and it's 2-3 microseconds better than my 500 MHz celeron
[03:34:03] <SWPadnos_> which is 1-2 usec better than the Athlon 2200
[03:34:04] <fenn> it would be nice to see the comparison between pci and isa parallel port latency
[03:34:26] <fenn> since port latency is included in that..
[03:34:33] <SWPadnos_> yes - I'll get to that someday - once I have a reasonable test method and I get around to plugging the PCI parport card into the machine ;)
[03:34:50] <fenn> heh i'll give you 5 bucks to buy a pci parport card
[03:35:08] <SWPadnos_> one thing that I'm not sure of is wether you can get away with just one ouyb per interrupt, and not get held up
[03:35:18] <SWPadnos_> I have a dual card, so it's more ;)
[03:36:43] <SWPadnos_> amn - they're pretty darned cheap these days - $26.95 for the dual PCI parport card, $18.95 for the single
[03:37:52] <fenn> i'm really glad ebay finally got around to putting shipping charges next to the bid price
[03:38:03] <SWPadnos_> yeah - that's a godsend
[03:38:10] <SWPadnos_> also in the my ebay page, if you choose
[04:30:39] <fenn> i think i'm going to try to fix the velocity adaptation bug so we can call emc2 semi-stable
[04:31:24] <cradek> which bug?
[04:33:02] <fenn> the one where it rounds off corners at low accels
[04:33:16] <cradek> ah
[04:33:31] <fenn> should stay within some tolerance
[04:33:33] <cradek> I thought the worse bug is the misblends at high velocity
[04:33:44] <fenn> is that when you get pointy corners?
[04:33:48] <cradek> my accels must be high enough (they are pretty high)
[04:34:03] <cradek> I haven't seen pointy corners I guess
[04:34:06] <fenn> er, sorry that didnt make sense
[04:34:14] <cradek> I mean the thing that shakes up les's machine
[04:34:21] <cradek> but I can even hear it on mine
[04:34:36] <fenn> http://fenn.freeshell.org/cds-defaultaccel15maxaccel.20.png
[04:34:42] <cradek> even colinear points don't blend properly
[04:34:50] <fenn> those are pointy corners
[04:35:02] <fenn> http://fenn.freeshell.org/cds-defaultaccel.15maxaccel20.png
[04:35:05] <fenn> those are rounded corners
[04:35:30] <SWPadnos_> fenn: those aren't necessarily real machine moves
[04:35:32] <cradek> hard to say whether that's sampling problem on the backplot
[04:35:37] <fenn> swp those are commanded moves
[04:35:38] <SWPadnos_> what he said
[04:35:41] <cradek> yeah, exactly
[04:35:48] <fenn> nothing to do with sampling rates
[04:35:57] <fenn> accel is 0.15 in/sec/sec
[04:36:03] <cradek> the round looks pretty convincing but I wouldn't trust the pointy plot
[04:36:05] <fenn> which is really low.. you actually get moves like that (verified)
[04:36:12] <fenn> i see it on my machine
[04:36:14] <cradek> huh
[04:36:18] <SWPadnos_> hmmm
[04:36:26] <SWPadnos_> ok -go ahead and fix it ;)
[04:36:57] <fenn> the other problem.. running out of queue space, may have no solution
[04:37:20] <cradek> http://timeguy.com/cradek-files/cnc/pcb/dscn6119.jpg
[04:37:23] <fenn> not until we define some maximum block rates at least
[04:37:33] <cradek> I get excellent corners
[04:37:49] <cradek> look at the square IC pads for instance
[04:38:07] <fenn> what's your accel set to?
[04:38:10] <cradek> and the corners on the octagonal pads
[04:38:34] <cradek> I think it's about 30 ips^2
[04:39:07] <cradek> that was cut at velocity 20ipm
[04:39:57] <cradek> I actually cut that with emc1 (cradek_stable branch) but the planner is the same as emc2 and I haven't seen any sign of it acting differently
[04:40:03] <petev> cradek, is that with EMC1?
[04:40:09] <cradek> ^^
[04:40:17] <petev> yeah, slow
[04:40:33] <cradek> can't cut any faster with those tiny tools
[04:40:52] <petev> no, I mean me seeing your msg
[04:40:52] <cradek> 20krpm spindle and .001/revolution
[04:41:10] <cradek> oh, I see
[04:41:27] <cradek> this is why I'm so surprised to see your terrible results
[04:41:57] <petev> cradek, is your moving mass pretty small?
[04:42:19] <cradek> yes, just a smallish aluminum table
[04:42:23] <petev> ok
[04:42:28] <petev> I think there is a pattern here
[04:42:42] <petev> I setup a machine for a buddy, about the size of a BP series II
[04:42:49] <cradek> obviously my high accel values can give me sharper corners
[04:42:51] <petev> I put 2.46 HP servos on it
[04:42:56] <petev> plenty of power
[04:43:00] <fenn> i'd say
[04:43:09] <petev> with EMC1, the motion was very rough and slow
[04:43:17] <petev> follow errors no matter how tuned
[04:43:35] <petev> yet I could hook the PC to the drive RS232 and get great motion
[04:43:42] <cradek> but lots of people run a machine like that
[04:44:02] <petev> are they trying to run it at real speeds, or at 30ipm?
[04:44:17] <cradek> I don't know
[04:44:44] <petev> that machine should have been capable of 200ipm cuts easily
[04:44:58] <petev> it couldn't even get close to that
[04:45:00] <cradek> yikes
[04:45:45] <cradek> I know les runs his machine very slowly to not beat it to death with the misblends
[04:45:53] <cradek> have you talked to him?
[04:46:06] <petev> but les's machine is has even more moving mass
[04:46:13] <cradek> right
[04:46:17] <petev> it's a big gantry router from what I know
[04:46:41] <SWPadnos_> there's a Bridgeport sitting at NIST that runs (ran) emc, and AFAIK, it was fine
[04:46:47] <SWPadnos_> (they no longer use it, I gathered)
[04:46:57] <petev> swp: at what speeds?
[04:47:16] <cradek> maybe ray would know
[04:47:16] <SWPadnos_> I'd assume that people get reasonable performance on them, or there wouldn't be a "bridgeportio" module
[04:47:19] <SWPadnos_> I'm not sure
[04:47:38] <petev> swp: my stock BP control had a max feed of 32ipm
[04:47:52] <petev> so maybe people are happy if it will do what the old control did
[04:47:59] <SWPadnos_> I'm sure they run faster, but I have no hard data
[04:48:08] <cradek> that's not very exciting but you could get plenty of work done at that speed
[04:48:23] <SWPadnos_> yeah - most machining will be no faster than that
[04:48:27] <fenn> are rapids limited to that speed also?
[04:48:29] <cradek> ... as long as your code doesn't traverse the whole table very often
[04:48:32] <SWPadnos_> yes
[04:48:32] <petev> cradek, I used to rough cut some aluminum with a rapid
[04:48:50] <SWPadnos_> you need lots of spindle HP for that
[04:48:59] <petev> fenn: rapids would go about 100-120 ipm
[04:49:13] <petev> swp: depends on the cut and it's not all that bad in AL
[04:49:21] <petev> I have 3HP on the spindle
[04:49:23] <cradek> I'd be thrilled to have a mill that could do that
[04:49:34] <SWPadnos_> yo uget roughly 6 CI/minute [per HP in Aluminum
[04:50:06] <fenn> at bridgeport speeds you do at least
[04:50:16] <SWPadnos_> no - that's a constant
[04:50:21] <fenn> situation is different for 60Krpm+ spindles
[04:50:24] <petev> fenn: no that's HP to remove metal
[04:50:26] <SWPadnos_> nope
[04:50:34] <SWPadnos_> yep to pete
[04:51:08] <petev> but it you have a 1/2 carbide cutter on a shallow cut, you can go pretty fast with 3 HP
[04:51:18] <SWPadnos_> true
[04:51:35] <SWPadnos_> 12 IPM/DOC
[04:51:50] <SWPadnos_> per HP
[04:55:28] <fenn> i thought that less heat needed to be dissipated in the chip at higher rpms since the material flexes instead of flows
[04:55:46] <fenn> there is more of a shock wave action than smooshing silly putty action
[04:55:49] <SWPadnos_> it's not heat, it's power to cut the metal
[04:55:56] <fenn> that power goes somewhere doesn't it?
[04:56:16] <SWPadnos_> yes, the power goes into heat, and physically separating the metal bonds
[04:56:28] <SWPadnos_> but it all comes from the spindle, regardless of how you remove it
[04:56:38] <fenn> the power doesnt go into separating bonds
[04:56:56] <fenn> if that were the case a .001" chip would take as much power to cut as a .005" chip
[04:57:17] <SWPadnos_> physically cutting the material should involve breaking bonds
[04:57:21] <SWPadnos_> as well as bending the chip
[04:57:23] <fenn> it goes into bending the chip as you cut it
[04:57:28] <petev> fenn, I think where the heat goes may change, more to chip or cutter
[04:57:36] <SWPadnos_> sure, but you still have to cut it
[04:57:44] <petev> but I haven't heard that it takes less HP at higher speed before
[04:58:00] <fenn> machining forces go down as machining speed goes up
[04:58:05] <SWPadnos_> check Machinery's Handbook, they have a handy table
[04:58:16] <fenn> that doesnt necessarily mean that HP is constant
[04:58:23] <SWPadnos_> force goes down, but you increase speed, so total power remains the same
[04:58:23] <petev> fenn, but the chip load is changing
[04:58:33] <fenn> petev: no for a constant chip load
[04:58:55] <fenn> they did experiments shooting bullets at cutting tools
[04:59:00] <SWPadnos_> you want to cut at a constant surface speed, so at high RPM, you use a narrower cutter
[04:59:20] <SWPadnos_> which you then can move faster, because it cuts a narrower swath through the metal
[04:59:32] <SWPadnos_> keeping the same or similar chip load per tooth
[04:59:39] <fenn> SWPadnos: why do you want to cut at a constant surface speed?
[05:00:00] <SWPadnos_> but, you're still limited by the spindle horsepower in how much metal you can remove
[05:00:09] <petev> fenn: there is usally a range of surface speed that produces good results with each material
[05:00:10] <SWPadnos_> SFM -the speed of the cutter over the metal
[05:00:29] <SWPadnos_> sure, and the coating on the tool, etc. will change the optimal number
[05:00:32] <fenn> yes and those "good results" were determined by trial and error, using machines that were generally big and slow
[05:00:33] <petev> that's what you usually use to calc the spindle speed
[05:00:42] <SWPadnos_> nope
[05:01:01] <fenn> okay, how did they arrive at that number?
[05:01:36] <SWPadnos_> it was empirical, but I don't think that the machines were all big and slow
[05:02:00] <SWPadnos_> they were almost certainly big, but there's a lot of high performance stuff out there, and those are the guys who really care
[05:02:18] <fenn> size isn't really an issue in this case actually
[05:02:36] <SWPadnos_> big != slow, that's all I'm saying
[05:02:40] <fenn> ok
[05:03:10] <SWPadnos_> I'm quite sure that the "optimal removal rate" experiments were done on machines that were capable of moving far outside the rates needed for the experiments
[05:03:31] <SWPadnos_> (all you have to do is lower the tool, and take more off in depth of cut, to increase spindle load)
[05:03:48] <SWPadnos_> if you can't move the axis fast enough
[05:03:52] <fenn> you're talking about HP, not sfm
[05:04:11] <SWPadnos_> true - sorry, mixing experimental data
[05:04:25] <SWPadnos_> all you need to do is increase / decrease spindle RPM to do that
[05:04:32] <SWPadnos_> or tool radius
[05:04:43] <fenn> right
[05:04:49] <fenn> up to a point
[05:05:09] <fenn> at larger sizes materials have lower "relative strengths"
[05:05:14] <fenn> not sure what this is called in engineering terms
[05:05:29] <fenn> but you can see it in nature - elephants are built more heavily than mice, and the earth is round
[05:05:46] <SWPadnos_> actually, an oblate spheroid, but close enough
[05:06:17] <fenn> an asteroid acts more like a clump of dust when it hits the moon
[05:06:21] <fenn> zero tensile strength
[05:06:45] <SWPadnos_> most rock (and concrete for that matter) has almost no tensile strength
[05:06:57] <SWPadnos_> I don't think the comparison is a good one
[05:07:26] <fenn> rock has zero tensile strength?
[05:07:40] <fenn> solid rock?
[05:07:47] <SWPadnos_> close, relative to its compression strength
[05:08:13] <fenn> if you drop a rock onto another rock it bounces off
[05:08:27] <SWPadnos_> I can't pull it apart, but that's because humans have less than 0 ensile or compression strength ;)
[05:08:29] <fenn> if you drop a meteor onto the moon it splashes
[05:08:42] <SWPadnos_> that's compression, not tension
[05:09:06] <SWPadnos_> the energy involved is so high it would make your head spin -it has nothing to do with machining
[05:09:44] <petev> I see jmk has been avoiding the irc
[05:09:50] <petev> he must be getting some work done
[05:09:53] <SWPadnos_> yep - getting work done ;)
[05:09:56] <fenn> heh
[05:10:02] <fenn> what's the point of that?
[05:10:03] <SWPadnos_> he had a couple of commits the last two evenings
[05:10:12] <SWPadnos_> no no - work on emc :)
[05:13:50] <fenn> It is observed that above a certain threshold velocity the particle undergoes fragmentation upon impact. This threshold velocity depends on the particle material properties, and decreases with increasing particle radius.
[05:14:05] <fenn> for a particle colliding with an anvil
[05:14:21] <SWPadnos_> sure - consider the torque on the edges of the particle
[05:14:54] <SWPadnos_> a fat particle will have a longer radius from the center, and will therefore put more force (the product of radius and mass) on the center
[05:15:53] <fenn> what causes material failure, stress?
[05:16:08] <SWPadnos_> I think that's the major component
[05:16:33] <SWPadnos_> it can also be an instantaneous stress, caused by reflection of waves off the surface
[05:16:48] <fenn> according to these guys stress is proportional to impact velocity, and constant with regard to particle size
[05:16:54] <SWPadnos_> I'm not sure what actually happens at a molecular level when cutting something
[05:17:14] <SWPadnos_> I'm just imagining a marble hitting a hard surface
[05:17:29] <fenn> that's the experiment in a nutshell
[05:17:44] <SWPadnos_> a 2" marble has (a) 8x the mass of a 1" marble and (b) 2x the radius ofa 1" marble
[05:18:20] <SWPadnos_> so the total momentum is 1/2 mv^2, or 8 times as much, and the effective radius for that momentum is 2x as much
[05:18:48] <fenn> they keep using terms like dynamic toughness and dynamic cohesive strength
[05:18:57] <SWPadnos_> it seems to me that you get a 4th order increase in the "splitting" force - though I'm not sure what percentage of the total that is
[05:19:08] <SWPadnos_> it's like dynamic HTML
[05:19:37] <Jymmm> SWPadnos ?!
[05:19:43] <SWPadnos_> yes?
[05:19:53] <SWPadnos_> (well - SWPadnos_ )
[05:20:20] <Jymmm> SWPadnos: WTH is this suppose to mean? <SWPadnos_> it's like dynamic HTML
[05:20:32] <SWPadnos_> dynamic this, dynamic that - you know
[05:21:04] <Jymmm> No, I doubt (not at least in the context you speak of)
[05:21:11] <Jymmm> s/doubt/dont/
[05:21:13] <SWPadnos_> "The dynamic synergies of out meta-marketing potential will form a cohesive business model for the foreseeable future" - that kind of thing
[05:21:28] <fenn> "dynamic toughness" implies that the toughness changes with speed
[05:21:31] <Jymmm> That's just marketing hype, not DHTML
[05:21:36] <SWPadnos_> he
[05:21:37] <SWPadnos_> heh
[05:21:39] <Jymmm> HUGE difference.
[05:22:59] <Jymmm> But someone earlier brought up XML too, so I usually stay out of those conversations.
[05:23:19] <SWPadnos_> this is about breaking marbles on anvils, and how it relates to metal removal rates in HSM
[05:23:55] <Jymmm> Eh, LOX + torch make marbels go POOF!
[05:24:09] <SWPadnos_> and micorwaves make PopTart packages sparkle
[05:24:14] <SWPadnos_> microwaves
[05:24:35] <Jymmm> XML == POS
[05:24:51] <fenn> all the "dynamic toughness" research is about ceramics, nothing about metals or machining
[05:24:54] <SWPadnos_> depends on the criteria, I'd say
[05:24:57] <petev> swp: is it an error to specify two of the same words like X or T on the same line?
[05:25:10] <SWPadnos_> in G code, yes - I believe so
[05:25:14] <SWPadnos_> not sure about T
[05:25:22] <fenn> no it's not
[05:25:23] <SWPadnos_> (the last may take effect)
[05:25:25] <petev> hmm, seems like most controls just take the last value
[05:25:30] <fenn> T is for tool prep
[05:25:36] <petev> but that's not that helpful
[05:25:39] <fenn> M06 actually does the tool change
[05:25:40] <petev> fenn: yes
[05:26:02] <SWPadnos_> well - if you have a machine with multiple turrets, for example, it would be useful
[05:26:25] <petev> what about X, etc.?
[05:26:27] <fenn> on the mazak a T word would cause the tool magazine to rotate to that tool
[05:26:29] <SWPadnos_> not necessary, but still useful
[05:27:26] <fenn> this is going on as the machine is cutting the part
[05:27:31] <SWPadnos_> I'm not sure if it's strictly illegal - Kramer only says that it's an error to omit all axis words
[05:27:49] <fenn> nah that's crap
[05:27:51] <SWPadnos_> that previous was to pete, not you fenn
[05:27:52] <petev> right, so what is prefered behavior?
[05:29:19] <SWPadnos_> the kramer text explicitly says that spaces and tabs are allowed anywhere on a line, so something like 'G 0 X 1. 2' is equivalent to 'G0X1.2'
[05:29:24] <SWPadnos_> (on another note)
[05:29:38] <fenn> what's wrong with having a g0 on its own line for instance?
[05:29:42] <petev> yeah, that's ugly too
[05:29:51] <petev> fenn: you can
[05:29:54] <SWPadnos_> g0 is illegal without at least one axis word
[05:29:58] <petev> at least on controls I have used
[05:30:13] <petev> swp: most controls will take it
[05:30:15] <SWPadnos_> according to Kramer, it's illegal on G0 and G1
[05:30:19] <petev> it sets the motion mode
[05:30:26] <fenn> i dont see any reason why it would need a value
[05:30:33] <SWPadnos_> sure - you can allow it - I'm only reading the book
[05:30:38] <petev> ok, so kramer is not the way to go
[05:30:44] <petev> how much do we want to deviate?
[05:30:44] <SWPadnos_> well - it's the reference
[05:30:51] <petev> I already fixed expressions
[05:31:02] <SWPadnos_> how fixed?
[05:31:38] <petev> gave things precedence and assiciativity and got rid of that stupid atan crap and the extra required []
[05:31:45] <SWPadnos_> ok
[05:31:48] <petev> associativity
[05:34:49] <fenn> heh i love it.. jmk suddenly has the same radical ideas i had 6 months ago
[05:35:04] <petev> how so
[05:35:30] <petev> are u looking at the docs I sent u?
[05:35:35] <fenn> yeah
[05:35:43] <fenn> or maybe it's you writing
[05:35:44] <petev> well I wrote the word doc
[05:35:51] <fenn> cant tell what's purple and whats black
[05:35:52] <petev> jmk just drew the pic
[05:35:55] <CIA-12> 03paul_c * 10emc2-auto/wiki/ (27 files in 15 dirs): "Auto update wiki from a cron job. Sat Dec 10 05:30:01 GMT 2005 "
[05:35:58] <petev> oh
[05:36:25] <fenn> canonical command queue is the entrance to rt space
[05:36:32] <petev> yes
[05:37:13] <fenn> this is an admittedly badly written first draft, which contains that idea:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CommandChain
[05:40:56] <petev> fenn: the Q ideas seem similar to what streams modules do
[05:41:13] <petev> some of the way u describe operation would be hard to implement though
[05:41:27] <petev> I would prefer to move to a more threads based approach
[05:41:42] <petev> then threads could actually block on buffer allocation, etc.
[05:44:09] <fenn> this is kinda like what you are doing with xml, only i didnt know that xml was for this sort of thing:
http://sourceforge.net/mailarchive/message.php?msg_id=12080584
[05:45:12] <fenn> i was thinking of using dbus to do the network/inter-process stuff
[05:46:29] <petev> yeah, similar
[05:46:30] <fenn> again, threads would probably be better than processes
[05:46:44] <fenn> i've never written a thread though
[05:46:58] <petev> BTW, I did look at xml rpc, but it requires HTTP and I think that's too much
[05:47:17] <petev> take a look at the POSIX specs
[05:47:36] <petev> it contains a pretty standard thread API
[05:47:51] <petev> there is an implementation for linux too
[05:48:20] <petev> from my basic understanding, XML is good at describing data
[05:48:30] <petev> HTML is good at describing how to display data
[05:49:11] <fenn> what's html have to do with it
[05:49:19] <fenn> http is just a data transfer protocol
[05:49:45] <petev> yes, just comparing XML to HTML and what they are good for
[05:49:52] <petev> the HTTP was in regards to rpc
[05:50:05] <petev> there is an XML rpc that runs over HTTP
[05:50:23] <petev> but I think the classic rpc over TCP or UDP would be better
[05:50:25] <Jymmm> XML Is EVIL
[05:50:30] <fenn> jymmm go away
[05:50:33] <petev> u don't understand it
[05:50:44] <Jymmm> petev: I understand it VERY well
[05:50:58] <Jymmm> That doesn't change the fact that XML is still evil
[05:51:07] <Jymmm> and the spawn of satan
[05:51:29] <fenn> the problem is that http was poorly designed, and so xml was used to patch it up
[05:51:33] <fenn> er html not http
[05:51:38] <Jymmm> ***IF*** XMl was used as intended that would be another thing.
[05:52:02] <Jymmm> fenn: XML AND HTML have nothing in common...
[05:52:02] <petev> I don't think XML is poorly desinged, why do you say that? It is very simple
[05:52:22] <petev> jymmm read back a bit
[05:52:49] <Jymmm> SGML it old by todays standards and not really improved at all in the last 5 years.
[05:52:50] <fenn> html isn't sufficient for much more than page formatting.. but people want more than that
[05:52:57] <petev> right
[05:53:19] <petev> but SGML is too complex and hard to implement, so XML
[05:53:22] <fenn> ok so now that we are all on the same page, can we drop this thread?
[05:53:23] <Jymmm> If as much effort went it PS as did SGML we would be far better off.
[05:53:53] <petev> let's drop it, I don't want to get started on SGML
[05:53:58] <SWPadnos_> Jymmm: what is better than XML for representing a hierarchy of information, including the type and range of values?
[05:54:37] <SWPadnos_> (I don't know - I'm actually asking)
[05:54:46] <Jymmm> SWPadnos_ anf how often to do you REALLY need that?
[05:54:58] <fenn> Jymmm: if you're doing something besides stupid webpages
[05:54:59] <Jymmm> CSV has worked for over 30 years.
[05:55:00] <SWPadnos_> every time you configure an emc2 machine, for starters
[05:55:18] <SWPadnos_> CSV is great, but how do you represent legal values?
[05:55:19] <Jymmm> And if you needed al aternative there is ANSI SQL
[05:55:26] <petev> jymmm that's a pretty poor answer
[05:55:31] <SWPadnos_> anda database - bad idea
[05:55:37] <Jymmm> YOu folks really need to read the spec on XML
[05:55:45] <fenn> yes, i do..
[05:56:10] <petev> fenn, quick overview here www.xmlfiles.com
[05:56:11] <Jymmm> petev: You really dont know much about it... from what you've stated so far you really dont know/understand what SMGL really is.
[05:56:14] <SWPadnos_> I agree that it's impossible to edit or read by hand, but it actually has some features that are desirable for the purpose we're discussing
[05:56:34] <petev> I do understand SGML, but it has problems with implementation
[05:56:44] <petev> it can't even be expressed with EBNF
[05:56:49] <Jymmm> XML is EXTREMELY bloated and very slow. It's primary intent was for TRANSPORT, not storage.
[05:56:50] <petev> parsers are hard to do for it
[05:57:05] <petev> it has it's place, but not to light weight stuff over the web
[05:57:10] <petev> to/for
[05:57:25] <SWPadnos_> ok - aside from bloat and speed, what's wrong with XML? *not* the software that uses it
[05:58:08] <Jymmm> SWPadnos: What more do you need to know?
[05:58:13] <SWPadnos_> reading 10k of text is not significantly slower than 1k, so bloat of the formatted data isn't an issue
[05:58:20] <petev> another good intro here
http://xml.com/pub/a/98/10/guide0.html?page=1
[05:58:31] <Jymmm> 600K of text I have seen as 300M of XML
[05:58:55] <SWPadnos_> well - the idea is to represent all of the configuration information of an emc machine, including what's now in the .ini file, and several .hal files, in a single unit
[05:59:10] <Jymmm> SWPadnos: Why do you want to use XML, becasue of what you've heard, or what you know abou tit?
[05:59:12] <Jymmm> it
[05:59:23] <SWPadnos_> I know tit!
[05:59:25] <SWPadnos_> sorry
[05:59:38] <Jymmm> we all know tit, that's besides the point.
[05:59:54] <petev> so jymmm, do u really think SQL is appropriate for this?
[06:00:03] <Jymmm> 'u' is not a word.
[06:00:16] <Jymmm> petev have you seen SQLite as example?
[06:00:38] <SWPadnos_> I don't know what's best, but I do know that XML allows us (the developers) to represent what's allowed for a given setting (via the DTD), and allow people to know that they will have a valid setup when they're finished
[06:00:41] <Jymmm> petev the output can be ascii in SQLite. The libraries are BSD licensed as well.
[06:00:58] <SWPadnos_> but where does teh data come from?
[06:01:07] <SWPadnos_> the
[06:01:59] <SWPadnos_> though XML isn't perfect, it does seem capable of at least carrying the configuration information, and the validation information
[06:02:09] <Jymmm> SWPadnos: Ok... in respect to publishing DTD's that's true. But from where I sit, there isn't even any documentation. When writing s DTD there are strict requirements involved.
[06:02:28] <SWPadnos_> that's OK - C is pretty strict as well
[06:02:43] <Jymmm> Not compared to DTD's (can be)
[06:02:52] <fenn> python is even stricter
[06:02:54] <SWPadnos_> again, assuming that it's properly used, are there any real problems with XML?
[06:03:03] <fenn> hey that's why it's called python!
[06:03:11] <SWPadnos_> (I know the files are large, and taht is an issue, but not a big one IMO)
[06:03:43] <SWPadnos_> processing is done once per run, or during config editing / validation, so speed isn't a big issue either
[06:03:46] <Jymmm> SWPadnos: Whats wrong with the way it is now? They method has worked for 30 years.
[06:03:53] <Jymmm> a/they/that/
[06:03:54] <SWPadnos_> not with emc2
[06:04:12] <SWPadnos_> there are half a dozen files containing config info for a non-trivial machine
[06:04:27] <SWPadnos_> some of it's in emc.ini, other stuff in some .hal or another
[06:04:34] <Jymmm> SWPadnos: In gerneral, unix configuations, usenet servers, mta's, and these handle huge tasks.
[06:04:35] <SWPadnos_> still more that's put in the emc.run script
[06:04:44] <Jymmm> and even dns
[06:04:49] <SWPadnos_> sure, but "normal people" don't sysadmin unix machines
[06:05:02] <Jymmm> You go tossing in XML, it will surely be a clusterfuck.
[06:05:21] <Jymmm> especially with DTD's being in the picture.
[06:05:26] <SWPadnos_> well - it would require a GUI tool to edit, which is needed anyway, for aunt tillie
[06:05:42] <Jymmm> IF emc2 was documented and kept up to date, I'd think overwise.
[06:05:53] <Jymmm> SWPadnos why gui?
[06:06:01] <SWPadnos_> I'm not sure - there are a lot of files to look at simultaneously
[06:06:11] <SWPadnos_> because XML would be way too confusing in text mode :)
[06:06:44] <Jymmm> SWPadnos Exactly... so now you want someone to fix a boo boo in an XML file where they have nfc what/why/hoh?
[06:06:52] <Jymmm> how
[06:06:58] <Jymmm> damn drunk kynd!
[06:07:01] <Jymmm> kybd
[06:07:19] <SWPadnos_> no - if the DTD is properly configured, then the user can't make stupid errors in the first place
[06:07:28] <Jymmm> wanna bet?
[06:07:39] <SWPadnos_> and if they do manage it (with vi or something), then they can email a single file to a developer for help
[06:08:00] <Jymmm> Yeah a 4mb file
[06:08:22] <SWPadnos_> hmmm -if you have a "fully compliant" xml editor, and a correctly defined DTD, can the editor make "mistakes"?
[06:08:23] <Jymmm> compared to a 400KB one
[06:08:33] <Jymmm> sure
[06:08:43] <SWPadnos_> can you explain why or how?
[06:09:03] <Jymmm> *I* can't explain it, but I know it can occure.
[06:09:07] <SWPadnos_> preventing mistakes is one of the central ideas around using XML
[06:09:14] <Jymmm> No, it's not.
[06:09:25] <SWPadnos_> is it because of buggy software, or a problem with the design of XML?
[06:09:36] <SWPadnos_> XML+DTD
[06:10:09] <Jymmm> it's the looseness of XML
[06:10:17] <SWPadnos_> hmm
[06:11:02] <SWPadnos_> at its least intrusive, you could actually do all of this by just wrapping all of the currently used files in XML headers (like <emcini> here's the ini file</emcini>)
[06:11:11] <SWPadnos_> or however the syntax actually works
[06:11:37] <SWPadnos_> you'd add about 100-200 bytes total, and have everything in one file
[06:11:44] <SWPadnos_> but no help in validation
[06:12:28] <Jymmm> Ok, so how many cases (percentage) have you seen/heard of where there has been issues with config files, that you want to move/use/need xml+DTD?
[06:13:33] <SWPadnos_> the idea was to provide a list of possible options to choose from, and to make it so that a bad entry (like text in a numeric field) would be flagged in the editor
[06:13:56] <SWPadnos_> so - DISPLAY = {axis,tkemc,keystick,mini} - pick one
[06:14:17] <Jymmm> Ok, and hwho is ging to maintain all this?
[06:14:21] <SWPadnos_> petev ;)
[06:15:06] <Jymmm> Uh, huh. *WACK*
[06:15:24] <SWPadnos_> well - it's true (sort of)
[06:15:59] <SWPadnos_> I thikn it's like the trivkins thing - once there's a good example, it should be easier for others to make different versions for other drivers or components
[06:16:23] <SWPadnos_> if you add an ini var, you add it to the DTD, just like you're supposed to add it to the manpage or docs or readme, etc
[06:18:31] <Jymmm> If you had to make lots of changes all the time, I might see it. but hell... setup once and you might never look at the config files ever again.
[06:18:40] <SWPadnos_> tru
[06:18:42] <SWPadnos_> e
[06:19:05] <SWPadnos_> but then, there's nobody who can tell you all of the ini vars, what they mean, or even what units they're in
[06:19:06] <Jymmm> So, why go thru hours of setup and maint effort .
[06:19:41] <petev> 1) The INI info is getting huge and scattered into multiple files. It would be nice to have all the data in one place, but it's too hard to manage with a flat structure. XML gives us a hierarchical tree structure.
[06:19:41] <petev> 2) There are XML editors that make viewing the file very nice, like viewing a directory structure in explorer.
[06:19:42] <petev> 3) The XML DTD defines what a valid file looks like. Right now, you don't even know what options can go in the INI file. You either have to wade through source, see it in another file, or hear it from someone else, as it sure isn't well documented.
[06:19:42] <petev> 4) I would like the EMC code base reduced to motion control code. I would rather use the gnome libxml2 lib than have code in the EMC tree that the EMC team has to maintain (and there is plenty of it for INI stuff). This lib has bindings for a bunch of languages including python. It should make it much easier for GUIs to support config editing (this we should discuss more for remote GUIs).
[06:19:48] <petev> 5) We can use the externally maintained libs to build a custom config editor when we get the time.
[06:19:50] <SWPadnos_> I'm not sure it's worth it - that's why I want your view - I know you hate it, but I really want to know why, in this context, it's so bad
[06:19:50] <Jymmm> xml still isn't going to help tell you what var means/does what, even if given certain criteria.
[06:21:27] <Jymmm> ok period has a range... now what value tdo you give it for your scenario
[06:22:24] <SWPadnos_> if you can specify a "help" text for each item (which would be ignored if left in the file), then you can actually guide people in the setup
[06:24:20] <fenn> alternative XML syntaxes take care of a lot of the readability problems
[06:24:37] <fenn> but that introduces more dependencies
[06:25:09] <fenn> and you can enter invalid values
[06:25:19] <fenn> but sometimes you gotta enter an invalid value
[06:26:01] <SWPadnos_> eyah -I don't think you can validate on the fly - it has to be a manual check
[06:26:09] <SWPadnos_> damn, I can't type
[06:27:33] <fenn> i'm talking about plain text editing
[06:27:51] <fenn> http://www.scottsweeney.com/projects/slip/
[06:28:10] <SWPadnos_> I saw that, it looks better than XML, for sure
[06:28:16] <fenn> http://www.langdale.com.au/SOX/
[06:29:46] <petev> yeah, but no libs or deb packages, it's too bad
[06:32:38] <fenn> btw pete why is the xml file duplicated in the second half, but with capitalized tags?
[06:32:52] <petev> fenn: where?
[06:33:10] <fenn> right after </emc>
[06:33:22] <petev> where are you looking?
[06:33:38] <fenn> emc.xml - the raw xml source
[06:33:47] <fenn> kxmleditor doesnt like it
[06:33:49] <petev> in what an email I sent u?
[06:33:53] <fenn> yeah
[06:34:07] <petev> hmm, it's not like that here, that's odd
[06:34:11] <petev> what date email?
[06:34:16] <petev> I can send it again
[06:35:28] <SWPadnos_> man - I've got to stop talking to you west coast guys - it's 1:35 AM again!
[06:35:37] <SWPadnos_> good night
[06:35:46] <fenn> night
[06:35:47] <SWPadnos> SWPadnos is now known as SWP_Away
[06:36:02] <fenn> oh weird
[06:36:08] <petev> gnight
[06:36:12] <fenn> my email client must have appended the new file to the old one
[06:36:16] <petev> fenn, sent it again
[06:36:24] <petev> it opens here fine
[06:36:44] <petev> yeah, I had an old one with lower case, but I went upper to be more like the current INI
[06:36:56] <fenn> i hate upper case stuff
[06:37:15] <petev> me too, so just run tr if u want to see it lower case
[06:37:30] <petev> I just want to have a shot at getting it accepted
[06:40:54] <fenn> wonder why kxmledit doesnt let you insert a dtd
[06:41:05] <petev> it's pretty basic
[06:41:10] <petev> it's got bugs too
[06:41:22] <petev> but it's the best light weight thing I found
[06:41:52] <petev> it won't even take the XML version processing intruction without barfing
[06:42:05] <fenn> that's abd
[06:42:08] <fenn> very bad
[06:42:10] <petev> yes
[06:42:18] <fenn> that's like the first thing you learn in "xml 101"
[06:42:22] <petev> there are other packages, but much heavier
[06:42:52] <fenn> hmm i can add a version statement
[06:42:53] <petev> I think the gnome libxml2 is pretty good, but didn't see any light weight editors built on it
[06:43:06] <petev> hmm, I had trouble with it
[06:43:12] <petev> there is one in the DTD
[06:43:25] <petev> when I had it in the XML it wasn't happy
[06:43:48] <petev> the DTD is also wrapped in a DOCTYPE now as I tried to put it at the head of the XML
[06:45:10] <fenn> how hard would it be to make it easy to change settings for multiple axis entries at once?
[06:45:28] <fenn> like 6 instances of 1 set of data
[06:45:33] <petev> without a custom condif editor?
[06:46:14] <petev> config
[06:46:18] <fenn> as things are i'd have to edit identical pid data 6 times
[06:46:29] <fenn> dunno if that's just something i'll have to live with or what
[06:46:47] <petev> it does need to be separate data though
[06:47:03] <petev> we could separate out the driver data and use a pointer to it
[06:47:16] <petev> but that doesn't seem intuitive for the non programmer
[06:47:45] <fenn> it should only be in a hexapod example file
[06:48:02] <petev> what should?
[06:48:05] <fenn> only other case i can think of is dual feedscrews on a gantry
[06:48:21] <fenn> i mean don't go screwing up everything else for the hexapod special case
[06:48:25] <petev> what's that, where axis driver data is the same?
[06:48:29] <petev> oh
[06:48:30] <fenn> right
[06:48:41] <SWPadnos_> PID is likely to be differnet on all axes, even for a Bridgeport or simple gantry machine
[06:48:48] <petev> what kind of machine do u have?
[06:48:48] <SWPadnos_> (not asleep yet ;) )
[06:48:54] <petev> swp: true
[06:48:58] <fenn> SWP_Away: even for dual X feedscrews?
[06:49:12] <SWPadnos_> that's one case where it *might* be the same
[06:49:17] <SWPadnos_> but only for the two axes
[06:49:18] <petev> fenn: probably not, but that;s rare
[06:49:45] <petev> fenn: but x, y, z would be diff even with same motors/drives
[06:49:55] <fenn> yeah
[06:50:01] <petev> y saddle carries x table
[06:50:09] <petev> so mass is totally different
[06:50:20] <fenn> i would sure like some documentation on what P I D FF0 FF1 actually represent
[06:50:30] <petev> P is position
[06:50:33] <SWPadnos_> search for PIDFF
[06:50:36] <petev> I is integral
[06:50:39] <SWPadnos_> P is error in position
[06:50:41] <petev> D is differential
[06:50:44] <SWPadnos_> (Proportional)
[06:50:47] <petev> they refer to the following error
[06:50:54] <petev> swp: yes, sorry
[06:51:37] <fenn> les once said ff0 was compensating for friction (i think)
[06:51:54] <petev> I think the FFs are the for look ahead, they are higher order derivatives or something like that
[06:52:12] <SWPadnos_> I'm not sure which numberis which, but the FF values are basically a "hint" at what the controller is asking for
[06:52:31] <SWPadnos_> FF1=1 means that the output will be exactly equal to the input (all others at 0)
[06:52:35] <petev> swp: I thought is was based on what was coming next?
[06:52:52] <petev> where's jmk?
[06:53:00] <SWPadnos_> for the PID, it is, since the PID loop is usually one cycle behind (waiting for feedback)
[06:53:34] <SWPadnos_> without the FF (feedforward), the PID has to wait until the position is wrong, then correct based on the error
[06:53:59] <SWPadnos_> FF tells it that the new value has arrived, and start doing sometihng about it before there's an error to correct
[06:54:22] <petev> ok, and FF1 is first derivative of FF0, and so on right?
[06:54:40] <SWPadnos_> could be - I'm not sure what the different FF numbers mean
[06:54:45] <SWPadnos_> (in emc that is)
[06:54:49] <petev> ok
[06:55:15] <fenn> jmk is probable in lala land
[06:55:50] <SWPadnos_> actually, I think they're the first and second derivatives of position (so vel and accel)
[06:56:13] <fenn> great all my search results return emc stuff
[06:56:15] <petev> right
[06:56:27] <SWPadnos_> (you already have proportional in the command, and I'm not sure integral makes sense)
[06:56:38] <SWPadnos_> I just don't know which FF[01] is which
[06:56:50] <petev> I think FF0 is position
[06:57:10] <SWPadnos_> ok - that could make sense
[06:57:20] <petev> I start by just setting P with others 0
[06:57:25] <petev> then I add D
[06:57:38] <SWPadnos_> what?
[06:57:48] <SWPadnos_> usually I and D are 0, and P in in the 10-1000 range
[06:58:05] <petev> no, I mean a value to P with all other 0
[06:58:10] <fenn> is it possible to output trajectories that don't need any PID ?
[06:58:22] <SWPadnos_> PID has nothing to do with the trajectory
[06:58:48] <fenn> if you're cutting air
[06:58:49] <SWPadnos_> it's all about making a mass be where you want, when you want, with the given drive power
[06:58:51] <petev> fenn: PID is the control loop for each axis alone
[06:59:04] <petev> it makes the drive go where u tell it to
[06:59:28] <SWPadnos_> the trajectory is where you want it to go, the PID is what makes the motor actually do that
[06:59:37] <petev> right
[06:59:40] <SWPadnos_> with 0 mass, or an infinite power motor, you wouldn't need PID
[07:00:01] <SWPadnos_> actually, you wouldn't need any servo loop (as jmk calls it)
[07:00:30] <SWPadnos_> "servoing" is the process of getting an actuator to follow a programmed position
[07:01:20] <fenn> dont we need a pid loop for threading then?
[07:01:31] <fenn> or is that totally crazy
[07:02:20] <SWPadnos_> we probably do, because we want to "servo" the cutting axis to the spindle speed
[07:02:24] <fenn> stop talking to me.. i'm obviously delirious
[07:02:37] <SWPadnos_> yeah - me too. good night (for real this time)
[07:02:41] <fenn> too much peach pie
[07:02:44] <petev> gnight
[07:06:25] <fenn> here's where i get it mixed up.. jerk represents changing current in the motor coils, so with a perfect system you could get current feedback and extrapolate position velocity and accel
[07:06:48] <fenn> so a limited jerk trajectory should always be feasible
[07:06:54] <SWPadnos_> stop that - I'm trying to go to bed!!!
[07:07:25] <fenn> SWPadnos_ SWPadnos_ does this make your computer beep?
[07:07:34] <SWPadnos_> fenn fenn fenn maybe
[07:09:52] <petev> fenn: what's the behavior when swithing between auto/mdi?
[07:10:19] <petev> can u send some mdi then go back to auto as if it were just part of the program file?
[07:11:31] <fenn> i dont think so
[07:11:38] <fenn> i would like that
[07:11:46] <petev> so going to mdi closes an open program?
[07:11:51] <fenn> right now it just starts the program over
[07:12:00] <petev> how should it behave?
[07:12:10] <fenn> well, pause should continue where you paused it
[07:12:40] <petev> so what happens when you break a cutter and need to re-start?
[07:12:49] <fenn> you are cutting air
[07:12:58] <petev> oh, that's really bad
[07:13:10] <petev> are u sure that's the only option?
[07:14:58] <fenn> i was wrong
[07:15:04] <fenn> pause works
[07:15:13] <fenn> but, you cant do any mdi commands when paused
[07:15:17] <fenn> you have to abort to do an mdi
[07:15:24] <petev> hmm
[07:15:32] <petev> what are the re-start options if any?
[07:15:51] <fenn> verify and run?
[07:16:06] <petev> can u give it a line number to start on?
[07:16:20] <fenn> not that i know of
[07:16:49] <fenn> lemme try some other gui's
[07:17:08] <petev> which gui are u using?
[07:17:49] <fenn> tkemc
[07:18:02] <petev> hmm, that probably has the most options
[07:19:23] <fenn> how would you know which subroutine loop to start on
[07:19:42] <SWPadnos_> neither axis nor tkemc does what you want
[07:19:49] <petev> well, that is a problem only with the new lerman changes
[07:20:02] <petev> I thought u were asleep
[07:20:15] <SWPadnos_> I'm still thinking about it (brain keeps me up)
[07:20:23] <petev> move to the west coast
[07:20:38] <petev> I had to put that sonja paper down
[07:20:42] <SWPadnos_> heh - Hawai'i would be more appropriate
[07:20:50] <petev> didn't get anything done last night trying to read it
[07:22:15] <fenn> pesky brain
[07:22:37] <petev> fenn: what kinda machine do u have?
[07:22:39] <fenn> i have that problem too.. that, and being unemployed causes me to be awake at ridiculous hours
[07:22:52] <fenn> petev: a really really crappy thing composed of gas line and 2x4's
[07:23:02] <petev> gas lines?
[07:23:11] <fenn> ad-hoc linear rails
[07:23:15] <petev> ahh
[07:23:16] <fenn> with rollerblade bearings
[07:23:20] <petev> where are u located?
[07:23:23] <petev> cool
[07:23:23] <fenn> indiana
[07:23:35] <petev> u have a router for the spindle motor?
[07:23:39] <fenn> dremel
[07:23:43] <petev> ahh
[07:23:48] <fenn> it's sufficient for styrofoam cutting
[07:23:56] <petev> isn't there any programming work in india?
[07:24:06] <fenn> i will be retrofitting my homebuilt lathe soon
[07:24:13] <fenn> maybe.. i'm not a programmer
[07:24:19] <fenn> and i prefer not having a job
[07:24:19] <petev> ahh
[07:24:30] <petev> so how do u get by without a job?
[07:24:32] <fenn> i could probably get a job somewhere
[07:24:50] <petev> u should say, self employeed, not unemployed
[07:24:57] <fenn> i have some money left over from college, and i've cut costs to almost nothing
[07:25:08] <fenn> nah i'm not self employed cause i dont make any money
[07:25:24] <fenn> unless you count capital as money
[07:25:34] <petev> capital?
[07:25:44] <fenn> machine tools, knowledge
[07:25:48] <petev> right
[07:25:58] <petev> being self employed is often like that
[07:26:05] <petev> u don't always make money
[07:26:13] <SWPadnos_> don't remind me
[07:26:15] <SWPadnos_> damn
[07:26:19] <petev> go to sleep
[07:26:22] <SWPadnos_> yeah
[07:26:27] <SWPadnos_> damn
[07:27:48] <fenn> at least i'm not like les, where i cant even do what i want to because there's so much money to be made
[14:26:17] <anonimasu> alex_joni: what's that ui from ?
[14:26:32] <alex_joni> some software
[14:26:42] <anonimasu> ok :)
[14:26:43] <alex_joni> but I liked how you can configure stuff
[14:27:03] <anonimasu> yeha
[14:27:04] <anonimasu> err
[14:27:04] <anonimasu> yeah
[14:27:07] <alex_joni> mostly the IO stuff
[14:27:08] <anonimasu> it looks really neat
[14:27:14] <alex_joni> naming & enabling
[14:27:16] <alex_joni> all that
[14:45:31] <anonimasu> * anonimasu nods
[14:48:58] <okalleo> I have filed a bugreport for escaping A axis at sourceforge. If anyone have any questions, Im here from time to time.
[14:49:08] <alex_joni> okalleo: seen that
[14:49:16] <alex_joni> can you try it with the latest CVS please?
[14:49:46] <okalleo> I used the source from this morning... is it too old?
[14:50:03] <alex_joni> no, this morning is ok
[14:50:37] <alex_joni> * alex_joni finishes something first
[14:50:41] <alex_joni> then I'll look at it
[14:52:20] <alex_joni> okalleo: ok like that?
[14:54:34] <cradek> ooh, I thought this was fixed
[14:54:42] <alex_joni> morning chris
[14:54:46] <cradek> hello
[14:54:47] <alex_joni> seems not
[14:55:00] <cradek> I think it's fixed in emc1/cradek_stable
[14:55:22] <alex_joni> do you remember where this came from?
[14:55:27] <alex_joni> where to look I mean..
[14:55:28] <cradek> unsurprisingly, it has to do with mixed up units
[14:55:37] <cradek> I'll go dig for it
[14:55:38] <alex_joni> oh, nice
[14:56:18] <cradek> okalleo: is your A axis set up in angular units?
[14:56:29] <okalleo> angular
[14:56:33] <cradek> ok
[14:56:41] <okalleo> the ini is in the report
[14:57:12] <alex_joni> cradek: btw, did you look at the quickfix for that velocities not beeing printed?
[14:57:22] <cradek> yes
[14:57:29] <alex_joni> seems ok?
[14:57:30] <cradek> mixed up units, right?
[14:57:45] <cradek> I haven't tested it, but yes, I think I just made a mistake
[14:57:50] <alex_joni> more the problem of liner_move not beeing set
[14:57:57] <cradek> thanks for finding that
[14:57:57] <alex_joni> even if it's G2 ;)
[14:58:16] <cradek> so it has always printed them wrong?
[14:58:19] <alex_joni> you only had a small typo, would have caused a bad conversion..
[14:58:29] <alex_joni> but the printing was always bad
[14:58:33] <cradek> interesting
[14:58:49] <dmess> good morning all
[14:58:55] <cradek> did you notice the vel calculation for arcs is pretty bogus?
[14:59:02] <alex_joni> I had a hard time figuring out I need to set linear_move for an arc ;)
[14:59:06] <alex_joni> yes I've seen that
[14:59:36] <alex_joni> also.. the whole thing kinda make me look from a different perspective at TP ;)
[14:59:40] <alex_joni> most of the stuff discussed happens in canon, not tp
[14:59:56] <alex_joni> like feed adjust & co
[14:59:58] <cradek> yes, for instance the arc vel calc is in canon
[15:00:20] <alex_joni> so there's the non-RT TP actually ;)
[15:00:24] <dmess> it should be to allow for matrices to be used
[15:00:27] <cradek> actually I understand how most of tp works other than blending
[15:00:34] <okalleo> Are you able to provoke escaping A axis?
[15:00:42] <alex_joni> blending is pretty simple in TP I think
[15:00:52] <alex_joni> when one TC starts to decel, the next one is pulled out
[15:00:54] <cradek> okalleo: I can't test right now but I am looking for the fix, which I think is in another tree
[15:01:09] <alex_joni> and starts to accel, and those two get mixed
[15:01:27] <alex_joni> so instead of ___/\___ you get ____X____
[15:01:31] <okalleo> If You want I can also attach my standard pinout
[15:01:39] <cradek> okalleo: not necessary
[15:02:10] <alex_joni> okalleo: till we let cradek work on that ;) maybe you can tell me a bit about your emc2 impressions
[15:02:19] <alex_joni> how did it install, how does it feel, run, etc
[15:02:36] <alex_joni> except for the bug ;) which is great for you to report..
[15:02:50] <cradek> http://cvs.sourceforge.net/viewcvs.py/emc/emc/src/emctask/emccanon.cc?r1=1.30.2.2&r2=1.30.2.3&only_with_tag=cradek_stable
[15:02:53] <alex_joni> what RT/linux-kernel are you using?
[15:03:58] <okalleo> I like the arcitcture alot. The wiki instructions is good for updating a BDI-4 installation
[15:04:29] <alex_joni> ok so basic bdi-4, (4.30? or older?)
[15:04:29] <okalleo> and it is good that emc1 is still functioning as usuall.
[15:04:40] <okalleo> 4.30
[15:04:51] <alex_joni> the two should never interfere (emc1 and emc2)
[15:05:24] <dmess> cool i might try an upgrade too then ... soon
[15:06:28] <okalleo> the tk interface is good for now and I havent got me that far to change for axis... maybe something to add to configure and makefiles
[15:07:50] <okalleo> I had problems with ferror and min_ferror (and I think mu current numbers are abnorm, but I couldent get it to work with others)
[15:09:05] <CIA-12> 03cradek * 10emc2/src/emc/task/emccanon.cc: This may fix bug 1377639, escaping A axis.
[15:09:21] <okalleo> the wiki would gain alot for some upgrade guides. Like how to set up emc2 like the emc1 bridgeportio
[15:09:26] <alex_joni> okalleo: cradek is quick ;)
[15:09:40] <cradek> it would be better if I tested it, but I can't right now
[15:09:53] <cradek> okalleo: can you test it?
[15:10:04] <okalleo> I'm impressed of ALL the work behind!
[15:10:11] <alex_joni> okalleo: you have developer access to CVS? or only pserver?
[15:10:21] <okalleo> It's already fixed?
[15:10:25] <alex_joni> if you have pserver it might be a few hours before you can get the fix
[15:10:33] <cradek> okalleo: yes
[15:10:35] <alex_joni> check CIA-12 message above ;)
[15:10:41] <okalleo> only pserver
[15:10:43] <cradek> I could send a patch (or the whole file)
[15:11:12] <alex_joni> okalleo: does the tkemc display show that the axis runs away?
[15:11:17] <alex_joni> in that case I can test too
[15:11:38] <okalleo> yes
[15:12:16] <okalleo> Quite fast (on my mashine) I get following error
[15:12:51] <cradek> I like bugs with such an obvious wrong behavior!
[15:13:01] <alex_joni> nice..
[15:13:48] <okalleo> if anyone whant the 4;th axis HAL files let me know... (will be back in 5min)
[15:14:23] <alex_joni> think I'll manage setting up one..
[15:19:03] <les_w> morning all
[15:19:09] <alex_joni> morning les
[15:19:13] <cradek> hello
[15:20:26] <les_w> frosty and cold down here
[15:20:39] <cradek> hiding inside up here
[15:21:08] <cradek> if this is autumn weather, I'm not so anxious for winter to come
[15:21:15] <les_w> Was just contemplating the complete inability to get dry firewood
[15:21:42] <les_w> need to get that solar kiln up
[15:21:42] <alex_joni> les_w: the last few days cradek & I have been looking on some problems with emc
[15:22:00] <les_w> which problem?
[15:22:01] <cradek> I've got a cord? chord? stashed in the barn
[15:22:09] <alex_joni> and I think you've been looking at the wrong place
[15:22:16] <cradek> (some silly american amount of wood)
[15:22:27] <alex_joni> les_w: problems with TP and feedoverride
[15:22:41] <alex_joni> not very important to the issue, those are fixed now
[15:22:49] <okalleo> morning, can abnormal values for ferror and min_ferror result in that a comande movement lets the axis alittle bit too far and then compensates this so the axis moves sligtly the other way when it stopps?
[15:23:15] <alex_joni> but the idea is that most of the stuff happens in emccanon and TP (not TP alone)
[15:23:47] <cradek> okalleo: some others have reported that behavior but I'm not sure anyone has looked into it. The guy to ask is probably jmkasunich
[15:24:02] <alex_joni> okalleo, cradek: just testing the A-axis problem now
[15:24:08] <cradek> great
[15:24:20] <alex_joni> it's a long way to -350
[15:24:21] <alex_joni> :)
[15:24:31] <alex_joni> A-335 actually..
[15:24:42] <les_w> Well my bughunt stopped when Fred said tp/tc can't velocity adapt at all
[15:24:50] <les_w> The is no bug
[15:24:56] <alex_joni> it can do some now
[15:25:06] <alex_joni> only not to exceed machine limits
[15:25:17] <les_w> Fred said it is just no good and should be completely replaced
[15:25:26] <cradek> I think you are talking about different things
[15:25:31] <alex_joni> cradek: I thought about it some more, and I think it works for non-triv kins too
[15:25:31] <les_w> heh
[15:25:49] <alex_joni> right.. probably
[15:25:59] <alex_joni> I agree that TP/TC is pretty simple (=daft)
[15:26:02] <cradek> alex_joni: oh, that's good, I have no idea how to test that
[15:26:09] <alex_joni> nm that ;)
[15:26:20] <okalleo> alex_joni are you running my ini? If so do You get funny moves the the axis stop (only for XYZ)
[15:26:55] <alex_joni> I added the A-axis to my ini
[15:27:07] <okalleo> cradek: maybe it is a metric (and ferror) problem
[15:27:16] <les_w> Fred feels trying to modify tp/tc would be difficult/impossible because the way it is written
[15:27:27] <cradek> okalleo: I think I saw it with my inch configuration
[15:27:54] <okalleo> ok
[15:27:56] <cradek> okalleo: I saw it when I tested low accel settings
[15:27:58] <alex_joni> cradek: I have one question
[15:28:12] <alex_joni> if I defined the A-axis as rotary
[15:28:22] <alex_joni> what are the units for it?
[15:28:31] <cradek> you specify ROTARY_UNITS
[15:28:35] <cradek> usually they are degrees
[15:28:48] <alex_joni> right.. I specified 1 as rotary units
[15:28:52] <alex_joni> so degrees..
[15:29:03] <alex_joni> then wth does it change when switching from G20 to G21
[15:29:09] <cradek> nfc
[15:29:12] <alex_joni> do you people have different degrees over there?
[15:29:17] <alex_joni> LOL
[15:29:18] <cradek> haha
[15:29:28] <alex_joni> probably changes to fahrenheit :P
[15:29:35] <cradek> g20/g21 is SO broken right now
[15:29:50] <alex_joni> I can prove that..
[15:30:11] <cradek> oh no my cat is helping
[15:30:44] <alex_joni> nice cat
[15:30:45] <alex_joni> :)
[15:30:51] <alex_joni> hmm.. guess what
[15:31:04] <alex_joni> I did an G0A-341.2692
[15:31:13] <cradek> [TRAJ] ANGULAR_UNITS = 1.0
[15:31:18] <alex_joni> and the axis didn't move, yet the display reads -8668.2329
[15:31:20] <alex_joni> :D
[15:31:58] <cradek> do you have that ANGULAR_UNITS in TRAJ?
[15:32:03] <alex_joni> yes
[15:32:04] <alex_joni> 1.0
[15:32:04] <les_w> cnc scares my cat
[15:32:17] <alex_joni> and in [axis_3] I have UNITS = 1.0
[15:32:22] <alex_joni> TYPE = ANGULAR
[15:32:40] <cradek> ok, that's what I did in emc1
[15:32:53] <cradek> I think
[15:32:55] <cradek> it's been a while
[15:34:13] <alex_joni> I get some weird behaviour on G0 Axxx
[15:34:22] <alex_joni> it ferrors, then when I enable it moves a bit more
[15:34:25] <alex_joni> then halts
[15:34:51] <alex_joni> I'll try your commit now
[15:35:00] <cradek> oh that's without the fix? ok
[15:35:04] <cradek> good (I guess)
[15:35:21] <cradek> I've seen the leftover movement after ferror, it seems bad.
[15:35:30] <cradek> it's probably another one for jmkasunich
[15:35:36] <alex_joni> it moves back..
[15:35:40] <alex_joni> not further on
[15:35:56] <cradek> maybe that's not so bad, but it would be better if it stopped!
[15:36:04] <alex_joni> right ;)
[15:36:52] <cradek> good morning ray
[15:37:03] <alex_joni> morning ray
[15:37:23] <rayh> Hi guys
[15:37:29] <cradek> rayh: let me introduce okalleo, a new emc2 user with a rotary axis!
[15:37:42] <rayh> hi okalleo
[15:38:14] <alex_joni> cradek: no difference after tha patch
[15:38:20] <cradek> alex_joni: drat
[15:38:26] <cradek> alex_joni: what behavior do you see?
[15:38:57] <alex_joni> ferrors (axis A)
[15:39:06] <cradek> do you get them without an offset?
[15:39:19] <alex_joni> what offset do you mean?
[15:39:26] <cradek> a g54 offset
[15:39:28] <alex_joni> I just started emc2, and put in an G0
[15:39:30] <alex_joni> no G54
[15:39:30] <cradek> that's the reported bug
[15:39:39] <cradek> oh, that's not the reported bug :-)
[15:39:50] <cradek> okalleo has that much working
[15:39:53] <alex_joni> http://sourceforge.net/tracker/download.php?group_id=6744&atid=106744&file_id=159344&aid=1377639
[15:41:08] <alex_joni> accell seems very slow on okalleo's machine
[15:41:15] <alex_joni> 2 mm/s^2 ?
[15:41:20] <alex_joni> max vel 4mm/s ?
[15:41:32] <cradek> two seconds to get up to speed?
[15:41:57] <alex_joni> but 2mm/sec is way sloow
[15:42:17] <cradek> yeah
[15:42:34] <alex_joni> also 12mm ferror doesn't seem right
[15:42:46] <okalleo> I had to put them low because I got following errors all the time
[15:43:04] <okalleo> I told You abnorm
[15:43:47] <alex_joni> you sure you can't go faster than 2mm/sec ?
[15:43:55] <cradek> accel on Y is 1mm/s^2
[15:44:14] <alex_joni> on Z
[15:44:24] <cradek> oh right, Z
[15:44:47] <cradek> I bet it's the low accels that are triggering the ferrors
[15:45:07] <rayh> This application uses a parport for step and direction?
[15:45:07] <okalleo> ok, I didnt try to alter the ferror and min_ferror for hours so this was the quick solution
[15:45:28] <alex_joni> what steppers do you use?
[15:45:46] <okalleo> vexta
[15:46:12] <okalleo> rayh: yes
[15:47:24] <okalleo> * okalleo is away: back in 5min
[15:49:15] <les_w> So i'm looking at firewood processors
[15:49:17] <alex_joni> darn.. still getting ferrors on axis_3
[15:49:18] <cradek> alex_joni: did you get yours to work (without offsets?)
[15:49:22] <cradek> alex_joni: oh
[15:49:47] <alex_joni> just modified the whole ini.. must have missed something
[15:50:42] <cradek> alex_joni: when I was using emc1 it seems like I had vel of maybe 30deg/sec and accel of maybe 100deg/sec^2
[15:51:01] <alex_joni> that's more like it
[15:51:14] <alex_joni> not: MAX_VELOCITY = 5.5
[15:51:14] <alex_joni> MAX_ACCELERATION = 3.0
[15:51:17] <alex_joni> :/
[15:51:38] <cradek> wow, it'll take him a while to get to 360 then
[15:51:55] <cradek> he may be working with VERY small steppers
[15:52:51] <alex_joni> I put 30/100 in the ini
[15:52:54] <alex_joni> still getting ferrors
[15:53:10] <cradek> alex_joni: time to break out halscope?
[15:53:21] <cradek> alex_joni: do you think you have stepgen configured right?
[15:53:31] <alex_joni> I hope so ;)
[15:53:41] <cradek> alex_joni: there may be units confusion or something
[15:53:56] <alex_joni> jog works ok
[15:54:07] <cradek> oh, interesting
[15:54:10] <rayh> phone
[15:54:25] <alex_joni> err.. no it doesn't for higher speeds
[15:54:33] <alex_joni> might be the headroom for the stepgen
[15:54:39] <cradek> maybe
[15:55:09] <alex_joni> one question..
[15:55:20] <alex_joni> how does stepgen know what units it runs ?
[15:55:30] <cradek> 09:53:38 < cradek> alex_joni: there may be units confusion or something
[15:55:38] <alex_joni> yup
[15:55:54] <dmess> thats not good
[15:56:15] <alex_joni> I think the core_stepper.hal needs some changes..
[15:56:18] <alex_joni> not sure
[15:56:51] <okalleo> * okalleo is back
[15:59:42] <cradek> okalleo: alex_joni still is getting his rotary axis to work (without offset)
[15:59:52] <cradek> okalleo: so we haven't tested the bugfix yet
[15:59:54] <alex_joni> trying to get..
[16:00:05] <alex_joni> must be something I'm foing wrong
[16:00:13] <alex_joni> the damn thing keeps ferror'ing
[16:00:17] <alex_joni> and I start to hate it
[16:02:16] <okalleo> alex_joni: maybe you can try abnormaly big ferror and min_ferror
[16:02:24] <alex_joni> I took over your values
[16:03:31] <okalleo> * okalleo is away: will be back soon
[16:03:40] <alex_joni> anyways.. tried G54, and I wasn't able to cause it to run away
[16:04:08] <alex_joni> okalleo: one question though.. why the slow speeds? can't the steppers do faster?
[16:04:12] <dmess> could it be rectifying the angular vel , accel, decel... to a linear tool velocity??
[16:04:13] <cradek> alex_joni: you think it's fixed?
[16:04:17] <Jacky^afk> Jacky^afk is now known as Jacky^
[16:04:20] <Jacky^> hello
[16:04:38] <alex_joni> cradek: to be honest.. I have no idea what it is
[16:04:49] <cradek> alex_joni: ok, then I say it's fixed
[16:04:50] <cradek> haha
[16:04:57] <alex_joni> but it doesn't look fixed to me ;) (not what you did, that seems ok... but the whole thing)
[16:05:04] <cradek> alex_joni: I think I fixed canon
[16:05:04] <alex_joni> very odd behaviour I'm getting
[16:05:12] <alex_joni> so would I..
[16:05:13] <cradek> I agree there may be big problems with angular units in stepgen
[16:06:06] <alex_joni> it shouldn't matter to stepgen that it's angular or not
[16:06:09] <cradek> I have a rotary axis for my mill, but I was too lazy when I was making my stepper drivers and stopped at 3
[16:06:15] <cradek> now I regret that
[16:06:17] <alex_joni> :P
[16:06:18] <okalleo> my mill is very small and it needs slow movements, but these nubers are slower than the ones I had in emc1 because I got joint following errors all the time so I put them down more and now I get less
[16:06:35] <dmess> are you moving a rotary servo only or a rotary table assembly??
[16:06:38] <alex_joni> okalleo: something is wrong, emc2 usually gets higher speeds than emc1
[16:06:44] <alex_joni> I've heard
[16:06:55] <cradek> alex_joni: he needs stepgen headroom
[16:07:02] <alex_joni> dmess: depending on who you're talking to
[16:07:05] <alex_joni> cradek: I agree
[16:07:31] <dmess> you alex
[16:07:38] <cradek> alex_joni: I really wish we (you or jmk) would fix that somehow
[16:07:41] <alex_joni> okalleo: try editing the .hal file of yours and make the stepgen.x.max_vel (&accel) about 20% higher than the ini
[16:08:05] <alex_joni> dmess: I'm turning a very nice imaginary rotary table assembly
[16:08:11] <alex_joni> dmess: big AC servo
[16:08:21] <alex_joni> and a 5kW motor
[16:08:24] <cradek> okalleo: at the same time, I suggest you put your ini values to the same as you had with emc1
[16:08:31] <dmess> gear driven??
[16:08:47] <alex_joni> dmess: yeah.. with 0 backlash
[16:08:55] <alex_joni> but don't skip the "imaginary" above..
[16:09:06] <dmess> i seen IT
[16:09:25] <alex_joni> ok.. then we can imagine a bit more ;)
[16:09:30] <cradek> I'm running my real rotary axis with an imaginary stepper driver
[16:09:39] <alex_joni> oh.. that's better ;)
[16:09:50] <alex_joni> btw, I have a 50kg rotary table
[16:10:00] <alex_joni> and I'll hook an G340 to it, not sure when.. but soon
[16:10:06] <alex_joni> maybe I'll drive it by emc2 then
[16:10:06] <dmess> then your issues are in the wiring... LOL
[16:10:23] <alex_joni> cradek: use one of those wireless drivers
[16:10:36] <alex_joni> microwave powered :D
[16:10:58] <dmess> small nuclear devices are cool..
[16:11:28] <alex_joni> I've been to a small research nuclear reactor once.. way cool
[16:11:36] <dmess> cheap russian plutonium being as available as it is
[16:12:25] <alex_joni> and that was for real.. not imaginary ;)
[16:12:32] <CIA-12> 03alex_joni * 10emc2/src/hal/drivers/hal_stg.c: some comments fixed, and model added as insmod param
[16:12:46] <alex_joni> was looking inside through a glass, seemed a bit distorted not very much
[16:12:51] <dmess> bbl ... gotta pick up my wife... she's real too... but in imagine alot... lol
[16:12:54] <alex_joni> and I asked what kind of glass it is..
[16:13:06] <alex_joni> they said it's lead-glass 1.5m thick ;)
[16:13:23] <dmess> no crap ehh
[16:13:28] <cradek> wow
[16:13:34] <alex_joni> yeah.. great
[16:13:53] <alex_joni> played a bit with those wire-manipulators you see in the movies, that was great
[16:14:00] <cradek> how transparent is 1.5m lead glass?
[16:14:10] <alex_joni> a LOT more than you would expect
[16:14:17] <alex_joni> I thought it's about 20cm thick or so
[16:14:24] <alex_joni> until they told me ;)
[16:14:29] <cradek> neat
[16:14:38] <alex_joni> but if you look at the edges it distorts pretty much
[16:14:47] <alex_joni> like 20-30 degree bending
[16:15:05] <alex_joni> if you get what I mean..
[16:15:13] <alex_joni> kinda hard to explain ;)
[16:16:19] <etla> videos?
[16:17:21] <alex_joni> etla: no
[16:17:29] <alex_joni> not even photos..
[16:17:45] <alex_joni> actually .. I shouldn't have been there at all..
[16:18:15] <alex_joni> you know.. the secret research facility stuff..
[16:18:40] <etla> :)
[16:18:40] <alex_joni> but THEY can't take away my memories.. I hope :P
[16:19:15] <etla> have you thought about moving the website to mediawiki. I think it would be a good idea.
[16:20:35] <alex_joni_> ahh.. they got me ...
[16:20:47] <alex_joni_> alex_joni_ is now known as alex_joni
[16:23:12] <rayh> <alex_joni> okalleo: try editing the .hal file of yours and make the stepgen.x.max_vel (&accel) about 20% higher than the ini
[16:23:27] <rayh> This didn't make any difference for me a few days ago.
[16:23:29] <alex_joni> rayh: to give stepgen some headroom
[16:23:42] <alex_joni> hmm.. was a thought..
[16:23:46] <rayh> tried 2 times and still.
[16:23:59] <alex_joni> I know it worked for cradek
[16:24:14] <rayh> But now the more recent code seems to handle an axis much better.
[16:24:32] <rayh> You were talking about coordinated linear and angular motion.
[16:24:59] <alex_joni> well in okalleo's case the ini seems so wrong
[16:25:01] <cradek> rayh: what problem are you talking about?
[16:25:15] <rayh> the planner did/does run the rotary so that it completes in the time the linear takes.
[16:25:21] <okalleo> In the 1960 KTH (the tecnichal univercity of Stockholm) had a experimental reactor on the campus (see how smart Swedes are)
[16:25:28] <rayh> following errors
[16:25:31] <okalleo> * okalleo is back
[16:25:56] <cradek> rayh: interesting - there were late fixes of that in emc1, maybe some of them didn't get into emc2
[16:26:13] <rayh> I wonder if that could be the case.
[16:26:15] <cradek> rayh: or, stepgen is broken for rotary
[16:26:15] <alex_joni> okalleo: where are you from?
[16:26:34] <rayh> Matt was working on individual axis max vel
[16:27:04] <rayh> so that if the rotary was going to go faster than it's max, the planner would slow down the linear.
[16:27:14] <cradek> and that DOES work in emc1
[16:27:21] <rayh> But accel for the rotary was still not honored.
[16:28:12] <cradek> I agree, I seem to remember there was still a problem with the rotary's accel
[16:28:31] <cradek> (I remember it accelerating VERY slowly)
[16:28:33] <okalleo> alex_joni: I'm born in sweden, but I'm not proud of that
[16:28:41] <rayh> Yes. The planner made it accel at the rate of the linear.
[16:28:49] <alex_joni> okalleo: been to sweden recently, great country
[16:29:16] <alex_joni> the language is bad though ;)
[16:29:16] <alex_joni> was in Lund, super-nice city
[16:29:58] <okalleo> alex_joni: south of france is less bad... I think I belong in the sub tropics
[16:30:28] <alex_joni> so you're in france now.. nice (maybe a pin on frappr might be something you would do :P)
[16:31:47] <okalleo> yep, btw for those who missed it the irc server did not let me use my old nick: chinamill (the server hates my adsl jumoing up and down)
[16:32:12] <alex_joni> oh.. so you're chinamill.. ok then ;)
[16:32:19] <rayh> Oh okalleo=chinamill
[16:32:26] <okalleo> yes
[16:32:27] <alex_joni> did you try to register the nick?
[16:32:49] <rayh> doh. rayh is slow if he catches on at all.
[16:32:54] <okalleo> yes, I did..
[16:32:58] <cradek> rayh: you're not the only one
[16:33:31] <alex_joni_> alex_joni_ is now known as alex_joni
[16:35:43] <rayh> Have you heard of BDI-emc locking up a computer on the last few lines of gcode?
[16:36:03] <cradek> the whole computer?
[16:36:18] <alex_joni> if it's older then 4.30 it might
[16:36:29] <rayh> yep. The reset or power switch is all that works.
[16:36:38] <Jymmm> kill -9
[16:36:42] <Jacky^> rayh: always at the same point ?
[16:37:06] <rayh> Yes.
[16:37:23] <rayh> and does it on several different gcode programs.
[16:37:28] <Jacky^> seems really strange
[16:38:17] <rayh> almost like the task planner reaches the end of the canonical stack but gets pointed to nothing.
[16:38:52] <les_w> I have never seen that problem
[16:39:01] <rayh> to bad we can't read dmesg after it.
[16:39:01] <cradek> I've never run programs on that version...
[16:39:21] <cradek> rayh: do you know exactly which bdi4 version it is?
[16:39:55] <rayh> I don't but will email the contact and see if he can get that info.
[16:40:19] <rayh> pree 4.30 would do this?
[16:40:26] <rayh> It could be a 4.20
[16:40:48] <alex_joni> pre 4.30 had a FP bug in some libs
[16:40:50] <rayh> but I've not heard of it happening there either.
[16:40:52] <cradek> rayh: we don't know the extent of the breakage, but running emc DOES corrupt any floating point math in the rest of the system
[16:40:55] <alex_joni> which caused segfaults and all
[16:41:03] <les_w> what was the last redhat version?
[16:41:16] <cradek> les_w: after 9, they started calling it fedora
[16:41:16] <alex_joni> FC4
[16:41:18] <rayh> TNG
[16:41:18] <alex_joni> :P
[16:41:23] <cradek> ha
[16:41:30] <cradek> three different answers, all right
[16:41:31] <rayh> is our last RH version
[16:41:35] <alex_joni> 3 people, 3 answers :D
[16:42:23] <alex_joni> the latest RH BDI was TNG (6.something iirc), redhat went on till 9, now it's called Fedora (lat version Fedora Core 4)
[16:42:32] <les_w> Well, still have redhat on the machines, but compiled latest emc about a year ago.
[16:42:37] <alex_joni> s/lat/last/
[16:43:01] <les_w> after drilling 80,000 holes...I thend to see any problems
[16:43:15] <Jacky^> wow
[16:43:24] <les_w> in general that vintage of emc is rock stable
[16:43:32] <rayh> Certainly. I think jmk's farm compiles it nightly on 2.18, 2.20, and TNG.
[16:43:33] <les_w> never crashes or locks
[16:43:37] <Jacky^> les_w: do you use Fedora ?
[16:44:03] <alex_joni> rayh: not nightly, only when new changes occur in CVS
[16:44:12] <les_w> no, just an old redhat6.something
[16:44:13] <rayh> Oh. Sorry.
[16:44:45] <alex_joni> rayh: don't be ;)
[16:45:15] <les_w> I do live with some probably now fixed minor things like messages being delayed
[16:48:15] <les_w> I have had many power outages before I had the thing on a UPS, and even that never phased it. Never trashed a file.
[16:48:36] <rayh> cradek: when you say "running emc" breaks floating point. What versions and OS's do we know this happens with?
[16:48:40] <les_w> or at least a file that wasn't fixed later...
[16:48:42] <alex_joni> les_w: got lucky..
[16:48:55] <Jymmm> les_w : 5 second delayed message that reads "Will self-destruct in 3... 2... 1"
[16:48:56] <les_w> yeah
[16:48:58] <alex_joni> rayh: bdi4.2x - bdi4.29 I think
[16:49:05] <cradek> rayh: I think it was fixed in 4.29 but I'm not sure
[16:49:09] <cradek> rayh: I *know* 4.30 is fixed
[16:49:22] <alex_joni> df
[16:49:25] <alex_joni> huh
[16:49:29] <rayh> Okay. So all 4.xx before 4.30.
[16:49:35] <alex_joni> wrong keyboard ;)
[16:49:35] <Jymmm> ok, so is there a 4.30 ISO ?
[16:49:36] <cradek> rayh: yes
[16:49:40] <cradek> Jymmm: yes
[16:49:46] <alex_joni> Jymmm: a few weeks old
[16:49:54] <rayh> That may account for this case and I'll report that and see what shakes out.
[16:49:58] <alex_joni> although mirrors are NOT up to date
[16:50:12] <alex_joni> Jymmm: since September I think
[16:50:22] <alex_joni> http://dsplabs.utt.ro/~juve/emc/
[16:50:23] <Jymmm> ok
[16:50:33] <okalleo> * okalleo is back
[16:50:52] <alex_joni> Imperator's mirror is 4.29
[16:51:02] <alex_joni> wildrice up to 4.29 too
[16:51:14] <alex_joni> neuron has 4.30
[16:51:31] <alex_joni> sherline has 4.18
[16:52:14] <okalleo> I tried to put back the values of my emc1 setup in my emc2 ini and raised the acc and vel in core stepper; I still get some joint following errors but alot less than before.
[16:52:32] <alex_joni> keep increasing them
[16:52:34] <alex_joni> a bit
[16:52:46] <okalleo> I'll test...
[16:53:26] <Jacky^> alex_joni: whats puppy emc2 ? a minimal distro ?
[16:53:44] <alex_joni> Jacky^: that's a live mini-distro running emc2
[16:54:00] <Jacky^> cool, how many space it take ?
[16:54:34] <Jacky^> could fit in a mini cd ?
[16:54:57] <okalleo> I experienced crashes with bdi4.30 when running long programs
[16:55:05] <alex_joni> 30 MB
[16:55:10] <Jacky^> nice
[16:55:21] <alex_joni> Jacky^: best would be an USB stick I think
[16:55:50] <Jacky^> a business card like credit card would be nice too
[16:55:57] <Jacky^> cd rom ..
[16:56:10] <okalleo> * okalleo is away: wbbs
[16:56:12] <Jacky^> for old pc that have not boot from usb
[16:57:03] <Jacky^> I want to try it :P
[17:03:39] <SWP_Away> SWP_Away is now known as SWPadnos
[17:05:17] <Jacky^> http://www.robot-italy.com/product_info.php/cPath/1_78/products_id/441
[17:05:58] <Jymmm> If you were to have a manual stepper controller, what would be a "natural" speed selection control? A knob just doens't seem right to me.
[17:06:38] <rayh> slider
[17:07:03] <SWPadnos> knobs are OK, that's what you use on a power feed
[17:07:34] <SWPadnos> look at
http://www.cncgear.com/MPG/ for some really crappy photos of the step generator I made
[17:08:08] <Jymmm> SWPadnos: wheres the details of it?
[17:08:24] <SWPadnos> I'm about to put up some nicer phots, plus the manual
[17:12:59] <Jymmm> SWPadnos: url?
[17:13:16] <SWPadnos> one sec - it'll be in the same place - I'm cropping and resizing stuff
[17:13:42] <Jymmm> oh, you LITERALLY meant right now. heh
[17:16:44] <SWPadnos> heh - yep
[17:18:05] <cradek> unsaid.45rtq2222222222222hbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
[17:18:12] <cradek> 10:51:00 < alex_joni> wildrice up to 4.29 too
[17:18:15] <cradek> 10:51:12 < alex_joni> neuron has 4.30
[17:18:17] <cradek> 10:51:29 < alex_joni> sherline has 4.18
[17:18:20] <cradek> 10:52:12 < okalleo> I tried to put back the values of my emc1 setup in my emc2
[17:18:22] <cradek> ini and raised the acc and vel in core stepper; I still get
[17:18:25] <cradek> some joint following errors but alot less than before.
[17:18:28] <cradek> 10:52:30 < alex_joni> keep increasing them
[17:18:30] <cradek> 10:52:32 < alex_joni> a bit
[17:18:33] <cradek> 10:52:44 < okalleo> I'll test...
[17:18:35] <cradek> 10:53:24 < Jacky^> alex_joni: whats puppy emc2 ? a minimal distro ?
[17:18:38] <cradek> 10:53:42 < alex_joni> Jacky^: that's a live mini-distro running emc2
[17:18:40] <cradek> 10:53:58 < Jacky^> cool, how many space it take ?
[17:18:43] <cradek> 10:54:32 < Jacky^> could fit in a mini cd ?
[17:18:45] <cradek> 10:54:55 < okalleo> I experienced crashes with bdi4.30 when running long
[17:18:48] <cradek> argh
[17:18:50] <cradek> sorry!
[17:21:14] <alex_joni> cradek: common mistake, it's like the keys are right next to each other
[17:22:24] <cradek> the cat sat his copious back end on the keyboard AND mouse that time
[17:22:29] <Jymmm> SWPadnos : Are you done yet?
[17:22:30] <Jymmm> SWPadnos : Are you done yet?
[17:22:30] <Jymmm> SWPadnos : Are you done yet?
[17:22:40] <SWPadnos> stop bugging me :)
[17:23:20] <Jymmm> * Jymmm hands SWPadnos man convert
[17:25:26] <SWPadnos> I suppose I should edit out those fingerprints on the board ;)
[17:25:35] <Jymmm> hell no
[17:25:51] <Jymmm> just post the shit
[17:26:06] <Jymmm> * Jymmm lights a fire under SWPadnos ass.
[17:26:18] <SWPadnos> I can't work any more - it's too hot
[17:26:48] <alex_joni> SWPadnos: I'd suggest you stop farting
[17:27:07] <SWPadnos> there's a lot of soldering flux on the board as well - maybe I should just wait ;)
[17:27:40] <Jymmm> SWPadnos: Just remember... payback is a bitch.
[17:27:45] <SWPadnos> heh
[17:36:01] <SWPadnos> OK - reload the page now
[17:36:36] <Jymmm> just porn now.
[17:36:42] <SWPadnos> oops -wrong dir
[17:37:00] <SWPadnos> you'll probably need to reload the linked photos as well
[17:37:24] <SWPadnos> now - that's my fingerprint - don't go copying it and stuff
[17:38:19] <Jymmm> Copying? Shit... It's already been digitized and BitTorrented
[17:39:21] <Jymmm> SWPadnos: so, are you making/selling these? How many axis per board ?
[17:39:26] <okalleo> I dont know if You got my message (the sever hated me again).
[17:39:48] <Jymmm> okalleo Register your nick.
[17:40:34] <alex_joni> Jymmm: looks like 1
[17:40:54] <SWPadnos> I have made and sold one, and each board can do 2 axes, with a display daughtercard
[17:41:02] <alex_joni> but probably you can stack em
[17:41:04] <okalleo> When I raised the acc and vel in core stepper by almost a factor 10 I could use more normal ferror and min_ferror without joint following errors
[17:41:06] <SWPadnos> the software only does one axis at the moment
[17:41:25] <alex_joni> okalleo: try factor 25.4
[17:41:26] <SWPadnos> not quite stackable - the display would be an issue ;)
[17:41:29] <alex_joni> * alex_joni has a suspicion
[17:41:33] <Jymmm> SWPadnos what are you selling them (it) for ?
[17:41:38] <SWPadnos> lots ;)
[17:41:53] <SWPadnos> the first was $200, but included some engineering time
[17:42:05] <alex_joni> SWPadnos: $50+?
[17:42:08] <alex_joni> ouch :)
[17:42:11] <SWPadnos> heh
[17:42:19] <Jymmm> if mor ethen $12.50 it's a rip off!
[17:42:19] <SWPadnos> the encoder alone costs $22
[17:42:31] <alex_joni> that's why I said 50
[17:42:32] <alex_joni> :P
[17:42:38] <Jymmm> SWPadnos why an encoder?
[17:42:41] <SWPadnos> (that's with the rotary encoder for speed setting, and all the connectors, of course)
[17:42:49] <SWPadnos> didn't you read the manual?
[17:43:01] <alex_joni> I must say it isn't very clear ;)
[17:43:08] <SWPadnos> the manual?
[17:43:44] <alex_joni> yes
[17:43:48] <Jacky^> an old idea from a friend of mine:
http://xspace.sourceforge.net/
[17:44:13] <Jymmm> SWPadnos: the manual assumes the user knows everything.
[17:44:39] <SWPadnos> heh - ok, it's more like instructions than a manual
[17:44:59] <Jacky^> it seem to me someone was talkilng about cad/cam yesterday
[17:45:01] <SWPadnos> as I said, it was a one-off design for a specific customer
[17:45:11] <Jymmm> SWPadnos: "Manual Pulse Generator" Yeah ok, but wheres' the description of the product? The list of features?
[17:45:32] <SWPadnos> hey - I'm not a marketing guy ;)
[17:45:37] <Jymmm> "WHAT DA HELL DOES THIS DAMN THING DO?"
[17:46:12] <SWPadnos> well - I could add a description of the product to the manual
[17:46:25] <Jymmm> SWPadnos: You dont have to be, but have you ever come across a widget that everyone is saying "that's awesome" and you going "Uhhhhhhhhhhhhhhhhhhh, what is it?"
[17:46:28] <SWPadnos> but the guy that bought it knew what it would do, since he asked for it ;)
[17:47:00] <SWPadnos> I've been meaning to actually make a product line of this kind of thing, but I always end up stuck on IRC
[17:47:08] <les_w> haha
[17:47:12] <Jymmm> SWPadnos; But what about the old fart with a BP that wants this, but doesn't knwo what it is or what it's called.
[17:47:40] <SWPadnos> actaully - that's why I made it the way I did, so you can go from powerfeed to CNC in two steps
[17:47:47] <SWPadnos> (that's what my customer wanted it for)
[17:48:00] <SWPadnos> or manual -> CNC
[17:48:10] <Jymmm> SWPadnos: is the manual/cnc automatic switchover?
[17:48:18] <SWPadnos> no
[17:48:27] <Jymmm> flip of a switch?
[17:48:30] <SWPadnos> this was designed as an interim step betwen manual and CNC
[17:48:41] <SWPadnos> but, there is no reason that I can't make the software do that
[17:48:57] <SWPadnos> the serial port was intended for computer control, such as indexing
[17:49:37] <SWPadnos> with an appropriate (software) driver, it could be used with emc as an outboard rate generator (though you'd need a fast serial port)
[17:49:38] <okalleo> * okalleo is away: _
[17:50:07] <les_w> selling tronics huh?
[17:50:13] <Jymmm> SWPadnos ok, whats this encoder thingy (it's not a pot) ?
[17:50:14] <SWPadnos> well - that's the hope
[17:50:27] <SWPadnos> no - it's a grayhill encoder, used like a digital pot
[17:50:37] <Jymmm> SWPadnos Why?
[17:50:44] <les_w> link again SWP?
[17:50:51] <Jymmm> http://www.cncgear.com/MPG/
[17:50:57] <SWPadnos> it allows you to set speed exactly, and also have other controls set the speed (for example, a serial command from a computer
[17:51:14] <SWPadnos> it's kind of like the NIST guideline of control only from one place
[17:51:20] <Jymmm> SWPadnos and a 10Turn pot could do this?
[17:51:27] <SWPadnos> no
[17:51:32] <Jymmm> why not?
[17:51:41] <SWPadnos> a pot has a setting which is invariant
[17:51:48] <SWPadnos> an encoder changes the current setting
[17:52:21] <SWPadnos> so if you switch between manual and computer control, you don't want it to suddenly change to full speed (because that's where the pot is)
[17:52:40] <SWPadnos> the encoder makes all changes relative to what's on the display
[17:53:16] <SWPadnos> incidentally, it's also useful for tuning Geckodrives - it's a reversible pulse stream
[17:53:24] <Jymmm> SWPadnos I understand that part, but I see this types in stock car radios. I'm sure as hell dont think they're using encoders though... more like a limitless pot (I would think).
[17:53:53] <SWPadnos> you mean the stock radio in a car?
[17:54:22] <SWPadnos> those are definitely encoders, just not nice optical ones with pushbuttons
[17:54:24] <Jymmm> Yeah, kill the ign, and when you strtup again, the volume has been lowered.
[17:54:42] <les_w> so you own cncgear.com domain?
[17:54:51] <SWPadnos> any car that has a "mode" button and a single knob is using an encoder
[17:54:57] <SWPadnos> les_w, yep - that's mine
[17:55:19] <Jymmm> SWPadnos you dont mention this fancy encoder is Included
[17:55:24] <SWPadnos> it is
[17:55:24] <Jymmm> in the manual
[17:55:33] <SWPadnos> nope - that would be in the ad copy, if there were any ;)
[17:55:38] <Jymmm> SWPadnos it's not in the manual you damn geek!
[17:56:02] <les_w> I was wondering where the ad copy was
[17:56:11] <SWPadnos> as you can see, I haven't fully developed this into a saleable product yet ;)
[17:56:35] <SWPadnos> I could sell the boards as a kit - that might work out better
[17:56:44] <Jymmm> SWPadnos I dont know, doesn't look like you carved that PCB yourself
[17:56:51] <SWPadnos> actually, it's also set up so you can drive a small 4-phase stepper directly
[17:57:06] <SWPadnos> no, I don;t do that kind of thing - prototypes are cheap these days
[17:57:19] <SWPadnos> also, I did sell one, so it had to loko professional
[17:57:29] <SWPadnos> (I cleaned the fingerprints and resin off that one ;) )
[17:57:31] <les_w> This morning I have been studying ways to foldback business profitsback into the company before the end of the year
[17:57:46] <SWPadnos> buy big stuff
[17:57:49] <Jymmm> les_w company jet
[17:58:10] <SWPadnos> I can suggest a really good PCB design package, and a very nice 3D CAD package
[17:58:11] <Jymmm> SWPadnos pic of the encoder?
[17:58:15] <les_w> looking at VMC, other things
[17:58:17] <SWPadnos> you can drp $20k on those
[17:58:21] <SWPadnos> drop
[17:58:28] <SWPadnos> one sec
[17:58:46] <Jymmm> les_w VNC? The remote access application?
[17:59:10] <Jymmm> les_w if so, you might check out TightVNC (iirc)
[17:59:16] <les_w> Well, yeah used late model Haas about 25K
[17:59:18] <alex_joni> he said VMC
[17:59:27] <les_w> VMC not VNC
[17:59:33] <Jymmm> ah, nm
[17:59:46] <SWPadnos> http://www.grayhill.com/Grayhill.nsf/947848defbb4d47e8625682c006b98b9/d6c5db22369d0aa786256846007185ff/$FILE/E-15-16.pdf
[18:00:03] <les_w> I was even looking at crazy things like firewood processors
[18:00:22] <Jacky^> Jacky^ is now known as Jacky^dinner
[18:00:26] <Jymmm> les_w about how much you want to fold back in?
[18:01:01] <les_w> not sure
[18:01:05] <les_w> 50 or something
[18:01:19] <Jymmm> ok, gimme a few to think
[18:01:45] <les_w> Need to keep my people working in other than turkey call season
[18:02:08] <SWPadnos> computer: $5k, PCB / schematic / FPGA package: $13k, 3D CAD package: $5k, VMC: $27k
[18:02:10] <Jymmm> * Jymmm knows a nice Spec Analyzer for $86K
[18:02:20] <les_w> And machines, most any machines are so cheap now
[18:02:50] <Jymmm> les_w solar panels
[18:03:14] <les_w> like firewood processor....1-4 cords/hr, about 30k
[18:03:22] <Jymmm> lol
[18:03:27] <SWPadnos> does it make you any money?
[18:03:42] <les_w> I was just checking that's all
[18:03:42] <Jymmm> SWPadnos saves him in aching backs
[18:03:49] <les_w> I't all marketing
[18:03:59] <SWPadnos> you should get a particleboard maker, to use up all the sawdust you generate from the turkey calls
[18:04:07] <les_w> combine it with solar kilns...
[18:04:10] <SWPadnos> or an MDF compressor
[18:04:44] <les_w> All firewood here is green. It just won't dry.
[18:05:04] <Jymmm> les_w OH OH OH.... a wood powder coater
[18:05:06] <les_w> Kiln data gets split wood down to 20% MC in six days
[18:05:43] <les_w> Some I note make the kilns from old refrigerated shipping containers
[18:05:45] <Jymmm> les_w fuck it... get yourself a laser engraver
[18:06:19] <les_w> The machines I get need to be such that I am not involved
[18:06:27] <les_w> something my people can do
[18:06:33] <SWPadnos> video games
[18:06:37] <les_w> I am maxed out doing engineering
[18:06:47] <Jymmm> les_w can they use a computer?
[18:06:48] <les_w> haha SWP
[18:07:03] <les_w> jymmm: no mostly not
[18:07:10] <Jymmm> les_w laser engracer just uses corel.
[18:07:43] <Jymmm> les_w what about pool tables/cues - equip to make them
[18:07:49] <les_w> out in the country there is little manufacturing. The smart people leave. Only dummies left.
[18:07:56] <les_w> and me;)
[18:08:01] <les_w> cough
[18:08:02] <SWPadnos> ahem
[18:08:13] <les_w> haha
[18:08:17] <Jymmm> whats the difference?
[18:08:27] <les_w> heh
[18:08:29] <Jymmm> * Jymmm snickers *
[18:08:43] <les_w> I have no one to run a vmc
[18:08:50] <rayh> Uh...
[18:08:52] <Jymmm> SWPadnos btw, that encoder better give BJ's for the cost.
[18:08:53] <les_w> but split firewood? yeah.
[18:09:11] <SWPadnos> it is expensive, but very nice
[18:09:20] <SWPadnos> you could use any encoder that takes 5V input
[18:09:28] <SWPadnos> or 12V, as long as the output is 5V
[18:10:37] <Jymmm> les_w I bet a wood powder coater would keep you folks busy, especially if you cna come up with various desings/style/patterns
[18:10:43] <SWPadnos> the board could be a lot cheaper if you leave off the switching regulator, the expensive connectors, and the expensive encoder
[18:10:54] <SWPadnos> and the serial port and interface chip
[18:11:17] <Jymmm> SWPadnos: Just sell two or three variants of it.
[18:11:21] <SWPadnos> (leaving just a few discretes, a ceramic resonator, and a processor
[18:11:25] <Jymmm> using the same PCB
[18:11:32] <les_w> Funny I was talking to someone on the phone talking about powder coated wood panels
[18:11:36] <SWPadnos> oh, and the LED driver chip and LEDs
[18:11:38] <SWPadnos> :)
[18:11:53] <SWPadnos> like I said - selling the board and a few key parts in a kit might be the best way
[18:12:08] <SWPadnos> plus the software, and I/O specs
[18:12:15] <les_w> leaded components?
[18:12:28] <SWPadnos> only the connectors and LED sockets
[18:12:46] <SWPadnos> unless you mean RoHS, in which case - who knows?
[18:13:00] <Jymmm> SWPadnos_ anyhow... nice product. good luck (but dont seel yourself short either).
[18:13:05] <Jymmm> sell
[18:13:19] <les_w> I would imagine a surface mount bag'o'parts kit would be a tough sell?
[18:13:34] <SWPadnos> could be
[18:13:41] <SWPadnos> and the switcher is all SMT
[18:13:57] <Jymmm> * Jymmm wouldn't buy a SMT kit
[18:14:18] <SWPadnos> right
[18:14:29] <les_w> I have to do all my SMT under a B&L stereozoom
[18:14:39] <SWPadnos> actually, if I could sell a few dozen, the price could be as little as $100 each, including the encoder
[18:15:28] <Jymmm> SWPadnos polish up the manual and the ad copy (vaporware).
[18:15:55] <SWPadnos> yeah - I should do that
[18:16:05] <SWPadnos> and maybe even write the serial interpreter code
[18:16:12] <SWPadnos> plus add ramping , etc
[18:16:15] <Jymmm> SWPadnos I'm not an editor, but I can help with the verbage.
[18:16:28] <SWPadnos> thanks, I may take you up on it
[18:16:30] <Jymmm> SWPadnos KEEP IT SIMPLE STUPID
[18:16:42] <SWPadnos> I'll write it, and maybe send it to you so I can find out what I forgot ;)
[18:16:46] <Jymmm> SWPadnos dont go adding shit till you get it out the door
[18:16:46] <les_w> cnc accesories could be an ok business
[18:17:04] <les_w> although I have decided not to get into the chinese cnc router thing
[18:17:11] <SWPadnos> it needs to be functional before I sell it. right now, it's just a powerfeed driver for a Gecko (or two)
[18:17:25] <les_w> look at all of them on ebay
[18:17:29] <Jymmm> SWPadnos also consider xylotex board
[18:17:32] <SWPadnos> that's not a great thing, and you need a programmer to change the software
[18:17:38] <SWPadnos> yeah
[18:17:57] <SWPadnos> it should have a remote update facility before getting sold
[18:17:57] <alex_joni> mmm.. yummy
[18:18:00] <SWPadnos> (remote = serial)
[18:18:07] <alex_joni> leftover chilli I made for lunch ;)
[18:18:07] <Jymmm> les_w You need a nitch, but I bet it can be done. I wanted one with a laser myself.
[18:19:15] <Jymmm> * Jymmm smacks SWPadnos! Quit being a geek... If it's functional as it stands now, just polish up. Not add headaches.
[18:19:20] <les_w> They are all trying to sell the things dropped shipped from shanghai
[18:19:35] <les_w> no inventory, no demonstrators
[18:19:42] <les_w> ridiculous
[18:20:32] <Jymmm> les_w: Well, the thing that is making money is service related businesses: cellphone, cable, satellite (tv and radio), VoIP, DSL, NetFlix, etc
[18:21:35] <les_w> I have been watching this guy...what a clown
[18:21:38] <les_w> http://cgi.ebay.com/CNC-WOOD-ROUTER-ENGRAVER-CAD-CAM-3D_W0QQitemZ7568383663QQcategoryZ57122QQrdZ1QQcmdZViewItem
[18:23:37] <alex_joni> ouch.. shipping cost 900$
[18:23:59] <les_w> BTW colleage finally saw one of these machines
[18:24:08] <les_w> horribly engineered
[18:24:30] <les_w> 900... and no insurance whatsoever!
[18:25:36] <alex_joni> http://cgi.ebay.com/CNC-Router-Engraver_W0QQitemZ7570107242QQcategoryZ57122QQrdZ1QQcmdZViewItem
[18:25:38] <alex_joni> that seems better
[18:26:03] <alex_joni> not by much though
[18:26:11] <alex_joni> need to add motors, spindle, drives, software
[18:26:26] <Jymmm> les_w: Why dont you make semi-custome kits?
[18:26:53] <Jymmm> alex_joni unsupported rails on the X axis
[18:27:40] <Jymmm> alex_joni 600 ppl looked at it and no bids
[18:27:56] <alex_joni> yeap
[18:28:28] <Jymmm> and he's nolting the the fram together with what looks like it'll never stay/be square frame
[18:28:55] <Jymmm> POOR engineeing - even I could do better than that.
[18:29:37] <cradek> yeah the one bolt in each corner does look pretty bad doesn't it
[18:29:39] <Jacky^dinner> Jacky^dinner is now known as Jacky^
[18:29:54] <SWPadnos> not if you like diamond shapes
[18:30:01] <Jymmm> cradek VERY bad - if he end clamped it would improve 100%
[18:30:10] <alex_joni> http://cgi.ebay.com/CNC-ROUTER-MILLING-MACHINE-ENGRAVER-Made-in-Germany_W0QQitemZ7571062437QQcategoryZ57122QQrdZ1QQcmdZViewItem
[18:30:16] <alex_joni> how about this one?
[18:30:42] <les_w> better
[18:30:55] <les_w> as is this...actually has a showroom
[18:31:03] <les_w> http://cgi.ebay.com/New-Industrial-CNC-Router-51-x-98-x-8_W0QQitemZ7570957775QQcategoryZ57122QQrdZ1QQcmdZViewItem
[18:31:25] <Jymmm> If you lokk at his feedback.... he bought a router mount from K2CNC, which is the one I have
[18:31:51] <les_w> ha
[18:32:03] <Jymmm> alex_joni again, unsupported rails
[18:32:34] <les_w> yeah
[18:33:07] <Jymmm> It's a good router mount, but he's either being lazy, or just stealing design ideas.
[18:33:16] <les_w> well, I talked a lot with the chinese factory where these are made. Strictly amateur engineering
[18:33:55] <Jymmm> les_w: Do you know where to buy the plastic caps for linear rail bolt covers?
[18:34:00] <les_w> We considered re engineering them, but they would steal the IP for sure. They seemed like slick operators.
[18:34:32] <alex_joni> I wonder how they did the tandem axis
[18:34:32] <les_w> Don't know where to get the caps.
[18:34:32] <alex_joni> http://www.schleppmesser.de/CNC_Frasmaschine_Frase_Portalfrasmaschine_Top.jpg
[18:34:36] <alex_joni> Imperator_: hello
[18:34:48] <Imperator_> Hi Alex
[18:34:52] <alex_joni> Imperator_: noticed you have bdi4-29 on your mirror, not 4.30
[18:35:14] <les_w> x axis=jello
[18:35:23] <Imperator_> ah, right have to mail my college to update it
[18:36:22] <Imperator_> alex_joni: i think the new PCNC can do that
[18:36:37] <alex_joni> yeah.. but it's open-loop
[18:36:40] <alex_joni> :(
[18:37:52] <Imperator_> Jymmm: this caps are product specific, ask the manufactor of your rails
[18:37:58] <Imperator_> jep alex
[18:38:17] <les_w> I don't use them
[18:38:27] <les_w> so the holes fill with grease
[18:39:10] <Jymmm> les_w: I was getting dust in mine, which get into the slides. That's why I was asking how often do you lube your macine.
[18:39:17] <Jymmm> Imperator_ thanks
[18:39:56] <les_w> Anyway the light industrial chinese cnc thing set off way too many alarm bells in my head.
[18:40:29] <les_w> Hobby market stuff might be ok though.
[18:40:52] <Imperator_> without the caps you kill the sealing of the runners
[18:41:04] <les_w> yes true
[18:41:22] <Jymmm> Imperator_: I have some spares, but I want a source for more.
[18:41:27] <les_w> my ways are mostly covered and sealed though
[18:41:37] <les_w> bottom of z is open though.
[18:42:10] <Jymmm> alex_joni
http://www.schleppmesser.de/
[18:42:19] <alex_joni> yeah.. I posted that above
[18:43:06] <Jymmm> alex_joni OH YOU DID NOT! =)
[18:43:15] <alex_joni> [20:34] <alex_joni>
http://www.schleppmesser.de/CNC_Frasmaschine_Frase_Portalfrasmaschine_Top.jpg
[18:43:17] <les_w> 100 newtons would bend those unsupported ways several mm i'll bet
[18:43:22] <alex_joni> [20:42] <Jymmm> alex_joni OH YOU DID NOT! =)
[18:43:38] <Jymmm> alex_joni lies! all lies!
[18:43:55] <Jymmm> http://www.cnc-step.com/englisch/index.html
[18:46:03] <Jymmm> seems they have a bigger one too :
http://www.cnc-step.com/englisch/Plexiglas_frasen_cnc_Portalfrasmaschine_Frase_S1000_Step_3_4.jpg
[18:46:15] <alex_joni> same sh*t
[18:46:34] <alex_joni> http://www.schleppmesser.de/CNC_Frasmaschine_HIGH_Z_S1000x600_mm_Verfahrweg_Frase_3.jpg
[18:47:51] <les_w> critical speed on those srew must be what
[18:47:55] <les_w> 100 rpm?
[18:47:57] <les_w> haha
[18:48:28] <etla> hi les, I'm designing a mill also, interested to hear about how critical speed limits feed
[18:49:11] <dmess> im searchin for a decent old stepper control machine
[18:50:03] <les_w> etla, on larger machines it is a big issue
[18:50:36] <etla> ok, so if I have 16mm diam ballscrews which are maybe 800mm long and bearings at both ends
[18:50:53] <etla> then the screw should be able to do 1500 rpm during rapids ?
[18:51:03] <les_w> In general screws need to be less than about 50:1
[18:51:21] <dmess> i was thinkin 56 mm screws and 8 M travel
[18:51:22] <les_w> It depends a lot on end fixity....fixed fixed is best
[18:51:59] <dmess> with cradles to avoid screw whip
[18:52:07] <les_w> you can get critical speed charts from ballscrew manufacturers
[18:52:26] <les_w> clever scissor type travelling cradles can help a bunch
[18:52:54] <les_w> or block /tackle driven
[18:52:56] <etla> hmm what's a travel cradle
[18:53:32] <les_w> it is a support that moves along at half speed
[18:53:47] <les_w> with a loose bearing to support the screw
[18:54:04] <dmess> i like it LES
[18:54:09] <les_w> so when the ballnut is at end of travel
[18:54:20] <les_w> the cradle is about in the middle
[18:54:44] <les_w> yeah, works real good
[18:54:47] <dmess> avoids falling off the edge.. syndrome
[18:54:49] <alex_joni> how does it move at half speed?
[18:54:59] <les_w> can be just a loose teflon bearing or something
[18:55:25] <les_w> alex: scissor or block/tackle/cable
[18:55:54] <alex_joni> I see.. thought driven by the screw
[18:56:03] <les_w> right
[18:56:10] <dmess> its a slip +.010" on pitch diameter...
[18:56:12] <alex_joni> that would be harder ;)
[18:56:39] <les_w> well it is driven off of the moving axis
[18:56:57] <dmess> so its ALWAYS linked
[18:57:01] <les_w> yeah dmess +.010 would be fine
[18:58:07] <dmess> hold up the reciever another .002-.003 " to allow for deflection
[18:58:09] <les_w> such a thing can quadruple critical speed...but you still have to watch bucking loads
[18:58:18] <les_w> buckling
[18:58:52] <anonimasu> * anonimasu nodshm
[18:58:53] <anonimasu> hmm
[18:59:07] <dmess> the follower HAS to be tight in linear rigidity...
[18:59:20] <les_w> Even with fixed/fixed one end must be allowed to slide axially
[18:59:28] <les_w> because screws get warm
[18:59:34] <dmess> and properly angularily alighned
[18:59:34] <les_w> and grow
[18:59:58] <Jymmm> les_w: Here you go les... look at the bid and view counts -->
http://search.ebay.com/7568393590
[19:00:51] <dmess> yes... always... Nitrogen cylinder on the end of the lead screw loads it up evenly regardless of temp and loads...
[19:01:24] <anonimasu> hmm
[19:02:14] <les_w> yes...I use stacked bellvile washers to do the same thing
[19:02:23] <dmess> always heavier on one side... but its calibrated
[19:02:27] <les_w> looking at those bids
[19:03:30] <dmess> nitros availibale down to 1.2 od thd cylinder... 3/16 piston..
[19:03:38] <alex_joni> strange bids.. why would anyone bid more than once?
[19:03:42] <dmess> 1/2
[19:04:02] <les_w> does look strange
[19:04:09] <les_w> looks like schills
[19:05:04] <anonimasu> hm would that be a reasonable price for that machine?
[19:05:13] <SWPadnos> $50
[19:05:35] <les_w> haha...let me look at it...
[19:05:37] <SWPadnos> I particularly like the particleboard table
[19:06:06] <SWPadnos> oh wait - that is actual plywood, not particleboard
[19:06:06] <anonimasu> ye�
[19:07:05] <SWPadnos> The control chip on this board uses the latest control chip technology"
[19:07:12] <SWPadnos> that's why I'm not into marketing ;)
[19:07:23] <les_w> Well, it's pretty flimsy.
[19:07:36] <les_w> I try to be into marketing.
[19:07:57] <SWPadnos> sure, but it's hard ;)
[19:08:22] <les_w> I would say the thing needs to be in the one kilobuck range.
[19:08:25] <les_w> no more
[19:08:48] <les_w> 900 something
[19:09:01] <les_w> and prettied up a little
[19:10:08] <alex_joni> SWPadnos: seen the stuff Jacky pasted a while back?
[19:10:16] <alex_joni> it's actually usefull for a change ;)
[19:10:16] <alex_joni> http://www.acmesystems.it/?id=4
[19:10:54] <alex_joni> about 150$
[19:11:15] <les_w> neat
[19:11:23] <alex_joni> very much so..
[19:12:21] <les_w> That router guy really needs that surplus low cost mic-6 aluminum I posted about for the bed
[19:12:48] <alex_joni> sell him some ;)
[19:12:52] <Jacky^> inedit video italian troups in action in nassiriya:
http://www.rainews24.it/ran24/clips/Video%5C08122005_256k.wmv
[19:14:35] <SWPadnos> oh yeah - I've seen that board - it's linked from the AXIS developer site
[19:14:44] <SWPadnos> (no - not that AXIS)
[19:14:51] <alex_joni> right
[19:14:53] <SWPadnos> I can't seem to get one delivered here though
[19:15:24] <SWPadnos> I thought about prototyping the digital camera on that board
[19:15:34] <alex_joni> try ImageCrat
[19:15:36] <alex_joni> try ImageCraft
[19:15:42] <alex_joni> http://www.acmesystems.it/?id=11
[19:15:59] <SWPadnos> but the processor is pretty expensive, especially the module with flash / SDRAM on it
[19:18:38] <SWPadnos> they list imagecraft as the US distributor, but they seem to not carry the hardware
[19:19:48] <SWPadnos> OK - I found it - it's only on the order page, they have no other description on their site
[19:21:05] <alex_joni> seen the TUX case?
[19:21:05] <alex_joni> :))
[19:21:28] <SWPadnos> yeah - cute
[19:21:30] <alex_joni> http://www.acmesystems.it/?id=21
[19:21:36] <alex_joni> very nice.. I like the mold
[19:22:01] <SWPadnos> oooohhh -shiny ;)
[19:22:11] <alex_joni> homer mode on
[19:22:18] <SWPadnos> yeah
[19:22:26] <SWPadnos> gott arun - see you later
[19:22:30] <SWPadnos> SWPadnos is now known as SWP_Away
[19:22:40] <Jymmm> les_w: You are just in the wrong business is all...
http://www.secondskinimages.com/statuegirl.htm
[19:23:22] <SWP_Away> I'd like to be the "costume" person :)
[19:24:14] <dmess> shiny molds arre a Biatch to build... been there
[19:24:36] <Jymmm> molds?
[19:25:27] <dmess> mirror polish required but with acidic hands ... i cant touch them... moulds.. if you rather
[19:25:59] <alex_joni> SWP_Away: seen the smalles TUX?
[19:26:00] <alex_joni> http://www.secondskinimages.com/statuegirl.htm
[19:26:05] <alex_joni> not that.. damn
[19:26:11] <alex_joni> http://microscopy.fsu.edu/creatures/pages/linuxpenguin.html
[19:26:25] <dmess> i cant touch past machining or edm stage...
[19:26:53] <Jymmm> dmess where did mold topic come into play?
[19:27:13] <etla> a_j: hmmm. 130 um, maybe I should make an even smaller one at work...
[19:27:15] <dmess> o rit shows up in the plastic.
[19:28:30] <dmess> shinny plastic.... was the thermal.. 500 fpm up... slight n/e..... sky is purrple where i am...
[19:30:50] <alex_joni> ok.. later guys
[19:32:49] <les_w> was watching jacky's video....
[19:33:07] <les_w> I might go outside now and do farmer stuff
[19:33:50] <Jymmm> Cya Farmer Les!
[19:34:25] <dmess> i did farmer stuff this AM... ; )
[19:34:36] <Jymmm> milk cows dmess ?
[19:35:10] <les_w> still have plenty of tractor work to do
[19:35:12] <dmess> no cows... kids killed the goats....
[19:35:19] <les_w> it's a little cool though
[19:35:21] <les_w> 45F
[19:35:34] <dmess> i collect SHiet in the am
[19:35:45] <les_w> sunny but some clouds moving in
[19:35:53] <dmess> below 0 c here
[19:36:03] <les_w> solar radiation currently 400 watts/meter^2
[19:36:21] <Jymmm> les_w : Got Cnadles?
[19:36:25] <dmess> how are you monitoring it
[19:36:49] <les_w> this station is about 200 yards from me:
[19:37:04] <les_w> http://www.griffin.uga.edu/aemn/cgi-bin/AEMN.pl?site=GATG&report=c
[19:37:26] <dmess> my friend is going OFF GRID in a straw bale house
[19:38:09] <dmess> you cheat...
[19:38:18] <les_w> strw bale...cool. Jymmm click graph data
[19:38:55] <les_w> notr thr "rainfall"...it's just frost.
[19:39:11] <les_w> keyboard is sticking badly
[19:39:18] <dmess> its plastered and drywalled like any other houes.... but the walls are 4 - 6 ft theck
[19:39:25] <les_w> another one of those prototypes
[19:39:43] <les_w> I read about then in mother earth
[19:40:00] <dmess> nope.. many homes built and lived in...
[19:40:26] <les_w> I mean the keyboard I am using is a prototype
[19:40:36] <dmess> Stephen has built 8-10 in the last 2 yrs
[19:41:29] <dmess> we usually hear at the end of the season.... we back-up..
[19:41:44] <les_w> too damp for them here I think...it is so damp that inthe summer the street is wet 24 hrs a day
[19:42:12] <dmess> i'll get the picks off Rich
[19:42:19] <les_w> mildew actually grows on car paint
[19:43:11] <dmess> no matter .. on styrophome blocks.. and sealed
[19:44:08] <dmess> so every 5 yrs .. you use it as a smudge for the bugs...
[19:46:21] <les_w> bet it's warm
[19:46:33] <les_w> r500 or something
[19:49:50] <Jymmm> les_w graph data... what am I looking for?
[19:50:12] <Jymmm> Hey 530Watts now =)
[19:50:22] <Jymmm> err peak I mean
[19:50:35] <les_w> nothin really...it's just a meteogram
[19:51:02] <Jymmm> les_w kinda cool... even part of USGS... nice
[19:51:03] <les_w> it will drop big time in a minute...cirrostratuss moving in
[19:51:33] <les_w> on a cloudy day it is usually only 30 watts/m^2 or so
[19:51:40] <les_w> eyes are very nonlinear
[19:51:57] <Jymmm> les_w since it's only 200yards away... you should muck with it.... build a fire around it, then drop about 40 lbs of dry ice
[19:52:05] <les_w> in june it's 1000W
[19:52:11] <les_w> haha
[19:52:28] <les_w> well the anemometer is not working right...I know that
[19:52:33] <Jymmm> les_w keep doing that till the grpah makes a happy face or something.
[19:52:42] <les_w> heh
[19:52:59] <Jymmm> les_w I'm serious... they'll eventually figure it out
[19:53:00] <les_w> It is actually linked via a land line
[19:53:55] <les_w> I was gonna but my own weather station...but don'tneed to now
[19:54:08] <les_w> buy
[19:54:14] <Jymmm> though, I'm not sure what you could create =(
[19:54:24] <Jymmm> les_w and much better one too
[19:54:39] <Jymmm> oh, it auto-updates too
[19:55:35] <les_w> yeah
[19:55:49] <les_w> gets pretty cold for this far south huh
[19:56:09] <Jymmm> I need to take off about .003 - .005" from a piece of aluminum that's 1" x 2" sq, manually, but it needs to remain sqaure. any suggestions?
[19:56:33] <les_w> hmm
[19:56:43] <Jymmm> 400grit is awefully slow (dry)
[19:56:50] <cradek> belt sander!
[19:56:57] <les_w> haha
[19:57:04] <Jymmm> I think it was 400 grit.
[19:57:11] <les_w> phosphoric acid!
[19:57:19] <les_w> or lye
[19:57:25] <cradek> surface grinder, obviously
[19:57:51] <Jymmm> cradek: Ok, will try that.... please place your left testical into the vice clamps so when it doesn't work I'll have soemthign to take my frustrations out on!
[19:58:02] <les_w> I don't have the right wheels for aluminum
[19:58:33] <les_w> using mostly norton 32a ceramic on the surface grinder these days
[19:58:41] <les_w> better than the pink ones
[19:58:55] <Jymmm> surface grinder for aluminum?
[19:58:57] <cradek> Jymmm: in all seriousness, I'd try a single cut file, or sandpaper and patience
[19:59:12] <les_w> yes you can grind aluminum
[19:59:23] <les_w> with a special wheel
[19:59:24] <cradek> Jymmm: depends how serious you are about "square"
[19:59:26] <Jymmm> cradek: I was trying 400 but awefully slow.
[19:59:38] <cradek> Jymmm: use 150 first, then switch to 400
[19:59:47] <les_w> 400 would remove about i micron per hour haha
[19:59:51] <Jymmm> cradek: It's the block that attaches from the ballnut to the gantry
[20:00:10] <Jymmm> if it's not sqaure, it'll make the ballnut bind
[20:00:19] <cradek> Jymmm: then measure often
[20:00:41] <cradek> Jymmm: if you use a single-cut file, hold the block, not the file, in your hand and it'll stay square
[20:00:52] <les_w> It's true you can make anything with a file
[20:01:05] <les_w> it is a hand help complete machine shop
[20:01:13] <cradek> les_w: only with patience and skill
[20:01:14] <les_w> held
[20:01:17] <Jymmm> What does wet sanding accomplish -vs- dry ?
[20:01:29] <cradek> the sandpaper doesn't fill up so easily
[20:01:35] <cradek> you can also get a better finish
[20:01:40] <Jymmm> so a tad more abrasive?
[20:01:48] <cradek> try kerosene/alumicut
[20:02:02] <les_w> I use kero.
[20:02:04] <Jymmm> all I have is water and tapping fluid
[20:02:20] <Jymmm> acetone, xylene
[20:02:28] <les_w> Pity I could have that cut for you in about 2 minutes
[20:02:58] <Jymmm> les_w all it takes is the right tool for the job =)
[20:03:14] <Jymmm> les_w have you thought about getting a cnc center?
[20:03:51] <les_w> just studying it. Like I said, I need to dump some profits soon
[20:04:19] <Jymmm> les_w buy a shitload of GPS'es and sell em =)
[20:04:27] <les_w> I would rather put it back in the business than pay a bunch of tax.
[20:05:03] <Jymmm> les_w get a laser
[20:05:15] <les_w> I was gonna just get a second vertical mill...cnc
[20:05:42] <Jymmm> les_w with a laser, you can get into plastics some too.
[20:05:48] <Jymmm> non PVC though
[20:05:48] <les_w> See, my time is maxed out. I need stuff my people can run.
[20:06:04] <Jymmm> they can run a laser
[20:06:18] <Jymmm> it's just a fansy printer
[20:06:19] <les_w> ha
[20:06:21] <Jymmm> fancy
[20:07:18] <les_w> One of my guys could...he is a retired engineer.
[20:07:26] <anonimasu> *yawns*
[20:07:53] <les_w> anon is tired of being admired again!
[20:08:14] <anonimasu> haha
[20:08:18] <anonimasu> never
[20:10:19] <anonimasu> clear
[20:10:22] <anonimasu> what's up?
[20:10:48] <les_w> nothing really
[20:11:17] <anonimasu> hm ok
[20:11:27] <anonimasu> I've been messing with the spinning nut stuff a bit in my head today
[20:11:34] <anonimasu> although a very little bit..
[20:11:47] <les_w> just contemplating more ways to make money.turning into a capitalist maniac
[20:11:58] <les_w> spinning nut?
[20:12:04] <anonimasu> yeah
[20:12:05] <anonimasu> on the mill
[20:12:08] <les_w> two things I think of...
[20:12:17] <anonimasu> my Z axis moves the whole table..
[20:12:23] <les_w> dynamic balance and grease slinging
[20:13:07] <anonimasu> we mount central grease systems at work ;)
[20:13:45] <les_w> I have auto lube on the router and surface grinder.
[20:14:36] <Jymmm> les_w: Make a cnc KIT
[20:14:52] <les_w> yeah worth a thought
[20:14:52] <Jymmm> les_w fab the parts, and let them build it.
[20:15:33] <les_w> VMC would be good for that....
[20:15:45] <Jymmm> what is VMC ?
[20:16:02] <les_w> Hey I was gonna call that one guy with the 52 bids and tell him about the mic-6
[20:16:05] <les_w> but nahhh
[20:16:22] <les_w> Vertical Machining center
[20:16:28] <Jymmm> ah, ok.
[20:16:35] <anonimasu> but I am not quite sure how dynamic balance would be issue
[20:16:44] <anonimasu> since the nut will be mounted into the base of the machine..
[20:16:47] <les_w> depends on the speed
[20:17:12] <les_w> might not be a problem
[20:17:19] <anonimasu> I've got plenty of space for bearings..
[20:17:33] <Jymmm> les_w I'm sure you could design a hobby/sm shop 'enconomy' router far better than anything out there.
[20:17:52] <les_w> Even the collet nut is dynamically balanced on my new electrospindle
[20:17:55] <Jymmm> les_w hell, even sell the plans and jsut the critical parts.
[20:18:08] <anonimasu> with a duplex bearing arrangement balance shouldnt be a issue
[20:18:11] <les_w> Jymmm, wel I think I could design a good one
[20:18:44] <Jymmm> les_w Yep, and even use 80/20 in the desing too
[20:18:44] <anonimasu> I dont know if I should go with > bearings though
[20:18:44] <Jymmm> design
[20:18:56] <les_w> I drew up some rotating ballnuts....complcated assembly
[20:19:30] <Jymmm> les_w: My Z is acme... it's actually pretty good surprisingly.
[20:20:08] <les_w> gosh if I designed a kit machine the size of yours...
[20:20:09] <les_w> hmm
[20:20:46] <Jymmm> les_w: I can tell you the pros/cons I've had if you decide to do that.
[20:20:59] <anonimasu> bbiab..
[20:21:10] <Jymmm> anonimasu thanks for the warning =)
[20:21:25] <les_w> Steel....15mm abbas....grouted construction
[20:21:41] <Jymmm> grouted?!
[20:21:42] <les_w> possibly conventional screws
[20:21:57] <les_w> yeah. Glues together.
[20:22:02] <les_w> glued
[20:22:06] <Jymmm> oh
[20:50:39] <anonimasu> iab
[21:02:14] <anonimasu> ^_^
[21:04:04] <Jymmm> geeeeze... no warning!
[21:07:03] <Jymmm> fuck me... they are selling yahoo email addresses on ebay?!
[21:07:19] <Jymmm> and getting bids too!
[21:08:04] <jepler> *snickers*
[21:08:15] <Jymmm> one is up to $76
[21:08:44] <jepler> it had better be a pretty good address
[21:19:48] <anonimasu> hm
[21:20:20] <alex_joni> Jymmm: got a link?
[21:32:01] <skunkworks> we figured out the z loosing steps - as we figured it wasn't the computer.
[21:33:58] <skunkworks> actually we don't know the why. We where using compumotor s6 drive. we switched to an oem650 and it stopped loosing steps. Don't know if we where not driving the s6 hard enough or what. the imputs are the same (opto-isolated with about a 220 ohm resister in series)
[21:49:05] <skunkworks> Plus we are going to change the gearing so that the scale will be 10000 instead of 20000
[21:49:13] <okalleo> * okalleo is back
[21:50:32] <alex_joni> skunkworks: great news
[21:52:22] <skunkworks> any thoughts on the acceleration issue? Do you think there should be a bug report? Or is it just me?
[21:53:58] <alex_joni> skunkworks: you mean having axes with different accels?
[21:54:35] <jmkasunich> skunkworks: its not just you
[21:54:37] <skunkworks> jmk had posted a very informitive reply to my jogging issue bug.
[21:54:48] <skunkworks> and there he is ;)
[21:54:52] <alex_joni> he's the man to ask..
[21:55:04] <jmkasunich> the stepgen component needs to have headroom, both in velocity and maybe even more important in accel
[21:56:11] <skunkworks> I did that - both velocity and accelleration - that worked great. the problem I have now is it seems I cannot set different accelleration for each axis
[21:57:07] <skunkworks> the max_accelleration in each axis does not seem to have effect - only the default_accelleration in the traj section
[21:57:41] <skunkworks> (I had to set the max acceleration for the stepgen componant to almost twice what the ini file had.) but it worked.
[21:59:17] <skunkworks> thanks again. the problem is my z axis seems to max out at about 3 ips^2 while my x and y can go over 10ips^2.
[22:00:24] <skunkworks> I would like to be able to make each axis run at the maximum accelleration it can consitatly run. Right now I can only run the whole system at the 3ipm^2
[22:00:39] <skunkworks> and now I am babling ;)
[22:09:07] <fenn> skunkworks: these are the sorts of reasons we want to write a whole new trajectory planner
[22:09:40] <fenn> although, you can set the default accel higher and it will still respect the axis limits
[22:10:00] <alex_joni> fenn: I really am pleased with all that... but you need to figure out how the thing works first..
[22:10:19] <alex_joni> just the other day I looked at it, and most of the action is happening in emccanon.cc not TP
[22:10:19] <fenn> the current one?
[22:10:48] <alex_joni> yup
[22:11:03] <alex_joni> not in TP.. screw that, it doesn't do much
[22:11:25] <alex_joni> but in emc2
[22:12:32] <skunkworks> it really does some funky stuff if you set the default_acceleration higher than one of the axises max_acceleration.
[22:12:44] <skunkworks> overshoot and stuff
[22:12:53] <fenn> where in emccanon.cc are you talking about?
[22:13:36] <fenn> oh man this is all screwed up
[22:13:59] <fenn> they're using joint acceleration limits to set the accel in cartesian space
[22:14:01] <alex_joni> fenn: for instance getStraightVelocity() does the velocity clamping
[22:14:21] <alex_joni> actually those aren't joint acceleration limits
[22:14:30] <alex_joni> they are cartesian acceleration limits
[22:14:41] <alex_joni> and they are AXES in the ini, not JOINTS
[22:14:44] <fenn> AXIS_MAX_VELOCITY[0] is a cartesian?
[22:14:54] <alex_joni> although that's a BAD way to build the ini
[22:15:04] <alex_joni> fenn: after looking at the code, yes
[22:15:14] <fenn> that doesnt make any sense
[22:17:13] <fenn> it would probably still work for a hexapod, but a puma or scara would be screwed
[22:17:28] <fenn> well, sorta work at least
[22:17:31] <alex_joni> although the HOME position inside the [AXIS_x] section refers to joints
[22:17:43] <fenn> yeesh
[22:17:53] <alex_joni> I guess so
[22:18:07] <alex_joni> it's pretty heavy fscked up (notationwise)
[22:18:23] <alex_joni> but then again.. I might have read it wrong
[22:18:23] <alex_joni> and the code is correct
[22:18:24] <alex_joni> who knows ;)
[22:18:41] <fenn> how do i know if axis_max_velocity is the value from the ini?
[22:18:53] <alex_joni> anyways.. emccanon does some non-RT planning
[22:18:59] <fenn> looks like it
[22:19:11] <fenn> who woulda thunk
[22:19:16] <alex_joni> AXIS_MAX_VELOCITY[0] <-this one?
[22:19:22] <alex_joni> that one is from the ini..
[22:20:00] <fenn> stupid globals..
[22:27:26] <fenn> there is so much stuff in canon that either doesn't belong there or doesn't do anything that i cant even tell what it's supposed to do
[22:28:11] <CIA-12> 03alex_joni * 10emc/src/ (9 files in 3 dirs): reverted Keith Rumley's changes in order to prepare HEAD for a release. the changes are on the rumley_changes branch.
[22:28:33] <fenn> what all has to be done to emc to finalize it?
[22:29:19] <alex_joni> sorry?
[22:29:49] <fenn> preparing for a release.. what remains to be done?
[22:30:12] <fenn> actually i dont care about emc1, what do i need to do to emc2?
[22:31:07] <alex_joni> fenn: a few things..
[22:31:09] <alex_joni> HAL naming stuff
[22:31:16] <alex_joni> config stuff
[22:31:16] <alex_joni> make install stuff
[22:31:50] <alex_joni> bug-fixes
[22:32:33] <alex_joni> then the bridgeport equivalence in config (to be emc1-equal at least), minimill seems to be working ok now
[22:51:42] <fenn> here's another bug for the pile
[22:52:59] <fenn> i dont get this at all
[22:53:10] <fenn> just wrote a test nc file
[22:53:12] <alex_joni> what?
[22:53:23] <fenn> apparently it doesnt like it
[22:54:13] <fenn> G0X0Y0Z0
[22:54:24] <fenn> that's the whole ifle
[22:54:31] <cradek> what doesn't like it?
[22:54:41] <cradek> you need M2 or %s to make it a valid program
[22:56:32] <fenn> ok that was the problem. error messages didnt help
[22:57:45] <cradek> [G-Code error in go.ngc] On line 1 of /home/chris/go.ngc: Internal error: NCE_FILE_NAME_TOO_LONG [OK]
[22:57:57] <cradek> this is what AXIS says, and I agree it's a strange error
[22:58:26] <fenn> ok now i'm getting another weird error
[22:58:35] <CIA-12> 03jmkasunich * 10emc2/configs/ (core_stepper.hal emc.ini): a short term fix to ensure that stepgen has some acceleration headroom over the commanded accel coming from the trajectory planner.
[22:59:15] <fenn> G0X0Y0Z0; G1 X0 Y1; M2
[22:59:19] <fenn> on separate lines of course
[22:59:37] <fenn> cannot do zero repeats of a cycle
[22:59:56] <cradek> the error should be "cannot do G1 with feed rate of 0"
[23:00:05] <cradek> we're getting totally wrong errors
[23:00:17] <alex_joni> fenn: what emc are you using?
[23:00:24] <fenn> just cvs up-ed
[23:00:34] <jmkasunich> the errors are looked up in a table, maybe somebody removed or added one and threw the table off?
[23:01:03] <alex_joni> fenn: what emc are you using?
[23:01:07] <cradek> 2
[23:01:15] <alex_joni> emc1, emc2?
[23:01:40] <alex_joni> cradek: you too?
[23:01:40] <alex_joni> getting weird errors?
[23:01:57] <cradek> still testing
[23:02:02] <skunkworks> sorry was away. jmk - how did you acomplish this? will this change what I have done as a bandaid? Meaning if I update emc will it cause me problems?
[23:02:22] <alex_joni> skunkworks: it won't cause you problems..
[23:02:26] <jmkasunich> skunkworks: it is pretty much the same thing you did as a band-aid
[23:02:45] <alex_joni> because you have locally modified files, and those won't get changed during the merge (you changed in the same place)
[23:02:53] <jmkasunich> I assume you are using renamed copies of the ini files with your machine specific stuff in them, so it will have no effect at all
[23:03:29] <skunkworks> thanks
[23:03:46] <jmkasunich> what I did was fix #2 in that long reply I wrote to the bug report
[23:04:05] <jmkasunich> I think it was #2, better check
[23:04:24] <skunkworks> ok
[23:04:58] <CIA-12> 03alex_joni * 10emc/src/ (6 files in 3 dirs): reverted Keith Rumley's changes in order to prepare HEAD for a release. the changes are on the rumley_changes branch.
[23:05:35] <skunkworks> I will probably go play with the machine a bit more tonight.
[23:13:46] <fenn> something is really borked in emc2
[23:14:04] <jmkasunich> fenn: what is borked?
[23:14:18] <fenn> um, if i knew that i might have some idea what to do
[23:14:27] <fenn> another symptom: emc refuses to go into teleop mode
[23:14:28] <SWP_Away> SWP_Away is now known as SWPadnos
[23:14:40] <SWPadnos> how does the borkage appear?
[23:15:03] <fenn> tkemc is in joint coordinates, refuses to go into machine on state
[23:15:56] <alex_joni> teleop?
[23:16:14] <fenn> it looks like certain nml messages just dont work
[23:16:29] <alex_joni> you have non-trivkins?
[23:16:29] <alex_joni> you can't switch to teleop mode, before homing
[23:17:46] <fenn> i'm using standard .ini files
[23:18:06] <fenn> here look:
http://pastebin.com/458949
[23:18:48] <fenn> opened up tkemc.. said "hmm thats odd it's in joint coords" so i clicked on "world" a couple times
[23:19:06] <fenn> and trying to get out of estop and machine on
[23:19:32] <alex_joni> you don't get TELEOP for trivial-kins
[23:19:38] <alex_joni> did you modify nontrivkins.c ?
[23:20:01] <fenn> want me to do a fresh checkout?
[23:20:59] <alex_joni> yeah.. I'm running mine without problems
[23:21:52] <anonimasu> hm
[23:21:52] <alex_joni> seems you might be somwhere inbetween merges.. or something else is fishy (maybe you touched some files, and they didn't get updated by the latest CVS)
[23:24:42] <alex_joni> fenn: just tried a file with F0, the message was the one that should be
[23:24:55] <fenn> try it without any f word?
[23:25:21] <les_w> heh
[23:25:34] <jmkasunich> jmkasunich is now known as jmk_eating
[23:25:48] <alex_joni> fenn: it runs :)
[23:26:00] <alex_joni> doesn't complain .. that's odd
[23:26:16] <fenn> heh how fast does it go?
[23:32:37] <alex_joni> very slow, I think default_speed or something
[23:32:37] <SWPadnos> SWPadnos is now known as SWP_Away
[23:32:37] <fenn> ok all appears normal with the new checkout
[23:32:37] <alex_joni> phew..
[23:32:37] <cradek> wtf
[23:32:37] <alex_joni> had me worried for a bit
[23:32:37] <cradek> I can't turn machine on in emc2 now
[23:32:37] <alex_joni> ??
[23:32:37] <alex_joni> cradek: do you have estop connected properly?
[23:32:37] <cradek> it goes into estop reset just fine
[23:32:37] <cradek> stat.estop goes to 0
[23:32:37] <alex_joni> does it give any error message?
[23:32:37] <cradek> but stat.enabled is stuck at 0
[23:32:37] <cradek> not without debugging - let me turn it on
[23:32:37] <fenn> cradek i just had that same problem
[23:32:37] <cradek> and it can't unload mbuff
[23:32:37] <cradek> wtf broke??
[23:32:37] <fenn> i do a cvs diff and i dont see anything wrong in the old checkout.. maybe it didnt get all the files it should have?
[23:32:37] <cradek> mbuff: Device or resource busy
[23:32:37] <cradek> ERROR: Could not unload 'mbuff'
[23:32:37] <alex_joni> some buffers in use..
[23:32:37] <alex_joni> motion?
[23:32:37] <alex_joni> try a lsmod..
[23:32:42] <cradek> Module Size Used by Tainted: P
[23:32:42] <cradek> mbuff 8460 2
[23:32:50] <alex_joni> used by 2?
[23:33:03] <cradek> yeah, but it doesn't say what they are
[23:33:03] <fenn> cradek: try realtime stop
[23:33:15] <cradek> % sudo scripts/realtime stop
[23:33:15] <cradek> mbuff: Device or resource busy
[23:33:15] <cradek> ERROR: Could not unload 'mbuff'
[23:33:57] <alex_joni> is there a /proc/rtapi ?
[23:34:06] <cradek> no
[23:34:24] <alex_joni> any other emc-related modules left?
[23:34:28] <cradek> nope
[23:34:37] <alex_joni> strange!
[23:34:46] <cradek> this is very recent breakage
[23:35:03] <alex_joni> but no-one touched emc2-cvs
[23:35:07] <cradek> I was just using emc2 a week ago or so
[23:35:12] <cradek> well I did - I fixed feed override
[23:35:19] <fenn> cradek: did you have the lerman-interp merged in?
[23:35:28] <alex_joni> so did I, but that's about it
[23:35:37] <cradek> fenn: it's head
[23:35:56] <alex_joni> yeah, but head has those merged in now
[23:36:06] <cradek> yeah, that's what I mean
[23:36:12] <alex_joni> cradek: try a cvs diff.. to see if you have anything different
[23:36:13] <cradek> my previous version may have been before that
[23:36:18] <cradek> alex_joni: just inis
[23:36:23] <fenn> alex_joni: does cvs diff find missing files?
[23:36:24] <cradek> alex_joni: ini and hal
[23:36:26] <rayh> I've had a lot of problems with mbuff over the years in both bdi-2 and 4
[23:36:29] <alex_joni> make clean, make?
[23:36:42] <cradek> alex_joni: good idea. probably bogus makefile dependencies again.
[23:36:54] <rayh> sometimes the motstruct do not get pulled out properly.
[23:37:10] <cradek> rayh: I've never had this happen before
[23:37:20] <cradek> rayh: like alex says, it's probably a bad compile
[23:37:24] <rayh> Many many many times
[23:37:34] <rayh> No it is an improper shutdown.
[23:37:55] <alex_joni> I never had it with emc2
[23:38:11] <cradek> I've never had it with emc1 or 2 (but I haven't used 2 much)
[23:38:13] <alex_joni> and I've done some bad things to it
[23:38:27] <rayh> can't speak for emc2
[23:38:29] <alex_joni> * alex_joni grins
[23:38:37] <cradek> rayh: I have rtlinux3.2 which I think is newer than any used on the old bdis
[23:38:49] <alex_joni> cradek: can it be from the recent emc1 you've run?
[23:38:56] <alex_joni> or isn't it the same machine?
[23:39:01] <cradek> same machine
[23:39:10] <cradek> I think it exited correctly, but I will check that (after I reboot)
[23:39:15] <alex_joni> can you humor me with one thing?
[23:39:24] <cradek> of course
[23:39:24] <alex_joni> check the shm id's for both
[23:39:42] <cradek> ?
[23:39:51] <alex_joni> [EMCMOT]
[23:39:51] <alex_joni> EMCMOT = motmod
[23:39:51] <alex_joni> # Key for real OS shared memory, e.g., for simulated motion
[23:39:51] <alex_joni> SHMEM_KEY = 111
[23:39:54] <alex_joni> I think that one gets used..
[23:40:08] <Jymmm> * Jymmm hands alex_joni a lollipop to humor him (and get him to shut up already =)
[23:40:17] <rayh> there is mbuff code in the adeos kernel.
[23:40:22] <cradek> % grep SHMEM_KEY emc2/configs/*
[23:40:22] <cradek> emc2/configs/emc.ini:SHMEM_KEY = 111
[23:40:34] <rayh> In there are several test programs that are not compiled by default
[23:40:41] <cradek> ! grep SHMEM_KEY emc-alex/emc/*.ini
[23:40:41] <cradek> emc-alex/emc/emc.ini:SHMEM_KEY = 100
[23:41:06] <alex_joni> ok..
[23:41:31] <alex_joni> I'm out of ideas
[23:42:06] <cradek> after make clean, it works
[23:42:27] <Jymmm> alex_joni: BTW... that lollipop is coolant flavored... YUM!
[23:42:29] <cradek> still stuck mbuff, rebooting
[23:42:39] <alex_joni> cradek: probably bogus compile the first time..
[23:42:46] <alex_joni> hi petev
[23:42:51] <petev> hi alex
[23:46:32] <cradek> back
[23:50:01] <cradek> huh, I get joint following errors on every jog now
[23:50:08] <cradek> when the jog stops
[23:50:12] <alex_joni> ?
[23:50:20] <fenn> me too
[23:50:31] <SWPadnos_> using stepgen?
[23:50:31] <cradek> reallllly
[23:50:34] <cradek> yes
[23:50:43] <cradek> my headrooms are configured properly
[23:50:44] <alex_joni> what axis speeds
[23:50:44] <alex_joni> ?
[23:50:45] <SWPadnos_> revert the ini change jmk just did - see what happens
[23:50:52] <cradek> .5i/s
[23:51:07] <cradek> SWPadnos_: I don't have that ini change
[23:51:22] <SWPadnos_> ok - I thought it was a fresh checkout etc etc
[23:51:23] <alex_joni> I went up to 1.2i/s
[23:51:25] <alex_joni> works ok
[23:52:06] <cradek> I have no idea what's different
[23:52:32] <alex_joni> very odd..
[23:52:39] <alex_joni> must be friday the 13th today
[23:54:47] <alex_joni> cradek: all axes give ferrors?
[23:54:50] <cradek> yes
[23:55:00] <alex_joni> you have core_stepper.hal?
[23:55:03] <alex_joni> that one did update..
[23:55:04] <cradek> yes
[23:55:34] <alex_joni> can you send me your ini?
[23:55:44] <cradek> I did not take that update
[23:55:58] <cradek> ini is unchanged:
http://timeguy.com/cradek-files/emc/emc.ini
[23:56:02] <alex_joni> or put it online...
[23:56:18] <cradek> I'll put my core_stepper there too
[23:56:25] <alex_joni> I see..
[23:56:37] <fenn> MIN_FERROR was changed to 0.000
[23:56:46] <fenn> that could be a problem
[23:56:53] <alex_joni> fenn: yes it can
[23:58:32] <cradek> alex_joni:
http://timeguy.com/cradek/emc
[23:58:41] <cradek> there are my inis and a picture of halscope showing the ferror
[23:59:21] <Jymmm> cradek: 1 perfect second?
[23:59:32] <cradek> Jymmm: ?
[23:59:57] <Jymmm> not .735s, but EXACTLY one second 1.0000
