#emc-devel | Logs for 2007-05-09

[05:06:49] <LawrenceG> petev: I am interested in the auto tune algorithm
[05:07:15] <LawrenceG> petev: downloading trunk now...
[05:07:44] <LawrenceG> petev: I have an embedded servo drive I could try it one
[05:07:55] <LawrenceG> s/one/on
[05:08:53] <LawrenceG> petev: http://members.shaw.ca/swstuff/dspic-servo.html
[05:12:22] <petev> what do you mean embedded servo drive?
[05:13:04] <petev> is it taking commands from a HAL PID component?
[05:13:11] <LawrenceG> well it is a board with its owm processor and local pid loop... interfaces to emc via type 2 stepping
[05:13:11] <petev> if so, then you can try it
[05:13:31] <petev> so you want to adapt the algo to your board?
[05:13:50] <LawrenceG> I would have to move the code to the micro
[05:13:54] <petev> is the local loop a vel loop?
[05:14:19] <LawrenceG> torque.... processor sets drive current
[05:14:52] <petev> so you want to tune your torque loop?
[05:15:27] <petev> the algo is pretty simple
[05:15:29] <LawrenceG> basically the drive is always in current limit mode and the positioning loop adjusts the current and polarity
[05:15:52] <petev> so you don't have a vel loop?
[05:16:27] <petev> in general the PID doesn't really care what it's controlling
[05:16:33] <LawrenceG> no velocity loop.. the PID code was basically extracted from the hal code and ported to the dspic
[05:16:49] <petev> as long as the set point and feedback are in the same metric it should work
[05:17:33] <LawrenceG> cool... I have a single axis of a cross slide table running at the moment
[05:17:54] <LawrenceG> what files should I be looking at?
[05:18:00] <petev> the at_pid.c
[05:18:15] <petev> it is a completely new PID, but the PID part is the same
[05:18:32] <petev> you can just look at PID_AutoTune()
[05:19:05] <LawrenceG> ok... will have a look in the next few days and see how I can tie it into the existing drive
[05:19:49] <LawrenceG> sounds very exciting.... tuning servos is kind of fun.... it will be interesting to see if your algorithm can do better
[05:20:08] <petev> it came pretty close on the axis that I hand tuned
[05:20:14] <petev> and it took me way too long
[05:20:20] <petev> took a few secs with the algo
[05:20:20] <LawrenceG> it should certainly be less time consuming
[05:20:25] <petev> yes
[05:20:29] <LawrenceG> yea
[05:20:40] <petev> I have 3 more axis to go and didn't want to waste more time ;-)
[05:21:48] <LawrenceG> if it results in a stable set of values that is way ahead of trying to start up a cold servo on strange iron.
[05:21:58] <petev> yep
[05:23:03] <LawrenceG> I did some servo stuff positiong large bandmills in sawmills... I never did get one to hop off the rails, but there were some scarely moments
[05:23:44] <LawrenceG> several machines had 100+ hp on the hydraulics used for positioning
[05:24:21] <petev> wow, got to be carefull with that
[05:24:50] <LawrenceG> some of the slab positioners ran at 60ips... 40gpm moog servo valves
[05:27:00] <LawrenceG> I'll probably have lots of questions.... thankyou for the contribution... headed off for bed.... goodnight
[05:28:31] <petev> gn
[12:19:07] <rayh> My 5.10 won't let me update emc2.
[12:19:34] <rayh> We must have required some newer packages?
[12:21:14] <skunkworks> is this what you need? http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingTo2.1
[12:23:11] <rayh> I have 2.1 on this box.
[12:23:44] <rayh> Just doesn't want to get 2.1.5
[12:24:18] <rayh> But then I've not been keeping the rest of the system up to date.
[12:24:20] <alex_joni> rayh: any errors?
[12:24:58] <rayh> Some updates require the removal of further software. Use the function "Mark All Upgrades" of the package manager "Synaptic" or run "sudo apt-get dist-upgrade" in a terminal to update your system completely.
[12:25:11] <alex_joni> hrmm
[12:25:35] <alex_joni> try apt-get update in a terminal, and see if that barfs
[12:25:57] <alex_joni> then apt-get install emc2
[12:26:02] <rayh> the update would require 106 Meg download
[12:26:11] <alex_joni> not update
[12:26:17] <alex_joni> upgrade would require that download
[12:26:33] <alex_joni> you can also try to get it here: http://www.linuxcnc.org/emc2/dists/breezy/emc2.1/binary-i386/emc2_2.1.5_i386.deb
[12:26:49] <alex_joni> and install it with dpkg -i emc2_2.1.5_i386.deb
[12:26:59] <rayh> I've got a compiler and the latest from head
[12:29:08] <rayh> update from the terminal went okay.
[12:30:09] <rayh> the install does seem to be working from the apt-get install emc2 command.
[12:30:29] <rayh> thanks guys
[12:30:40] <alex_joni> cool.. np
[12:31:04] <rayh> The following packages will be REMOVED:
[12:31:04] <rayh> emc2-axis
[12:31:19] <alex_joni> hmm.. that means you have an pre 2.1 emc2 installed
[12:31:39] <rayh> This did start life as 5.10
[12:31:55] <alex_joni> yeah.. 2.0.x had emc2 and emc2-axis
[12:31:56] <rayh> But I thought I'd been keeping up with updates to emc
[12:32:13] <alex_joni> 2.1.x has emc2 only, emc2-axis is merged into emc2
[12:32:23] <rayh> Right.
[12:32:27] <alex_joni> you probably did keep up with 2.0.x updates
[12:32:32] <alex_joni> 2.0.1, .. 2.0.5
[12:32:40] <alex_joni> dpkg -l emc2 will tell you exactly
[12:32:55] <rayh> No I was keeping up.
[12:33:11] <rayh> But EMC is not the only issue that's come up of late.
[12:33:57] <rayh> evolution has nearly quit these days also.
[12:35:12] <rayh> and the disks admin shows 4 hard drives and I've got one.
[12:36:37] <rayh> I must say that this Ubuntu install is the longest lived Linux I've ever run.
[12:36:53] <alex_joni> I'd install 6.06 in your place
[12:37:04] <alex_joni> you won't change it for 3 years at least ;)
[12:38:12] <rayh> I've got 5 computers running it now. This old one is/was my web box.
[12:38:24] <alex_joni> ahh.. ok
[12:40:23] <rayh> It's reminding me of a line from Rutger Hauer in the movie Blade Runner.
[12:40:34] <rayh> "Time to die!"
[12:40:43] <alex_joni> heh
[12:41:06] <alex_joni> so you installed the 2.1.5 emc2 now?
[12:41:26] <rayh> It seems to be working at it.
[12:41:59] <rayh> apt said it would take an hour to download stuff.
[12:42:11] <alex_joni> ouch
[12:42:19] <alex_joni> no news from the wireless guys?
[12:42:49] <rayh> They said this month on their web site.
[12:43:03] <rayh> I'm getting anxious.
[12:52:38] <alex_joni> hrmm.. cradek_ is having connection issues ;)
[12:53:06] <rayh> Looks like it.
[13:14:43] <cradek_> cradek_ is now known as cradek
[13:50:48] <jepler_> jepler_ is now known as jepler
[14:04:47] <jepler> cradek: I'm looking at [ 1712475 ] linking a pin to a second signal should trigger an error
[14:05:01] <jepler> cradek: halcmd implements all kinds of links as a call to the C function hal_link()
[14:05:49] <jepler> cradek: given that it's probably not on the table to change the semantics of hal_link(), do you have a name suggestion for the function that would only link when the pin is previously unlinked?
[14:06:58] <cradek> does this mean you also think that case should generate an error? I wasn't sure whether or not people would agree with me
[14:08:31] <jepler> well, I am planning to stake out a nuanced position on that
[14:09:09] <jepler> halcmd would optionally enforce the "pin to be linked must start unlinked" requirement, and the emc runscript would invoke halcmd that way
[14:11:25] <cradek> I'm pretty sure I don't agree that complexity is necessary
[14:12:00] <cradek> 'pin is already linked. use unlinkp first if you want to link it to another signal'
[14:12:19] <cradek> explicit is better than implicit?
[14:13:49] <jepler> I wonder if this behavior was different at some time in the past .. http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/configs/common/axis_manualtoolchange.hal?rev=1.1;content-type=text%2Fplain
[14:13:58] <jepler> # in case they were linked already
[14:13:59] <jepler> unlinkp iocontrol.0.tool-change
[14:13:59] <jepler> unlinkp iocontrol.0.tool-changed
[14:14:20] <cradek> interesting
[14:17:13] <jepler> reading the annotated source, it looks like this was in hal_link from rev 1.1:
[14:17:16] <jepler> 903: /* everything is OK, break any old link */
[14:17:19] <jepler> 904: unlink_pin(pin);
[14:39:33] <SWPadnos> AFAIK, hal_link has always explicitly unlinked a previously linked pin
[14:42:05] <cradek> SWPadnos: what is your opinion on the bug report?
[14:42:29] <SWPadnos> how about a definite maybe?
[14:42:54] <SWPadnos> maybe it shuld be a warning
[14:43:02] <cradek> nobody would see it
[14:43:09] <SWPadnos> but then again, I don't think we have any way of seeing warnings
[14:43:11] <SWPadnos> right
[14:43:50] <SWPadnos> one of the other issues that unveiled the "problem" was that there are separate namespaces for signals and pins
[14:43:52] <cradek> it's a huge shoot-yourself-in-the-foot "feature" and I don't see why that implicit behavior is needed or even desired
[14:44:19] <SWPadnos> the advantage is that you can always link a pin with one statement
[14:44:30] <SWPadnos> I'm not sure that's a big enough edvantage though
[14:45:36] <SWPadnos> both cases could be satisfied by adding relink{sp,ps} commands
[14:45:44] <jepler> hal_link (at least) has always been documented as removing the old link first
[14:45:48] <SWPadnos> yep
[14:46:05] <jepler> I'm wary of changing that behavior, even though the only user in the world is halcmd
[14:46:14] <cradek> I agree it's always been that way, I think that's not the issue
[14:46:29] <SWPadnos> change linkxx to error out (by checking ahead of time, not by changing hal_link)
[14:46:40] <SWPadnos> add relinkxx to act as linkxx does now
[14:46:50] <cradek> when we see the same question from many people, each with a foot missing, it's sometimes time to reconsider something
[14:47:04] <SWPadnos> yeah -"why make shoes in pairs?"
[14:47:12] <jepler> hahah
[14:47:14] <jepler> * jepler wanders off
[14:48:01] <SWPadnos> it would be interesting to make the change to linkxx, and then try loading all the sample configs
[14:48:10] <SWPadnos> just to see if we have any of those errors in our own code