#emc-devel | Logs for 2007-04-28

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