#linuxcnc-devel | Logs for 2014-10-18

Back
[09:27:29] <jepler> pcw_home: spun some motors with u3 + 7i90spi last night. no new problems cropped up.
[09:27:32] <jepler> (servos)
[09:29:48] <pcw_home> Thats good news.
[09:29:49] <pcw_home> I plan to add DPLL encoder sample re-timing next which will improve servo jitter tolerance
[09:33:33] <pcw_home> (absolute encoders already have this feature since they require a pre-trigger to start the serial read cycle)
[10:06:10] <jepler> these little motors are funny
[10:06:48] <jepler> <200mA @ 30V
[10:06:51] <jepler> not much velocity or acceleration
[10:09:19] <pcw_home> thats pretty tiny
[10:09:37] <jepler> I'm sure their peak is higher, I haven't tried to stall them
[10:10:42] <jepler> tuned to 500u (20 counts) by this amateur
[10:11:24] <pcw_home> bare Hbridge drive?
[10:11:29] <jepler> your 7iwhatever
[10:11:46] <jepler> the one with 4 amps & encoders
[10:12:03] <pcw_home> 7I30
[10:12:43] <pcw_home> Small motors especially bare may be hard to tune at 1 KHz
[10:12:56] <jepler> they're not bare actually
[10:13:11] <jepler> years ago cradek made this little gantry homing test device
[10:13:18] <pcw_home> Ahh
[10:13:29] <jepler> I dunno if it was there the year you visited us in wichita
[10:13:45] <jepler> a couple of little nylon (?) blocks on leadscrews
[10:13:58] <pcw_home> I think it may have been
[10:14:16] <pcw_home> bbl dog walking time
[10:14:19] <jepler> see ya
[16:03:35] <jepler> we were surprised by the low max velocity and low holding torque of these motors with the 7i30. eventually jmk soldered an inductor in series with the motor. the peak current doubled and the velocity went up over 4x
[16:04:10] <jepler> I dunno if he's going to do that to the other motor, or just declare the mystery of low performance solved
[16:16:26] <skunkworks> wow
[16:29:51] <jepler> I think the estimated motor inductance was 15mH, so the current limit is reached very quickly, and even in slow decay mode the current decayed really rapidly, so you only got a fraction of the average current
[16:29:56] <jepler> if jmk were here he'd explain it accurately
[16:36:01] <skunkworks> I think you channelled jmk very nicely..
[16:36:27] <skunkworks> minus the maths...
[17:45:07] <jepler> seb, cradek: terrible implementation of single-step http://paste.debian.net/plain/127523
[17:46:37] <jepler> seb_kuzminsky: ^^
[17:52:45] <seb_kuzminsky> ossom, thanks
[18:11:09] <jepler> be warned, it fails all the runtests because it always fails at shutdown
[18:11:29] <jepler> the way I created a component to own thread pins/parameters is too tricky, I guess
[19:48:47] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/motoman 8415e84 06linuxcnc 10(13 files) motoman kinematics * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8415e84
[19:48:47] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/motoman 99ca0a8 06linuxcnc 04motoman-r/motoman.var.bak remove the var backup file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=99ca0a8
[19:48:47] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/motoman 806659e 06linuxcnc 10(25 files in 7 dirs) integrate motoman robot6kins with our build system * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=806659e
[19:48:48] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/motoman 943b43a 06linuxcnc 10configs/sim/axis/vismach/motoman/motoman_sim_6.hal comment out motomangui stuff, missing stl files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=943b43a
[20:08:49] <jepler> boo, our 7i30 stopped working
[20:09:17] <jepler> it seems like something in the logic section went wrong, though we can't spot any damaged component
[20:09:52] <jepler> no encoder feedback, let alone running the amps
[20:11:24] <jepler> the green LED silkscreened "3.3V" doesn't light now, and measuring at what appears to be the output of VR1 shows .2v. resistance from the VR1 output to GND is 1.2ohm.
[20:18:00] <jepler> pcw_home: anything you can think of to try or check?
[20:47:19] <pcw_home> Hmm either the voltage regulator failed or one of chips it powers shorted
[20:47:54] <cradek> it was actually running when it failed
[20:48:09] <cradek> we weren't moving wires around, or doing any of the other things that usually make things fail
[20:48:15] <pcw_home> I dont have access to a current schematic so I dont know off hand what the 3.3v regulator powers
[20:48:31] <cradek> it's on the gantry homing jig :-(
[20:50:45] <pcw_home> I guess you could try powering the 3.3 with a lab supply and inch the current up until you find something hot
[20:51:08] <cradek> that's a good idea (I fixed my laptop by doing that)
[20:55:16] <atom1> out of curiosity, what feedrate does the backlash comp move feed at before a normal feed move?
[21:04:58] <pcw_home> freeby.mesanet.com/7i30sch.zip shoud be about right (though old)
[21:04:59] <pcw_home> The 74HC14s may be powered by the 3.3V on newer versions
[21:06:04] <cradek> thanks!
[21:06:39] <cradek> this one says art rev. D (I bet it's quite old)
[21:10:19] <pcw_home> I think we have had a few LM3480s fail so it may be the 3.3v VR that failed
[21:47:07] <pcw_home> if the LM3480 is bad and you have a 5V tolerant FPGA card, I think you can just jumper it out (so the 74HC14s run on 5V instead)
[21:48:06] <pcw_home> (this will raise the nominal encoder input threshold to ~2.5V which should be OK)
[21:55:37] <jepler> pcw_home: we snipped pin 14 of U6 after jon elson's finger picked it out as the overheating part. now we have a green "3.3V" led again.
[21:56:04] <jepler> more word soon once we have things put back together, but it looks like one of the 74HC14s failed
[21:56:14] <pcw_home> weird
[22:04:39] <jepler> well now things went worse
[22:05:01] <jepler> (a h bridge gave up its smoke)
[22:05:18] <jepler> "I don't know why that happened" </cradek>
[22:07:02] <jepler> different channel too
[22:07:27] <pcw_home> maybe this started with a Hbridge damaging a 74HC14 on its way to failure
[22:12:10] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/dotty-docs 8d16c65 06linuxcnc 10debian/control.in 10docs/src/Submakefile 10docs/src/code/.gitignore 10docs/src/code/Code_Notes.txt docs: include homing state diagrams in the Code Notes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=8d16c65
[22:12:10] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/master/dotty-docs f594930 06linuxcnc 10docs/src/asciideps docs: better asciidoc dependency generation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f594930
[22:14:13] <pcw_home> The Hbridges on the 7I30 can be destroyed by fast braking when in slow decay mode
[22:14:14] <pcw_home> (or not dropping enable on a following error )
[22:15:53] <cradek> it sounds like that might have been what we were doing
[22:16:27] <pcw_home> This is because in slow decay mode they short the load in the PWM off cycle but they only have one common current sense resistor
[22:16:28] <pcw_home> so cannot sense current in this condition
[22:16:48] <jepler> before the first failure I had just increased velocity and acceleration considerably
[22:16:57] <cradek> yeah, it was working great
[22:17:28] <jepler> went from something like 1ips and 4ips^2 to 8ips and 36ips^2
[22:17:38] <jepler> and yes, slow decay mode
[22:18:26] <pcw_home> may also have had a overvoltage, it has no protection against this
[22:18:33] <cradek> atom1: half of the configured max velocity I think?
[22:18:45] <cradek> yes we were running it on 30v
[22:19:18] <cradek> but tiny mass on the motors (just 10" of leadscrew)
[22:20:08] <pcw_home> Big output capacitor on PS?
[22:20:35] <jepler> dunno, there's a 470uF on the input to the 7i30 and we were using a 5A bench supply which is probably beefy
[22:22:22] <pcw_home> I will look to seen if we have any 7I30s or 7I40s in stock on Monday and send you one
[22:22:24] <jepler> live and learn and don't tune everything so darned fast
[22:23:07] <jepler> pcw_home: I'm not sure we'll be here for long enough that it's worth it. I leave first thing wednesday morning
[22:24:11] <pcw_home> (you may be able to remove the bad chips and continue with what still works)
[22:24:28] <jepler> yeah, I hear they have a nice hot-air rework station here
[22:24:53] <cradek> it's true we only need two working H bridges for this task
[22:24:56] <jepler> we only need two fully working channels for our little gantry setup, but we know we have two at least partially busted channels
[22:26:05] <pcw_home> if the busted HBridge channel was unused, that points to an overvoltage
[22:26:40] <jepler> this was a used channel
[22:27:46] <jepler> though after we hooked things back up it was already a non-working channel -- the motors had no holding torque even before the smoke came out
[22:28:03] <jepler> we were busy scratching our heads over that when things started popping and smoking
[22:28:12] <pcw_home> OK so most likely overcurrent (maybe wide FE settings)
[22:28:33] <jepler> though I *may* have just turned the screw way far away from its commanded position when it popped
[22:29:13] <jepler> pretty sure I was turning one of the leadscrews at the time, and since I felt no resistance I wasn't thinking it was particularly problematic to turn it further
[22:29:30] <jepler> more "huh, why are our enables broken" than anything else
[22:35:04] <pcw_home> Hard to tell the exact sequence of what went wrong but from experience
[22:35:06] <pcw_home> slow decay mode, high speeds and accelerations and wide FEs (or no dropping enables on FE)
[22:35:07] <pcw_home> are liable to kill the A3959s
[22:41:39] <jepler> we sure did a couple of those things
[22:41:46] <jepler> one more reason not to reward us with more hardware :-P
[22:43:02] <pcw_home> Well the A3959s are not very tough
[22:47:21] <pcw_home> (mainly because of the lack of current sensing in slow decay mode)
[22:47:23] <pcw_home> Damage is mostly preventable by having small FEs but that makes tuning
[22:47:24] <pcw_home> harder
[22:49:03] <jepler> 7i40 looks like it must be your own discrete hbridge design?
[23:08:50] <pcw_home> Yes (and much tougher)
[23:10:07] <fenugrec> Hi, I spent a lot of time on some trivial setup questions, and to make things easier for others I would have some additions to propose for the lincnc docs (mostly text, and one illustration). Where would I submit these ? I can probably make diff's against git.linuxcnc.org