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