It's beautiful in the north woods today.
How you doing today.
good, I'm cooking some crawfish this afternoon
I noticed while running my plasma cutter that EMC almost stops between a line and an arc at speeds above 25IPM
and the faster you go the more pronounced it is
when it is all lines it is smooth as silk as high as 400IPM (as far as I tested)
would anything help reduce the slow down between an arc and a line?
like more memory or faster processor
I doubt it. What proc are you using know?
I don't know off the top of my head but it's about a p4 1000 or something like that
its out in the shop
You can get an easy answer from a terminal. "cat /proc/cpuinfo"
I saw some of the discussion about this yesterday and don't have a good answer.
I'd think though that a 1g proc should have enough throughput to handle the stream of canonical commands.
it is smooth as silk up to 25 IPM after that it starts to jitter
That seems odd.
cat/proc/cpuinfo didn't work on this termial it said no such file or directory
put a space between cat and /
you can see the speed in Axis start to bounce up and down
the space did it
I love Linux.
I'll go out to the shop and see what it is
well it is a Pentium 4 2.4GHz
faster than I thought
That should not be the problem.
circles are smooth as silk up to 400 IPM as well
So it is an accel/decel issue.
also when I did the ellipse with about 450 lines it was smooth to
Refresh me on the drives you use.
What value for accel?
I changed the acceleration in my ini from real low to real high with not much change
200 is what I normally have
* rayh throws out that idea.
I went as high as 400 to test
Wow more than a G.
How heavy is that head?
about 20 pounds
let me read for a minute
it seems to me that EMC throws a pause in between the line and the arc move
G64P0.010 didn't make any difference?
no, I was told by cradek (I think) that it only works on lines
I did a G64P1 to test
with all lines a G64P0.001 did fine
When cradek was working up the interpreter we did a lot of testing. This combination may have gotten past us.
Did you try the four arc approximation of an ellipse?
I used eight when I programmed the elliptical beam splitter.
it was not just the ellipse but the letters I cut out too
Do you see any difference between going from arc to line and line to arc?
I didn't test that
but I will after breakfast
How about sending me some samples that show what you are seeing.
of the g code?
or pastbin em
I just happen to have the two examples on a floppy
[13:30:20] <BigJohnT> http://pastebin.ca/1027924
[13:32:04] <BigJohnT> http://pastebin.ca/1027925
don't know why pastebin threw in a blank line between each line....
I see that. Don't think it will make a difference.
the arcs are .001-.002" long. it has to nearly stop to be sure to hit them. if you just remove the arc lines it will work much better and make no difference.
How did you generate this program?
even on the letters that have longer arcs I can see the pause between arc and line
it is not a problem blending line-arc or arc-line, it's a problem with blending very short moves (and this is worked around for lines but not arcs)
which paste is that?
can you tell sheetcam a tolerance so it doesn't output so many tiny moves? some of these are way under .001 long which seems silly
I took the first one.
I thought it was set for 0.005
in the second paste I'm looking at line 136-138, it is .0006
Could this be caused by sheet cams eol?
for all lines that's ok, emc can handle it (it ignores the useless moves) but with arcs this bites you
what is eol?
end of line?
120-122 is also .0006
maybe your setting is .0005 not .005
no, blank lines don't hurt anything
my circle recognition limit is 0.1"
in my post the minArcSize is set at 0.5
I wonder if it is in mm
but in the first paste the arcs are under .001 long. look at line 24-26
these short moves are what is hurting you, if you can get the cam to not generate them, it would be good. otherwise, use all lines and G64P and emc will combine the unnecessary moves for you
How big is your table, BigJohnT?
rayh: I think http://www.youtube.com/watch?v=KvhvQu5Xxtk
is BigJohnT's machine
can't tell for sure but it looks maybe a yard wide
Okay. I built a bigjohn-stepper.ini
I do see a lot of the jerking
yes I don't doubt it, looking at the gcode. I hope he can try the things I suggested.
You were suggesting changes to sheet cam's output?
I should try to reproduce with Synergy.
yes. he has to get rid of the tiny moves somehow. if he uses lines only, G64P can do this for him. otherwise, he needs to change the output.
Could we remodel the traj or interp to handle this sort of case.
sure, it would be ideal if we could make G64P handle arcs too. but that is harder than the line case of course.
I understand the "load" carried with my question.
it's hard to gracefully handle arbitrarily bad cam output. but we did g64p because one very common form of cad output is a zillion tiny tiny G1 moves
that case is handled pretty well
but BigJohnT's case where there are reasonable lines with tiny tiny arcs sprinkled between each of them, is one we haven't worked around yet
it looks like if he just deletes the G2 and G3 lines from that file, it will run fine with G64P. (assuming all the arcs are tiny tiny, I can't tell)
cool, my high speed spindle is on the way.
a guy sells them on ebay, but I think he doesn't build them until he has a buyer
Seems like the curve fitting in sheet cam needs a bit of work
What sort of thing is it?
Oh. I got the box of boards from mesa for the raffle.
ok I'm back
oh? I didn't know we had a mesa raffle. I might buy a ticket then.
9 boards including several I want.
usually the raffle has stuff I don't care much about (like windows software)
rayh: the table is 38 x 50 but I can use a 4x8 sheet
Okay. I made my test 100x100
so is what I am seeing a result of the shear number of moves at that speed where as the one with lines is reduced in the actual amout of moves?
gotta reboot to run synergy. been playing with fluxbox and blackbox on a new 8.04 install
the problem is the SHORT moves
I keep saying this
ok, I was just trying to understand better
emc knows how to throw out useless short moves (the ones that don't affect the path within the G64P tolerance) but it does not know how to throw out unnecessary arcs
ok, that makes sense
so your two solutions are: get sheetcam to use your tolerance and not put out short moves, or use all G1 so emc knows how to discard the unnecessary ones
I just changed the post on sheetcam to see what the result is
if you tell sheetcam tolerance .005 but it generates moves .0006 long, it's not working right
did you change it to use all G1?
that was a mastercam output
I just changed minArcSize to 1 and got all G1 moves
I don't have any of these products, so it's tough for me to guess how to get them to generate gcode that emc will like
maybe I should be thankful I don't have them :-)
I created a post for it that EMC likes but this must be a mm value
ahhh .005mm could explain it
I think Les (the developer) has some issues with mm/inch
don't we all
that's why I keep working on an EMC CAM package...
I jump when the MPG readout on my car shows 25.4 because for so long I'd see those in EMC when there was a units bug
fortunately the EMC units bugs are all fixed now :-)
yep that's the other one
but fortunately I get better mileage than that
I get 15-16 mpg in my truck
gotta finish that electric motorcycle
that's good for a truck, but trucks are very bad for everyday driving
yea, I gotta do something soon for driving back and forth to my machineshop
I bought a new motorcycle helmet this weekend. everyone was talking about gas mileage at the bike shop.
what are motorcycles getting now
they must love it when the gas prices peak while the weather is perfect
because all these fool kids will buy bikes, forgetting that they're in nebraska :-)
mine only gets about 35-40, it is huge. you can probably get 75-100 on a little scooter
I use to ride one when I lived in Alaska year round
my bike is not much better than my car
but I was young and dumb
yeah I used to ride mine whenever there wasn't snow. I'm older/smarter now.
I screwed sheet metal screws from the inside of the tires to ride on the snow and ice
wow, I've never been that "young and dumb"
sounds fun though :-)
hey, I was 15 and had a honda 50 supersport
EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/drivers/hal_evoreg.c: this driver uses floating point math - label it accordingly
well, the wife just announced that the construction crew (me) needs to get to work on the deck
I commuted year round in oregon on a honda 350 -- used up four rain suits.
Have a good day. I'll see if I can get synergy to spit out an ellipse.
the good old days
EMC: 03jmkasunich 07v2_2_branch * 10emc2/src/hal/drivers/hal_evoreg.c: backport from trunk - driver uses floating point
so, that guy who was having stepconf problems is now threading, but with some other problems: http://pastebin.ca/1027962
I suggested that he try threading passes at high and low speeds, to see if the "hunting" problem happens all the time
hunting, it isn't season yet! Fishing yes, hunting no.
maybe it is where he lives, it's a Denford lathe ;)
EMC: 03swpadnos 07v2_2_branch * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: Backport fixes for lathe setups using counter mode for spindle feedback
he doesn't actually describe the problem (or was that in an earlier message?)
he couldn't thread at all before
we got that fixed with some corrections to stepconf's setup in custom.hal
(and I fixed stepconf so the rpoblem won't show up later)
but apparently the XZ motors "hunt" for the right speed
I asked him to clarify what he means, and maybe post to the emc-users list rather than CCED
he's got a 48-slot wheel on the spindle, so he's only getting position updates half the time (at 600 RPM)
I don't know what kind of speeds he wants, but he used the g76.ngc sample to test
so EMC is issuing position commands that say "stay where you are", "no, move", "no, stay", etc
I think that could be it
but then again, it would be doing that 500 times a second
although that would be happening at 500Hz or so
they way he said "i've still got the 'hunting for the exact speed' problem" makes it sound like a problem that he has previously described in more detail
one sec - lemme look
oh - here are the pastebins of his config (same as yesterday): http://pastebin.ca/1027234 http://pastebin.ca/1027235 http://pastebin.ca/1027239
though we fixed the spindle index connection
that still doesn't describe what he is seeing
no, just background info
Can I post that the developers are working on inproving this? http://www.cnczone.com/forums/showthread.php?t=58418
when I was doing my fusee I found and fixed a problem that resulted in a disturbance when going from one threading segment to another, but most people don't use multiple segments
is that in v2_2_branch?
I also saw some disturbances at the start of a thread, and I know the root cause, but not neccessarily a decent fix
he's got the 8.04-aj07 disc, so he's on 2.2.5
the workaround is to start your threading passes far enough in the air that it is over before you start cutting
I dunno, its been a couple of months, I'll have to see if I can find the commit
actually I think cradek found it (after a joint debugging session) but IIRC I tested and committed the fix
3/12/2008 at 11:59PM
yep. it's in 2.2.5
[15:38:16] <jmkasunich> http://cvs.linuxcnc.org/cvs/emc2/src/emc/kinematics/tp.c?graph=1
there already :)
skunkworks: yeah, sure.. why not?
I didn't know how far along that was or if it was still being thought about :)
well.. cradek started working on it
and he has a history of finishing things so far ;)
I suppose ;)
otoh it's not clear when it's "finished"
so he can just call it done at any time :D
which is also fine ;)
I think it's working for 1 or 2 segment lookahead
* skunkworks wonders if he can find some of the screenshots
guess how much time I spent trying to get a dial up modem working on me.
* alex_joni pukes loudly
[16:36:49] <alex_joni> http://pastebin.ca/1028026
SWPadnos: pretty close.. (I really didn't keep track)
alex_joni, yeah, but how many seconds does it take to do a full kernel build? :)
no gcc on it
Timing cached reads: 8776 MB in 2.00 seconds = 4393.12 MB/sec
oh, so it's a gaming machine? :)
Timing buffered disk reads: 288 MB in 3.01 seconds = 95.63 MB/sec
nope, it'll be a server :)
that's from /dev/md0 (RAID1)
it might make a nice gaming machine though
after trying various motorola, lucent, whatever.. a odd usb modem works. (finding drivers now for me is almost like finding dinasour bones)
but software raid
with the right graphics card, I'm sure it would do fine for games
skunkworks: trust me.. I know how it feels
SWPadnos: 00:02.1 Display controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)
guess this one doesn't really count.. does it?
just upgrade the computer to Vista, then replace the computer with one that can use Vista, then do the same modem driver dance on VIsta, then notice that the machine performs worse than the old one did, then install Linux on both machines and be hapy
no thanks .. I'll save myself from doing that
it'll do OK for wolfenstein, I think :)
heh - what started the problem, I think, was that the phone company changed thier equipment which made the original modem quit connecting.
that was for skunkworks
well.. judging by the fact that I won't have X on it.. you might be right
skunkworks: talk about standards
oh, just add the init string to the modem that prevents 4.92bis negotiation
V.92bis, that was
Now you tell me :)
well, you didn't ask before :)
hmm.. I wonder what's with people and USB..
this board has 11 ports
no PS2 though
remember, everything should be USB, mice, keyboards, speakers, hard disks, motion controllers
yep - most new stuff is like that. I use usb to ps2 style addaptors.
wtf.. I meant "even emc" :)
I wondered what the heck you were trying to say :)
yeah, well.. me too
(reading some nice man pages.. )
are you following the USB motion controller related discussion on the geckodrive list?
well, it's come up again
I read the geckodrive list only when I'm really bored
now I need to replace a server.. and it will be a _load_ of work to install everything before doing the switch
s/install/install & configure/
mv //server1 //server2 ; apt-get --fixallthefuckups
the old one is 2.6.8 :D
throw some tar cvzf foo|configure && make in there
[16:57:54] <skunkworks> http://www.cnczohttp://www.cnczone.com/forums/showthread.php?p=455869#post455869ne.com/forums/showthread.php?p=455869#post455869
It's to bad there isn't a cat /proc/moboinfo command.
hwinfo might do it
yeck. I ment http://www.cnczone.com/forums/showthread.php?p=455869#post455869
skunkworks: that got a bit mangled
alex_joni: computer was running a but slow.. pasted too many times. Second url works.
skunkworks, can you ask Andre' how his controls deal with multiple segments that would gouge (like having 4 segments that approximate a small 90-degree corner)
ie, how much lookahead do they have
ok - the guy was threading at 100RPM
so only 80 position updates per second
that might be a bit slow
12 or 13 servo cycles between position updates, with each update = 7.5 degrees
I guess I should get cracking on that interpolating encoder counter
just make sure there's a scale input :)
there will be - it will be a canonical encoder
I wonderif it would make sense to add it to encoder, with a parameter like "interpolate-position"
I thought a bit about that
undecided at the moment, but I think I'm in favor if keeping it separate
the velocity estimates are quite good, if I remember the plots you did
I could probably be convinced
well, it is an encoder reader ...
the differences will be on the hardware interface side
the count_pulses routine?
not talking about implementation, talking about interface to the world
encoder assumes quadrature, with or without intex, but has a counter mode that doens't do quad
dunno if the counter mode does index or not
yes, it does
these low ppr things could be one of three flavors:
1ppr (index) only
it's only counting that is affected
N ppr with index (quad or single)
Nppr without index (quad or single)
you can't use anything without index
the latter would benefit from the module being able to divide by N and fake an index
but you would eliminate any ability to do multiple passes
threading - you need to know where the spindle is so you hit the same thread on every pass
I guess as long as the feedback is running continuously the fake index would still track
if you have 48ppr with no index, but the driver knows you have 48 ppr, it can fake an index - with quadrature the "index" position would be valid from when you start the module running till you stop it - with single phase it would be valid as long as you don't go backwards
I can see the less astute users getting all fscked up by not understanding the real world implications
I guess I'd separate the no index case from the only index case - they're two very different conceptual changes
they're two different dimensions, but they can overlap
synthesized index could be useful in some cases, position estimation between feedback events is useful in some cases
they are both reasonable features for the encoder module to have
they should be more or less independent, though they obviously touch the same files
I'm just saying that to ease the actual implementation, they can be considered separately :)
"interpolate position" and "synthesize index"
and we already have counter mode
which is also an independent dimension
fr synthesize-index mode, I'd stick an input that lets you force the current position to be the index position
what are you thinking? manually rotate the chuck to some mark and hit a button?
hmmm. actually, in synthesize-index mode, still reset on an incoming index pulse, but synchronize the internal counter to 0
you can then hook up a pyvcp button to index for the manual mode
I'm afraid the people who are using sync index will also be using single phase - if they touch the chuck after pressing the button and it turns even 1 count backwards they're screwed
yes, that's definitely true
the normal index input wouldn't work for that anyway - it only has an effect if "index-enable" is true, which won't be the case during setup
it only goes true right before each threading pass
right. forgot about that
I'm thinking that if you specify synthesize-index, it won't export the index input
the master reset input could be used for what you have in mind though
oh. that makes it a load-time option rather than a HAL parameter
is counter-mode a load time option?
I don't think so
* jmkasunich reads the man page
its a param
I suppose it would be nice of the two new features were also params
can you take a look at adding "X2 mode" for counter?
so it counts on rising and falling edges
I didn't look at the mode arrays long enough to figure out how to do that
(I'd use the x4 param for that, like quadrature mode does)
just change the last line of the param description....
heh - right :)
plus add the functionality to the module ;)
all those things seem possible
I just remembered something about lathe threading that makes the initial disturbance worse
EMC's "target" Z position is simply initialZ+spindle_revs*pitch
that target is subjected to accel limiting, but the limiting only means that the command coming out of EMC will lag behind the internal "target", then overspeed to catch up to it
if the internal target were more like "initialZ+accel_distance+spindle_revs*pitch" then it wouldn't have to overspeed to catch up, and much less "air threading" distance would be needed
I thought cradek said something about adding pid to that.. o
pid (or whatever) is only about tracking the internal target
as long as the target doesn't include an accel distance offset, the axis will have to go faster than the nominal threading speed to catch up
the accel_distance fix is simple in theory, the trick is what to use for accel_distance
you can't base it on the target axis speed (and thus on spindle speed) because if you did threading passes at different speeds they would have different offsets
might have to base it on max axis speed and the axis accel limit, but that could get ugly
ha.. this looks familiar: http://imagebin.org/18541