this is disturbing - nothing has changed (that I know of), but my machine is now stalling during rapids
true, it's in the basement
so far I've seen it only on X
the hard one
speaking of steppers and them sucking, pluto-step has a dynamic error that is about 2 * velocity * servorate (e.g., around .0008 inches at 48 in/min and .5ms servo). Is this a level of error at which I should just shrug and move on, or should I fix it by changing the control loop inside the pluto_step hal drivre?
in the case of my system this is a much smaller effect than, say, the backlash ..
probably smaller than screw irregularity
I don't understand what the error actually is - can you post a scope trace or reword that description? ;)
it's following error
oscillating around 0?
no, during a move. always the same sign.
ok, so it goes to some calue then stays constant (relative to speed)?
pluto is lagging the command?
[02:12:13] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/pluto-ferror.png
I can't get a good trace that shows it, but -fb is lagging -cmd
ok, that makes sense
I suspect it's a latency problem
scope.sample is at the end of the thread, axis.n.motor-pos-cmd is already updated, but the feedback isn't yet
but axis.0.f-error is "real"
and anyway that would account for one cycle of offset
but there is about 2
if the step rate commands are clocked into the pluto by the driver, then the new rate doesn't take effect until the end of the thread though
it's the USB cycle time problem, only faster :)
actually pluto-step seems to work quite well. the "stopped" error is <1 step (it has sub-step "accuracy" like stepgen), and the "moving" error is small compared to the slop in the machine
is it used like that USC, ie with PID?
that is cool
it is more like stepgen -- the position loop is inside the HAL component, and there is no user tuning
but otherwise it's like USC -- a frequency command goes to the FPGA, and a position feedback comes from the FPGA
all my best ideas are stolen
right - I was wondering about FF0 (or FF1 or whatever it is)
the position loop should read as follows: /* copy from stepgen, except that jmkasunich went over my head -- oh and no accel constraints, oops! */
the FPGA should slew from one rate to the next ;)
I already used all 500 FF+LUTs
hm actually there is a knob you can turn: v = v - debug_2 * est_err / fperiod;
double v = new_position_cmd - data.old_position_cmd[i];
double est_err = stepgen_position_fb(i) + data.old_velocity_cmd[i] * fperiod - new_position_cmd;
is that a paste (or two)?
I understand this even less well now than when I wrote it
that's two pastes, it put things a bit out of order (first line comes last)
I'm just wondering why new_position_cmd isn't subscripted
double new_position_cmd = stepgen_position_cmd(i);
it's referred to several times so I pull it into a local
I think you can get rid of that est_error stuff - that should be to compensate for acceleration, which pluto doesn't do
just use v
actually, I think I've convinced myself not to touch it
this servo motor I bought from you doesn't make a bad jog wheel
it's the right shape to stick on a panel
a big panel
a real big panel
you sold all of these motors, right?
no, I still have 6
chris was threatening to make a new circuit board milling machine for himself, and I was thinking these motors might be good ones
but then I'd have to give up my jog wheel
soft limits are great but I think I need to write a userspace component to go "thunk" when you hit one
well, if he actually does get far enough to need motors, you guys can let me know. I don't expect to sell any more until next year
a coconut shell sound
yeah that's the ticket
I think that line you pasted is the culprit actually - it subtracts a little from V
the power-up value for debug_2 is 0.5. setting debug_2 = 0, it ferrors. setting debug_2 = 1, it whines a little like a hunting servo.
I think est_err is negated compared to what you expected
err - put a read and a write in there somewhere
[02:37:05] <jepler> http://pastebin.com/m3975f2d0
(machine is 2.1GHz)
(setting debug_2 too high causes this)
it could be timing related, but if it stays constant during long moves, that leads me toward a calculation error
or just phase shift
I think I want to go back to earlier, where I didn't care abuot this
sure - you can see in that trace that it's ping-ponging around some value (changing every cycle)
you should set v (or old_velocity) to a value calculated from the final rate sent to the pluto
jepler: what is scripts/latency-test?
it pops up a dialog with HAL latency numbers
attempting to run it did strange ane meaningless things, is it intended to be invoked from stepconf or something?
you may need emc-environment for it to work correctly (unless it's installed)
no dialog, just a series of lines in the shell with "." on each one
I'm about 95% sure I did the emc-env thing, lemme try again
I think those are "waiting for stuff to load" prints
you didn't run it while emc was running, did you?
um, the realtime script and/or halcmd will print dots while waiting for something -- I think 'loadusr -W' will print dots, for instance
I don't know what I did wrong, but its working now
eww, 300uS on the base thread
that's a long time
yes, it is
did you lose your smi fix somehow?
ah, I bet thats it - this is a RIP cvs checkout, not the installed version
flowsnake really hurts on a machine with backlash comp
or it looks like crap on a machine with a lot of uncompensated backlash
both are probably true
well I have no idea how this looks .. it might still look like crap
re: pluto-step, I think the debug_2 sensitivity is because the old vel is saved as the ideal number, not the actual number sent to the pluto
good news is it kept position during flowsnake
interesting - this dell has good latencies when run remotely
looks like smi fixed the problem
I think it wasn't as good with the local X server
crap, not fixed
hmm, undocumented HAL pins
I think it isn't hooked to anything yet
used for feed per rev I believe
not sure though
oh, I must be thinking of spindle-at-speed or something like that
(which may not even exist ;) )
spindle-speed-out is RPM, I wonder what the units of spindle-speed-in are?
you have to scale by 1/60 outside, IIRC
well, if it is coming from the encoder module it will already be in rps
ok, it's RPM - you have to scale it from the encoder output
I knew there was scaling in there somewhere :)
hmmm. no, it's RPS
sorry - looking at sim/lathe.hal
rps goes to spindle-speed-in
yeah (I tried it)
weird - G76 with a P word of 0.020 (50 tpi) is moving much faster in Z than it should
I thought K was the thread pitch
or is that for rigid tapping?
K is for G33
whatever that is ;)
33 = a single synced move, 33.1 = rigid tap
76 = threading canned cycle
it isn't 60 times faster is it? :)
60x faster is well past rapid
its running at rapid, so I can't rule that out
but threading moves aren't controlled by spindle-speed-in, they're controlled by spindle-position
weird. emd2-dev is installed, and i just did build-dep emc2, and I still have no cvs
I figured that would be pulled in somewhere, but I guess it isn't strictly necessary
nope, you might have gotten the code from a tarball
this is freaky
motion doesn't seem to be asserting spindle-index-enable at the start of each threading pass
are all the moves in the loop (I'm assuming you're looping) synch moves?
or is the return non-synched?
I'm using G76, the looping is in the canned cycle
oh wait, you're using a canned cycle - nevermind
G33 shows the same thing
actually, its like the synced moves are being completely ignored
why am I having a deja vu? I think this happened once before
I'd think that would make synchronized moves not work, so I wonder about your testing
I'm almost certain I ran it
run-in-place should refuse to run if it doesn't detect some of the settings emc-environment sets up
unless they're there anyway for an installed system, of course
I'm pretty sure that isn't it
[04:11:53] <jmkasunich> http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-03-08.txt
I was right - deja vu
that was feed rate related though
and this program, like that one, doesn't set an F value, because the only moves are G0 and the threading
don't do that :)
I think when I looked at it, it seemed like it's not an easy fix
though I don't recall the specifics
yep, putting an F1 in the program fixes it
did either of us ever file a bug report for that one?
bed time. night
I'm not going to be able to test the effect of spindle speed droop
any cut that is near heavy enough to slow the spindle causes work deflection
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ (Master_Integrator.lyx Submakefile): Fixed intro in integrator manual
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/integrator_intro.lyx: Fixed intro in integrator manual
EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/ (Master_Integrator.lyx Submakefile): fixed integrator intro
EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/common/integrator_intro.lyx: fixed integrator intro
hmmm, when I go to CVS and show only files with tag: v2_2_branch docs/src/examples/spindle.lyx does not show up. It does show up in trunk
did I miss something?
I see the same here. The examples directory is there but nothing is in it.
In the commit message for spindle.lyx I don't see that it was added to the 2.2 branch.
I could not find it either...
I just edited the file to see if it will commit now
"/emc2-2.2.x/docs$ cvs -z5 diff -u" gives me "? src/examples"
I see that latex is still complaining about our using titles the way we do.
Jeff added this to trunk /docs/submakefile "$(filter objects/examples_%.xml,$(DOC_TARGETS_XML)): objects/examples_%.xml: $(DOC_SRCDIR)/examples/%.lyx $(XMLDEP)
wonder if I need to add it to the branch?
There is some sort of "issue" with the EMC2 image in the title block. It does it fine but doesn't like doing it.
BigJohnT: you may after you add the new file in the new directory to 2.2
BigJohnT: I'm trying to figure out what step you need to do to successfully add it..
BigJohnT: move your newly-created examples directory to a different name (examples.1). then: cvs -f up -d examples. move the new lyx files into the new examples directory. now you should be able to "cvs add" it. remove the examples.1 directory when you no longer need it
EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/examples/spindle.lyx: added spindle chapter
ok, thanks jepler that worked
BigJohnT: OK good
BigJohnT: same fix is now needed in the 2.2 Submakefile; I'll check it in in a second.
I was about to do it
EMC: 03jepler 07v2_2_branch * 10emc2/docs/src/Submakefile: from TRUNK: new documentation directory
you beat me too it :)
hope your toes don't feel too stepped on
not at all thanks for the help
see you later; it's breakfast time here
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/examples/spindle.lyx: fixed formatting
EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/Master_Integrator.lyx: fixed formatting
EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/examples/spindle.lyx: fixed formatting
in case you didn't get that far in the IRC log, it was the change from rev 1.122 to 1.123 that caused the problem
now where is my knobkerrie
and for emccanon.cc
I wonder if getStraightAcceleration is needed on synch moves
I'm thinking along those lines too.
I stuck my foot in my mouth on cnczone last night with respect to PyVCP and relative numbers.
how did it taste? :)
So I modified halui.cc this morning and added relative pins.
someone want to test my work before we make any changes to the official source.
you can change the DRO size in AXIS
yes we can but that is not the issue I was addressing.
still reading the thread :)
sorry I don't yet understand what you added
And I would like to see an axis change font menu item.
I added relative position pins to halui.
I asked alex about it but have not gotten an answer yet.
oh! that sounds great.
I didn't know it was missing.
for a font change in AXIS we'd probably want to scale all the little indicator bitmaps too. That makes it a little harder but not impossible.
I think there are only two: homed and on limit switch
I know nothing of writing this kind of code so modeled from xemc.cc, copied, pasted, and changed axis names.
Yes you are right about scaling those. I didn't think of that.
are those (or similar) glyphs available in some scalable font?
no, those are hand-generated and not in a font
rayh: want to put a patch on pastebin? other than just checking it in that seems the easiest way for someone to review it
Um. How do I create a patch?
cvs diff -u halui.cc
but if it is working, you have probably already done it right...
there are similar glyphs in these sets: http://www.unicode.org/charts/PDF/U2980.pdf http://www.unicode.org/charts/PDF/U2B00.pdf http://www.unicode.org/charts/PDF/U2A00.pdf
ooooh - 2345-2438 look good here: http://www.unicode.org/charts/PDF/U2300.pdf
and maybe 233E or 2388 for homed
neither of those look like an origin symbol to me
2388 is an isometric view of a 3D origin ;-)
(I'd be surprised if unicode didn't have the right symbol)
the symbol could be a house - it doesn't have to be an origin
yes, 2388 did look like a 3-D origin
SWPadnos: you're mistaken about that :-)
ok, so there are other constraints, huh? ;)
2347 and 2348 seem reasonable for limits
"you are at the edge of the box"
ah-ha! 21E4 and 21E5: http://www.unicode.org/charts/PDF/U2190.pdf
there's no guarantee that any particular font will have all those symbols, though
I was about to say we'd have to ask jepler if we can use any of this.
21AF: "amplifier fault"
21B9 is there too, for "both limits" :)
the limit icons in axis don't tell you which limit do they?
is that information available now? it would be nice if they did.
(it wasn't available when we did that)
I know it's a cliche, but I'm too busy to look into this right now
could SVG images be used?
heh - enjoy your trip :)
for a couple more choices of [traditional X] fonts, scaling those few bitmaps by hand would be foolproof
even one big bold font like 10x20 might be enough to make people happier.
what is the current font?
looks like it's 9x15
hmm, 10x20 isn't as big as it used to be
it is much bolder though.
somebody shrunk the pixels
there is 12x24
ugh, it's ugly though
is there by any chance n x 30?
12x24 is the biggest I see in 'misc'
I was thinking if you could get 18x30 or 20x30 or something, you could just double the icons
true. but it would be simple to redraw them too.
and it would look better
those m x n fonts are all monospaced, right?
cradek: scalable fonts should work fine too
I imagine those unicode things that swp found are not monospaced
jepler: don't they do various things based on dpi etc?
(I guess that's a feature, but it makes it hard to match a bitmap to the font.)
cradek: you can find the pixel height of the font fairly easily
coordinate_linespace = int(coordinate_font_metrics[linespace_index+1])
jepler: go pack!
and have a safe and fun trip
just noticed the GPIO driver - cool
I wonder how well it works WRT realtime
[16:53:22] <rayh> http://www.pastebin.ca/1063083
rayh: that change looks plausible
Okay. Should this be included in 2.2 or only trunk?
rayh: I think this would be OK for 2.2 if it gets tested first.
Okay. I'll commit to trunk and then when others have tested/revised we can get it in the next release.
Thanks but aren't you supposed to be packing, jepler ;
rayh: I have trouble taking good advice
EMC: 03rayh 07TRUNK * 10emc2/src/emc/usr_intf/halui.cc: added relative position pins
Hey have a good trip, guy.
rayh: is halui.axis.n.pos-relative for making a big DRO?
it's so pyvcp displays can show the same number as the AXIS (or other UI) displays
I noticed that when you touch off .pos-relative gives you a wierd number
until you move
then if i move 0.0001 it displays 0.0001001798
small number. I saw that as well.
sounds like a formatting problem - the 4.4...e-06 should print as 0.000
does pyvcp have a format string for the printed value?
I also see that my fix does not compensate for tool length on z
rayh: that's a pita to do right
imo this shouldn't come from halui
it's more likely something from the GUI
(based on user settings .. etc)
but then again.. what do I know :)
2638 is nice for a home symbol
"wheel of dharma"
[19:09:23] <alex_joni> http://www.decodeunicode.org/u+2638
so it can be scaled?
if it's available in a font.. yeah
* BigJohnT is off to shoot holes in some paper and maybe blow something up
rayh: if you add in tool offset, be sure you get all of X,Z,W
X would just be diameter offse
I don't know that we show this in X pos.
But for w we should have it.
nope, on lathes tool "length" offset can be in X,Z
g43 can give both X,Z on a lathe
thanks for doing this. I hope to try putting a position display on the front panel of my mill when I convert it.
I suppose you'd want to see it show the finished diameter.
Ah. That sounds like a good use for the hal display stuff.
I wonder if motion (or something else) should just output the appropriate coordinates