Back
[03:03:00] <lilo> [Global Notice] Hi all. If your channel was just attacked, please message me. Thanks.
[14:24:29] <alex_joni> hello
[14:24:41] <cradek> hi
[14:24:57] <alex_joni> didn't want to interrupt your helping out in #emc ;)
[14:25:09] <alex_joni> managed to ssh into cvs3 ?
[14:25:15] <cradek> haven't tried yet
[14:25:26] <alex_joni> should be working
[14:25:34] <alex_joni> I moved the HDD to the final machine
[14:25:42] <alex_joni> and isolated it a bit for noise ;)
[14:26:17] <cradek> need to shower and eat first!
[14:26:48] <cradek> sometimes "support calls" come at inconvenient times though...
[14:27:26] <cradek> I wonder if you can enable those repositories in synaptic
[14:27:31] <alex_joni> I can try
[15:04:02] <alex_joni> jmkasunich: I installed cvs3, cradek will complete the config later today he said ;)
[15:04:16] <jmkasunich> cool
[15:04:21] <jmkasunich> I dunno where he is on cvs2
[15:04:28] <alex_joni> had 3 days fighting with freebsd :(
[15:04:41] <jmkasunich> but yours is probably higher priority since you have static IP (I think)
[15:04:57] <alex_joni> yeah, this will replace solaris.cs.utt.ro I think
[15:05:17] <alex_joni> right now it's at home, so it's a DHCP ip, but it never changed yet
[15:13:33] <alex_joni> jmkasunich: so, how's everything?
[15:21:01] <jmkasunich> sleepy
[15:21:11] <jmkasunich> I was up after 1am every day last week
[15:21:16] <jmkasunich> 3 am a couple times
[15:21:22] <alex_joni> heh, that's not nice ;)
[15:21:32] <alex_joni> I was working hard this week too..
[15:21:40] <alex_joni> always till around 1900 or so
[15:21:43] <jmkasunich> did you commit your changes to HAL_Intro.lyx?
[15:21:58] <alex_joni> yes,I did
[15:22:00] <jmkasunich> ok
[15:22:07] <jmkasunich> I might do some editing on that this weekend
[15:22:19] <alex_joni> before the lists commit started working again
[15:22:51] <alex_joni> wonder what happens if cradek's mailers send the mail from:<username@users.sourceforge.net>
[15:23:14] <jmkasunich> instead of "EMC CVS Server"?
[15:23:46] <alex_joni> yeah
[15:23:57] <alex_joni> I find it easier to spot who commits what..
[15:24:05] <alex_joni> but maybe that will be regarded as spamming?
[15:24:10] <jmkasunich> I bet altering the actual user@host part might be tough
[15:24:23] <jmkasunich> but he could probably alter the other part (the full name)
[15:24:43] <jmkasunich> instead of From: EMC CVS server <cvs-adm@cvs.linuxcnc.org>
[15:25:00] <jmkasunich> do From: cradek <cvs-adm@cvs.linuxcnc.org>
[15:25:07] <alex_joni> yeah, that's what I meant
[15:25:27] <alex_joni> even like that
[15:25:50] <jmkasunich> ask him when he comes back
[15:26:13] <alex_joni> I sure will :)
[15:26:17] <jmkasunich> gotta kvm over to my doze box (doing some easycad and pov ray work)
[15:26:26] <alex_joni> right now I'm adding bash to freebsd
[15:26:27] <jmkasunich> biab
[15:26:32] <alex_joni> ok, laters
[16:28:31] <skunkworks> jmkasunich: ?
[16:34:31] <jmkasunich> yeah?
[16:35:17] <jmkasunich> skunkworks: ?
[16:35:51] <skunkworks> how does this circuit to play with small motors with
http://www.cnczone.com/forums/attachment.php?attachmentid=14128
[16:36:35] <skunkworks> I would hook hl and lb togathee and la and hb togather.
[16:37:06] <jmkasunich> can't view the circuit, it wants a username and password
[16:37:13] <skunkworks> sorry
[16:37:17] <skunkworks> give me a second
[16:41:36] <skunkworks> http://www.electronicsam.com/images/KandT/sch_bridge.jpg
[16:45:24] <jmkasunich> I don't know the mosfet numbers
[16:45:40] <jmkasunich> I assume the top ones are P channel and the botton ones N channel?
[16:45:58] <skunkworks> I was planning on using what I had around - that is what I was assuming. just from the arrows
[16:46:13] <jmkasunich> what current are you aiming for
[16:46:23] <jmkasunich> is that for those fscking huge servos?
[16:46:31] <skunkworks> just to play - prpbably under 10
[16:46:32] <skunkworks> no
[16:46:39] <skunkworks> just to play with pid
[16:47:02] <jmkasunich> how bout "probably under 1" ;-)
[16:47:22] <jmkasunich> currnet sense resistor, 0.47 ohms - at 10A that would be 4.7V and 47 watts
[16:47:53] <jmkasunich> at 1A, .47V and .47W, as half watt resistor would be getting hot
[16:48:19] <jmkasunich> ok, lets look at gate drive
[16:48:21] <jmkasunich> high side first
[16:48:31] <jmkasunich> what is Vmotor going to be?
[16:48:56] <skunkworks> at the most 24v
[16:49:15] <jmkasunich> assume T1 is turned on
[16:49:23] <jmkasunich> 24V on Vmotor
[16:49:45] <jmkasunich> 15V zener (I'd make it 10 or 12, most fets are rated with 10V on the gate and max gate V is 20)
[16:50:00] <skunkworks> 10 volts across r3
[16:50:08] <jmkasunich> right
[16:50:12] <jmkasunich> which means a lot of current
[16:50:22] <jmkasunich> 66mA I think
[16:51:00] <jmkasunich> not a lot when it comes to charging the gate cap of the fet, but a lot for steady state
[16:51:07] <jmkasunich> meanwhile, when you turn off
[16:51:19] <jmkasunich> all you have discharging the gate cap of the fet is 2.2K
[16:51:22] <jmkasunich> R1
[16:51:33] <jmkasunich> so turn off will be slow
[16:52:20] <jmkasunich> high side gate drive is always a pain
[16:52:29] <skunkworks> so there could be an issue with both high and low be on at the same time. ouch.
[16:52:56] <jmkasunich> lets look at low side
[16:53:06] <jmkasunich> what pulls up LA?
[16:53:23] <skunkworks> I was hoping ttl
[16:53:37] <jmkasunich> isn't the 7408 open collector?
[16:53:47] <jmkasunich> oops, no
[16:53:53] <jmkasunich> 7408 is and gate
[16:53:56] <jmkasunich> * jmkasunich is rusty
[16:54:02] <skunkworks> thats ok - so am I
[16:54:29] <jmkasunich> ok, if LA is only pulled up to 4V or so by the 7408, then its emitter will only reach 3.4V
[16:54:36] <jmkasunich> not enough to turn on the fet
[16:54:41] <jmkasunich> you want 10V on the fet gate
[16:54:58] <jmkasunich> (thats why I thought you were doing open collector to level shift it to 12V)
[16:55:33] <skunkworks> well - I could - the top 7408 was there - to do pwm + direction
[16:55:58] <skunkworks> I would want to do pwm+pwm
[16:56:35] <skunkworks> if that makes sense
[16:57:14] <jmkasunich> give me a few minutes, I have a gate drive ckt that I think is better, but I have to draw it
[16:58:10] <skunkworks> if you have time. I not trying to pressure you. Just thought I could find a decent circut.
[17:01:01] <jmkasunich> crap
[17:01:13] <jmkasunich> there is an interactive sketching tool online, but you need flash
[17:01:19] <jmkasunich> and the flash download link seems busted
[17:02:59] <jmkasunich> bah - typo in the url on their download page
[17:05:47] <skunkworks> np
[17:05:53] <alex_joni> http://mcglothin.us/RobotScrapbook/CommunityPcbMill2005/IntroductionToGCodes/
[17:06:02] <alex_joni> that's some nice introductory info
[17:16:16] <alex_joni> jmkasunich:
http://www.rtai.dk/ <- rtai wiki, may come in handy some day :)
[17:43:30] <jmkasunich> skunkworks:
http://home.att.net/~jmkasunich/Pics/totem-pole-driver.pdf
[17:44:15] <jmkasunich> that design works for a P-channel/N-channel totem pole, when the motor supply voltage is fixed
[17:44:35] <jmkasunich> you have to choose zener ZD1 to be (Vmotor - 10V)
[17:44:50] <jmkasunich> if ZD1 is too high, the fets won't turn on all the way and will get hot
[17:45:05] <jmkasunich> if ZD1 is too low, both fets can turn on at the same time
[17:45:18] <jmkasunich> you might not need D3, D4, R4, and R6
[17:45:32] <jmkasunich> they are used to make sure turn off is faster than turn on to avoid shoot-thru
[17:46:03] <jmkasunich> Q1 thru Q3 are ordinary NPN switching transistors, 2N2222, 2N3904, etc
[17:46:20] <jmkasunich> D1 thru 4 are switching diodes
[17:46:30] <jmkasunich> 1N914, 1N4154, etc
[17:46:58] <jmkasunich> R1 = 470 to 1K
[17:47:14] <jmkasunich> R2 = 1K or so if driven from TTL
[17:47:22] <skunkworks> thank you very much. This will give me a good circuit to play with
[17:47:51] <jmkasunich> R3 and R5 are turn on resistors, value depends on the fets, try a few hundred ohms or so
[17:48:21] <jmkasunich> R4 and R5 are the turn off resistors, should be lower than the turn on resistors, maybe 1/2 to 1/4 of R3 and R5
[17:48:35] <jmkasunich> more like 1/2 I think
[17:48:35] <skunkworks> ok
[17:49:07] <jmkasunich> you can put a current sense resistor in the source of the bottom fet if your circuit needs one
[17:49:47] <jmkasunich> (or just for testing - look for a spike of current when switching from high to low, if you get a spike you need to either lower the turn off resistors, raise the turn on ones, or raise ZD1 voltage
[17:50:17] <jmkasunich> if you don't see a spike, you can try raising the turn off resistors, maybe remove them and the turn-off diodes completely
[17:50:57] <skunkworks> cool - time to blow the dust of the tecktronics
[17:50:59] <jmkasunich> the overall circuit is non-inverting
[17:51:14] <jmkasunich> when input goes hi, Q1 turns on, its collector goes low
[17:51:36] <jmkasunich> current goes thru D1, D4, and R6 (plus thru R5) turning off the lower fet
[17:52:00] <jmkasunich> current also goes thru R3, D2, and ZD1, turning on the upper mosfet
[17:52:15] <jmkasunich> since D1 and D2 are forward biased, Q2 and Q3 stay off
[17:52:50] <jmkasunich> Q1 can sink a few hundred mA of current, to charge/discharge the gate C of the fets quickly
[17:53:04] <jmkasunich> when input goes low, Q1 turns off
[17:53:24] <jmkasunich> R1 pulls up (rather weakly), but Q2 and Q3 amplify that
[17:53:55] <jmkasunich> so Q2 sends pulls up on the high fet gate thru D3 and R3, in parallel with R3, to turn it off
[17:54:16] <jmkasunich> Q3 pulls up on the low fet gate thru R5 only to turn it on
[17:55:01] <skunkworks> would you put "braking" diodes around the motor to supply and ground?
[17:55:14] <jmkasunich> Q2 and Q3 multiply the R1 current so they can source a few hundred mA to switch the gates quickly
[17:55:15] <skunkworks> or whatever you would call them
[17:55:30] <jmkasunich> yes, freewheel diodes are absolutely neccessary
[17:55:43] <skunkworks> I thought that was a stupid question
[17:55:44] <jmkasunich> you may or may not be able to rely on the fet's intrinsic diodes
[17:56:02] <jmkasunich> I didn't draw them because I was focused on the gate drive part of the circuit
[17:57:10] <skunkworks> yes - agian thank you. you guys are great. I am copying the text right now. ;) not that I don't trust logger_devel ;)
[17:57:46] <jmkasunich> copy the pic too.. I'll leave the pdf up for a while, but eventually I'll do housecleaning of my webpage and remove it
[17:58:12] <jmkasunich> you know there are easier and better ways to make a totem pole
[17:58:23] <skunkworks> done. thanks
[17:58:30] <jmkasunich> use IRF2010 or similar chips and all N channel fets, for example
[17:58:58] <skunkworks> I will look. I know there are pre driver chips out there.
[17:58:59] <jmkasunich> that eliminates the requirement that VMOTOR be fixed
[18:00:14] <alex_joni> hello
[18:01:11] <skunkworks> Hi again
[18:09:05] <skunkworks> biab
[19:02:39] <lilo> [Global Notice] Hi all. The network is currently not accepting new connections while we work through some cloaking issues. Thanks!
[19:18:04] <alex_joni> hi ray
[19:18:22] <rayh> Hi Alex.
[19:25:32] <lilo> [Global Notice] Hi all. In regard our connect problems, we'll periodically reopen connections for just a moment in order to make sure you aren't shut out. Thanks!
[19:30:09] <skunkworks> hi ray
[19:30:48] <rayh> hey skunkworks. how you doing today.
[19:33:24] <skunkworks> so far so good. working on the basement.
[19:38:33] <rayh> This is a day to be outdoors here.
[19:39:33] <skunkworks> same here :(
[19:39:52] <rayh> Hey skunkworks. Do you know Pete_Gruendeman?
[19:40:33] <skunkworks> no - he around this area?
[19:41:18] <rayh> Someplace along the western WI border.
[19:41:53] <rayh> He just wrote that he's planning on Fest again this year.
[19:42:10] <skunkworks> well then I should meet him
[19:42:14] <rayh> EDM is his desired study area this year.
[19:42:36] <rayh> Roland already has the Japax 4 axis wire machine in our area.
[19:42:47] <rayh> He said just in case we wanted to play.
[19:44:30] <skunkworks> nice. my mom wants me to take my dad for the whole week ;) - but I don't think that is going to happen
[20:12:08] <lilo> [Global Notice] almost there, thanks for your patience....we should be back up continuously in just a bit
[21:11:37] <skunkworks> sigh ;)
[21:12:06] <jmkasunich> bored?
[21:12:25] <skunkworks> If I ever get that way - please tell me.
[21:12:39] <skunkworks> no - thanks again for the circuit.
[21:13:43] <rayh> Sometimes it does get tedius.
[21:14:56] <jmkasunich> I have 500 things I should be doing, and none I want to do
[21:15:11] <rayh> oh I know that feeling right now.
[23:00:25] <alex_joni> ok, what do we expect?
[23:00:43] <alex_joni> if the position jumps to 0 suddenly.. will it ferror?
[23:00:57] <jmkasunich> unless we do something to prevent it, yes
[23:01:01] <alex_joni> * alex_joni has an idea..
[23:01:08] <alex_joni> lets make a small setup
[23:01:09] <jmkasunich> and worse, we'll have a huge error, so the PID will make a huge output
[23:01:23] <alex_joni> stepgen with quadrature stepping, driving an encoder
[23:01:35] <alex_joni> only sim
[23:01:43] <jmkasunich> the ferror can be masked, since its done inside the motion controller
[23:01:49] <jmkasunich> but the step on command is messier
[23:02:15] <alex_joni> how does that setup sound for debugging purposes?
[23:02:25] <jmkasunich> that works
[23:02:40] <alex_joni> then drive the index reset with halcmd sets
[23:02:57] <jmkasunich> actually, don't use stepgen
[23:03:07] <jmkasunich> we want to use real PID
[23:03:15] <alex_joni> freqgen?
[23:03:24] <jmkasunich> use PID driving the speed input of the simulated encoder
[23:03:32] <jmkasunich> that gives you an index pulse too
[23:04:13] <alex_joni> darn, don't think I'm any use to you if I continue :(
[23:04:15] <jmkasunich> heh, run the pid output thru a lowpass filter to simulate motor inertia too
[23:04:31] <alex_joni> my eyes are falling shut :(
[23:04:40] <jmkasunich> its 2am isn't it?
[23:04:51] <alex_joni> and my ubuntu box is down (had to remove the NIC to set up cvs3)
[23:04:53] <alex_joni> yeah.. 2am
[23:05:02] <jmkasunich> you have a nic shortage?
[23:05:16] <jmkasunich> bummer, I have more than I know what to do with (3com mostly)
[23:05:18] <cradek> what are you guys plotting?
[23:05:26] <alex_joni> I usually don't have 3 pc's in my room ;)
[23:05:45] <alex_joni> cradek: accel vs. time vs. age
[23:05:45] <jmkasunich> cradek: digressing mostly, but talking about index handling
[23:06:22] <jmkasunich> alex, go to sleep
[23:06:32] <alex_joni> * alex_joni is kidding
[23:06:45] <alex_joni> cradek: index handling during homing mainly
[23:06:50] <cradek> oh ok
[23:07:03] <alex_joni> we sorta came to the conclusion that it's best to reset the counters when index arrives
[23:07:06] <jmkasunich> and threading
[23:07:13] <alex_joni> even when homing, no question during threading
[23:07:32] <cradek> * cradek knows nothing about homing
[23:07:44] <jmkasunich> the problem is that if you reset the encoder counter when you hit an index during homing, you generate a large step in position feedback
[23:07:51] <jmkasunich> which can cause a machine upset
[23:08:36] <jmkasunich> alex: I just realized that it won't cause a following error (if we handle it right)
[23:08:39] <alex_joni> jmkasunich: unless you stop imediately
[23:08:50] <alex_joni> how so?
[23:09:01] <alex_joni> * alex_joni pumps more coke in his veins
[23:09:07] <jmkasunich> in the same servo period where the step happens, we will be correcting the commanded position to match the feedback anyway
[23:09:16] <alex_joni> errr. coca-cola
[23:09:22] <jmkasunich> so by the end of the motion controller code, they match again, and ferror is small
[23:09:54] <jmkasunich> unfortunately right now ferror is checked early in the code, so it would need to be changed
[23:09:58] <alex_joni> right, because you have the free set to 0
[23:10:11] <alex_joni> so commanded matches feedback ?
[23:10:34] <jmkasunich> I'm not communicating very well
[23:10:59] <alex_joni> right ;) me neither
[23:11:16] <alex_joni> get_pos_cmds() before check_for_faults() ?
[23:11:23] <jmkasunich> at the beginning of the "index search" phase, the motion controller sets index-enable high so on the next index the counter will reset
[23:11:40] <jmkasunich> when it sees index-enable go low, it knows the reset just happened
[23:11:59] <jmkasunich> thats when it needs to change its position anyway (from the random pre-homed position, to the actual homed position)
[23:12:13] <jmkasunich> once it does that change, the positions will match again
[23:12:28] <alex_joni> ok, this is in do_homing() right?
[23:12:42] <jmkasunich> yeah
[23:12:48] <alex_joni> * alex_joni is looking at the beginning of control.c
[23:13:01] <jmkasunich> do_homing is a state machine
[23:13:04] <alex_joni> but do_homing() is after check_for_faults() right now
[23:13:13] <jmkasunich> right, that would need to be addressed
[23:13:20] <alex_joni> ok, that's what I meant
[23:13:44] <alex_joni> somehow ;)
[23:14:21] <alex_joni> process_inputs(), do_forward_kins(), check_soft_limits(),
[23:14:31] <alex_joni> then a new function adapt_homing_stuff()
[23:14:38] <alex_joni> check_for_faults() etc
[23:16:14] <jmkasunich> I think I'd rather modify check_for_faults, maybe defer tripping until the ferror is too high for 2 consecutive samples
[23:16:42] <jmkasunich> or move that one check down to the end of control.c instead of at the beginning
[23:16:51] <lilo> [Global Notice] Hi all. It looks as if we've managed to find our problems. We were experiencing difficulties in labeling attacking bots, and for that reason we had to turn off incoming connections and just turn them on intermittently. We believe we've resolved the issues.
[23:17:31] <jmkasunich> damn thers a lot of homing code - 530 lines
[23:17:53] <lilo> [Global Notice] We may still have occasional cases during the morning where we block new connections for two or three minutes at a time, but we think we've solved most of the related issues. Additional detail on wallops if you're interested. Thank you for your patience, and thank you for using freenode!
[23:18:03] <alex_joni> can't move it after get_pos_cmds()
[23:18:17] <alex_joni> because in there the current_pos=feedback_pos
[23:18:28] <alex_joni> joint->pos_cmd = joint->pos_fb
[23:18:53] <jmkasunich> only if your not running
[23:19:11] <alex_joni> oh.. and then it doesn't matter.. right
[23:21:20] <jmkasunich> actually, check_for_faults doesn't do the compare between fb and command
[23:21:37] <jmkasunich> process_inputs() does that, and sets a joint ferror flag
[23:21:48] <jmkasunich> check_for_faults() tests the flag
[23:22:00] <alex_joni> argh ;)
[23:22:25] <jmkasunich> actually, that could be good
[23:22:32] <jmkasunich> leave the compare where it is
[23:22:40] <jmkasunich> move the test of the flag near the end
[23:22:56] <jmkasunich> and do_homing can clear the flag if it knows that we just reset the counter
[23:23:43] <alex_joni> ok, but it needs to clear more than one flag..
[23:23:50] <jmkasunich> anyway, I'm convinced that dealing with ferror is just a SMOP
[23:23:58] <alex_joni> right
[23:24:04] <jmkasunich> dealing with the PID upset is more complex
[23:26:14] <alex_joni> hmm.. but the thing is we will need to stop anyways..
[23:26:30] <alex_joni> so we could make the switch after motion stopped
[23:26:31] <jmkasunich> not instantly
[23:26:55] <alex_joni> have motion add the offset, and blind PID
[23:27:03] <jmkasunich> the feedback is going to change the instant that the index pulse arrives (on the very next servo cycle)
[23:27:10] <jmkasunich> it will still be moving at that point
[23:27:40] <alex_joni> then PID needs to know this might happen
[23:27:45] <jmkasunich> ys
[23:27:47] <jmkasunich> yes
[23:27:50] <alex_joni> and maybe have a pin to get that signaled
[23:27:56] <jmkasunich> the order of execution in the thread is:
[23:28:11] <jmkasunich> 1) driver captures value (which has made a step change) and clears index-enable
[23:28:29] <jmkasunich> 2) motion controller sees index-enable low, knows the reset happened, and changes the command
[23:28:41] <jmkasunich> 3) pid runs, sees new feedback _and_ new command
[23:28:51] <alex_joni> and index-enable
[23:28:51] <jmkasunich> the error actually isn't large at all
[23:29:02] <alex_joni> hrmm.. yes
[23:29:10] <jmkasunich> I'm talking about how it would work if we didn;t change anything
[23:29:22] <alex_joni> yes, I just realized after you typed in #3
[23:29:31] <jmkasunich> the problem is the FF0, FF1, FF2 terms of PID
[23:30:14] <jmkasunich> FF0 sees a step, FF1 sees a spike, FF2 sees two spikes, one positive one negative
[23:50:50] <jmkasunich> ok, back to this stuff
[23:52:19] <alex_joni> right..
[23:52:20] <jmkasunich> we could turn off axis.N.amp-enable when we detect the encoder reset
[23:52:41] <alex_joni> not everyone will use that
[23:52:47] <jmkasunich> that still cause a disturbance tho, because it will force the PID output to zero for one servo period, and reset the integrators
[23:53:10] <jmkasunich> if they have servos, they need to connect it to the pid enable even if they dont' turn off their amps
[23:54:24] <alex_joni> right..
[23:54:43] <alex_joni> so PID goes offline
[23:54:45] <jmkasunich> what it really might want is an input to the PID called "hold"
[23:55:08] <alex_joni> FFx are usually very small values.. do they have much effect?
[23:55:09] <jmkasunich> that just freezes the integrators and output, rather than reseting them
[23:55:26] <jmkasunich> FF1 is usualy 1.00 if things are scaled right
[23:56:04] <alex_joni> how does translate to output?
[23:56:08] <alex_joni> that
[23:56:10] <jmkasunich> and a step change would cause an enormous output (well, it would be clamped by max-output, but still large)
[23:57:07] <alex_joni> btw, there is only FF0 & FF1 if I'm reading pid.c right
[23:57:29] <jmkasunich> yeah
[23:57:34] <alex_joni> *(pid->command) * pid->ff0gain
[23:58:02] <alex_joni> command is 0 or close to 0, right?
[23:58:14] <jmkasunich> no
[23:58:26] <jmkasunich> error is zero or close, command is the desired position
[23:58:31] <jmkasunich> could be hundreds of mm
[23:58:44] <alex_joni> no, I mean when we reset the enc
