#emc-devel | Logs for 2008-05-27

Back
[00:00:23] <jepler> jmkasunich: no problem
[00:00:31] <jepler> I am a tiny bit curious why it wasn't causing a noticed problem
[00:00:44] <jmkasunich> so am I
[00:00:47] <jepler> my best guess is that the number of 4k pages of memory was almost always the same no matter which math you did
[00:00:52] <jepler> but I didn't try too hard to figure it out
[00:01:27] <jmkasunich> it was only the allocation that was wrong, right? if the reads and writes were different sizes there would have been worse problems
[00:01:38] <jmkasunich> oh, I bet I know why
[00:01:48] <jepler> yes, only the allocations
[00:01:53] <jmkasunich> you normally load the RT part first - it reserves the memory space
[00:02:00] <jmkasunich> and it was correct
[00:02:10] <jepler> yes it was created with the right size then mapped with the wrong size in one of two places
[00:04:08] <jmkasunich> /* check if a block is already open for this key */
[00:04:28] <jmkasunich> /* is it big enough? */
[00:04:28] <jmkasunich> if (shmem->size < size) {
[00:04:38] <jmkasunich> shmem_addr_array[shmem_id] = rtai_malloc(key, shmem->size);
[00:04:58] <jmkasunich> rtapi checks that the pre-existing block is as big or bigger than the request
[00:05:11] <jmkasunich> and then uses the pre-existing size, not the request, to do the map
[00:05:33] <jepler> maybe it should squawk if there's a mismatch
[00:05:43] <jepler> no, forget that
[00:05:58] <jmkasunich> just another message for us to explain to people
[00:06:27] <jmkasunich> it squawks ( and fails) if it is too small
[00:08:30] <jmkasunich> I'm rather pleased with rtapi - its been pretty low-maintainence
[00:08:37] <jepler> yeah it really has
[00:09:46] <jmkasunich> did you make a flavor of rtapi that worked with a "stock" kernel using the rt_preempt patch?
[00:09:59] <jepler> well .. kinda-sorta
[00:11:08] <jepler> jmkasunich: if you want to look at that, http://axis.unpy.net/01190912545
[00:12:15] <jmkasunich> the "rt" code runs in userspace doesn't it
[00:12:16] <jepler> I don't think it works for #threads > 1, and drivers that use the kernel interfaces to find pci devices won't compile
[00:12:26] <jepler> yes, it's a hack on the existing 'sim' code
[00:12:53] <jepler> I think that kernel threads can get the same (or slightly better?) rt performance but there would have been more to write in that case
[00:13:15] <jepler> but userspace/pthreads-type APIs seem to be what is promoted these days
[00:13:32] <jmkasunich> yeah - it might be interesting to take that the rest of the way someday
[00:13:56] <jmkasunich> if I ever get moving on mesa stuff again my machine might become a no-base-thread system
[00:14:06] <jmkasunich> I'll still want a couple of RT threads tho
[00:14:26] <jmkasunich> 4-5KHz for spindle motor control, and the usual 1khz for emc
[00:15:41] <jepler> I think that hostmot2 in TRUNK can do stepgens
[00:16:03] <jmkasunich> I think so, but I have in mind more than that
[00:16:08] <jmkasunich> I want to do a soft VFD
[00:16:28] <jepler> hm2_<BoardType>.<BoardNum>.pet-watchdog
[00:16:28] <jepler> Pet the watchdog to keep it from biting us for a while.
[00:16:30] <jmkasunich> three phase PWM generation and serial A/Ds will both be required
[00:16:42] <jepler> aww how cute
[00:16:51] <jmkasunich> usually you kick the dog
[00:16:53] <jepler> actually i'm thrilled that there's a manpage for this
[00:17:29] <jmkasunich> yeah, seb seems to know his stuff and do a very complete job
[00:19:24] <jepler> hostmot2 has SPI functions, they're just not in the HAL driver yet
[00:19:42] <jmkasunich> * jmkasunich suffers from NIH
[00:19:51] <jmkasunich> I have some specific things I want to do with the A/D
[00:20:22] <jmkasunich> namely, a 32 bit register that consists of a 22 bit "running sum of all readings" and a 10 bit "running count of readings"
[00:20:32] <jepler> ah yes
[00:20:39] <jmkasunich> the A/Ds I have in mind can sample at a few hundred kilosamples/sec
[00:20:42] <jmkasunich> nearly a meg actually
[00:20:55] <jmkasunich> that approach lets me average over a period's worth of samples
[00:20:58] <jepler> is that a "clear to zero on read" register?
[00:21:02] <jmkasunich> nope
[00:21:10] <jepler> how's it work when you overflow the 22 bits?
[00:21:13] <jmkasunich> subtract old from new
[00:21:18] <jepler> ah
[00:21:35] <jmkasunich> modulo 22 bits, it will probably take me a try or two to get that right
[00:21:41] <jepler> heh yeah
[00:21:54] <jepler> that's got to be only half as hard as sign-extending
[00:22:02] <jepler> like on ppmc or pluto
[00:23:22] <jmkasunich> speaking of iterated projects - how goes the dimmer?
[00:25:22] <jepler> haven't touched it since the night I was bugging you about it
[00:25:32] <jmkasunich> heh
[00:25:36] <jmkasunich> I know how that goes
[00:25:57] <jepler> next I have to write all the clock & I/O functions and that's a bit of work
[00:26:54] <jepler> not to mention a PITA to debug
[00:27:11] <jepler> "aw crap, the lamp came on at 3AM again .. I wonder what's wrong"
[00:27:16] <jmkasunich> those bugs that happen once a day
[00:27:59] <jmkasunich> cradek had a "once every leap year" bug in one of his clocks
[00:27:59] <jepler> cradek asked me a good question, which is: will the skew between the ZC detect and the actual zero cross be the same under load or not
[00:28:33] <jepler> it seems like that's about the load on the transformer secondary which will not change by much at any time
[00:28:41] <jmkasunich> it will be affected to some degree by the load on the transformer, but that should be nearly constant
[00:29:05] <jmkasunich> I would expect little or no effect due to load on the line (the lamp itself)
[00:29:45] <jepler> of course it's rated 85mA on the secondary, so 5mA of current to an LED (indicator or optotriac) is more than 5% load change
[00:29:58] <jmkasunich> heh
[00:30:02] <jmkasunich> that is one tiny transformer
[00:30:11] <jepler> (the current on the optotriac led being much less than continuous-duty of course)
[00:31:09] <jmkasunich> if it turns out to be a problem there is a brute force solution - have another path that draws the same current but simply heats a resistor, and make it the inverse of the LED state
[00:31:21] <jmkasunich> not exactly the green approach
[00:33:24] <jepler> heh
[00:33:28] <jepler> yeah that is a possibility
[02:00:27] <rayh> Hey guys I just got a request from poutine to be unbanned. Think I ought to?
[02:02:20] <jepler> it's your call
[02:02:31] <jepler> unban him if you think he won't pull stupid stuff again
[02:02:49] <rayh> He claims an occasional behavioral disorder.
[02:14:04] <SWPadnos> well, he did something really bad, then lied about it, and now claims "the devil made him do it" (or equivalent)
[02:14:16] <SWPadnos> my inclination would be to leave him out, but it is your call
[02:18:45] <jmkasunich> ban ban ban
[02:22:32] <rayh> I asked a few questions and I'll see if he answers.
[02:43:48] <cradek> dumbassery usually doesn't heal as fast as this
[02:44:00] <jmkasunich> nope
[02:44:21] <jmkasunich> and its not like he was a regular contributer to discussions who had a crazy moment
[02:44:31] <cradek> occasional behavioral disorder == "it's not my fault" == dumbassery
[02:44:39] <jmkasunich> he came, he did bad things, now its time for him to go away
[02:44:51] <SWPadnos> the devil, the devil!
[02:44:59] <rayh> He tells me he's a developer. I suggested he send a key to cradek and we'll get him into the CVS>
[02:45:08] <SWPadnos> um - yeah
[02:45:18] <SWPadnos> that's not something I'd vote for at the moment
[02:45:21] <jmkasunich> ditto
[02:45:23] <cradek> that's not the procedure for adding new developers...
[02:45:26] <rayh> hehe
[02:45:58] <rayh> He seems to insist that now he is the injured party.
[02:46:01] <cradek> rayh: that reminds me: there's even a webpage now about that! did you see it?
[02:46:46] <rayh> link?
[02:46:52] <cradek> http://www.linuxcnc.org/content/view/50/13/
[02:46:54] <cradek> finally found it
[02:47:10] <cradek> if he says he wants to contribute, you could point him there.
[02:47:46] <cradek> we'll consider adding "Step 0": dig through the logs to find a password someone accidentally typed, and then use it to be a pain in the ass
[02:48:10] <SWPadnos> then claim temporary insanity
[02:48:12] <rayh> Sounds like I'd never get direct access. Not enough commits.
[02:48:16] <SWPadnos> that's very important
[02:48:19] <rayh> I will point him there.
[02:51:49] <rayh> Night guys. This old guy has had more than enough fun for one day.
[02:52:02] <cradek> goodnight
[02:52:41] <SWPadnos> nighty night
[02:53:48] <jmkasunich> goodnight
[02:54:14] <jmkasunich> I should call it a night too - sitting here and admiring my bench is tough work
[02:54:33] <cradek> I was admiring my welding like that earlier...
[02:55:29] <jmkasunich> did you see my bench pic?
[02:55:35] <cradek> nope
[02:55:42] <jmkasunich> http://jmkasunich.com/pics/new-bench-2109.jpg
[02:55:57] <jmkasunich> my version of the underground laboratory
[02:56:04] <cradek> wow!
[02:56:12] <cradek> what neat shelves
[02:56:28] <jmkasunich> took forever to build (at least that's how it felt)
[02:56:43] <cradek> did you weld the bench yourself?
[02:56:55] <jmkasunich> no
[02:57:15] <jmkasunich> I ground off the welds on one crossmember, moved it, and welded it back on
[02:57:22] <jmkasunich> but the rest was already welded
[02:57:29] <cradek> is the surface gage for looks or do you actually use it? :-)
[02:57:41] <jmkasunich> I use the height gage more
[02:58:00] <jmkasunich> my Dad gave the the surface gage
[02:58:30] <cradek> neat, it's a keeper
[02:58:43] <cradek> looks like you could use more light under the shelves
[02:58:58] <jmkasunich> http://jmkasunich.com/pics/color-case-hardening.jpg <-- surface gage
[02:59:12] <jmkasunich> (somebody was asking about color case-hardening one day, so I took that pic)
[02:59:14] <cradek> cool, I have one just like it
[02:59:21] <jmkasunich> I'
[02:59:32] <cradek> iirc, it says "England" but no name
[02:59:54] <SWPadnos> England is a name
[02:59:58] <jmkasunich> I'm planning to move the light out about 6" (should be easy, two screw job, but not tonight)
[03:00:09] <cradek> ah that might do it.
[03:00:18] <cradek> as long as you don't get head shadows then
[03:00:24] <jmkasunich> besides, you don't use the last 4" of a 30" deep bench
[03:00:25] <cradek> (lighting is hard)
[03:00:38] <cradek> no that's just where the junk collects
[03:01:14] <jmkasunich> I thought about starting the shelves right above the benchtop
[03:01:32] <jmkasunich> but the space allows for stuff like the back end of an o-scope, or a bench supply, etc
[03:01:33] <cradek> nice to have a picture so you can remember what the table surface looks like
[03:02:05] <jmkasunich> yeah, jymm said I should print it out, frame it, and hang it as a reminder
[03:03:29] <jmkasunich> I have 9 more of those drawer units in the garage, I could put some of them along the back of the bench to keep crap from accumulating
[03:03:34] <jmkasunich> but I probably won
[03:03:36] <jmkasunich> 't
[03:03:53] <cradek> did you see the new bus stuff?
[03:05:03] <jmkasunich> I saw that Bill posted his stiches
[03:05:53] <jmkasunich> frankenthumb
[03:06:04] <cradek> it looks pretty normal again, already
[03:06:15] <cradek> he heals fast, which is good, considering
[03:06:30] <jmkasunich> considering how often he damages himself?
[03:06:38] <cradek> :-)
[03:06:41] <jmkasunich> pretty panel
[03:07:05] <jmkasunich> are those corners round but too small to see, or did you square them up with a file or something?
[03:07:26] <cradek> round, but only 1/8 rad
[03:08:00] <jmkasunich> wow, you guys are making lots of progress
[03:08:18] <cradek> yes it's really coming together.
[03:08:39] <jmkasunich> many hands make light work I guess
[03:08:43] <cradek> we will have the big water tank and propanes mounted soon. we have a design (finally)
[03:08:53] <jmkasunich> it took me a month (or more) to get that one corner of the basement done
[03:08:54] <cradek> well it's a LOT of work, but it's fun
[03:09:47] <jmkasunich> is the pic where you are mounting stuff on the panel you "underground laboratory"?
[03:10:04] <cradek> no that's the new shop
[03:10:19] <cradek> 'new'
[03:10:34] <cradek> this spot was always a workbench even when it was the garage
[03:10:40] <jmkasunich> ah
[03:10:42] <cradek> mill is on the very left of the pic
[03:11:06] <jmkasunich> ah, ok
[03:11:12] <jmkasunich> there is a pic farther up of the mill
[03:11:18] <jmkasunich> what is the round duct going up?
[03:11:24] <jmkasunich> stove pipe?
[03:11:45] <cradek> yes there's a woodstove in the downstairs main room, on the other side of that wall
[03:12:03] <jmkasunich> do you get any heat for the shop from the pipe?
[03:12:04] <cradek> in 10 years we have used it 0 times
[03:12:10] <jmkasunich> guess not
[03:12:31] <jmkasunich> what is the beige box on the wall by the pipe?
[03:12:33] <cradek> no but there's great heat now, with that electric heater
[03:13:02] <cradek> phase converter control
[03:13:08] <jmkasunich> ah, that was my guess
[03:13:22] <cradek> to the left is the subpanel for the shop
[03:13:39] <jmkasunich> hiding behind the mill head
[03:13:43] <cradek> yes
[03:19:08] <jmkasunich> aram.... <shakes head>
[03:22:19] <cradek> dang, I have welder sunburn
[03:24:11] <jmkasunich> oops, forgot to cover up?
[03:24:49] <cradek> more like thought about it, and shrugged it off, because it was too warm
[03:24:59] <cradek> stupid
[03:25:33] <jmkasunich> thats one nice thing about gas welding
[03:25:35] <cradek> looks funny too, because I had gloves on
[03:26:10] <cradek> yeah, and you can see
[03:26:49] <jmkasunich> #5 shade is a lot easier to see thru than a 10
[04:12:46] <SWPadnos> you need dimmable LCD
[07:01:03] <alex_joni> SWPadnos: dimmable LCD is evil
[07:06:37] <alex_joni> it's very direction dependent.. I usually weld with the mask in my hand, if I tilt it a bit it reduces the shade factor by a lot
[10:29:07] <BigJohnT> jmkasunich: I noticed in the log where you commented that my sight and hearing must be increable to see/hear such a small change
[10:30:18] <BigJohnT> actually I need reading glasses and lisened to loud rock and roll as a kid so my hearing is not that great either
[10:31:26] <BigJohnT> I noticed the problem that EMC has with arcs when I was cutting some large letters out with an ellipse around them.
[10:31:52] <BigJohnT> the machine was vibrating while cutting the letters to the point I thought something was wrong with my machine
[10:33:00] <BigJohnT> when it got to the ellipse I thought at least that would be smooth... but to my horror the machine shook so bad that it cut a sawtooth pattern on the ellipse that was about 0.050"
[10:33:59] <BigJohnT> so after asking about that cradek explained to me that my arcs were too short and that I should not use sheetcam if it won't generate code that EMC can use at speed.
[10:34:43] <BigJohnT> and that I should only use lines not arcs...
[10:36:10] <BigJohnT> I was trying to demonstrate that the length of the arc was not the problem but the pause before or after and arc was the problem.
[10:36:56] <BigJohnT> I generated an ellipse with a zillion small lines and it cut it perfectly with no change in speed so I know it's not my machine
[10:39:38] <BigJohnT> s/increable/incredible I can't spell either
[10:43:14] <BigJohnT> I guess my next test will be to install Mach3 to see if it will handle a sheetcam file without problems at plasma speeds
[10:52:37] <BigJohnT> I just got an e-mail from the sheetcam guy Les and there is no setting to control the length of an arc in sheetcam only the radius...
[10:54:30] <fenn> you should generate an ellipse with a zillion small arcs
[10:54:44] <fenn> or try arcspiral.ngc
[10:55:18] <BigJohnT> what would that do
[10:55:27] <fenn> not work properly, i'd guess
[10:56:28] <fenn> all i'm saying is an ellipse made of many small lines doesn't say anything about paths made of small ellipses
[10:56:33] <fenn> er, s/ellipses/arcs/
[10:57:12] <BigJohnT> I don't understand
[10:58:18] <fenn> can you tell sheetcam to only output lines?
[10:58:26] <BigJohnT> no
[10:58:31] <fenn> bummer
[10:59:15] <BigJohnT> even cutting out 4" tall letters at plasma speeds is a problem
[10:59:42] <fenn> of course, because you're going fast
[10:59:52] <BigJohnT> it has nothing to do with direction changes either
[11:00:20] <fenn> and the machine isn't stiff enough to just brute-force ignore the velocity change
[11:00:24] <BigJohnT> I can go 450 IPM with small lines that make a circle
[11:00:31] <BigJohnT> smooth as silk
[11:00:53] <BigJohnT> I can only go 50 IPM with arcs before the EMC induced problem show up
[11:01:11] <fenn> oh? even one single big arc?
[11:01:12] <BigJohnT> there should be no velocity change
[11:01:15] <BigJohnT> yes
[11:01:26] <fenn> that sounds like a different sort of bug then
[11:01:33] <BigJohnT> thank you!
[11:02:25] <BigJohnT> one big arc made up of smaller arcs will stop and go so fast that it shakes the whole machine
[11:02:51] <fenn> eh.. 'one big arc made up of smaller arcs' is not what i meant
[11:03:03] <BigJohnT> sorry
[11:03:14] <BigJohnT> bigger arcs once underway are smooth
[11:03:33] <fenn> so, a single g3 command, is limited to 50IPM or not?
[11:03:39] <BigJohnT> at each transition into or out of an arc there is a delay
[11:03:52] <BigJohnT> no a single g2/3 will go 450 IPM
[11:04:36] <BigJohnT> and is smooth throughout the entire arc
[11:59:40] <alex_joni> BigJohnT: it doesn't matter if the bazillion of small arcs all describe the big arc
[11:59:59] <alex_joni> the problem is that the trajectory planner takes 2 of them (the current one and the next one)
[12:00:23] <alex_joni> and it doesn't know what will happen after that.. so it tried to keep speed in such a manner that it could stop at the end of the #2
[12:21:29] <BigJohnT> alex_joni: so if the arc lenght is long enough for the speed/acceleration the movement should be smooth from arc to arc and from line to arc?
[12:24:48] <rayh> Morning BigJohnT
[12:25:18] <rayh> I know that there is no pause in a circle if you write the code as four quadrant moves.
[12:26:56] <jepler> BigJohnT: have you put one of these problematic gcode files on pastebin? I'd like to see it for myself.
[12:35:15] <BigJohnT> ok, I'm back
[12:35:35] <BigJohnT> I created 3 files each with a circle with 360 segements
[12:35:44] <alex_joni> BigJohnT: yes
[12:35:54] <fenn> line segments or arc segments?
[12:36:03] <BigJohnT> one was all arcs one was all lines one was arc/line/arc/line etc
[12:36:11] <BigJohnT> I'm typing as fast as I can
[12:36:37] <BigJohnT> all arc and all lines run smooth and the speed is limited but steady
[12:37:06] <BigJohnT> arc/line vibrates my machine from constant velocity changes
[12:37:25] <BigJohnT> 6" diameter circles
[12:38:23] <BigJohnT> I have to get ready for work now
[13:35:39] <skunkworks_> logger_dev: bookmark
[13:35:39] <skunkworks_> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-05-27.txt
[13:36:12] <alex_joni> hey samco
[13:43:04] <skunkworks_> Hi alex
[18:03:24] <BigJohnT> I apologize if my frustrations were showing their ass this am on the feed issue
[18:03:44] <BigJohnT> I ran a couple more tests when I went home for lunch
[18:04:11] <BigJohnT> I created a 6" diameter circle of 360 arcs and set my feed to 400 IPM
[18:04:32] <BigJohnT> when I ran it the fastest it would go was 150 IPM
[18:05:00] <BigJohnT> I then created a 6" diameter circle of 360 lines and set the feed to 400
[18:05:23] <BigJohnT> to my surprise (not really) the line circle ran at 400 IPM
[18:05:53] <BigJohnT> then I created a 3" diameter circle made of 360 arcs and set the feed to 400
[18:06:04] <BigJohnT> it would run at 100 IPM max
[18:06:20] <BigJohnT> all three ran smooth but at different speeds
[18:06:52] <BigJohnT> the difference in speed of an arc and a line is the root of the problem as far as I can tell
[18:07:01] <BigJohnT> of equal lenght
[18:07:21] <BigJohnT> lines and arcs of equal length I mean
[18:07:31] <SWPadnos> what happens with a single circle?
[18:08:01] <SWPadnos> (out of curiosity - not related to any blending/combining issues)
[18:08:06] <BigJohnT> I didn't try it at 400, I think I did one at 250 with no problem
[18:08:43] <BigJohnT> and 400 is where I have the max speed set even though during testing it would go 550 IPM
[18:11:38] <skunkworks_> SWPadnos: you can see it pretty easy with spiral and arcspiral. (setting g64p.001 for both) (yes I know it doesn't work for arcspiral) You will notice the max velocity reached with arcspiral is much lower unless you crank up the accelleration a ton.
[18:12:02] <jepler> skunkworks_: FOR THE BILLIONTH TIME YES BECAUSE THE "NAIVE CAM DETECTOR" ONLY OPERATES ON LINES
[18:12:08] <jepler> not on arcs or combinations of lines and arcs
[18:12:21] <jepler> (there goes my frustration showing)
[18:13:01] <BigJohnT> sorry
[18:13:17] <skunkworks_> I know - I am just saying that SWPadnos could see it for himself what is happening.
[18:14:41] <BigJohnT> I don't even think I had g64pn set... when I ran the lines
[18:15:45] <jepler> the thing that is frustrating me here is that we don't have the gcode BigJohnT is running, just his prose descriptions of what they are. we're sitting here just taking shots in the dark as to what is going on.
[18:17:01] <jepler> if it really is short arcs or short arcs interspersed with lines, then "live with it" is the only solution right now, unless you're going to contribute improved code to emc.
[18:17:25] <jepler> but at least once BigJohnT told me that the arcs weren't tiny in the original cam-generated gcode that started this whole thing
[18:17:47] <cradek> the gcode I saw a few days ago certainly had tiny arcs.
[18:18:01] <jepler> I missed the actual gcode
[18:18:08] <cradek> I thought I explained fully what was going on (and some strategies for working around it), but I guess not
[18:18:25] <jepler> I admit I haven't followed the whole discussion
[18:18:36] <cradek> it had lines alternating with .001" long arcs
[18:20:04] <jepler> I see.
[18:26:05] <SWPadnos> I guess I could look at it myself :)
[18:31:10] <jepler> cradek: can you recap for me how the centripetal acceleration of the arc influences the point where contouring performance drops?
[18:31:14] <rayh> I'm running BigJohnT's oval right now and anything over 16.25ipm causes the vel value to jump around.
[18:31:27] <BigJohnT> http://pastebin.com/m5a01d732
[18:33:03] <jepler> when comparing arcspiral with spiral using G64 (no P-) they both displayed a drop in speed as they went towards the center of the spiral, with arcspiral maybe being a little slower at a given part. running on sim, so no motors to hear..
[18:33:13] <BigJohnT> sorry I don't have the 6 inch circle from arcs here but here is the 5" one http://pastebin.ca/1031238
[18:34:02] <BigJohnT> the one cradek saw was the first one that started me noticing the problem
[18:34:41] <BigJohnT> the one jepler saw was a test by me to see if it had anything to do with going from an arc to a line or the other way around
[18:35:36] <BigJohnT> now that I'm done breaking drill bits for the day back to tramming the head on the BP
[18:36:57] <cradek> jepler: the velocity along the circle is limited by a=v^2/r
[18:37:45] <cradek> BigJohnT: this file will run great if you just delete all the G3 lines.
[18:38:04] <cradek> I imagine they were a workaround for some OTHER control
[18:38:09] <cradek> can't you make the post not do that?
[18:38:42] <rayh> It looks to me like that circle program has three places on each quadrant where the accel dips.
[18:39:21] <cradek> sorry I was looking at 1031238
[18:40:49] <rayh> circle program at http://pastebin.com/m5a01d732
[18:41:15] <BigJohnT> sorry the second one is a mix of lines and arcs
[18:41:58] <BigJohnT> hmmm I don't have the one with just arcs on the disk I forgot to take out of my pocket sorry
[18:49:02] <BigJohnT> this is one with arcs only, the post was mcam but it should be the same http://pastebin.ca/1031252
[19:04:30] <skunkworks_> hmmm
[19:05:57] <BigJohnT> cradek: I did get an e-mail from Les (programmer for sheet cam) and the minArcSize setting is in mm and is for the length of the arc not the radius as was thought before....
[19:06:11] <alex_joni> those are a lot of tiny arcs
[19:06:39] <SWPadnos> what's the effective plasma cut width?
[19:07:33] <alex_joni> 1-2mm
[19:07:46] <alex_joni> you mean the kerf.. right?
[19:07:53] <SWPadnos> could be :)
[19:08:05] <alex_joni> the slot that results after cutting..
[19:08:09] <SWPadnos> does it make sense to have the CAM path tolerance much smaller than that?
[19:08:18] <skunkworks_> I am running arcspiral and spiral here. I am not seeing what I saw at home. Odd. I have max velocity set to 480ipm and as I am upping the accelleration - the both run about the same speed (g64p.001). arcspiral seems to run a more consistant feed while spiral velocity seems to bounce around a bit. (I will have to play with what I had at home)
[19:09:18] <skunkworks_> with accelleration at 100in/s/s - I am getting a velocity of about 140ipm at the start on both programs.
[19:13:26] <BigJohnT> SWPadnos: a 40 amp tip (the one that you use for thin metal at higher speeds) on my torch is about .050" wide kerf
[19:16:17] <SWPadnos> ok. about how much does that vary along the cut?
[19:16:39] <BigJohnT> IF you keep your speed constant not much
[19:16:41] <alex_joni> SWPadnos: if speed is constant it shouldn't
[19:16:46] <alex_joni> but if you slow down it widens
[19:16:48] <SWPadnos> I'm just wondering if the CAM tolerances are mugh higher than they need to be for the machine type
[19:16:51] <SWPadnos> ok
[19:17:35] <BigJohnT> why does an arc and a line the same length have such differences in speed?
[19:18:03] <jepler> BigJohnT: because when you program G64 P- with nonzero P you activate the naive cam detector which combines some of the lines -- but never changes arcs ever
[19:20:03] <BigJohnT> I'll have to run the circle with lines when I get home to see if it makes any difference. I don't think it did when I was testing the other day
[19:23:33] <BigJohnT> jepler: If I set G64P0 will it ignore the naive cam detector on the lines?
[19:23:43] <alex_joni> BigJohnT: yeah
[19:24:16] <BigJohnT> I'll run the test again when I get back to my fab shop
[19:25:15] <BigJohnT> so with G64P0 I should get the same speed from a circle made with lines or arcs of the same length?
[19:25:46] <cradek> yes probably
[19:25:57] <jepler> there may be some difference because of the centripetal acceleration of the arc
[19:26:16] <alex_joni> and it depends if you have the exact number of arcs/lines
[19:26:20] <jepler> out of the machine's total acceleration, a part can be used for starting/blending/stopping, and a part can be used for the accleration that occurs at all points on the arc
[19:27:18] <cradek> I said 'probably' because I was assuming the arc radii would be relatively large
[19:30:13] <BigJohnT> I'll do the 3 inch radii with equal number to form a complete circle
[19:30:53] <skunkworks_> BigJohnT: did you see this reply? ;) http://www.cnczone.com/forums/showpost.php?p=456901&postcount=6
[19:30:55] <BigJohnT> jepler: the difference would be minor?
[19:31:16] <BigJohnT> skunkworks yes
[19:34:55] <jepler> BigJohnT: I don't have a good feel for how much the circle radius will play into this
[19:36:15] <rayh> circle program at http://pastebin.com/m5a01d732 is an ellipse about the size of the one used the other day.
[19:36:35] <rayh> It was coded with synergy and is intended for milling but it's close.
[19:37:25] <rayh> Feedrate is 165 and I do see a bit of slowdown at the intersections of the arcs.
[19:42:33] <BigJohnT> rayh: that's my circle made from lines...
[19:42:50] <BigJohnT> did you post up the wrong link?
[19:44:08] <rayh> let me look.
[19:45:16] <rayh> oh. http://www.pastebin.ca/1031297
[19:49:10] <cradek> skunkworks_: interesting. I wonder what they've done that makes the >125% problem hard to fix
[19:49:56] <cradek> nonrealtime trajectory planning I bet (with assumptions that become wrong when using feed override)
[19:50:09] <SWPadnos> I think they scale the accel and vel somehow
[19:50:28] <cradek> yeah I bet they try to "plan ahead"
[19:50:31] <SWPadnos> rather than changing the target feedrate and still applying correct accel values
[19:50:41] <cradek> it's a very hard problem
[19:50:55] <BigJohnT> rayh: I got it. I'll try it when I get home, what is the max speed you could get it to run?
[19:51:34] <SWPadnos> in case anyone was wondering, this is definitely a blending/lookahead problem. a single G2 of the same size works great :)
[19:52:06] <SWPadnos> I also see those speed bobbles, and I think it may be due to slightly different arc lengths - the longer ones get up to a higher vel
[19:52:17] <BigJohnT> inquiring minds want to know :)
[19:52:40] <BigJohnT> SWPadnos: in my test today a longer arc would run at a higher rate
[19:52:47] <alex_joni> that is expected
[19:52:50] <jepler> this is almost totally untested, and I'm about to walk away from the keyboard .. http://emergent.unpy.net/files/sandbox/naive-cam-detector-for-arcs.png http://emergent.unpy.net/files/sandbox/naive-cam-detector-for-arcs.patch
[19:53:03] <SWPadnos> G2X0Y3I3F400 runs at 400 IPM :)
[19:53:37] <jepler> if the max deviation of the arc from the chord conecting the endpoints is smaller than the programmed tolerance, then it's converted into two lines (to the midpoint of the arc then to the endpoint), and then it's also a candidate for tossing out extra lines (the existing naive cam detector)
[19:53:49] <jepler> the screenshot shows blue for arcs and red for lines
[19:54:03] <SWPadnos> oh - cool
[19:54:17] <BigJohnT> sweet!
[19:55:20] <BigJohnT> I'm running trunk so when I get home I'll try and patch it in...
[19:55:47] <rayh> About 360 ipm but it slowed a bit on the smaller arcs.
[19:56:39] <rayh> I did increase accel to 200 and it smoothed it a lot.
[19:56:50] <alex_joni> jepler: this is only for XY.. right?
[19:56:59] <jepler> alex_joni: yes
[19:57:07] <jepler> the other cases are left as an exercise for someone smarter than me
[19:57:19] <BigJohnT> that leaves me out :)
[19:57:44] <BigJohnT> rayh: I'm running 200 on accel normally on the plasma cutter
[19:58:09] <rayh> Okay then the arc version of the ellipse should run pretty well for you.
[19:58:36] <BigJohnT> yes
[19:58:51] <rayh> I commented out a couple of the tool change and such lines. You'll probably have to edit before you run it.
[19:59:13] <BigJohnT> jepler: IF I get it patched I'll give it the acid test on the plasma cutter ASAP
[19:59:28] <BigJohnT> ok
[19:59:40] <SWPadnos> here's a halscope plot showing the regularity of the speed bobbles: http://cncgear.com/images/tiny-arc-vels.png
[20:00:20] <rayh> That is pretty darn regular.
[20:00:35] <SWPadnos> yep
[20:01:05] <SWPadnos> the trace doesn't show as much variation as there seems to be on the dtg display in Axis
[20:01:44] <SWPadnos> like maybe 0.03 IPS for the worst ones
[20:08:54] <BigJohnT> SWPadnos: is that on rayh's file
[20:09:05] <SWPadnos> no, yours
[20:09:33] <SWPadnos> I loaded it in a slightly modified "sim_axis" config - I opened up the accel and vel to 60 and 12, respectively
[20:09:50] <BigJohnT> which one?
[20:10:02] <SWPadnos> http://pastebin.ca/1031252
[20:10:10] <SWPadnos> 6" circle
[20:10:15] <SWPadnos> I took out the A references
[20:10:22] <SWPadnos> and the O0000
[20:10:29] <BigJohnT> ok the one with 360 arcs
[20:10:58] <BigJohnT> that one ran smooth for me just lots slower than the one with 360 lines
[20:11:18] <BigJohnT> arcs 150IPM lines >400IPM
[20:11:26] <SWPadnos> single arc == 400IPM :)
[20:11:40] <BigJohnT> :)
[20:11:58] <SWPadnos> hmmm - re: that CNCzone thread, you should note that the jog shuttle pro doesn't work quite right
[20:15:24] <BigJohnT> SWPadnos: what is a jog shuttle pro?
[20:15:54] <SWPadnos> it's a USB jog wheel
[20:16:23] <BigJohnT> oh, I sent him to the wiki page for the MPG pendant
[20:16:33] <SWPadnos> he probably means the shuttle express. Tormach sells it with a mach configuration to use it
[20:16:46] <SWPadnos> pro: http://www.contourdesign.com/shuttlepro/
[20:16:56] <SWPadnos> xpress: http://www.contourdesign.com/shuttlepro/shuttlexpress.htm
[20:16:59] <BigJohnT> I use a joy pad to move my plasma
[20:17:17] <SWPadnos> sure - the shuttlexpress just has a quirk that isn't handled correctly by the kernel
[21:15:32] <skunkworks_> hmm - does this mean paul is back? :)
[21:15:41] <skunkworks_> (Hi paul!)
[22:27:17] <BigJohnT> jepler: I just ran the patch with the circle of arcs and it ran 400 IPM more or less... in case you don't recall it ran 150 tops before
[22:28:53] <BigJohnT> circle with lines and G64P0 ran at about 130 IPM slower than the arc one before
[22:31:30] <BigJohnT> circles with same length lines and circles with the same length arcs run the same speed as you play with G64Pnn
[22:31:47] <jepler> BigJohnT: sounds promising, then
[22:31:49] <BigJohnT> Arcs and circles should play well together
[22:31:58] <BigJohnT> It looks damm good from here
[22:32:46] <BigJohnT> I have to lug the box back out to the fab shop and plug it in and run as many programs as I can to test...
[22:32:56] <jepler> BigJohnT: let me know if you see any problems
[22:33:03] <BigJohnT> Thank You Very much for the patch
[22:33:11] <BigJohnT> will do
[22:33:23] <jepler> BigJohnT: when I did the original "naive cam detector" for lines the problem was that in certain cases it resulted in the machine doing the wrong thing
[22:33:31] <jepler> .. going at the wrong feed rate, going to the wrong location, and so on
[22:33:44] <BigJohnT> I'll look out for that
[22:34:03] <jepler> do you use offsets (touch off, g10 l2, or g92)? those are sometimes the places where a problem will crop up
[22:34:15] <BigJohnT> the best thing I see is that arcs and lines have the same speed for the Pnn setting that you choose
[22:34:26] <BigJohnT> this means smoother movement
[22:34:56] <BigJohnT> I use G92 just about all the time
[22:35:21] <jepler> ok
[22:35:52] <BigJohnT> going to test it out be back in a bit
[22:36:04] <jepler> I'm not sure I see why you'd need different p-values for arcs vs for lines
[22:36:32] <BigJohnT> I don't but I was just testing the results of changing it
[22:36:39] <jepler> ah
[22:36:40] <jepler> ok
[23:07:02] <BigJohnT> jepler: I just got done running all the files I had on the plasma machine. Once I got a Pn for G64 that was happy it ran smooth at plasma cutting speeds.
[23:07:37] <BigJohnT> even the one with tiny tiny arcs ran well
[23:08:55] <BigJohnT> with a little tweeking on sheetcam I'll be in like Flynn
[23:13:08] <jepler> BigJohnT: thanks for the testing. I'll go ahead and put this change in CVS so everyone can enjoy it (or run into problems with it :-P)
[23:14:18] <BigJohnT> Thanks for making the patch. If I see anything not good I'll let you know, but so far it is sweet!
[23:17:26] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emccanon.cc: (log message trimmed)
[23:17:26] <CIA-32> EMC: extend the naive cam detector to arcs.
[23:17:26] <CIA-32> EMC: When the maximum deviation of an arc from a straight line is less than the
[23:17:26] <CIA-32> EMC: G64 P- tolerance, break the arc into two lines (from start of arc to midpoint,
[23:17:26] <CIA-32> EMC: and from midpoint to end). those lines are then subject to the existing naive
[23:17:29] <CIA-32> EMC: cam algorithm which may eliminate or join successive lines that are within
[23:17:31] <CIA-32> EMC: the tolerance. Thus, line-arc, arc-arc, and arc-line cases can now benefit
[23:17:57] <jepler> now that the -17 kernel is out from ubuntu, I think a lot of people are going to run into problems at their next reboot (the new ubuntu kernel will be chosen over the rtai kernel). I don't have time right now, but can someone write a message to the users list explaining how to select the right kernel at boot time so that emc can be run?
[23:18:17] <jepler> unfortunately without editing grub's menu manually I'm not sure how to change the default to be the rtai kernel..
[23:18:30] <jepler> * jepler goes to make dinner
[23:39:21] <rayh> I can do this.
[23:53:05] <BigJohnT> rayh: you around
[23:55:55] <rayh> Yup.
[23:56:14] <rayh> Working on an email and almost done.
[23:56:42] <BigJohnT> cool, the patch worked like a charm thanks for your support and help
[23:56:59] <BigJohnT> * BigJohnT hears the dinner bell