lerman_ is now known as lerman
jepler, FYI I did some reading on udev. Apparently the version in dapper is old. The newer versions support KERNELS, SUBSYSTEMS, etc.. With the S on the end it means to check all parent nodes for a match too. Without means to check just the specified node. The newer versions also use ATTRS instead of SYSFS.
udev was ignoring the match keys it didn't understand so it was matching all of the event* devs
so which ever one was last got linked
I found another issue in the process
if gdm fails to start because a device specified in X config doesn't exist, ubuntu doesn't have any console screens
not sure why this happens, but it sure sux
I don't have that problem
but I think I have seen it on pci-express machines (but I don't own any)
my MB is plain old PCI
what video driver is it trying/failing to load?
not video, it fails on an input device
I've used nvidia (binary), ati (free) and matrox
like the touchscreen because the udev link wasn't built
I thought you were talking about a video card freakout
so it's a keyboard thing?
no, just X startup failure and no console windows
KB should still work as it's there
but ctl-alt-f1, etc. doesn't get a console
so you have to re-boot in recovery mode
kb usb or ps2?
ps2 on this test
yeah, pretty strange
I guess I've never messed with input devices enough to see that
yeah I'm surprised anything will screw up the ps2 keyboard
have a serial port? network?
I think the KB is still working, but I guess I can't be sure
not connected to the network at the time
noting on the serial port either
could bring in a laptop and wire network or serial - might save you a lot of irritating reboots
yeah, I'm going to get a USB wifi for when I need it
they look pretty cheap
too lazy to make a big cat 5 cable and have it all over the floor
I haven't used one of those yet - but they seem like a good answer to the kernel driver problems you get with cards
I looked at the prism project and it looks like it supports severl chips used in a lot of the adapters
lerman_ is now known as lerman
lerman_ is now known as lerman
lerman_ is now known as lerman
lerman_ is now known as lerman
lerman_ is now known as lerman
lerman_ is now known as lerman
cradek: remember the nvidia problems?
a simple "depmod" fixed it
glxgears works nice, and "/usr/lib/xscreensaver/gears -delay 0 -fps" says 580 frames per second
is that with the nvidia driver?
seems kinda low
didn't try the screensaver gears
but the glxgears should be way faster than that
we spent couple hours fighting with it thursday trying to get it to find the driver
yeah, read the log
does glxgears print fps?
there's some obscure command to make it print fps
but I always forget it
It went from a couple frames per second to "visibly smooth"
no manpage for glxgears
* jmk-solo asks google
printfps or something like that
I think it's -printfps
prints every 5 seconds
guess it depends on the card
this is a $50 card ($40 after rebate)
but it's not a benchmark :D
I don't expect to play games on it
I don't expect you to either
so.. think I'll get my mesa tomorrow
this is from the group order in december? what happened?
nothing happened :)
long delivery times :D
somebody shipped it across the ocean by rowboat?
lol, no.. brought it in the hand luggage
but they just arrived this week
had no hurry though
I need to get re-focused on that stuff
does it help if I bug you?
I had a heck of a time getting started, then I went along pretty well for a while, then got distracted
my problem is conflicting goals
I'll try :P
what kind of?
I could just build a custom FPGA that meets my needs, and a matching driver, and that wouldn't be too hard
what would that contain?
but I want to make sure others can use the stuff, so I get into all kinds of config issues
for me, I need:
3 (4 later) stepgens
1-3 encoders (maybe more later)
and a bunch of misc IO for operator panel stuff
and the rest I/O ?
* alex_joni would be happy with that config
oh, and A/D converters
outputs I guess..
analog to digital - inputs
or did you really mean ADC?
I want to build a spindle drive
and use that for tach?
thats what the three phase PWM is for
yeah, I guessed that
no, current feedback
was just writing you can use enc. for speed feedback
actually I need more encoders than I listed
1 for jogwheel
1 for lathe spindle (encoder on spindle, with index, for threading)
1 for mill spindle (for rigid tap someday)
1 encoder that is part of the spindle motor
the motor encoder will be used for motor control, the motor is belted to the spindle, with a non-1:1 ratio, so the spindle encoder will be used for threading, etc
need A/D channels for DC bus voltage and at least 2 of the 3 phase currents
if there is no ground fault, the sum of the three phases is zero, so you can get away with measuring two of them
anyway, the A/D driver (and FPGA stuff) will depend on the chip I choose
probably some serial interface one, to avoid wasting FPGA pins
stepgen comes first
I hve the fpga code
and most of the driver - need to tweak it a bit
I'm trying to design a config framework so that the fpga can tell the driver what it has, and the driver can export HAL stuff to match
plus, in some cases the FPGA may have choices itself
hmm.. it sounds like overengineering
I would be happy with that config
like 8 stepgens and 8 pwms, where each stepgen and pwm share pins, and you want to pick which ones to use
I do have a tendency to overengineer things
I guess having the fpga stuff as blocks, and mix & matching them is not that hard
says me without looking at how it works :D
alex_joni: you can't change the fpga config without the xilinx tools
jmk-solo: I did assume at least that much
they are free of cost, but not Free, they are a big download, and the place-route process is slow
so I'd like Joe User not to need them
jmk-solo, you got a minute for some motor commutation help?
the problem is how to tell Joe that "this FPGA config supports 8 stepgens and 8 pwms and 8 encoders, the pwms are on pins blah-blah, which they share with the pwm, and the encoders are on pins blah...
I'm trying to use an ab1398 drive with a non-ab motor
the ab drive supports custom motor params
the hall and rst comm order need to match ab
I can try to help - I have no knowledge of that drive, but I have general AC motor and drive info
I turned the motor and looked at rst on the scope
the oder looked the same as ab for same rotation
oh, halls... I don't know much about that
for phase rotation there is just abc, or cba
the hall is used to tell the drive the orientation for comm startup
but when you puts the halls in the picture, then there are 6 possibilities (I think)
once it sees a hall edge, then it uses the encoder to know position between hall
the hall is like a ttl square wave of rst
abc, bca, cab (same direction, differnt phasing), and cba, bac, acb (other direction)
the glentek motor has a lead b for CCW and ab wants it the other way, so I swapped them
the encoders seem to read fine
what is the question then? sounds like its under control?
glentek shows me the hall lines vs r-n, s-n, etc.
ab shows them vs r-s, s-t, etc.
oh, line-to-line vs. line-to-neutral
so the order looks the same
60 degrees offset there I think
now I need to tell the ab drive the degree offset between what is expects and what the motor is doing
or is it 30? I always have to draw a picture
it has that as a parameter?
I thought 30 if I did the vectors right
I think you might be right
30 or -30 anyway
I think r-s would lead r-n
so the ab look like the hall goes high when r-s goes low
the glentek is the opposite
so theres 180 degree, plus/minus the 30 degree
do you have an ab motor too? or some docs that tell you what the drive expects?
I tried everything on 30 degree increments but can't get anything more than a twich
I have docs on the drive
are they on the web? if so post a URL so I can look at them
I have the current limited to less than 10% of normal for testing
yes, from the web, but I can't remember where
somewhere on the rockwell site
* jmk-solo looks
I would think the motor should still move fine with no load and that much current, no?
when I look at the drive status, it hits the current limit, and at best the motor twitches
and it doesn't have much holding power, I can grab it and turn it pretty easy
how much of a twitch? a few degrees?
depends on the position of the shaft and the hall offset
sometimes about 30 degrees
the motor is 8-pole
any hands on experience that you can give me to help figure out what is going on?
ok, so 30 mechanical degrees is 120 electrical degrees
no hands on with that drive, or hall'ed brushless in general
hands on with the motor in general
maybe some way to tell when I'm getting close
or how close I have to be to get some motion
how much commutation error would cause issues like this?
what is the command to the drive? analog or some serial/digital shit? speed or position?
it's analog velocity, but I'm not even using that
what are you using?
I'm using the rs232 interface from a laptop
the ab sw has very good diags and control
but what is the command?
so I'm using that to start with
the sw tells the drive to do something over the rs232
you can view internal signals, etc.
it MUST be in either torque, velocity, or position mode, and there must be a commanded torque, velocity, or position
fault states, etc.
from the sw I tell it to run at a vel
unless you are in some kind of startup or tuning mode, in which case you know 1000 times more than I do because you have the manual
not sure what mode it runs the drive in
when the external command is used, I have it in analog vel mode
you can select all kinds of modes for the external interface
but I'm not sure what is used when controlling via the sw
let me find the manual and show you the page
we either have to find a link for the manual, or get back to the basics (which means eliminating as much of the drive's fancy features as possible)
while you look for the manual, I'll ramble about basics
how much commutation error would cause no movements or twitches?
twitches are not very helpfull
there will be a twitch on startup even if its perfect
what about holding torque?
that is affected by comm error
the innermost loop is torque, lets consider that one only for a minute
the rotor has a fixed field (permanent magnets)
to develop torque, the drive tries to make a stator field that is 90 degrees to the rotor field
the magnitude of the stator field times the sine of the angle between stator and rotor fields = the torque
if you wind up with the fields inline, you can have a ton of current, but no torque
so even with 30 degree error I should get something?
I would think so
you say you can turn it by hand - how does the drag when powered compare to the drag when unpowered?
there is more when powered, and it cogs a lot
but still nothing like it should be
well, you are limiting current to 10%, so at best it will be 10% of rating
I think it's less
these motors are about 54 in-lb
and I don't think I can generate much by grabbing the shaft with my hand
but that brings up another question
10% is only 5.4
are the current ratings typically in rms or peak?
the motor spec gives me both a continuous and peak value
but not sure if they are rms or not
cont is definitely rms
I assumed peak to be safe
so maybe I have the current limit pretty low if they are rms numbers
I suspect that "peak" really means "short term RMS", but I wouldn't bet money (or motor magnets) on it
probably about 7% then
yeah, that's what I was thinking
I'll have to confirm before I up the limit
what are the motor specs? do you have a URL for the motor data?
yes, one sec
interpreting motor nameplates is on thing I'm reasonably good at ;-)
[17:43:39] <petev> http://www.glentek.com/gmbmsel.html
well, the cont and peak currents are either both RMS or both peak
I would be astonished to see running currents rated as peak, because ammeters don't read peak, they read RMS
the only thing that makes me hesitate a bit is that they spec the currents at stall
where the current is DC and you _can_ measure peak (if you look at the right phase and at the right angle)
but I'm 99% sure they are rms
the drive amp ratings and measurements will also be RMS
ok, so I have the current limit quite low right now then
what do you have it set at (in amps)?
I have it at 0.5 A peak
I tired up to 1.5 A
with not much different other than faster twitches
the problem here is that the drives are too damned smart
motors are dumb, and thus predictable
hah, they are old legacy drives ;-)
I found the manual
[17:52:17] <petev> http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1398-um002_-en-p.pdf
burried in the legacy archive
yeah, heaven forbid you use something old instead of buying the latest...
see the Creating Custom Motor Files chapter
my approach to this would be simplify simplify simplify
looking at what ab drive wants, and what I think glentek does, I think 180 deg hall offset would be correct
ok, what do you suggest?
but you've tried that and it doesn't work?
"that" = 180 degrees offset?
yeah, didn't seem to
I wonder if the a/b is not what the drive is expecting?
the hall signals from your motor are all 180 degree square waves, not 120 or anything, right?
no, they are square waves, but they match the rst signals
so it's not 180 degrees
180 degrees of the hall wave form
* jmk-solo reads
you are using "ultra master" sw to mess with it?
I wish the drive would show the hall signals, but it doesn't
does it show the encoder feedback?
dang near impossible to probe with the mil connectors
yes, I can see the counts
do they pass sanity tests?
count in the right direction, and proper counts per turn?
yes, that looked good from the way I read it
CW was pos
proper in this case means not just "what the motor nameplate says", but "what the drive (per your config) expects"
and 10000 per rev
2500 line encoders
I told the drive 2500 per rev
lines that is
did you also tell the drive 8 poles?
yes, double checking now
yes, it's correct
I assume they did mean lines and not counts?
heh, assume nothing
it says lines in the sw
one good thing about hour low current limit - you can experiment
I don't know a what point they stop using halls and start using the encoder for current control
the way I get no motion makes me wonder if the A/B is wrong
it say on first edge of hall
once they do, if the phase rotation (encoder and stator) is correct, it should be smooth, no cogging
so the motor needs to move to switch
if the angle is wrong the torque will suck, but it should suck smoothly
hmm, since I don't usually see motion on startup
I bet it's still on the halls
at best I get it to twitch once
maybe it's not even switching to encoders
when I say "smooth, no cogging" I mean when you turn it by hand, with no speed command
having a speed loop inthe picture just makes things more complicated
if the sw obeys the settings for the external command, I can put it in torque mode and try it
do you have anything connected to J2-16 ("ABS" input)?
no, that's an ab motor sig
my startup is set to hall/hall
this manual is too long
(actually a good thing, but hard to come up to speed)
ok, I don't want to waste your time, if you think of anything let me know
I'll go try and see if I can get the sw in torque mode
is the drive and motor anywhere near a computer with IRC?
I'd like to help if I can
no, it's in the machine and I don't have a wifi adapter yet
but I can drap my notebook out there
let me do that, then I can keep you in the loop
I'll keep reading
ok, going to switch to the NB
is there anything connected to the motor shaft? (leadscrew, etc)
what mode do you have it in right now?
I'm thinking either analog control or preset control would be good to test
its in analog vel
let me get teh nb connected and change it
looks like it won't let you load params unless there is a motor selected, right?
hence the custom motor config
in the drive config, the motor is one selection
it takes all motor params from that selection
if you use "advanced" mode, you can make new motor param files
all the other drive params can be changed separate from motor settings
booting machine now
booting what machine?
the EMC pc?
need to control the pyhsical drive enable
hal commands ;-)
(I'd be tempted to use hardware jumpers and such for that, but if you know the mill PC stuff works and isn;t contributing to the problem, thats fine
I tested all of the other IO and all that
it works fine, the ultra sw needs the physical enable changed at times
it has to be off to load motor params
and on to control the drive
that part is working fine
have you ever gotten an error code?
"blinking orange/green" on the LEDs
only on the drives without encoder cable connected
it gives bad hall state as expected
code 11 "illegal hall state" and code 25 "commutation angle error" would be the interesting ones
it stays green on the test drive
and I see no faults from the sw
p. 195 in the manual "testing encoder inputs"
I don't see a way to get tha actuall error code #, just has a dialog with indicators
I think what they do for an encoder test is use the motor encoder as a source, and send it to both the motor encoder input and the aux encoder input
thats mostly to test the aux encoder, not usefull here...
forget I said anything about p 195
the aux encoder can be used for master/slave
ok, I'm going to start with 150 degree hall offset
then I'll try 90 degree
go for it
let me try analog torque
analog torque with zero command should result in zero torque, you can turn the shaft with no resistance
since it should have zero current at all times, it will probably NOT tell you much
a zero current flux vector can be at a totally wrong angle and still makes zero torque
hmm, looks like the sw is still taking a vel command
so I don't think it pays attention to external setting
what kind of "metering" does it have? does it display speed, current, etc? either on the drive or thru the SW?
yes, quite a few params
even a scope view
what do you find interesting?
there is command, peak +/-, avg, and limit +/-
actual, or whatever gets closest to that
command or avg, I'll display both
ahh, I got the sw in torque mode
you want to stick with vel, or can we learn anything fromthis?
I can set the current in this mode
I assume for the torque loop
* jmk-solo vaccilates
torque mode has the advantage of keeping things simple
but assuming it works, a non-zero torque command will result in accel to top speed
yeah, that could be ugly
maybe I can limit vel somewhere
I bet there is a max frequency or max speed somewhere
unlike DC motors, its easly for AC ones to limit the top speed
hmm, have current limits, accel limits, etc.
have vel error limit
but looks like only vel limit is from motor param file
that makes sense, but is a pain for testing
that makes sense
ok, will stick to vel mode
ok, nothing but a few counts of movement and current goes to 0.5 A limit
current is sitting at limit?
but motor doesn't move
you don't by any chance have a clamp-on ammeter do you?
I do, but I don't know how I would get it on a motor lead
how would that help?
if it reads DC, you can see what happens to the current as you turn the shaft
if not, it won't help
if its a pain to use, skip it
why can't I just see what the drive says for that?
does it report individual phase currents, or just a single number?
it can also display the R, T, Torque, and Field currents
don't see S
not sure why
they only measure 2, unless there is a ground fault, all three sum to zero
right now, Torque should be 0.5A and Field should be zero
so T goes to limit and S is close to 0
let me add field
what is that, BTW?
its used for non-permenanet magnet motors (induction motors)
oh, got it
remember I said that the stator field is at right angles to the rotor field?
with no vel cmd, they are bouncing around 0
torq and field are both near zero?
but T is at the limit of 0.5?
thats not right
with vel command, T and torque go to limit
field and R at 0
I didn't realize you were changing things
with no command, all are around 0
leave the command there
field doesn't seem to change
no command - no current - nothing usefull
is there a keyway on the shaft?
(or other sharp edges and bitey things?
just the key way and key, why?
might want to tape it up, unless you are confident the motor isn't strong enough to hurt you
you're gonna be turning it while energized, and if it takes off....
it's pressed in and I have vel at 1 rpm
can't go too fast
1 rpm is probably too slow, make it 60 or something
vel command is 1 rpm? or vel limit?
set to 50 and the same results
oh, command doesn't matter, anything non-zero will saturate the loop and result in 100% torque command
vel limit is the one that will save your fingers if it runs away
so I figure 1 rpm is going to hurt me if it does move
and I would rather loose some skin than get a glove wrapped up in the thing
so do you think A limit is too low?
ok, its sitting there with T = 0.5A, R near zero...
field never seems to change much
bounces around 0
torqoue is at 0.5 also
if you turn the shaft slowly, does T and R current change?
field+torque represent a vector in a rotating reference frame, torque is 90 degrees to field
and if I leave the shaft in a bad spot, the motor growls a bit
R+S+T represnet the same vector in a stationary reference frame, in a 120 degree coordinate system
hmm, how wide is the growl spot?
I understand R S T, not sure about torque and field
a few degrees only?
yeah, it's not much
probalby right around a hall edge
hmm, if it sees a hall edge, it should switch to encoders
if something is backwards, then when you cross the edge, instead of the field moving the same direction you are turning, it moves the other way, and you get an oscillation
then it has a more analog position reference
so maybe it is on encoders and A/B are wrong?
you are using Hall/Hall, right?
yeah, but that's the startup mode
it always goes to encoders after startup
I don't think there is any way to change that
power down and swap encoder A and B...
ok, that will tak a while, I have to change the high density connector
oh, its not a terminal block or anything
that's why I only made on cable to start with
are the halls in the same connector?
no, mil conn to high dens D shell
output from drive is on terminal block, but that doesn't help
well I was just tinking bout that
if you swap the motor leads, you reverse the rotation relative to the encoder (what we want) but also relative to the halls (don't want)
given that you can do that in 2 mins tho, I'd try it
I spund the motor CW and looked at R S T and they sequenced like the ab pic
lets take some notes about the current config first
can you mark the shaft so you can see position?
I can see the key way and the encoder count
if you start it and T = 0.5, R = 0, then then note the keyway position
let me disable/enable
turn it until it growls, note position, turn it till R = 0.5, note position, turn till T = -0.5, note position, etc
want to correlate the positive and negative peaks of T and R current with rotor position
ok, so I just disable/enable and no movement
I wonder if the drive is smart enough to only do comm startup on pwr on?
let me reset it
this is frustrating to do by IRC
I'd love to be able to put my own fingers on the shaft and see what I feel as it turns
ok, after a rst and en, there is no current
you still have velocity command?
so I guess it waits for a command for comm startup
no, not yet
give it command
ok, motor growled and turned a bit
turned 607 counts
so maybe A/B is wrong and it stopped when it switched?
ok, with it energized, gently try to turn it - gently means get a feel for whether it is simply resisting you and stays where you put it, or if it actually wants to go back and sit at a particular spot
it resists, then when I let go it goes back to close to where it was
I suspect it has null positions every 60 electrical degrees, with growlers half way between?
if you turn it to a growl point (and just beyond) does it find a new null spot?
it cogs about every 600 counts
how many counts per rev? 10000?
seems to growl in between the cog points
2500 lines so that should be 10000
let me sanity check that
so 600 counts = 1/16.6 of a rev
try turning it thru a complete physical rev and count nulls/cogs
yes, looks like 10000
I expect 12 or 24
8 cogs as expected
8 in a full rev?
thats only 2 in an electrical cycle
yes, let me check again
I'm very surprised its not a multiple of 3
hmm, sure seems like 8
it is an 8-pole motor
I was thinking the cogs were current switching from phase to phase when the halls switches
no, I think it's pole related
8 pole = 4 electrical cycles per one mechanical cycle
I think its worth the time to switch the encoder leads at this point
I'm looking at the encoder count, and it's definitely one rev and 8 cogs
ok, I'll get to soldering
in fact, if I'm visualizing things correctly, a backwards encoder would give 2 cogs per electrical cycle
I think these manuals suck and have the wrong info
you start out with rotor and stator fields aligned (thats stable)
then you begin turning... if it was right, the stator field would turn to follow the rotor, no net torque
I can't visualize the fields, you know that way better than me
but if its backwards, the rotor stator field goes the other way (resisting your motion)
when you've turned it 90, the field has moved -90, they are 180 degrees apart, restoring force goes to zero
I think it definitely has switched off of the hall signals and is using the encoders, so that makes sense
when you turn it 180, the field has turned -180, and both are aligned again - thats the next cog
easiest way to think of the fields is to first forget about the 8 pole, think 2 pole, its simpler
the rotor is a bar magnet on a shaft, 1 N, 1 S = 2pole
the stator is another bar magnet
held near the first one
if stator N and rotor S are aligned, they attract each other, but they are as close as they can get, no torque
as you turn one relative to the other, there is a restoring force
max torqe at 90
which hits a maximum as when the two bar magnets are at 90 degrees to each other
and zero again (but unstable equilibrum) at 180
right, that's the growl
but that seems like one stable position for 2 poles
so shouldn't 8 poles make 4 positions?
how do we get to 8?
if you lock the stator magnet and turn the rotor, there is 1 stable position for 2 poles
but the stator field is controlled by the drive
normally it wants to track the rotor
ahh, and it's spinning the other way because of the encoders?
but if the rotor fb is backwards, the stator magnet goes backwards
ok, that makes sense
let me re-do the cable
this may take a while
by the time you've turned the shaft 180, the stator went 180 the other way, and you are stable again
once the direction is right, you'll still need to figure out the offset
yeah, I think I got that, unless the glentek info is totally wrong
they sent me a spread sheet and it said plain as day, A leads B for CCW when viewing shaft
ab says A leads B for CW when viewing shaft
so somebody got it wrong
there are all those various 30 and 60 degree ambiguities tho, line-line vs line-neut, and such
and I think i'ts glentek
you can look at the shaft from two directions :D
I'd do that part by testing too
they shaft only comes out on one side
* jmk-solo noodles out how to verify the offset
petev: sorry, was just joking
the cables from glentek were already foobar
I didn't care because I was going to re-do the drive side
but they were not even all the same
so I hope the info the guy gave me on the hall timing isn't wrong too
to top it off, they didn't even use the same color pairs on the motor end for all of the cables
I had to freakin ohm each one out separately
pete: have you started soldering yet?
I think there is an "invert direction" checkbox, which if I read it right inverts the encoder feedback
I'm working on it
hmm, is that all it does?
its not 100% clear
that would be nice
if you hadn't started it would be worth a try
let me put the cable back together and try it
the way I had understood that box was that is just made the motor go the other way, but didn't change the sequence of signals relative to each other
so if you're motor had ab sequencing, but turned the opposite dir, you could check the box
it could be that the difference isn't the encoder, its the windings...
I think the windings are the same, as I spun the motor with a rope on the scope
the stupid glentek info gave each winding / hall separate without reference to each other
a lot of good that was
but, the encoder cables were screwed up, so maybe the motor cables are too
I better check that
don't change anything now
just flip that bit and see if it makes a difference
ok, hang on
there are three "things", each with a direction of rotation - encoder, halls, and windings
that gives us 6 permutations, of which 2 will work
yeah, if the motor cables are screwed up, the hall may not matcht the winding either
one will rotate CW for a positive command and one will rotate CCW, EMC's scaling can deal with that
if the halls are wrong, but the encoder and winding are in sync, you might have startup issues depending on the intial position, but if you turn it part of a rev so it sees a hall edge it should change to encoder and stop cogging
hmm, I see 2 settings
once we know that encoder and winding are in sync we can tackle the halls
a list box on the drive setup
and a radio on the drive param-follower setup
I think the follower is for master/slave
sounds like it
the one I saw is in the custom motor config part
pate D-11 in the manual
oh, then I guess there is a 3rd ;-)
oh, that one looks promissing
I thought you meant the one in the drive setup
something is different
different might be good
cogs are closer together and motor turns by itself between them
I think the hall offset is wrong now
ok, hang on
maybe not just the offset
encoder, halls, and windings all have rotation
halls/winding has offset as well
but halls are out of the pic after startup move
but hall offset and hall direction both affect the initial postion
if the halls are rotating backwards, there will be two initial states (out of six) in which it will work right once the offset is correct
but the other 4 states will be messed up
if the halls are rotating right, then the right offset will make it work regardless of the initial state/position
ok, let me get some data here
lerman_ is now known as lerman
ok, this is strange
I get 8 cogs, and break free torque is very low
after the cog, the motor moves a bit then stops
always the same direction?
so I turn it, it cogs, then continues to move a bit in same dir, then stops
this repeats 8 x for one mechanical rev
when you say "it cogs" what exactly do you mean
I turn it with some torque and it breaks free and moves easy, then stiffens and moves by itself
the break free torque is pretty low
so initially the torque opposed you, then it aids you
lower than before when there were just 8 cogs and no movement
that's how is seems, it snaps when it breaks loose
then the motor growls and moves about the same amount by itself
its possible that fliping that bit didn't do much of anything
but this time you powered up in a different initial position, differnet hall state, and different offset error
the fact that its still 8 per rev makes me think nothing changes
if I hold it between the spot where it breaks loose and starts to move by itself, it is unstable
it will want to move either direction from there
power down and try swapping any two motor leads (winding leads)
ok, let me try another power up and see what we get
that is a lot quicker than changing the encoder wires, and unlike flipping that bit, we know exactly what it will do
let me get a few more startup data points
then I'll do that and check the freakin power cable too
this has been educational for me - my future spindle motor is similar to what you have, and I haven't thought through the geometry/control stuff yet
except I don't think this motor has actual halls
it might have hall-like signals on the encoder cable
there are 6 signal pairs coming from the encoder, 3 of them are almost certainly A/B/index
it must have something for startup comm
haven't looked at the other 3
the other 3 are probably the halls
all 6 comes from the actual encoder though, not from sensors in the motor part
same here, I think the halls are built into the encoders
and get aligned to the shaft
so "hall" is used loosely
where the encoder isn't necessarily alinged
yes, it's a digital hall
true hall encoders sense the rotor magentic field, not clear vs black on an encoder disk
and therefore have to be embedded in the motor itself
I think they are just a simple low res encoder that is aligned to the motor shaft
and there are 3 of them, not quadrature
just more tracks on the same encoder really
all startups have had same behavior
swithing CCW back to check that
gotta lithp ?
no, fat fingers on this small KB
definitely seems different
no movement by itself in the original config
consistent movement when feedback inverted
ok, so its doing something
this is all with a 1 RPM command, right?
I have been turning the motor the same way the whole time
yes, 1 rpm
turning it the other way in the original config, has the same behavior
meaning snap, growl move, stop
try turning it the other way, and try changing the command (both sign and magnitude)
that sure sounds like its backwards
and the break free torque one way is less than the other
set the bit again, and try turning both ways, and with different commands
I changes the vel to -1 and everything is reversed
so sounds like that's all the bit does
that's pretty stupid
they have one in the motor param and another in the drive param
the motor param one should change the encoder only
would be more useful
my mental image depends on the torque command remaining constant (at the limit), and if you get actual movement then the velocity loop might unsaturate and reduce torque command
so you still feel the field is rotating the wrong way?
I didn't follow exactly what happened in the last few mins
you said with the bit off, you get 8 detents and no movmenet
ok, I switched the direction in motor params
then you change the command to -1 and "everything" reversed....
then the behavior seemed different, with cog/move
did you change the command, or the invert bit, or both?
but I was always turning the same dir with same 1 rpm command
changing the command has the same effect as changing the bit
as does turning the shaft the other way
so bot behavior is there at the same time
ok, forget the bit, set it back to the initial state
depends which way you turn relative to cmd and invert bit
and do something that we can trust
swap any two motor (winding) leads
I think it's just a stupid reverse in another location
ok, hang on
I need to power down for that
yeah, that would be a lot safer ;-)
I thought I would have this working last night, ha ha
100Mbs ethernet sure beats downloading from the web...
(transferring the Xilinx tools from one box to another - its about a gig)
well you wond beleive this
the motor doc says A=T, B=S, C=R
the cable has A=U, B=V, C=W
doens't that seem backwards?
abc uvw seems find
tsr is fscked
ABC are the mill conn pins
well the TSR is the motor doc
I've worked with so many motors of unknown phasing that I don't even bother to try to figure it out
and that's what I used on the scope
hook it up, if it goes the wrong way reverse a pair
what I don't understand is why cables from the same mfg are different
that's easy without hall and encoders issues
granted, reverseing a pair can be a pain when they are 2x500MCM per phase.....
so to get things to match what I did on the scope, I have to switch a few leads around
I assumed that R=U, S=V, and T=W
but I guess not
thats what a sane person would assume
didn't even think of testing such a simple cable
but after the encoder cables, I guess I'm not surprised
let me swap them all around and see what happens
I think I may see what's going on
looks like I was anal when I made the pinout spread sheet, and already took into account the UVW->RST mapping
however, I forgot about that when I was phasing the motor
so I think bot the hal and motor power had two leads swapped, but they match each other
that would reverse the direction and explaing the A/B encoder problem
I think with just the motor leads reversed now, the hals don't match
is it working better now?
didn't try it, was checking all the pinouts
what do you think will happen if the hal sequence is wrong now?
jeeze pete, its been 30 mins since I said "swap them"
I guess not much with the low current?
yeah, but I had to check all the pinouts after that
don't trust anything at this point
so now I think the motor and hal don't match
and A/B are reversed
no, you just had to unscrew two screws on the front of the drive, swap the wires, tighten the screws, and run it
we know stuff doesn't match, already
you trust too much
what can happen?
I'll try it and see what happens, but I think it's all wrong
don't know, you are the expert there
I guess not much with the limited current
trial and error
in this case, I think we already have the error, and the swap will make it better
but I think the swap makes the hals wrong
so not sure about that
I think the only error was A/B before
you might be right, I'm ignoring the halls at this point
the reason for the motor lead swap was to quickly see if that got windings and encoder going the same direction
keyword quickly, hence not reworking the cable (and not spending 30 mins checking stuff) ;-)
the motor is spinning now
but way too fast
I have it at 1 rpm
and it's going about 70
the offset figures into that
but if its not cogging badly, then we now know that the windings and the encoder are in phase
it seems smooth
s/in phase/rotating the same direction/
so I think a/b may have been the issue
speed is not stable either
we don't know whether the halls match the windings, or what offset there is between the encoder and the actual magnetic field
its going faster now
according to glentek tha hals are in phase with the windings
if the angle is wrong, then that introduces a huge offset and non-linearity INSIDE the torque loop
and I have pin info if it can be trusted, that says which goes with which
net result is that the speed loop will be confused as a sterile rabbit
so the speed behavior doesn't surprise me at all
so should I go back to the docs and all the bad cables, set things up the way I think they should be and try again?
woot! old system FPGA build time: 2:16, new system 0:20 ;-)
I think the windings and hals were matched before
but encoder was wrong
thats a huge difference
now that we know that winding and encoder were mismatched, fix one or the other, whichever you think is wrong
I just wanted you to try the winding switch because that is faster
ok, I'm going to double check all the cables to pin numbers and go from there
the speed loop is tweaked now
it will run at 0 cmd
not surprised at all
remember the bar magents?
the torque command is positive, negative, or zero
I guess the part I don't get is the drive seems to be so smart
if the offset is right, positive gives you a stator "bar magnet" at +90 wrt rotor, negative gives you -90
why can't it see that it's moving and adjust the hall offset itself?
and sero gives you zero field strength
it doesn't know why its moving
well it should at least fault then, no?
position loop should fault
anyhow, let me fix this stuff and try again
I think there is a "max velocity error" limit, I bet if set and enabled it would trip
why not vel?
if cmd is 0 and it's moving, something seems wrong?
its just like following error in EMC
alex_joni, what setting?
but you have to set the limits
petev: I'd guess drive setting
I bet in that drive, you have to set the velocity error limit
I think I had the limit a 2 rpm
_but_ it can also be a mechanical influence on the motor
and maybe enable it, that fault might be disabled by default
and it's going like 60 rpm at 0 cmd
so the drive can't be smart and assume bad field
maybe some faults are ignored when in ultramaster too
I don't pretend to understand software based drive features, I understand motors and current and magnets
I'll have to check that
say your Z axis is very heavy, and your pneumatic counterweight just died
it could make the motor spin even with 0 cmd
I wouldn't want the drive to readjust offsets in that case
sure, but wouln't the drive try to hold 0 vel and fault if it couldn't?
I bet that is an option
petev:that depends on the drive and how it's set up
I see the point on adjusting the offset, but I was thinking only during the startup phase when it switches to the encoder
there are drives with position requests and ferrors inside
but to always do that is at least as bad as to never do it
then there are some with vel requests
its all about drive configuration, and unfortunately I don't know enough about that
the manual (strangely) doesn't have a parameter list for that drive
yeah, you have to muddle through ultramaster
I work with drives that have over 1000 parameters... they can do just about anything except wash dishes, but you gotta configure them to do that
and different drive fw revs have different features
getting back to why its not running at the right speed (as opposed to why its not faulting)
if the angle is sufficiently far off, a positive torque command from the speed loop will result in negative torque at the motor, negative rotation, and a saturated loop
once you have the wires as right as you can get them, I'd try changing that offset parameter
go 90 degrees at a time to start
you'll probably find a couple settings that are stable and a couple that aren't
I can play with that now, but I'm wondering how I confirm the halls match the windings?
short of powering the encoder and getting the scope on it
I'm not sure how to determine
only other option seems to trust the docs
I bet the drive only reads the halls once for each power cycle, then it uses the encoder
yes, that seems to be the case, once after a reset
so power down, set the motor position by hand, power up, run it, repeat with a new motor position 30 degrees away (electrical), and repeat for a full cycle
when I reset it, it seems to go back to halls even without a power cycle
if it always acts the same, you probably have the hall rotation correct
then you work on the hall offset
actually, I'd get a sane offset first
sane = positive torque command results in actual positive torque and positive rotation
according to glentek the halls are in phase witht he windings
so then you probably have hall rotation correct
but I have 2 of the windings swapped now
and ab uses a 90 deg offset from the line to line voltage
then unswap the windings, and swap the encoder
glentek uses 0 deg fromt the line to neutral
that will get everything going the same direction
yeah, that's what I'm thinking
then you adjust the offset to fix the 90 degree glentek/ab thing
going to have to swap the encoder
I thought we already decided that?
going to check pinouts once over and make the change
getting close to dinner time here, back in a while
ok, thanks for the help
lerman_ is now known as lerman
Hi I have a problem building a realtime-kernel
kernel:2.6.17 and rtai3.5
I can compile the kernel, but mkinitrd does not run
I'm afraid the kernel building experts are not here right now
most of us use a pre-built RT kernel because its such a pain
mschuhmacher: are you using make-kpkg?
oh, one of the kernel building experts IS here... hi Chris ;-)
you're being very generous to call me an expert though
I already heard of make-kpkg
but it is not described in the EMC-wiki
I heard there are different ways to acomplish the initrd
so you're not using make-kpkg?
please describe your problem - I may have missed the explanation
jmk-solo, I'm in motor phasing hell over here
I can get the motors to turn the correct direction
and the encoders count up for CW, so I think all that is good
however, i can't seem to find an offset that makes the motors behave reall nice
some hall offsets make it run backwards
the ones that make it run forward, have a resonance at 0 vel
at around 180 offeset, the motor will run either way if I turn it that way, but always starts reverse for a forward command
offsets around 330 seem the best
I have checked all wiring against the docs and halls should match winding, and winding sequence should match ab
I scoped the winding sequence, so I'm pretty sure on that one
and since the encoders match the windings now, and count correctly, I think they are good
so that leaves hall crap
can anything be deduced from the peak +/- currents in the fwd/rev directions?
you think I might need some PI tuning in the drive to get it right? how can I determine what the best hall offset is? I don't trust the glentek docs as it is almost 180 deg from what I expected looking at their stuff
I followed the steps described in the wiki:
here is mkinitrd used
my problem is the following:
I want to boot with grub and the grub wants to have an initrd.img-2.6.17,
so i tryed the method described in a),
after usr/src/linux$ make modules_install
I issued the command:
mkinitrd /boot/initrd.img-2.6.17 2.6.17
nothing happens (except a usage message)
this could mean that either the make modules_install did not work or the mkinitrd is another version or...
on my system it's mkinitramfs, not mkinitrd
maybe that's the only problem
its still the same errot
and the error is?
jmk-solo, looks like the drive needed some tuning. I ran the auto tune and P came back much less. It doens't growl now. Not sure how to determine if the hall offset is optimal, but it seems to work ok now.
martin@Auctor400:/usr/src/linux$ sudo mkinitramfs /boot/initrd-2.6.17.img 2.6.17
Usage: /usr/sbin/mkinitramfs [OPTION]... <-o outfile> [version]
-d confdir Specify an alternative configuration directory.
-k Keep temporary directory used to make the image.
-o outfile Write to outfile.
-r root Override ROOT setting in mkinitrd.conf.
See /usr/sbin/mkinitramfs(8) for further details.
so fix the usage: add the -o it wants
martin@Auctor400:/usr/src/linux$ sudo mkinitrd -o /boot/initrd-2.6.17.img 2.6.17
find: /lib/modules/2.6.17/kernel/drivers/acpi: No such file or directory
petev: I'm not sure about the exact best way to determine offset either
I can think of a few kluges, but nothing I'd inflict on someone if I haven't tried it out first
the error is cradek: it didnt work
mschuhmacher: I don't know how to fix that one - the acpi directory doesn't exist on my kernel either
is there any kind of torque test I can do with 0 vel?
petev: what I was thinking was to put it in torque mode, change the offset by 90 degrees which in theory makes the bar magnets parallel and results in zero torque for any amount of current
then give it a bit of torque command
if it turns, the magnets aren't parallel after all, so tweak the offset
get it to the point where you can give it a strong torque command, and nothing happens
then you just have to change it by 90 degrees to go from the zero torque alignment to the max torque alignment
(you could also just target the max torque alignment from the beginning - attach a rod and a force measruing device to the shaft (fish scale, etc), apply a constant torque command and adjust offset for max torque
but the peak is rather flat (its a sine waveform), so it will be hard to really find the max
I like the first idea
I can lower the vel limit
the zero point has a much steeper slope and is bascially a null test
and give it a small torque command
ok, let me try it
the auto tune thing is pretty cool
it gives it a step input and analyzes it
cradek:can I boot without initrd image as described in b) I how would I have to modify /boot/grub/menu.lst not to use an initrd-image?
you'll probably need it if you have a lot of things built as modules (ext3, ide?)
cradek: I used mostly the same kernel-options as you used in your kernel 2.6.17-rtai3.5
I changed max number of processors to 8
cradek:Kernel panic - not syncing: VFS:Unable to mount root fs on unknown-block(0,0)
you've got important things built as modules
can't get by without an initrd
lerman_ is now known as lerman