Back
[00:02:34] <PCW> So if you build your own VFD beware that you need a return AC path from DC VBUS to frame ground (say .01 @3KV)
[00:03:41] <PCW> and perhaps a ferrite bead common mode choke around the 3 phase lines going to the motor
[00:09:15] <PCW> bbl time to go home and commune with my lagomorph and ovine friends...
[00:09:18] <andypugh> OK, I will bear it in mine
[00:09:52] <andypugh> Say "Bahh" to the latter, and, err, give the others carrots
[00:11:05] <PCW> ya that current has to go somewhere (big motors may have 1000s of pf)
[00:11:07] <PCW> OK bye andy
[03:13:59] <cradek> KimK: did I get my recommendations about pid right in that email (based on our conversation a while back)?
[03:21:38] <KimK> 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.)
[03:21:55] <cradek> yikes, sounds miserable
[03:22:26] <cradek> the scheme to simulate a differential velocity input to a torque mode amp
[03:22:57] <cradek> thread started with a message from Jake A "odd PID tuning problem"
[03:26:22] <KimK> 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.
[03:27:25] <cradek> sounds like a lot of work - hope the move goes well and safely
[03:27:48] <KimK> Thanks for the subject line, I'll review the thread real quick. Hold on.
[03:28:13] <Jymmm> KimK: Just toss in a 10lb bag of ice in the PC
[03:28:35] <cradek> submerge in vegetable oil? (the computer, not you)
[03:28:53] <Jymmm> 500 lbs of CO2
[03:28:56] <KimK> Jymmm: Thanks, I'll keep that in mind. Can I borrow some for margaritas?
[03:29:29] <Jymmm> KimK: Depends, what tequila ?
[03:31:41] <Jymmm> KimK:
http://www.drinksmixer.com/drink7393.html
[03:32:34] <KimK> 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.)
[03:33:24] <Jymmm> KimK: 1800 isn't bad, I have a preference to Jose Cuevro Gold.
[03:33:27] <KimK> Ha, great minds think alike?
[03:34:31] <Jymmm> KimK: If you've never had a Cadillac MArgarita, and you like tequila, you should try one. I like on the rocks with salt.
[03:35:25] <KimK> (your link recommended 1800 also, I mean. ) OK, thanks, I will try one when the next opportunity arrives.
[03:35:26] <Jymmm> HEY! That's what we should do... Make a Bartender module for EMC
[03:36:17] <Jymmm> Yeah, but I always order top shelf with Jose Gold instead.
[03:37:35] <Jymmm> The bartender module could cut fruit, squeeze for juices, and dispense
[03:37:54] <Jymmm> as well as shaken and not stirred
[03:49:19] <seb_kuzminsky_> jepler: i noticed emc2.deb Recommends hostmot2-firmware.deb, but there's no such package
[03:49:46] <cradek> oops
[03:49:49] <seb_kuzminsky_> maybe it should recommend hostmot2-firmware-all? or maybe all hostmot2-firmware-* packages should Provide: hostmot2-firmware?
[03:50:43] <cradek> does recommend cause it to be automatically installed sometimes, or is it just informative?
[03:51:35] <seb_kuzminsky_> recommended packages are installed by default, but can be manually removed without breaking anything
[03:51:47] <seb_kuzminsky_> "suggests" is informative but not installed by default
[03:52:05] <cradek> ah
[03:52:15] <seb_kuzminsky_> i <3 debs
[03:53:33] <cradek> they sure do beat rpms
[03:54:25] <cradek> the best feature is apt-get source as a regular user
[03:54:26] <seb_kuzminsky_> brb rebooting
[03:58:14] <seb_kuzminsky> hola
[03:58:18] <cradek> hey
[03:59:32] <seb_kuzminsky> apt-get source is pretty cool, i also like "apt-get build-dep"
[03:59:41] <cradek> yep that too
[04:00:15] <cradek> I like the idea that any user should be able to see (and modify and repackage) source for anything he runs
[04:07:21] <KimK> 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.)
[04:10:32] <seb_kuzminsky> huh, i just got the message "PARPORT: linux parport parport0 does not support mode 4"
[04:10:46] <seb_kuzminsky> fresh live-cd install, then compiled & ran master
[04:10:50] <seb_kuzminsky> using 7i43-400
[04:13:15] <cradek> is that a warning or fatal?
[04:14:00] <seb_kuzminsky> its a warning
[04:14:09] <seb_kuzminsky> then it says "PARPORT: continuing anyway"
[04:14:13] <seb_kuzminsky> then everything works fine
[04:14:21] <seb_kuzminsky> i wonder what mode 4 is
[04:14:24] <cradek> that means linux doesn't recognize it as epp-capable
[04:14:43] <seb_kuzminsky> oh, right
[04:15:07] <seb_kuzminsky> dmesg from loading the parport driver at boot says: parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
[04:15:18] <seb_kuzminsky> but clearly the port does support epp
[04:15:31] <seb_kuzminsky> i think i even set the bios setting for the port
[04:15:54] <seb_kuzminsky> * seb_kuzminsky looks for that failing hm2 stepgen config pcw was talking about
[04:20:03] <cradek> before:[ 9.732132] parport0: PC-style at 0x3bc, irq 7 [PCSPP,TRISTATE]
[04:20:07] <cradek> after:[ 15.376122] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE,EPP]
[04:20:18] <cradek> on this thinkpad, fixing my bios settings does make a difference
[04:20:31] <seb_kuzminsky> hold on, i'll double-check mine
[04:23:51] <seb_kuzminsky> the bios is already set to epp on this machine
[04:24:06] <seb_kuzminsky> it's an old dell (a dimension 4600, for the search engines)
[04:24:48] <KimK> 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?
[04:24:50] <cradek> huh, linux must get the test wrong (or knows something we don't)
[04:25:04] <cradek> KimK: yes, and it's just a warning now, so it's toothless
[04:29:21] <KimK> OK. While we wait to hear more from Seb on that I'll sneak in some reply lines to cradek's earlier question.
[04:29:43] <KimK> 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!
[04:30:16] <KimK> 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!
[04:30:43] <cradek> I'd sure like for someone to try it...
[04:32:15] <cradek> I guess I could try it on my sherline lathe, but it's not a great test bed.
[04:33:09] <seb_kuzminsky> ok i got nothing on the epp bios thing, the bios setting doesnt seem to matter on this computer
[04:33:20] <cradek> but it works?
[04:33:24] <seb_kuzminsky> works fine
[04:34:01] <seb_kuzminsky> 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
[04:34:21] <seb_kuzminsky> except i dont have another 5i20 to put in it, and all i have at this lab is a 7i43
[04:34:29] <seb_kuzminsky> maybe that matters, i dont know
[04:34:49] <seb_kuzminsky> but rick g's config ferrors on axis 0 immediately when running the logo program
[04:35:57] <seb_kuzminsky> that's with a 50 us base thread
[04:36:58] <seb_kuzminsky> if i remove the base thread it does not ferror, just as the OP reported
[04:37:43] <cradek> wild
[04:41:02] <seb_kuzminsky> heh
[04:41:19] <cradek> it's actually quite great that you reproduced it
[04:41:22] <seb_kuzminsky> if i add halscope's sampler function to the base thread, the ferror goes away
[04:41:29] <seb_kuzminsky> for a little while at least
[04:41:43] <seb_kuzminsky> it just ferror'd, but on the M, not on the first move of the E
[04:42:43] <seb_kuzminsky> twice ferrored in the same place
[04:43:10] <seb_kuzminsky> line 147 of the logo
[04:44:07] <cradek> teeny little line in just Y
[04:44:41] <cradek> wonder what's special about it
[04:45:38] <cradek> which joint ferrors?
[04:45:53] <seb_kuzminsky> thte one with the funny config - joint 0
[04:46:07] <cradek> oh you said axis 0 - but it's not even moving in line 147
[04:47:02] <seb_kuzminsky> innit? 147 as shown here is g1 with an x word
[04:47:14] <cradek> X same as on line 145
[04:47:51] <seb_kuzminsky> oh, right
[04:47:53] <seb_kuzminsky> huh
[04:50:13] <KimK> * KimK thinks "innit?" must be from the same dictionary as "djeet?"
[04:51:33] <cradek> ack, central time is causing me to want to go to bed
[04:51:45] <seb_kuzminsky> stupid timezones, making us sleepy
[04:51:47] <cradek> see you coconspirators later
[04:51:53] <seb_kuzminsky> see ya :-)
[04:52:24] <KimK> 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).
[04:52:43] <seb_kuzminsky> quick! say something interesting to cradek will stay up and talk to us!
[04:52:50] <cradek> dangit
[04:53:00] <KimK> haha
[04:53:04] <seb_kuzminsky> ooh, ohh, i almost have a halscope trace that will keep him up for sure
[04:53:07] <cradek> but you know I'll get (even) more and more coherent
[04:53:14] <cradek> incoherent, haha
[04:54:31] <KimK> 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
[04:57:17] <seb_kuzminsky> the ferror is just -.00013 when it stops, because the .ini is crazy
[04:57:39] <cradek> so it built up gradually and then errored
[05:01:30] <seb_kuzminsky> looks like the rapid is just too fast for the stepgen
[05:06:05] <cradek> same old problem
[05:06:15] <cradek> it built up over like 0.2 sec
[05:06:29] <KimK> 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...
[05:06:30] <cradek> why does the base period affect how fast it can go?
[05:06:33] <seb_kuzminsky> if i remove the base thread, the ferror goes away
[05:08:09] <cradek> those counters are a sure sign that the stepper machines never really worked very well
[05:09:00] <KimK> 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.
[05:09:41] <cradek> 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
[05:11:18] <seb_kuzminsky> first one is with a basethread and the rapid gets away from the stepgen
[05:11:24] <seb_kuzminsky> second one is no basethread, and it keeps up just fine
[05:11:40] <seb_kuzminsky> different time scales, sampling in the base thread in the first pic
[05:12:29] <seb_kuzminsky> here's a theory
[05:12:35] <cradek> I notice it's running out of accel, not velocity
[05:13:16] <seb_kuzminsky> err... yes
[05:13:56] <cradek> I bet programming G61 will make it a lot worse
[05:14:11] <seb_kuzminsky> in both cases it's got hm2 stepgen.maxaccel=0
[05:14:16] <seb_kuzminsky> but
[05:14:38] <seb_kuzminsky> with a basethread, the servo thread gets interrupted more between read & write
[05:14:55] <seb_kuzminsky> hm2 chooses the stepgen vel when it's time to write
[05:15:07] <seb_kuzminsky> based on how far off it was when it read
[05:15:20] <cradek> ahh
[05:15:30] <cradek> so that new vel doesn't get to act for a whole period
[05:15:35] <seb_kuzminsky> 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
[05:15:56] <seb_kuzminsky> the new vel doesnt get to act until the base thread has interrupted it a bunch
[05:16:36] <seb_kuzminsky> it wont be this bad with the 5i20, but with the 7i43 the servo thread takes 500-875 us to run...
[05:16:55] <seb_kuzminsky> so it gets interrupted by the base thread 10-17 times
[05:17:07] <seb_kuzminsky> even if each interruption is short, that can't be good
[05:17:55] <seb_kuzminsky> i dont see a great way around that
[05:18:27] <seb_kuzminsky> i could try to detect the skew between hm2_read and hm2_write, and complain (once) if it's too big
[05:18:39] <seb_kuzminsky> but i can't really fix it i think
[05:21:28] <cradek> why does it keep up fine until it tries to decel?
[05:22:00] <seb_kuzminsky> it keeps up worse and worse as long as the rapid continues
[05:22:12] <cradek> that's not what the plot says
[05:22:38] <seb_kuzminsky> hmm
[05:22:53] <cradek> as you're cruising along your rapid it's fine
[05:23:04] <cradek> it's the decel to a stop that kills it
[05:24:00] <cradek> with this negative ferror is the feedback position leading or lagging on the decel?
[05:24:55] <seb_kuzminsky> you're right
[05:29:23] <seb_kuzminsky> http://imagebin.ca/view/VGkd1elc.html
[05:30:29] <cradek> only on decels! not on the (surely matching) accels
[05:35:28] <cradek> goodnight :-)
[05:35:37] <cradek> I look forward to reading back in the morning
[05:35:39] <seb_kuzminsky> goodnight chris
[05:35:46] <seb_kuzminsky> thanks for your help
[05:37:28] <KimK> 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.
[05:38:11] <KimK> 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
[05:38:12] <KimK> 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.
[05:38:22] <KimK> Oops
[05:43:36] <KimK> 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?
[05:45:57] <seb_kuzminsky> i'm trying to write a smaller g code that triggers it
[05:49:47] <KimK> 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?
[05:53:13] <seb_kuzminsky> i'll be hacking for a little bit longer, but i dont know if i'll make much progress...
[06:00:09] <seb_kuzminsky> looks like accel = 2x decel:
http://imagebin.ca/view/8AGcLQNp.html
[06:03:00] <seb_kuzminsky> hm that's probably my program being stupid
[06:03:22] <seb_kuzminsky> yeah that's fake
[06:03:31] <seb_kuzminsky> nevermind me, maybe i should go to bed too
[06:09:19] <seb_kuzminsky> KimK: here's the plot you asked for, i think:
http://imagebin.ca/view/iaC-au.html
[06:09:39] <seb_kuzminsky> it shows ferror getting larger in magnitude whenever it's decelerating with a basethread
[06:10:31] <seb_kuzminsky> uhm, and by "decelerating" i mean "making the velocity less positive"
[06:11:17] <seb_kuzminsky> 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
[06:12:07] <seb_kuzminsky> 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
[06:56:02] <seb_kuzminsky> the functions exported to HAL with hal_export_funct() get a long argument, which hal.h claims is the thread period in nanoseconds
[06:56:27] <seb_kuzminsky> but it appears this number is the computed ideal thread period, not the actual time since the previous invocation of the function
[07:15:00] <seb_kuzminsky> ugh, i give up for tonight
[13:39:24] <jepler> 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.
[21:22:29] <cradek> oddly, I thought I built 2.4.1 on mozmckhardy, but I can't build 2.4.2
[21:22:52] <cradek> /usr/realtime-2.6.32-22-rtai/include/asm/rtai_vectors.h:44:23: error: asm/ipipe.h: No such file or directory
[21:23:03] <cradek> on the step CC [M] /home/chris/emc2-2.4.1/src/hal/classicladder/arithm_eval.o
[21:25:24] <cradek> oops I meant mozmck/lucid of course
[22:24:15] <alex_joni> cradek: kernel upgrade probably broke the headers
[22:43:36] <jepler> cradek: you have to pin one of the kernel packages otherwise an ubuntu upgrade clobbers an adeos header
[22:44:16] <jepler> There are some magic lines for apt_preferences but I can't tell you what right now.
[22:47:36] <alex_joni> logger_dev: bookmark
[22:47:36] <alex_joni> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-07-10.txt
[22:50:11] <alex_joni> I think the logger was off the day jepler wrote about it
[22:56:37] <alex_joni> good night all
[23:46:25] <cradek> dpkg-deb: building package `emc2' in `../emc2_2.4.2_i386.deb'.
[23:46:27] <cradek> whee
[23:49:29] <jepler> cradek: in case you didn't find it:
http://pastebin.ca/1898128