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

[01:47:27] <petev> jmk-solo, u there?
[01:51:41] <jmk-solo> who me?
[01:52:55] <petev> just started to do some emc tuning
[01:53:10] <petev> and I'm wondering why emc disables the drives when it hits a limit?
[01:53:25] <petev> seems like it could stop a lot faster with active braking
[01:53:49] <jmk-solo> unless you hit the limit because of a drive malfunction
[01:53:57] <jmk-solo> (or an encoder malfunction, or.....)
[01:54:05] <petev> true, but that's a rare case
[01:54:13] <jmk-solo> this gets into estop philosophy, which I refuse to discuss
[01:54:23] <petev> fair enough
[01:54:24] <jmk-solo> every machine builder has to do what they think is right
[01:54:39] <jmk-solo> there is a HAL pin from motion that is called enable and goes false on limit
[01:54:50] <jmk-solo> you get to decide what it does, you don't have to make it turn off the amps
[01:55:08] <petev> my amp enables are connected to axis
[01:55:16] <petev> axis is turning off the amp-enable-out
[01:55:17] <jmk-solo> axis.N.enable, right?
[01:55:26] <jmk-solo> or axis the GUI?
[01:55:29] <petev> amp-enable-out
[01:55:39] <petev> axis in emc, not gui
[01:55:55] <jmk-solo> is amp-enable-out a pin coming from the motion controller, or a signal or pin that you made in HAL?
[01:56:10] <petev> it comes from each axis
[01:56:18] <jmk-solo> I'm confused
[01:56:28] <petev> so axi.0.---, axis.1.---, etc
[01:56:35] <jmk-solo> I thought motmod exported hal pins called axis.N.enable
[01:56:39] <petev> no
[01:56:43] <jmk-solo> are they called axis.N.amp-enable-out?
[01:56:46] <petev> at least that's not what I see
[01:56:47] <petev> yes
[01:56:55] <jmk-solo> ok, you are looking at it, I'm not
[01:57:10] <jmk-solo> you can choose not to use those signals to enable your amps
[01:57:30] <petev> so what is the pin from motion that you mention?
[01:57:42] <jmk-solo> axis.N.amp-enable-out is probably it
[01:58:21] <petev> hmm, so how do I know if emc disabled the amps because of a limit or some other reason?
[01:58:25] <jmk-solo> motmod (the motion controller) exports motion.foo pins (common to all axes) and axis.N.foo pins (specific to an axis)
[01:58:33] <petev> the case for a limit is the only one I want to ignore
[01:58:45] <jmk-solo> hmm, that is not easy
[01:59:06] <petev> ok, not a big deal right now
[01:59:16] <jmk-solo> this is yet another case where runlevels would be good
[01:59:33] <petev> yes, that would be nice
[01:59:44] <petev> user definable levels, even better
[01:59:51] <jmk-solo> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?RunLevels
[02:00:23] <petev> i'm using low currents and accels, but I'm still seeing following errors
[02:00:38] <petev> I have the emc accel set real low too
[02:00:46] <jmk-solo> halscope it
[02:00:54] <petev> I'm going to turn the drive current up a bit and check the dac input offsets
[02:01:04] <petev> I might need to null them in the drives
[02:01:17] <jmk-solo> I've said a million and one times that I think people should do axis testing and tuning with EMC itself out of the picture
[02:01:36] <petev> well I did it from the drives already
[02:01:41] <petev> and that is working great
[02:01:56] <petev> I suppose I could do just a hal test
[02:02:13] <jmk-solo> thats what I do
[02:02:16] <petev> the motors are super smooth now that I tuned the drives
[02:02:20] <jmk-solo> siggen->limit3->PID
[02:02:33] <jmk-solo> gives a velocity and accel limited command
[02:02:35] <petev> yeah, I have a file like that with sine gens
[02:02:45] <petev> I need to modify it for this machine
[02:03:19] <petev> I figured stuff was working so good I would go righ to emc ;-)
[02:03:20] <jmk-solo> once you've beat it up that way while watching with a scope, you know what accels and vels you can achieve, and what kind of following error you get during those moves
[02:03:27] <jmk-solo> and can set the limits in emc accordingly
[02:03:39] <petev> oh, I don't have the belts on yet
[02:03:46] <petev> I'm not that crazy
[02:03:59] <petev> just want to get good motion from the motors first
[02:04:33] <petev> without the belts I figured the following error should be small as the drive only indicates a couple of counts
[02:04:57] <jmk-solo> are you running position control in the drives?
[02:05:20] <petev> no, vel
[02:05:38] <jmk-solo> then how can the drive compute "counts" of error?
[02:05:42] <jmk-solo> that is a position
[02:05:42] <petev> so I still need the position pid in emc
[02:06:04] <petev> when vel is 0, it only moves a few counts +/-
[02:06:07] <jmk-solo> yeah, thats what I thought, but you confused me when you said the drive only indicates a couple counts of error
[02:06:21] <jmk-solo> oh
[02:06:24] <jmk-solo> thats meaningless
[02:06:25] <petev> I tuned the vel pid in the drive
[02:06:46] <petev> not totally meaningless, as emc bounces around a whole lot more
[02:06:57] <petev> so something is not ideal in the tuning yet
[02:06:58] <jmk-solo> a parked car doesn't move much either, that doesn't mean you can do precision position control with a car ;-)
[02:07:12] <petev> sure, but I'm comparing parked to parked
[02:07:29] <petev> with the position PID in emc on, it's not as stable
[02:07:37] <jmk-solo> with zero vel command to the dac (no EMC, no HAL PID), the drive should sit still
[02:07:39] <petev> but this may be a dac offset issue
[02:07:46] <petev> which is what I was going to check now
[02:07:53] <jmk-solo> ok
[02:08:05] <jmk-solo> * jmk-solo goes back to reading about checksums and crcs
[02:20:44] <petev> ok, I found the problem
[02:20:55] <petev> I had the drive accel limit at 100 rpm/sec
[02:21:03] <petev> and emc limit at 1 ips
[02:22:32] <jmkasunich> ah
[02:22:52] <petev> I have a 5tpi screw and 2:1 so thats 600rpm/sec
[02:23:16] <petev> I will set the drives to 700 and see what happens
[02:24:18] <petev> ha, I can decel the mpg much faster than this, but this is ok for testing at the moment
[02:24:41] <petev> it's like a rubberband connection
[02:24:51] <jmkasunich> accel rates on many machines wind up being 20in per sec^2 or more
[02:25:10] <petev> yeah, I have them real low for testing
[02:25:19] <jmkasunich> 1 G is 384 ips^2
[02:25:21] <petev> give me time to hit e-stop if needed ;-)
[02:25:36] <petev> so far so good
[02:25:41] <petev> looks promissing
[02:25:56] <petev> no crashes since fixing the udev rules for the old udev
[02:26:11] <petev> I think having a new device linked out from under X was crashing it
[02:29:35] <petev> did you see my comment earliser today regarding the hall offset discrepency?
[02:30:04] <jmkasunich> yeah
[02:30:19] <jmkasunich> what matters is that it works
[02:30:22] <petev> make me feel better now that I know the cause
[02:30:33] <petev> yeah, but now I'm even more sure all is ok ;-)
[02:30:45] <jmkasunich> I'm not used to having manuals, so I don't worry about figuring out which manual is wrong
[02:30:50] <jmkasunich> ;-)
[02:33:29] <petev> man, I wish I would have connected all the drives together in rs485 mode, hopefully I won't have to change parameters much more
[04:02:42] <jmkasunich> while ( n < 1024 ) { checksum += data[i++] }
[04:02:42] <jmkasunich> oops
[04:07:24] <jmkasunich> I suppose a for loop would be more robust against that kind of thing
[04:11:09] <tomp> jmkasunich: just an outsider view.. n isnt incremented, i isnt tested... while (n<1024){ csum += data[n++]} ??
[04:11:17] <jmkasunich> exactly
[04:11:37] <jmkasunich> I copied the code from another file, where it used N for everything
[04:11:51] <jmkasunich> the new file already was using N for somethign else, so I used I
[04:11:56] <jmkasunich> but I didn't change it everywhere
[04:12:06] <jmkasunich> result: it went off accessing memory all over the kernel
[04:12:11] <jmkasunich> fortunately reading, not writing
[04:12:31] <jmkasunich> but it still meant that the module couldn't be unloaded (cause it crashed during init)
[04:13:41] <tomp> i make alot of errs in copy & paste, esp on symmetric code (like octants fer instance, where 8 similar codes are just a little different)
[22:12:56] <skunkworks> join cnc
[22:13:00] <skunkworks> :)