So if you build your own VFD beware that you need a return AC path from DC VBUS to frame ground (say .01 @3KV)
and perhaps a ferrite bead common mode choke around the 3 phase lines going to the motor
bbl time to go home and commune with my lagomorph and ovine friends...
OK, I will bear it in mine
Say "Bahh" to the latter, and, err, give the others carrots
ya that current has to go somewhere (big motors may have 1000s of pf)
OK bye andy
KimK: did I get my recommendations about pid right in that email (based on our conversation a while back)?
cradek: An email to the list? Sorry, I've been pretty busy here, I'm afraid I'm behind on the list. And we've had the garage doors open for the forklifts so no air conditioning, and my desktop PC has been beeping its overheat alarm when the sun comes through the west window, and I have to shut it off, so I lose IRC too. What was this about? (while I try to check my email and the list.)
yikes, sounds miserable
the scheme to simulate a differential velocity input to a torque mode amp
thread started with a message from Jake A "odd PID tuning problem"
Yeah, the circus is in town, I'm afraid. We're downsizing here, moving from suites E & G to just G. Almost all of the stuff left in E now belongs to John's brother Dave. I don't know what he's going to do with it all. I'm mostly just trying to help John get his machine shop moved into his half of G. But Saturday Dave will be here and John and I and some other volunteers will try to help him.
sounds like a lot of work - hope the move goes well and safely
Thanks for the subject line, I'll review the thread real quick. Hold on.
KimK: Just toss in a 10lb bag of ice in the PC
submerge in vegetable oil? (the computer, not you)
500 lbs of CO2
Jymmm: Thanks, I'll keep that in mind. Can I borrow some for margaritas?
KimK: Depends, what tequila ?
Actually lately (with all this hauling) lemonade sounds pretty good, I think I'll hit the grocery store on the way home. (But for a good margarita, how about 1800? I haven't tried any of the many lesser-known and even "microbrew" tequilas that are fashionable lately.)
KimK: 1800 isn't bad, I have a preference to Jose Cuevro Gold.
Ha, great minds think alike?
KimK: If you've never had a Cadillac MArgarita, and you like tequila, you should try one. I like on the rocks with salt.
(your link recommended 1800 also, I mean. ) OK, thanks, I will try one when the next opportunity arrives.
HEY! That's what we should do... Make a Bartender module for EMC
Yeah, but I always order top shelf with Jose Gold instead.
The bartender module could cut fruit, squeeze for juices, and dispense
as well as shaken and not stirred
jepler: i noticed emc2.deb Recommends hostmot2-firmware.deb, but there's no such package
maybe it should recommend hostmot2-firmware-all? or maybe all hostmot2-firmware-* packages should Provide: hostmot2-firmware?
does recommend cause it to be automatically installed sometimes, or is it just informative?
recommended packages are installed by default, but can be manually removed without breaking anything
"suggests" is informative but not installed by default
i <3 debs
they sure do beat rpms
the best feature is apt-get source as a regular user
apt-get source is pretty cool, i also like "apt-get build-dep"
yep that too
I like the idea that any user should be able to see (and modify and repackage) source for anything he runs
OK, I'm back. Hi Seb! I thought the rank was Jose Cuervo Silver, then Gold, then 1800, then what, "Reservo de Familia" or something? (Too much money for me. It's like that episode of "The West Wing" where one of the characters (to celebrate a special occasion) pulls out a bottle of Johnnie Walker Blue (Blue??) and says, "Johnnie Walker Blue, $500 a bottle!" It's probably more now, West Wing has been gone for awhile.)
huh, i just got the message "PARPORT: linux parport parport0 does not support mode 4"
fresh live-cd install, then compiled & ran master
is that a warning or fatal?
its a warning
then it says "PARPORT: continuing anyway"
then everything works fine
i wonder what mode 4 is
that means linux doesn't recognize it as epp-capable
dmesg from loading the parport driver at boot says: parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
but clearly the port does support epp
i think i even set the bios setting for the port
* seb_kuzminsky looks for that failing hm2 stepgen config pcw was talking about
before:[ 9.732132] parport0: PC-style at 0x3bc, irq 7 [PCSPP,TRISTATE]
after:[ 15.376122] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
on this thinkpad, fixing my bios settings does make a difference
hold on, i'll double-check mine
the bios is already set to epp on this machine
it's an old dell (a dimension 4600, for the search engines)
cradek, seb_kuzminsky: Is this more of that Linux/Debian/Ubuntu/whoever "new parallel port operating method/instruction"(?) business that gave jepler trouble on the 2.4.0, 2.4.1, 2.4.1plus round of releases?
huh, linux must get the test wrong (or knows something we don't)
KimK: yes, and it's just a warning now, so it's toothless
OK. While we wait to hear more from Seb on that I'll sneak in some reply lines to cradek's earlier question.
cradek: Yes, I think you were right on the money in your email (and thanks for the credit, btw). I'll look around and see if I copied that chat, I wanted to show it to John, I may have it still. The problem (in my view, anyway) is that torque mode is just, well, wrong. Now, the fact that there is a feedback loop closed around it makes it look pretty good despite it being wrong, so people look at the pretty-good results and say, great!
Torque mode is supposed to be used for applications like spooling, winding, product rolls, etc., where the rotational speed is usually set arbitrarily as a matter of convenience, and is largely unimportant!
I'd sure like for someone to try it...
I guess I could try it on my sherline lathe, but it's not a great test bed.
ok i got nothing on the epp bios thing, the bios setting doesnt seem to matter on this computer
but it works?
the reason i built this computer was to try to duplicate the problem rick g reported to pcw about following errors in the hm2 stepgen
except i dont have another 5i20 to put in it, and all i have at this lab is a 7i43
maybe that matters, i dont know
but rick g's config ferrors on axis 0 immediately when running the logo program
that's with a 50 us base thread
if i remove the base thread it does not ferror, just as the OP reported
it's actually quite great that you reproduced it
if i add halscope's sampler function to the base thread, the ferror goes away
for a little while at least
it just ferror'd, but on the M, not on the first move of the E
twice ferrored in the same place
line 147 of the logo
teeny little line in just Y
wonder what's special about it
which joint ferrors?
thte one with the funny config - joint 0
oh you said axis 0 - but it's not even moving in line 147
innit? 147 as shown here is g1 with an x word
X same as on line 145
* KimK thinks "innit?" must be from the same dictionary as "djeet?"
ack, central time is causing me to want to go to bed
stupid timezones, making us sleepy
see you coconspirators later
see ya :-)
cradek: OK, goodnight. One more reply line: In torque mode (i.e., a roller drive) the really important thing is to maintain the set load (i.e., web tension), regardless of RPM(!!). It's exactly the opposite of velocity mode (i.e., a spindle drive), where the really important thing is to maintain the set RPM regardless of load (i.e., cutting force or lack of it).
quick! say something interesting to cradek will stay up and talk to us!
ooh, ohh, i almost have a halscope trace that will keep him up for sure
but you know I'll get (even) more and more coherent
I've invented an anti-gravity drive! (Oh crap, where did I put that McDonald's napkin?)
[04:56:35] <seb_kuzminsky> http://imagebin.ca/view/qQk1tdc.html
the ferror is just -.00013 when it stops, because the .ini is crazy
so it built up gradually and then errored
looks like the rapid is just too fast for the stepgen
same old problem
it built up over like 0.2 sec
When I was testing John's BP2 (steppers), we started out by tuning max v, accel, etc., by hand by jogging back and forth, and say, "great, we're done". Then we'd run a part program, and get lost steps, which we knew about because John's BP2 came with mechanical counters on each axis. So we recorded the starting counts, and ended our part programs at the same place. So...
why does the base period affect how fast it can go?
if i remove the base thread, the ferror goes away
those counters are a sure sign that the stepper machines never really worked very well
so we ended up having to test tuning values with cradek's/jepler's "cloud" of g-code, because only that seemed to be random(?) enough that it was an adequate test of whether we had correct tuning or not. The correct tuning (to guarantee no missed steps) turned out to be a lot "slower" than we initially would have guessed.
what percentage difference between settings that seemed ok and settings that are actually reliable?
[05:11:02] <seb_kuzminsky> http://imagebin.ca/view/5p_JhT.html
[05:11:02] <seb_kuzminsky> http://imagebin.ca/view/Dr2qQ0KM.html
first one is with a basethread and the rapid gets away from the stepgen
second one is no basethread, and it keeps up just fine
different time scales, sampling in the base thread in the first pic
here's a theory
I notice it's running out of accel, not velocity
I bet programming G61 will make it a lot worse
in both cases it's got hm2 stepgen.maxaccel=0
with a basethread, the servo thread gets interrupted more between read & write
hm2 chooses the stepgen vel when it's time to write
based on how far off it was when it read
so that new vel doesn't get to act for a whole period
but if the servo thread was interrupted by the base thread, that measurement is no longer accurate - it's now *behind* where the tp wants it to be
the new vel doesnt get to act until the base thread has interrupted it a bunch
it wont be this bad with the 5i20, but with the 7i43 the servo thread takes 500-875 us to run...
so it gets interrupted by the base thread 10-17 times
even if each interruption is short, that can't be good
i dont see a great way around that
i could try to detect the skew between hm2_read and hm2_write, and complain (once) if it's too big
but i can't really fix it i think
why does it keep up fine until it tries to decel?
it keeps up worse and worse as long as the rapid continues
that's not what the plot says
as you're cruising along your rapid it's fine
it's the decel to a stop that kills it
with this negative ferror is the feedback position leading or lagging on the decel?
[05:29:23] <seb_kuzminsky> http://imagebin.ca/view/VGkd1elc.html
only on decels! not on the (surely matching) accels
I look forward to reading back in the morning
thanks for your help
seb_kuzminsky: That last one is a great trace, shows the problem very clearly, great work. And cradek is right, even the very tiny decreasing velocity from about 2.5 to 2.6 seconds was starting to cause problems in the following error, where the much larger increasing velocity from 2.6 to 3.0 seconds (4 times longer?) did not seem to cause much of an issue.
cradek: Goodnight, and before I forget: The percentage difference in the settings we ended up with varied by the mass of the axes (knee mill, so masses ranked in size X, Y, Z. All same motors.), plus the gearing further confused things because X, Y are 2:1 and Z is 4:1. And Z is vertical with an air counterbalance (we started by setting air to book spec, later we disabled Z motor and set by ballscrew feel). But to answer your question, just as a general
rule I would guess X & Y maybe about 2/3(?) of the max_v and accel we thought would work and Z maybe about half(?) of what we thought would work. John was kind of disappointed and wished for servos.
seb_kuzminsky: An interesting question would be what would happen if the velocity-fb was increasing/decreasing on the *negative* side of the zero line. Can you trigger on that *and* following error? Or, maybe have to write your own (similar) g-code?
i'm trying to write a smaller g code that triggers it
OK. I've got to go finish a job which has to be done in the morning, I'll do that and check back here in a little while, maybe half an hour or so? Or can you make us a last post if you get tired?
i'll be hacking for a little bit longer, but i dont know if i'll make much progress...
looks like accel = 2x decel: http://imagebin.ca/view/8AGcLQNp.html
hm that's probably my program being stupid
yeah that's fake
nevermind me, maybe i should go to bed too
KimK: here's the plot you asked for, i think: http://imagebin.ca/view/iaC-au.html
it shows ferror getting larger in magnitude whenever it's decelerating with a basethread
uhm, and by "decelerating" i mean "making the velocity less positive"
this is not *so* bad if vel<0, because then "making vel less positive" means increasing the magnitude of the vel, which allows a larger ferror before faulting
but when vel>0, then "making vel less positive" means decreasing the magnitude of the vel, so the acceptable ferror decreases, while the actual ferror increases, and it faults
the functions exported to HAL with hal_export_funct() get a long argument, which hal.h claims is the thread period in nanoseconds
but it appears this number is the computed ideal thread period, not the actual time since the previous invocation of the function
ugh, i give up for tonight
seb: yes, the 'period' you get in your function is the period the underlying rtos has promised for the thread. It doesn't have anything to do with the time since the last invocation of that function.
oddly, I thought I built 2.4.1 on mozmckhardy, but I can't build 2.4.2
/usr/realtime-2.6.32-22-rtai/include/asm/rtai_vectors.h:44:23: error: asm/ipipe.h: No such file or directory
on the step CC [M] /home/chris/emc2-2.4.1/src/hal/classicladder/arithm_eval.o
oops I meant mozmck/lucid of course
cradek: kernel upgrade probably broke the headers
cradek: you have to pin one of the kernel packages otherwise an ubuntu upgrade clobbers an adeos header
There are some magic lines for apt_preferences but I can't tell you what right now.
Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-07-10.txt
I think the logger was off the day jepler wrote about it
good night all
dpkg-deb: building package `emc2' in `../emc2_2.4.2_i386.deb'.
cradek: in case you didn't find it: http://pastebin.ca/1898128