Back
[00:09:14] <cradek> jmkasunich: think I should release?
[00:09:42] <jmkasunich> why are you asking me? ;-)
[00:09:52] <jmkasunich> if you think its stable, go for it
[00:09:55] <cradek> hmm, good question
[00:10:19] <jmkasunich> what I'm doing is utterly irrelevant to 2.1.2, so don't let me stop you
[00:10:41] <jmkasunich> there are certainly enough bugfixes in the changelog to make it worthwhile
[00:10:51] <cradek> yes, some very important things are in there
[00:11:05] <jmkasunich> (says the guy who doesn't have to do the work)
[00:11:31] <jmkasunich> I type to slow - that wasn't in response to you ;-)
[00:11:53] <cradek> since I haven't tested stepper-xyza, I should update the 'max' configuration to what I'm running successfully
[00:12:35] <cradek> that will give us a jogwheel sample config too
[00:15:59] <jepler> a tiny bit of me says: what if someone is using /etc/emc2/sample-configs/max exactly as-is, and they ignored the advice of the installer about copying, and they get an update that changes the hal files?
[00:16:14] <jepler> that voice is only a tiny one, though
[00:16:56] <jmkasunich> very tiny
[00:17:11] <jmkasunich> * jmkasunich hands jepler a very tiny pillow, to smother the tiny voice with
[00:18:16] <jmkasunich> whats the syntax for getting extra samples with halscope?
[00:18:31] <jmkasunich> halscope 80000?
[00:18:39] <jmkasunich> halscope num_samples=80000?
[00:19:06] <jepler> I think it's 'halscope 80000'
[00:19:08] <jmkasunich> never mind
[00:19:12] <jmkasunich> it is
[00:19:15] <jmkasunich> I was being lazy
[00:19:37] <jmkasunich> the num_samples one is for the RT part
[00:22:46] <cradek> jepler: then they could now add a jogwheel
[00:25:51] <jmkasunich> I dunno why Jymm is asking me about tooling marks
[00:46:42] <cradek> last call for 2.1.2 checkins
[01:12:41] <jepler> cradek: you'll get nothing from me
[01:12:58] <cradek> build build build build build
[01:18:40] <cradek> upload upload upload upload upload
[01:19:39] <SWPadnos> download download download download download
[01:19:42] <SWPadnos> :)
[01:20:31] <petev> SWPadnos, what do you think of this:
[01:20:42] <petev> aixs ini stuff needs to get the axis type
[01:20:48] <petev> linear/angular
[01:21:12] <petev> I would like to make the define an enum, trivial and all old code still works
[01:21:27] <petev> then I would like to add a Find() method for EmcAxisType enum
[01:21:49] <petev> however, this is an Emc specific type and kinda doesn't belong under libnml
[01:22:10] <petev> should I inherit an EmcIniFile class?
[01:24:55] <SWPadnos> I like the goal, but I'm not sure it's possible with the way EMC is partitioned right now
[01:25:07] <SWPadnos> some axis information goes to the TP/task, otehr info goes to HAL
[01:25:09] <petev> yeah, it's getting a bit ugly
[01:25:37] <SWPadnos> there's also no specific name for anything - it's all defined in the HAL files (for HAL parameters)
[01:25:38] <petev> I just hate to see all the code doing it differently and duplicated
[01:25:59] <petev> stuff like this is canned in the strcmp calls in the code
[01:26:05] <SWPadnos> you can set a P term with setp pid.0.p = [FRED]PROPORTIONAL_TERM
[01:26:12] <petev> definitely has to be the right name, or it won't work
[01:26:20] <SWPadnos> it doesn't have to be [AXIS_0]P
[01:26:26] <petev> hal is different
[01:26:36] <SWPadnos> right, but that's where most of the info goes
[01:26:50] <petev> no, lot's of it is in the emc code
[01:26:52] <jmkasunich> SWPadnos: I wouldn't say most
[01:26:57] <petev> look at ini/iniaxis.cc
[01:27:10] <petev> that's what I'm working on now
[01:27:14] <SWPadnos> for the parts that are used in motion/task a single read might be good, as long as all the info is in one struct
[01:27:19] <SWPadnos> one sec
[01:27:21] <petev> the first thing it gets is the axis type
[01:31:47] <SWPLinux> ok - I'm looking at the file (onm a Linux machine even :) )
[01:31:50] <SWPLinux> on
[01:32:09] <petev> so it's basically a string conversion to 1 or 2 for the axis type
[01:32:33] <petev> and about 20 lines of code that obscures what's happening
[01:33:10] <SWPLinux> are those defines in emcglb.h?
[01:33:19] <petev> emc.hh
[01:33:24] <SWPLinux> oh 0 ok
[01:33:28] <SWPLinux> -0
[01:35:01] <SWPLinux> are enums int sized?
[01:35:37] <petev> usually, but there are compiler flags to change the size in most compilers
[01:35:58] <petev> they can also be passed as ints and chars, usually without any type cast
[01:36:41] <petev> I already tried replacing the defines with an enum and everything compiled without warning
[01:36:50] <SWPLinux> hmmm. my c++ foo is rusty - I thought enums were different types in c++
[01:36:53] <SWPLinux> ok
[01:36:58] <petev> but thats the easy part
[01:37:01] <SWPLinux> heh
[01:37:19] <SWPLinux> * SWPLinux bets that error handling is the hard part ;)
[01:37:31] <petev> no, thats not bad either
[01:37:43] <petev> the hard part is an EMC enum in lib nml
[01:37:46] <petev> I don't like it
[01:38:00] <SWPLinux> that should be in iniaxis, I think
[01:38:02] <petev> but I would have to create a new module in emc that derives from inifile
[01:38:16] <petev> I think it needs to be in emcinifile
[01:38:30] <petev> that way anybody that wants axis type can get it with the same code
[01:38:45] <SWPLinux> sure - all the EMC-related ini reads are in the same dir right now (just not the same one as the ini base class)
[01:39:11] <petev> actually ini reads are in at least 3 dirs for emc
[01:39:17] <petev> but let's not get into that
[01:39:21] <SWPLinux> heh
[01:39:33] <petev> I can add the EmcIniFile class in a module in the ini dir
[01:39:40] <SWPLinux> I see iniaxis, initraj, and initool in the same place, at least
[01:39:49] <petev> and add Find() methods for Emc specific types
[01:39:55] <petev> yes
[01:40:08] <petev> but there's more in motion and use_intf and the axis dir
[01:41:06] <SWPLinux> to minimize problems with history, I'd just "class-ify" initraj, initool, and iniaxis
[01:41:44] <petev> the issue is whether created the new EmcIniFile class and module is ok
[01:41:48] <SWPLinux> although the UIs may all read some ini info, there's no guarantee that they'll all need the same info, so I'm not sure it makes sense to make a single UIIniRead class
[01:42:11] <SWPLinux> heh - that's not a me question ;)
[01:42:16] <petev> at some point some code needs each of the things in the INI file
[01:42:25] <petev> if not, I guess it shouldn't be in the INI file
[01:42:45] <petev> so I think libnml supports basic stuff like in, double, bool
[01:42:57] <petev> but emc specific enums shouldn't be in there
[01:42:58] <SWPLinux> duh - axis as in joint, not axis as in GUI - I get it eventually :)
[01:43:19] <petev> BRB, got to grill some fish
[01:43:23] <SWPLinux> right - there should be a base ini class that you could use in another project
[01:43:24] <SWPLinux> heh
[01:44:00] <SWPLinux> then one or two layers on top of that - possibly one for units and that kind of things and another for emc-specific "structs"
[01:44:10] <SWPLinux> (like a whole axis or whatever)
[01:45:19] <cradek> start over start over start over
[01:45:36] <cradek> build build build build
[01:45:36] <SWPLinux> build build build build build
[01:45:39] <SWPLinux> heh
[01:45:43] <cradek> grngh
[01:46:16] <SWPLinux> I wish a VM would be fast at building the packages for you :(
[01:46:25] <SWPLinux> I could do it relatively quickly in that case
[01:46:54] <cradek> it doesn't take that long really - but there are three architectures, plus a slow upload
[01:47:07] <cradek> so it means an hour of fiddly work
[01:47:10] <SWPLinux> right
[01:47:23] <SWPLinux> hmmm. sim, RT, (?)
[01:47:26] <cradek> breezy
[01:47:30] <SWPLinux> ah
[01:47:50] <jmkasunich> do you have to do it on 3 separate machines (or VMs)?
[01:48:01] <cradek> no, fortunately not
[01:48:03] <jepler> one could do the RT and sim on the same machine
[01:48:17] <cradek> I used to have to reboot into breezy, but since jepler cleaned it up, now I can chroot
[01:48:38] <jepler> what did I clean up? depending on the building "uname"?
[01:48:44] <cradek> yes
[01:50:17] <jepler> yay me
[01:53:01] <petev> so cradek, any objection to creating an emcinifile module in ini?
[01:54:34] <cradek> petev: that's outside my area of expertise, so I'll go along with whatever the crowd thinks
[01:54:54] <petev> SWPadnos?
[01:55:38] <SWPLinux> are you planning on replacing the files in emc/ini with a different file in libnml/ ?
[01:55:59] <petev> no, the new class will be derived from the libnml
[01:56:09] <jmkasunich> and the code will live where?
[01:56:12] <petev> and will add Find() methods for Emc specific types
[01:56:24] <petev> the new class will be in the ini dir
[01:56:34] <petev> since it's emc specific
[01:56:38] <SWPLinux> ah - emc specific types, not necessarily "a whole axis"? ...
[01:56:43] <petev> right
[01:56:44] <jmkasunich> src/emc/ini, or src/libnml/ini?
[01:56:48] <SWPLinux> ok. sound sgreat to me
[01:56:52] <petev> src/emc/ini
[01:57:24] <petev> jmkasunich?
[01:57:56] <jmkasunich> I guess
[01:57:56] <SWPLinux> src/libnml/ini should have only "primitives", src/emc/ini should have (a) non-primitives (length, time ...) and (b) struct loads (ie, a whole axis or all of traj ...)
[01:58:16] <SWPLinux> if that's the plan then I'm all for it
[01:58:17] <jmkasunich> I'm with cradek - not really my area
[01:58:24] <cradek> may as well be greek
[01:58:27] <petev> yes, the only thing under nml/ini is double, int, bool
[01:58:41] <SWPLinux> string? ...
[01:58:41] <cradek> what's the external effect the user will see?
[01:58:44] <petev> any emc enums and the likes will be under emc/ini
[01:58:52] <petev> no change for user
[01:59:04] <petev> just cleaner emc code with less bugs
[01:59:03] <SWPLinux> user: none. programmer: different but probably simpler interface to ini vars
[01:59:13] <petev> and will be easier to make INI changes in the future
[01:59:49] <SWPLinux> petev: maybe I should add an enum class to the libnml library - that's a common primitive (list of options)
[01:59:59] <petev> I don't want to make any changes right now that will effect what the user puts in the INI file
[02:00:16] <cradek> sounds like the only negative might be getting out of sync with 2.1 so we can't work on trunk and backport any related fixes -- but ini stuff isn't likely to need any work
[02:00:23] <SWPLinux> or at least a findEnum interface
[02:00:58] <petev> SWPadnos, I don't fully understand what you mean, please elaborate
[02:01:20] <petev> you mean some type of generic enum conversion routine?
[02:01:30] <petev> perhaps a table driver thing?
[02:01:33] <SWPLinux> something that gets a list of string/value pairs, and if it finds a string, returns the appropriate value
[02:01:40] <SWPLinux> yep - like my AVR assembly code ;)
[02:01:46] <petev> yeah, I knew you were going there
[02:01:48] <SWPLinux> heh
[02:01:51] <petev> Ok, I can look at that
[02:02:02] <SWPLinux> it's the obvious choice for bool, units, and any other enums
[02:02:12] <petev> could probably replace that bool code wit a call to it too ;-)
[02:02:14] <SWPLinux> I can add that to inifile
[02:02:16] <SWPLinux> right
[02:02:22] <petev> ok, done
[02:02:33] <SWPLinux> you aren't changing inifile.{cc,hh} right now are you?
[02:02:50] <petev> no, but will have to for this
[02:02:56] <SWPLinux> hmmm
[02:03:07] <petev> I'll do the table routine and then call it for bool
[02:03:16] <petev> then the emc code can pass in tables for the eunums
[02:03:18] <SWPLinux> use the current interface, and I'll change your new classes to use the new interface when needed
[02:03:37] <petev> are you making changes in there now?
[02:03:53] <SWPLinux> no,but I may want to tonight
[02:04:21] <petev> ok, I'll make the new emcinifile and code to that and glue it to libnml later when your done
[02:04:34] <SWPLinux> that works
[02:04:45] <petev> the other interfaces in libnml shouldn't change, other than adding the new enum support
[02:05:15] <SWPLinux> right - you can make your new classes without my changes, and I'll fix your classes when I add the new code to inifile
[02:05:23] <petev> righ
[02:05:51] <petev> BBL, got to go eat some grilled fish ;-)
[02:05:57] <SWPLinux> heh
[02:06:11] <cradek> upload upload upload
[02:06:32] <SWPLinux> wait wait wait wait
[02:06:37] <jmkasunich> cradek: code grinder
[02:06:46] <jmkasunich> crank crank crank
[02:06:58] <cradek> how's stepgen?
[02:07:02] <jmkasunich> steppy
[02:07:08] <cradek> (glad I have a fastish computer now)
[02:07:16] <cradek> steppy is good
[02:07:23] <jmkasunich> welllllll
[02:07:36] <jmkasunich> it still does weird things sometimes
[02:07:45] <jmkasunich> but of course, never on repeatable inputs
[02:07:48] <cradek> weird things are not so good
[02:14:37] <jepler> three or four times I read "<cradek> (glad I have a computer fetish now)"
[02:15:01] <cradek> oh I don't want to talk about that
[02:15:22] <SWPadnos> a fastish computer fetish
[02:15:29] <cradek> no, that's you
[02:15:35] <SWPadnos> oh - right
[02:15:41] <SWPadnos> no, mine's an obsession ;)
[02:16:14] <jmkasunich> SWPadnos: how fast is your second fastest computer?
[02:16:36] <SWPadnos> A64 3500+, 1G RAM, Quadro FX3500 video
[02:17:00] <jmkasunich> the big one is dual opterons?
[02:17:28] <SWPadnos> dual cual-core now, yes
[02:17:31] <SWPadnos> s/cual/dual/
[02:17:37] <jmkasunich> nice
[02:17:45] <jmkasunich> thats what I want for the compile farm ;-)
[02:18:07] <SWPadnos> I'll probably move the Quadro FX into that machine, and add the other one for SLI goodness (and put the 7800GT into the A64-3500
[02:18:09] <SWPadnos> )
[02:18:24] <jmkasunich> video schmideo
[02:18:38] <jmkasunich> I just want CPU and RAM
[02:18:42] <SWPadnos> yeah, it runs VMWare pretty well. these CPUs have the virtualization features (which I think helped some)
[02:18:46] <jmkasunich> oh, and some disk would be nice
[02:18:46] <SWPadnos> 4G should do it ;)
[02:19:11] <SWPadnos> and 300G hard disks, but only 8 at a time (I only have 3 though, of which one is in the A64)
[02:19:11] <jmkasunich> I wasted some time the other day at newegg
[02:19:16] <jmkasunich> about $1100 would do it
[02:19:21] <SWPadnos> 300G, $90 or so O_O
[02:19:31] <SWPadnos> 300, 320 - whichever
[02:20:54] <jmkasunich> 1212 CPU, 2G ram, 80G WD Raptor for swap and apps, two 250G drives for user stuff (mirrored)
[02:23:05] <jmkasunich> the two socket mobos are appealing, but that bumps the price up alot...
[02:23:28] <jmkasunich> quad core cpus are coming, so single socket makes more financial sense to me
[02:23:53] <SWPadnos> the single socket is worse the more cores you have per CPU
[02:23:54] <SWPadnos> at least for Opteron
[02:25:08] <jmkasunich> bang per buck though...
[02:25:52] <jmkasunich> the 2nd socket adds about $100 (or more) to the mobo price, and the 2nd CPU adds $200 or more depending on speed grade
[02:26:52] <SWPadnos> the second CPU isn't needed at first, you get performance equivalent to a single CPU MB with only one
[02:27:08] <SWPadnos> the only added cost is the $$ for the MB (+$200 though, so not trivial)
[02:27:14] <jmkasunich> thats true, but for SMP both CPUs have to be the same
[02:27:59] <SWPadnos> yes, but once the quad cores come out, you'll be able to get 2x dual core for less (or not as much anyway), and you'll have better performance (assuming you also add RAM)
[02:28:04] <jmkasunich> so if I get a 1212 now, and later 1218s get cheaper, I either have to buy two 1218s and retire the 1212, or use two 1212sa
[02:28:12] <SWPadnos> yes
[02:28:32] <SWPadnos> probably better to use the same stepping as well, but that's not as inmportant with Opterons, I gather
[02:28:51] <jmkasunich> IOW, you pretty much want to buy them as a pair
[02:29:01] <jmkasunich> unless you shop very carefully
[02:29:03] <SWPadnos> yes, that's the best idea
[02:29:50] <SWPadnos> I'm betting that 2x dual-core will be pretty cheap once quad cores come out, so the upgrade path is better for the dual, I think
[02:30:04] <jmkasunich> maybe
[02:30:09] <SWPadnos> higher performance and probably lower or the same price for a CPU/memory upgrade
[02:30:23] <jmkasunich> after spending some time drooling, I decided I had better things to spend $1000+ on
[02:30:35] <SWPadnos> heh - that's probably a good decision :)
[02:30:45] <jmkasunich> doesn't stop me wanting it every time the farm loads up though
[02:30:53] <SWPadnos> heh
[02:31:05] <SWPadnos> can you burn DVDs?
[02:31:20] <jmkasunich> whats a DVD?
[02:31:26] <jmkasunich> iow, no
[02:31:31] <SWPadnos> it's a high capacity CD ;)
[02:31:42] <SWPadnos> ok. no sending of VMs then
[02:33:19] <jmkasunich> this damned thing....
[02:33:35] <jmkasunich> I'm sure its using hi-res position feedback
[02:33:51] <jmkasunich> but it still goes wonky right after a step is issued, as if step granularity is throwing it off
[02:35:43] <SWPadnos> that points me at some mis-scaling between the fraction and the step (or something similar)
[02:36:02] <jmkasunich> unlikely
[02:36:15] <SWPadnos> or possibly the position-update thread getting interrupted and having an out-of-sync pair of values
[02:36:38] <jmkasunich> the position is a 64 bit number, in 36.28 format
[02:37:12] <jmkasunich> its atomically read, then multiplied by ( 1.0 / ( 1L << 28 )) to make a double
[02:37:58] <SWPadnos> hmmm
[02:39:09] <jmkasunich> this is that "pretuned position loop" in the stepgen
[02:39:10] <jmkasunich> I hate it
[02:39:27] <jmkasunich> it makes my brain hurt
[02:39:49] <SWPadnos> I assume that you've halscoped the position with an exceedingly slow step rate? (looking for anomalies in the output value around step time)
[02:40:05] <jmkasunich> wellllll not quite
[02:40:35] <jmkasunich> the problem is that position is all over the place, based on where in the program the analomy happens
[02:40:44] <jmkasunich> I'm mostly looking at velocitys
[02:40:52] <jmkasunich> which stay centered around zero
[02:41:10] <SWPadnos> ok - derivative of that ;)
[02:41:16] <jmkasunich> anomalys happen around direction reversals
[02:41:21] <SWPadnos> ah
[02:42:01] <jmkasunich> lemme post a pic and pastebin some code
[02:43:30] <jmkasunich> http://www.pastebin.ca/391368
[02:44:46] <SWPadnos> you should be able to simplify the pseudo-tuning because you can now use fractional steps (or fractional time chunks)
[02:45:26] <SWPadnos> so you no longer need to end exactly on some step - if you calculate it "exactly", then the number of steps issued should be closest to the ideal position (in my theory anyway)
[02:45:32] <jmkasunich> http://jmkasunich.dyndns.org/pics/stepgen-dir-toggle-2.pn
[02:45:53] <jmkasunich> commanded position is and has always been a float, it could stop between steps
[02:46:10] <jmkasunich> control loops have deadband to stop on the nearest full step
[02:47:05] <jmkasunich> the vast majority of the vars in that code snippet are doubles
[02:47:25] <jmkasunich> pos_cmd, vel_cmd, curr_pos, curr_vel, all doubles
[02:47:38] <SWPadnos> (hand't looked at the code yet - just positing possibilities)
[02:47:49] <jmkasunich> in fact, that code _should_ be completely unaware of step quantization
[02:47:56] <SWPadnos> ok
[02:48:01] <jmkasunich> there is still time quantization of course...
[02:48:35] <jmkasunich> in the pic: the with stairstep is commanded velocity, in length units
[02:48:53] <jmkasunich> the smooter antled line (green) is "addval", the DDS internal rate
[02:49:20] <jmkasunich> you can see the commanded vel stepping every 1mS, while addvel has ramping
[02:49:40] <jmkasunich> target_addvel is calced by the code in the pastebin every 1mS, and addval is ramped in the high speed code
[02:50:06] <jmkasunich> comanded vel and addval are not scaled the same, so don't worry about the small alope difference
[02:50:19] <jmkasunich> step and dir are the red and blue at the bottom
[02:50:52] <jmkasunich> the little sawteeth are my timers for steplen, dirhold, and dirsetup
[02:51:08] <jmkasunich> and in this particular event, they are irrelevant
[02:51:55] <jmkasunich> because they were timed out when the vel command and addval crossed zero, the dir change was not delayed, and no dir change is pending when the addvel trace decides to go negative for some reason
[02:52:47] <jmkasunich> now you know what I know - please point out the problem in my code ;-)
[02:53:26] <jmkasunich> I'm gonna make some of the internal vars (pos_cmd, curr_pos, and friends) available on params
[02:53:38] <SWPadnos> ok - will do ;)
[02:53:46] <SWPadnos> iff I see it
[02:55:02] <SWPadnos> commanded vel is internal?
[02:55:25] <jmkasunich> anything without stepgen-> in front is internal
[02:55:41] <SWPadnos> there's nothing with stepgen-> in front on the plot ;)
[02:55:57] <SWPadnos> (I've been meaning to add that, but am totally clueless about gtk)
[02:55:59] <jmkasunich> oh, I thought you were talking about the code
[02:56:17] <jmkasunich> you mean the white trace?
[02:56:53] <SWPadnos> yes (though it looks purplish to me)
[02:57:02] <jmkasunich> the stairstep one?
[02:57:08] <SWPadnos> yep
[02:57:19] <SWPadnos> duh - that's commanded vel
[02:57:27] <SWPadnos> XVel (it's in the pic)
[02:57:26] <jmkasunich> that is a ddt of the position command to the module
[02:57:39] <jmkasunich> ok, I can rule out some things
[02:57:58] <jmkasunich> I've been running it some more (haven't added test points yet)
[02:58:05] <jmkasunich> and I see disturbances that don
[02:58:15] <jmkasunich> don't conincide with step pulses
[02:58:24] <jmkasunich> that was apparantly a coincidence
[02:58:53] <SWPadnos> ok. that's good
[02:59:13] <jmkasunich> I bet the position loop is flopping around inside the 1 step deadband that it used to need
[03:00:23] <jmkasunich> I think thats line 38 of the pastebin
[03:00:35] <SWPadnos> is it always around a reversal, or is there a problem with two position changes in the same direction (like two G-codes would be)?
[03:00:50] <jmkasunich> hard to say
[03:01:00] <jmkasunich> I'm triggering on a dir pin change when it shouldn't
[03:01:08] <SWPadnos> ok
[03:01:25] <jmkasunich> these deviations from the desired velocity ramp cross zero and make the dir pin change
[03:01:34] <jmkasunich> a similar deviation at higher speed would not
[03:02:37] <jmkasunich> hmm - I should calc a "naive_freq" from the commanded velocity, and compare that with the actual freq
[03:02:47] <jmkasunich> that would let me spot deviations
[03:03:03] <SWPadnos> hmmm
[03:03:19] <jmkasunich> as long as the command doesn't exceed constraints (which it shouldn't if coming from EMC's TP
[03:03:48] <SWPadnos> probably unrelated, but possibly a bug (or possibly me only having read the first 5 lines of code):
[03:04:47] <SWPadnos> the velocity command uses old_pos and pos_cmd to get a delta, then gets the vel. it then replaces old_pos with pos_cmd, even though the stepgen hasn't "gotten there" yet
[03:05:09] <jmkasunich> what line number?
[03:05:11] <SWPadnos> if the pos_cmd changes before the move is done, then the next deltawill be wrong (and the next vel)
[03:05:15] <SWPadnos> line 5
[03:05:21] <SWPadnos> 2,4, and 5
[03:05:44] <jmkasunich> doesn't matter whether it gets there or not
[03:05:44] <SWPadnos> those lines assume that the output is "stopped" before a new command comes in - is that guaranteed before this code executes?
[03:05:55] <jmkasunich> that is one command value minus the previous command value
[03:06:20] <SWPadnos> is cmd_pos updated elsewhwere as well?
[03:06:23] <SWPadnos> oops - old_pos
[03:06:27] <jmkasunich> pos_cmd and vel_cmd are info about the incoming command signal
[03:06:35] <SWPadnos> ... old_pos_cmd ...
[03:06:57] <jmkasunich> stepgen->old_pos_cmd is only used to do the vel_cmd calc
[03:07:03] <jmkasunich> * jmkasunich double checks
[03:07:06] <SWPadnos> but actual position and old_pos_cmd are not necessarily the same thing
[03:07:29] <SWPadnos> they are the same only when the stepgen is "in position"
[03:08:10] <jmkasunich> pos_cmd and old_pos_cmd have absolutely nothing to do with actual position
[03:08:26] <jmkasunich> see line 17
[03:08:48] <SWPadnos> I disagree with that comment :)
[03:08:52] <SWPadnos> ok. this is my thought experiment:
[03:09:12] <SWPadnos> from 0, command a 2" move at 1 IPS
[03:09:15] <jmkasunich> in a pathological case where the commanded position steps by 10", the actual won't match the command for a long time
[03:09:27] <SWPadnos> old_cmd_pos is now 2"
[03:09:36] <jmkasunich> define now
[03:09:41] <jmkasunich> this is periodic code
[03:10:03] <jmkasunich> if the TP is moving at 1IPS then cmd_pos is changing by 0.001" every call
[03:10:03] <SWPadnos> ok - good point
[03:11:17] <SWPadnos> ok - this is running in lock step with traj
[03:11:22] <jmkasunich> btw, this wierdness only happens when the input signal is within the vel and accel constraints
[03:11:47] <jmkasunich> this code runs at the servo rate
[03:11:52] <SWPadnos> this problem shouldn't happen with EMC, but could with a HAL-only "go to position" type system
[03:12:06] <jmkasunich> which problem?
[03:12:34] <jmkasunich> this code works perfectly with signals that exceed limits
[03:12:35] <SWPadnos> heh - lemme think about it more before completely sidetracking you. it's probably only a problem in my head
[03:12:47] <jmkasunich> put a position step in, you get a trapezoidal move out
[03:13:17] <SWPadnos> put in a position step back to the origin *before the previous move is done*, and you may not get what you expect, I think
[03:13:26] <jmkasunich> nope, it works
[03:13:34] <SWPadnos> ok - see, it's all in my head :)
[03:13:52] <jmkasunich> the trap move immediately decels, reverses, accels, cruises in reverse, decels and stops
[03:14:03] <SWPadnos> (I'm not convinced of why, but I can look at that any time)
[03:14:48] <jmkasunich> for signals that fit inside vel and accel constraints, things like "match_time" should be less than one period
[03:15:01] <SWPadnos> yep
[03:15:16] <SWPadnos> (assuming the stepgen and TP are set up compatibly)
[03:15:39] <jmkasunich> that is implied by "for signals that fit inside the vel and accel constraints"
[03:15:57] <jmkasunich> and the bug is happening with signals that do fit inside the constraints
[03:16:00] <SWPadnos> oh - *those* vel and acc constraints :)
[03:16:07] <jmkasunich> vel near zero, and accel about half of max
[03:17:11] <jmkasunich> the numbers in there scare me
[03:17:21] <jmkasunich> 0.5 on line 30 is OK, thats an average calc
[03:17:35] <jmkasunich> the 1.5 on line 33, I don't remember that that is for
[03:17:48] <jmkasunich> line 38 is a deadband of sorts
[03:18:01] <jmkasunich> 44, dunno
[03:18:05] <jmkasunich> 55 dunno
[03:18:36] <jmkasunich> I need visibility on some of these values
[03:18:41] <jmkasunich> gotta scope them
[03:18:47] <SWPadnos> this is "update-freq" or similar?
[03:18:50] <jmkasunich> yes
[03:19:12] <jmkasunich> I trimmed the stuff that validates scale, checks the steplen, etc
[03:19:18] <SWPadnos> ok. maybe the annotated version of the source will point to a commit message that helps identify the magic numbers
[03:20:23] <jmkasunich> I think from line 15 on is exactly the same as the existing stepgen
[03:20:39] <SWPadnos> ok
[03:20:54] <jmkasunich> the key difference is that curr_pos is derived from the accum with high resolution, instead of from stepgen->counts with one step resolution
[03:21:24] <jmkasunich> lines 2 thru 5 are unchanged too
[03:21:47] <SWPadnos> ok, so 6-14 are mostly added and somewhat changed
[03:21:53] <SWPadnos> and that's about it?
[03:22:25] <jmkasunich> yeah
[03:22:36] <jmkasunich> which probably explains why the same bug is happening that happened before
[03:22:52] <jmkasunich> the finer resolution curr_pos (at least alone) didn't solve it
[03:22:59] <SWPadnos> is dt the update_freq period or the make_pulses period?
[03:23:08] <jmkasunich> update_freq
[03:23:14] <SWPadnos> ok
[03:23:41] <jmkasunich> the make_pulses period doesn't appear here, its embedded in freqscale on line 73
[03:24:13] <SWPadnos> consider match_time near 0 (small delta V or hig max acc)
[03:24:36] <SWPadnos> line 33 becomes est_cmd = pos_cmd - vel_cmd * (1.5 * dt)
[03:25:13] <SWPadnos> that's 1.5 slow periods of travel at the current vel, which doesn't immediately make sense
[03:25:20] <jmkasunich> yeah, that doesn't seem right
[03:25:22] <SWPadnos> but it's minus that
[03:25:37] <SWPadnos> (since 1.5 * dt is subtracted, I moved the minus sign)
[03:26:12] <jmkasunich> that is supposed to be saying "if the command continues to do what its doing now, where will it be some time in the future"
[03:26:19] <jmkasunich> but for match_time = 0, its in the past
[03:26:21] <SWPadnos> I haven't scrutinized the ifs later though, which deal with match_time <dt ,,,
[03:26:53] <SWPadnos> ok - the estimated error is wrong, I think
[03:27:06] <jmkasunich> because est_cmd is wrong...
[03:27:09] <SWPadnos> right
[03:27:35] <SWPadnos> but est_err isn't recalculated inside the if (match_time<dt) block, which may make sense to do
[03:28:31] <SWPadnos> ok - the 1.5 constant may be trying to make sure there's time for decel (?)
[03:28:54] <SWPadnos> if you accelerate for one period, you have to decel for one period to stop (of course)
[03:28:55] <jmkasunich> I have a feeling the 1.5 constant was chosen during testing of the original version
[03:29:00] <SWPadnos> oh
[03:29:21] <SWPadnos> but probably with moves that were pushing the limits
[03:29:32] <SWPadnos> since those are expected to be the interesting cases
[03:30:03] <jmkasunich> yeah, if you exceed the limits, thats when you see funny stuff like ringing, and the testing solved that
[03:30:06] <jmkasunich> ;
[03:30:09] <jmkasunich> oops
[03:31:32] <SWPadnos> how about this: try replacing the if (match_time < dt) case with just new_vel=vel_cmd;
[03:31:57] <jmkasunich> disable the if on line 38?
[03:32:23] <SWPadnos> more or less. replace lines 39-51 with new_vel=vel_cmd
[03:32:35] <SWPadnos> but leave it alone for match_time > dt
[03:32:41] <SWPadnos> >= I guess
[03:32:49] <jmkasunich> that is pretty much guaranteed to result in position drift
[03:33:17] <SWPadnos> not if curr_pos is used somewhere in there
[03:33:46] <jmkasunich> line 41 says "we're close on position, just match vel"
[03:33:58] <jmkasunich> lines 43-49 attempt to match position
[03:34:25] <jmkasunich> if you disable 43-49, you'll never correct position, and gradually drift away
[03:34:31] <SWPadnos> ok - further thought then
[03:34:37] <SWPadnos> (soon ;) )
[03:34:50] <jmkasunich> I'm very tempted to change the 1.0 on line 38 to 0.001 ;-)
[03:35:09] <SWPadnos> just do <0 ;)
[03:35:39] <SWPadnos> that number is in steps though, right?
[03:35:59] <jmkasunich> yes
[03:36:07] <jmkasunich> that is the +/- 1 step deadband
[03:36:09] <SWPadnos> right
[03:36:13] <jmkasunich> and shouldn't be needed now
[03:36:45] <SWPadnos> well, some deadband is good (maybe a half step) so it doesn't ping around a step pulse
[03:37:07] <jmkasunich> it won't
[03:37:16] <jmkasunich> because this code doesn't know about step pulses
[03:37:36] <jmkasunich> it thinks it has a 250 million PPR encoder
[03:37:47] <SWPadnos> right
[03:39:51] <jmkasunich> running now, with 0.0001 in that compare
[03:40:54] <SWPadnos> line 33 should only be done that way for match_time >> 1.5, I think
[03:41:04] <SWPadnos> again, look at match_time near zero
[03:41:25] <jmkasunich> yeah, that just seems borked
[03:41:36] <SWPadnos> avg_v will be ~= val_cmd
[03:41:41] <SWPadnos> vel_cmd
[03:42:04] <SWPadnos> line 31 will be est_out = curr_pos (match_time is ~0)
[03:42:30] <SWPadnos> then on line 33 est_cmd suddenly has 1.5 periods of motion thrown in (subtracted out)
[03:42:51] <SWPadnos> so est_err will be cmd_vel * 1.5 dt
[03:43:17] <jmkasunich> I bet part of that is compensating for system delay
[03:43:28] <SWPadnos> hmmm - that's not quite accurate, but it's still fishy
[03:43:29] <jmkasunich> even a perfect loop can't make its output match its input
[03:43:33] <SWPadnos> sure
[03:43:42] <jmkasunich> its output after one dt will match its input now
[03:43:51] <SWPadnos> yep - "group delay"
[03:43:56] <SWPadnos> (sort of)
[03:44:12] <jmkasunich> I dunno if that 1.5 is trying to compensate for group delay, or just wrong
[03:44:26] <jmkasunich> match_time assumes no time quantization
[03:44:39] <SWPadnos> ok - one error in my analysis: line 31 uses curr_pos and line 33 uses cmd_pos
[03:44:49] <SWPadnos> pos-cmd
[03:44:54] <SWPadnos> pos_cmd
[03:45:02] <jmkasunich> the new stepgen core defeats position quantisation, but time quantization still lurks
[03:45:15] <SWPadnos> so it's the endpoint minus 1.5 periods at the current vel
[03:45:24] <SWPadnos> not the current pos - 1.5 periods travel
[03:45:26] <jmkasunich> not the endpoint
[03:45:48] <SWPadnos> position command - 1.5 periods travel
[03:46:19] <jmkasunich> either way it sounds fscked doesn't it ;-)
[03:46:25] <SWPadnos> ayep :)
[03:46:29] <jmkasunich> where you wanted me to be 1.5 periods ago
[03:46:52] <SWPadnos> no - it's pos_cmd, not curr_pos
[03:47:16] <jmkasunich> ran a complete flowsnake.ngc with no triggers
[03:47:23] <jmkasunich> normally I get half-a-dozen or so
[03:47:28] <jmkasunich> running another
[03:47:39] <SWPadnos> ok - so maybe I had the opposite of the solution :)
[03:47:52] <SWPadnos> (make it always use the other case for that if / else block)
[03:47:52] <jmkasunich> right - pos_cmd = "where you want me to be now"
[03:48:11] <SWPadnos> ok. I was reading pos_cmd as "where you want me to end up"
[03:48:38] <jmkasunich> you could read it as either "where you want me to be now" or "where you want me to be in one period"
[03:48:43] <SWPadnos> (same tjhing, just semantics of getting there)
[03:48:51] <jmkasunich> the diff is group delay
[03:49:05] <SWPadnos> right, or acc/vel constraints
[03:49:07] <jmkasunich> if the input takes a big step, then its asking the impossible
[03:49:20] <jmkasunich> but its still interpreted as where you want me now
[03:50:05] <jmkasunich> and "ok, I'm going there as fast as I can" ;-)
[03:50:10] <SWPadnos> ok - no problem with naming now
[03:50:11] <SWPadnos> heh
[03:51:08] <jmkasunich> it seems like cutting the deadband fixed it
[03:51:14] <jmkasunich> but that 1.5 bugs me
[03:52:11] <jmkasunich> for the match_time = small case, est_err starts to become irrelevant
[03:52:30] <jmkasunich> oops, no, its used on lin 44
[03:55:06] <jmkasunich> I'm gonna start at line 27 and talk this thru
[03:55:13] <jmkasunich> no questions about 28
[03:55:21] <jmkasunich> it is what it says it is
[03:55:59] <jmkasunich> 30 predicts a position at some time in the future which may NOT be an integral number of periods
[03:56:11] <jmkasunich> and in fact may be 1/4 of a period or less
[03:56:11] <SWPadnos> 31
[03:56:18] <jmkasunich> right
[03:56:29] <jmkasunich> 30+31 math is correct
[03:56:33] <SWPadnos> looks it
[03:56:44] <jmkasunich> but we must keep in mind that the result in 31 may be for 0.02 periods from now
[03:57:12] <SWPadnos> it should be for match_time periods from now
[03:57:22] <jmkasunich> match time is in seconds
[03:57:49] <jmkasunich> and if the velocity is nearly matched already, it will be very short
[03:58:49] <jmkasunich> suppose match_time calcs out to 1/3 of a period
[03:59:25] <jmkasunich> if you command a vel = to the desired vel, the high speed ramper will reach the target vel in 1/3 period
[03:59:32] <jmkasunich> and run at the target vel for the remaining 2/3
[04:00:08] <jmkasunich> so est_out is the position after that 1/3 period
[04:00:21] <jmkasunich> and the position after a full period is something differnet
[04:00:54] <jmkasunich> I wonder if lines 29-35 should be inside the "if match_time < dt"
[04:01:01] <jmkasunich> and handled differnetly for the two cases
[04:01:26] <jmkasunich> if you know match_time is < dt, you certainly don't want that -1.5 I don't think
[04:03:51] <SWPadnos> I wou;d think not
[04:04:05] <jmkasunich> not sure you want it in the other case either, but...
[04:04:26] <SWPadnos> well, it workedat some point ...
[04:04:29] <jmkasunich> the problem right now is - it works with EMC (which provides input that meets the constraints)
[04:04:42] <jmkasunich> I don't have test cases for all the other possibilities
[04:05:33] <jmkasunich> I think I will test a little with siggen as input
[04:06:13] <jmkasunich> I can do triangle waves (the turnaround at the peaks violates accel constraint, but not velocity) and square (violates both)
[04:06:41] <jmkasunich> if I don't see anything strange, I'll commit it and ask ed to test
[04:07:08] <jmkasunich> I'm about 99.99% certain this fixes his problem - just not sure if something else is lurking
[04:08:06] <jmkasunich> working on the third pass thru flowsnake, still no bobbles
[04:09:09] <jmkasunich> I wonder how many line segments are in flowsnake
[04:14:27] <jmkasunich> 3rd pass done
[04:19:57] <SWPadnos> didn't ken say it's a 5th-order flowsnake?
[04:20:10] <jmkasunich> I think so
[04:20:19] <jmkasunich> dunno what that means though
[04:21:03] <SWPadnos> order 0 is a triangle I think. then each new order gives 3 segments per original segment, so 3^5 lines, probably
[04:21:24] <SWPadnos> it looks like more than that though - that would be 243 segments
[04:22:07] <jmkasunich> I think there is a parameter for level
[04:22:14] <jmkasunich> I'm not running emc anymore - doing siggen testing
[04:22:20] <SWPadnos> there is in flowsnake.py, but not .ngc
[04:22:26] <SWPadnos> (I think)
[04:24:28] <jmkasunich> triangle testing is sort of OK
[04:24:41] <jmkasunich> there is a bobble as it is recovering from the out-of-limits accel (the peak)
[04:24:44] <jmkasunich> but that was there before
[04:25:04] <SWPadnos> you know, I have a copy of the annotated source up, and I just noticed that several lines in this function are from yabosukz
[04:25:20] <jmkasunich> that is definitely on the other side of the match_time < dt compare
[04:25:21] <jmkasunich> hmm
[04:25:25] <jmkasunich> URL?
[04:25:28] <SWPadnos> http://cvs.linuxcnc.org/cvs/emc2/src/hal/components/stepgen.c?annotate=1.46
[04:26:00] <SWPadnos> including what's line 4 in your pastebin
[04:26:03] <SWPadnos> and a couple of others
[04:26:19] <SWPadnos> so whatever it is, it's not all your fault ;)
[04:26:22] <jmkasunich> heh
[04:28:17] <jmkasunich> the change on that line is reformatting only
[04:28:36] <jmkasunich> took out spaces between the expression and the parenthesis
[04:28:43] <SWPadnos> ok - I haven't pored over the diffs - I just noticed the name
[04:31:38] <jmkasunich> the modified stepgen seems to be handling out-of-limits commands fine
[04:31:50] <SWPadnos> great!
[04:31:59] <SWPadnos> does it stop in the right spot? ;)
[04:32:22] <jmkasunich> I haven't given it a square wave yet, so it hasn't had a chance to stop
[04:32:29] <SWPadnos> ah
[04:32:40] <jmkasunich> got a neat profile when I changed the amplitude of the triangle on the fly tho
[04:32:46] <SWPadnos> heh
[04:34:13] <jmkasunich> http://jmkasunich.dyndns.org/pics/stepgen-dir-toggle-3.png
[04:34:26] <jmkasunich> red is the position command, blue is the feedback
[04:34:37] <jmkasunich> green is addval, proportional to step frequency
[04:34:59] <SWPadnos> ok - nice
[04:36:11] <jmkasunich> squares look good too
[04:36:51] <jmkasunich> no hunting (I was a bit worried about that after reducing the deadband)
[04:37:13] <jmkasunich> there is a constant 20 nano-unit error in the flat part of the square
[04:37:15] <jmkasunich> no overshoot
[04:38:09] <jmkasunich> in fact its fscking beautiful - far better than ever before
[04:38:15] <SWPadnos> what value is position in the flats?
[04:38:20] <jmkasunich> perfectly damped approach to the steady state value
[04:38:24] <jmkasunich> 0,01
[04:38:28] <SWPadnos> hmmm
[04:39:32] <jmkasunich> I'm using eds vel and accel numbers, which aren't high
[04:39:54] <SWPadnos> ok. I guess it makes sense that the check for being within one count make no sense when you have fractions
[04:40:01] <jmkasunich> so at 1Hz it is limited to about 0.05 inches
[04:47:17] <jmkasunich> more than 243 lines I think
[04:47:58] <SWPadnos> did you load flowsnake.py or .ngc?
[04:48:10] <jmkasunich> ngc
[04:48:28] <SWPadnos> it says level 5
[04:48:36] <jmkasunich> based on velocity scope trace, I think its doing about 8 or so segments per second
[04:48:50] <jmkasunich> maybe I'm seeing blending tho
[04:49:17] <jmkasunich> maybe 5 per second
[04:49:24] <SWPadnos> oops - it's 4^5 lines, not 3^5
[04:49:27] <jmkasunich> (looking at the axis screen
[04:49:41] <SWPadnos> first third, 2 sides of a triangle, then the last third
[04:49:49] <SWPadnos> so it's 1024 lines
[04:50:18] <jmkasunich> thats about right
[04:51:45] <SWPadnos> and it may be 3072, since the "original" triangle has 3 calls to the function
[04:51:59] <SWPadnos> (or it's 768, 3 * 4^4)
[04:52:59] <jmkasunich> dang - I'd like to commit this tonight so ed can test as soon as possible
[04:53:06] <jmkasunich> but it really need man page updates
[04:54:43] <SWPadnos> isn't the interface (HAL pin meanings) the same as before?
[04:55:07] <jmkasunich> yeah, except the timing params (steplen, dirhold, etc) are in nanoseconds now
[04:55:27] <SWPadnos> oh. I thought those were still in steps externally
[04:55:36] <jmkasunich> you mean periods?
[04:56:07] <jmkasunich> it would have been more work - I'd need extra struct members to hold the integer period, and the nanoseconds that the high speed code now expects
[04:57:25] <SWPadnos> err - yeah, periods
[04:57:46] <SWPadnos> ok. I thought that was the plan, at least for v2_1_branch
[04:58:02] <jmkasunich> this commit is going into trunk
[04:58:14] <SWPadnos> right
[04:58:28] <jmkasunich> dunno if we'll backport or not - if we do, I'll kludge in the integer period parameters
[04:58:31] <SWPadnos> anyway - I don't think Ed would be messing with it tonight ;)
[04:58:49] <jmkasunich> I'm gonna commit tonight, because he might mess with it while I'm at work
[04:59:20] <SWPadnos> cool then
[05:00:22] <jmkasunich> for 2.2 I think I want to eliminate freqgen
[05:00:48] <jmkasunich> loadrt stepgen step_type=0,0,0,2 ctrl_type=p,p,p,v
[05:01:01] <jmkasunich> p = position mode, v = velocity mode (aka freqgen)
[05:01:13] <jmkasunich> 90% of the code (if not more) in those two is the same (or should be)
[05:01:46] <jmkasunich> ctrl_type will default to all P, so if you use stepgen the old way, you'll get what you expect
[05:03:10] <SWPadnos> is depmod correct for HAL modules?
[05:03:29] <SWPadnos> (ie, if I modprobe stepgen, will rtai be loaded)
[05:03:59] <SWPadnos> if so, then the core could be made into one module, which both freqgen and stepgen depend on
[05:04:26] <jmkasunich> no, loadrt uses module_helper (setuid program) which invokes insmod
[05:04:40] <jmkasunich> our modules aren't in the right place for modprobe (especially if you are running-in-place)
[05:04:54] <SWPadnos> ok - then that's out ;)
[05:05:09] <jmkasunich> that would just make things harder anyway
[05:05:47] <jmkasunich> think about the 5i20 stepgens... I'd like to make the "pretuned loop" thing available to them too - not force people to use PID
[05:05:53] <jmkasunich> I don't want two drivers
[05:06:15] <jmkasunich> ctrl_type lets people chose what they want
[05:07:15] <SWPadnos> then you need pins between update_freq and make_pulses ...
[05:07:22] <SWPadnos> (to abvoid duplicating code)
[05:08:10] <jmkasunich> you mean so the stepgen update can be used with 5i20 etc?
[05:08:42] <jmkasunich> I thought about "stepper_pos_loop" as a component, and changing stepgen to accept frequency input
[05:09:01] <jmkasunich> but decided that would be more disruptive - everybody and his brother uses stepgen, few use freqgen
[05:09:27] <SWPadnos> right - makes the connections the PITA instead of PID
[05:09:49] <jmkasunich> the pretuned loop think is only the 50 or so lines that were in that pastebin, it won't be that bad to have it in the 5i20 driver
[05:10:03] <jmkasunich> s/think/thing
[05:10:16] <SWPadnos> nope
[05:10:31] <jmkasunich> well, after 1 again
[05:10:33] <SWPadnos> I wonder if it'll work the same? (should, but then again theory and reality ...)
[05:10:54] <jmkasunich> thats another reason to have it in the driver - it can be tweaked if needed
[05:11:08] <jmkasunich> I'll find out - I hope to get back on the 5i20 this week
[05:11:10] <jmkasunich> goodnight
[05:11:43] <jmkasunich> oops, I should restart the compile farm
[05:13:15] <SWPadnos> good night
[05:17:31] <jmkasunich> cradek: what are you still doing up?
[05:19:01] <cradek> fixing a silly bug jepler found right after I made the release
[05:19:23] <jmkasunich> that sucks
[05:19:27] <cradek> yes
[05:19:37] <jmkasunich> how bad of a bug?
[05:19:52] <cradek> wrong path when using tool comp with a tool either not loaded, or zero radius
[05:20:10] <jmkasunich> worse than before this last round of fixes?
[05:20:24] <cradek> win some, lose some
[05:20:31] <jmkasunich> I thought ray did zero dia tools for testing things - did it work before?
[05:20:34] <cradek> this particular bug is new, but several others are fixed
[05:20:36] <cradek> yes
[05:20:53] <jmkasunich> bummer
[05:21:06] <cradek> I obviously need to rebuild, but I don't know if I want to call this 2.1.2 or 2.1.3 or some other number
[05:21:23] <cradek> depends if anyone downloaded it, and I don't have that information
[05:21:28] <jmkasunich> darn - the bdi 4.50 VM didn't deal with the time change
[05:21:29] <SWPadnos> I'd call it 2.1.3, in case someone has 2.1.2 installed ...
[05:21:37] <jmkasunich> I wonder if that will cause cvs grief
[05:21:44] <cradek> jmkasunich: probably so
[05:21:46] <SWPadnos> my prediction: yes
[05:21:54] <jmkasunich> shit
[05:22:01] <cradek> * cradek flips GWB the bird
[05:22:06] <SWPadnos> again?
[05:22:23] <jmkasunich> I like my sunshine, so I'm not complaining
[05:22:37] <cradek> yeah, and the flowers grow better with more afternoon light
[05:23:06] <jmkasunich> the flowers don't have day jobs, they don't care
[05:23:07] <cradek> while that simple change doesn't cause much work for politicians, it was a nightmare for some of us
[05:23:18] <jmkasunich> sunshine in the morning is totally wasted IMO
[05:23:23] <SWPadnos> I'm still waiting for my watch to update
[05:23:40] <cradek> jmkasunich: then go to work earlier?
[05:23:52] <jmkasunich> yeah, right
[05:24:08] <jmkasunich> stay up till all hours of the night and then get up early ?!?
[05:24:10] <SWPadnos> how about this: change to 1/2 hour in between, and never change it again
[05:24:30] <SWPadnos> or just don't bother with it anyway - we have electric lights now
[05:24:35] <jmkasunich> what time does CVS use anyway - after all, users and the server aren't in the same timezone
[05:24:41] <cradek> utc
[05:24:50] <jmkasunich> well then this is no problem
[05:24:51] <cradek> but make uses localtime
[05:25:09] <jmkasunich> hmm
[05:25:26] <jmkasunich> so when you do a checkout, the files are tagged with what time?
[05:25:27] <cradek> maybe it will be fine
[05:25:28] <SWPadnos> it looks like the breezy install also wasn't updated ...
[05:26:19] <jmkasunich> I ran nptdate on them after resuming them (they don't get the time right after a resume anyway)
[05:26:31] <jmkasunich> but they seem right, both local and real time
[05:26:53] <jmkasunich> (the farm scripts record all times in utc, and they are correct)
[05:26:58] <SWPadnos> ok. maybe it is around 5:30 UTC right now
[05:27:08] <jmkasunich> the bdi has UTC correct, but local is off
[05:27:37] <jmkasunich> if a checkout or a make happened during the change, that would be very ugly I bet
[05:27:55] <jmkasunich> but if make uses local time, any make happening during any change would be borked
[05:29:10] <jmkasunich> file timestamps aren't really in local time are they? aren't they seconds since some time in 1970?
[05:29:11] <SWPadnos> cvs has to convert local time to UTC to check the status of files on the server, so if localtime calcs are wrong, there's a problem
[05:30:08] <SWPadnos> I think Linux uses UTC timestamps and converts at the filesystem level (or higher), but I'm not positive of that
[05:30:10] <jmkasunich> all timestamps should be in seconds since 1970 UTC
[05:30:47] <jmkasunich> if the timestamps are in UTC then CVS doesn' t need to convert
[05:30:54] <jmkasunich> it can just compare the 32 bit numbers
[05:31:01] <SWPadnos> yes, but I'm not sure where the conversion from what's on disk to what you want to see happens
[05:31:09] <SWPadnos> true
[05:31:30] <SWPadnos> but not all OSes use UTC timestamps. I'm not sure how cvs deals with that
[05:31:45] <SWPadnos> it may be just in the client for those OSes
[05:32:54] <jmkasunich> oops, somebody broke it
[05:33:14] <SWPadnos> stepgen - looks like you ;)
[05:33:26] <jmkasunich> crap
[05:33:56] <SWPadnos> the log for breezy looks all screwed up - I have euro signs and stuff in the log
[05:33:59] <jmkasunich> wtf? error: syntax error before ‘u32’
[05:34:27] <jmkasunich> I can see how that would not compile
[05:34:40] <cradek> <troll> did Kate find a new way to crap up your files? </troll>
[05:34:58] <SWPadnos> "view Differences"
[05:37:05] <jmkasunich> no, its not kate
[05:37:20] <jmkasunich> the breezy RT VM built it fine
[05:37:28] <jmkasunich> as did the dapper farm slot
[05:37:43] <jmkasunich> the problem must be in the checkout on the non-rt breezy box
[05:38:09] <jmkasunich> its doing another build at the moment
[05:39:14] <jmkasunich> gawd, when even the shell is slow, you know you got too much going on
[05:41:33] <cradek> I think those are just ``smart'' quotes in the compile output
[05:41:48] <cradek> (and the error is real)
[05:42:07] <cradek> set LANG=C in your script to fix those stupid quotes
[05:43:49] <jmkasunich> the greek is gone when I view it on the VM
[05:44:06] <cradek> you probably mean hal_u32_t, not u32
[05:44:07] <jmkasunich> the error is (I think) that sim doesn't know about u32
[05:44:11] <cradek> right
[05:44:28] <jmkasunich> well, they're not HAL objects, so they really don't need hal types
[05:44:40] <jmkasunich> just a good old u32 would do fine
[05:44:55] <cradek> ok, I was just looking above a few lines to the ones that worked
[05:45:47] <jmkasunich> its some stupid thing like "u32 in kernel space and _u32 in user space"
[05:45:57] <jmkasunich> pain in the ass, and I thought it worked OK
[05:46:04] <jmkasunich> I could swear other stuff uses u32
[05:47:05] <jmkasunich> * jmkasunich growls at sim
[05:49:52] <jmkasunich> damn... looks like the only u32 usage is stepgen and the new 5i20 driver
[05:50:00] <jmkasunich> drivers don't get built for sim
[05:50:16] <jmkasunich> I guess they're gonna be hal types for now
[05:50:37] <jmkasunich> we gotta fix that - typedefs in rtapi.h or something
[05:57:31] <jmkasunich> goodnight again
[06:00:01] <petev> cradek, u still there?
[11:57:24] <rayh> 6 meg upgrade -- 1h6m26s and I remember putting emc on a floppy once.
[11:57:53] <rayh> I'd probably better put a grin after that, 'eh.
[12:10:07] <rayh> Got the housing settled out skunkworks?
[12:10:57] <alex_joni> morning ray
[12:11:01] <alex_joni> what'cha doing up so early?
[12:11:11] <rayh> Hi Alex.
[12:11:15] <skunkworks> moved a bunch and painted. getting there. we close on our house on april 3 so that gives us a bit of time to move.
[12:11:29] <skunkworks> morning
[12:11:33] <alex_joni> skunkworks: cool stuff
[12:11:42] <alex_joni> rayh: or did you change times last night?
[12:11:43] <skunkworks> yes - very excited.
[12:11:53] <alex_joni> skunkworks: hope that lasts :P
[12:11:54] <rayh> Yes
[12:12:13] <rayh> I really dislike doing that.
[12:12:13] <skunkworks> * skunkworks needs to remember to take some pictures
[12:12:14] <alex_joni> rayh: did you have the same internet connection back then when you put emc on a floppy?
[12:12:20] <alex_joni> * alex_joni grins :D
[12:12:49] <rayh> Yes
[12:13:03] <alex_joni> well.. some things evolve (or should at least)
[12:13:07] <rayh> There is not a lot of variety with a local phone call.
[12:13:20] <alex_joni> yeah, I can understand that :(
[12:13:40] <alex_joni> I have a great plan on my data-cell
[12:13:44] <rayh> You bet. I was thinking about that disk. No graphical interface.
[12:13:59] <rayh> One rt module
[12:14:01] <alex_joni> 100 hours online, 2.4 MBps for 30$
[12:14:14] <rayh> Wow.
[12:14:14] <alex_joni> rayh: yeah, but that had the rest of linux too.. right?
[12:14:17] <alex_joni> not just emc2
[12:14:23] <rayh> I don't get cell here.
[12:14:33] <alex_joni> satellite?
[12:14:43] <alex_joni> hope you're not that deep underground :D
[12:15:02] <rayh> could but it's bad for vnc
[12:15:04] <skunkworks> satellite is expensive
[12:15:16] <skunkworks> and bad for vnc
[12:15:19] <skunkworks> ;)
[12:15:19] <alex_joni> skunkworks: 40-50EUR / month here (one way)
[12:15:28] <alex_joni> the laggy one..
[12:15:40] <skunkworks> it is like 80us here for 2way.
[12:15:43] <alex_joni> upload through your current dialup, download from above
[12:15:44] <rayh> I'm hoping fast-air gets a tower this summer that I can reach.
[12:17:37] <rayh> I Don't remember how much of linux and rt I got on that same disk.
[12:17:48] <rayh> I don't think it was bootable but that was a long time ago.
[12:18:31] <alex_joni> rayh: not that important :-)
[12:18:43] <alex_joni> although it's probably a nice trip on memoruy lane
[12:18:47] <rayh> I don't think we can go back to that sized install.
[12:19:03] <alex_joni> rayh: even the kernel is close to that these days
[12:19:24] <alex_joni> we can probably make one custom install that small.. (without docs & all)
[12:19:30] <rayh> Matt and I were commenting the other day about how there were less than a half mill web folk when we got on there.
[12:19:58] <rayh> Matt still has a complete printed web directory from those days.
[12:20:13] <alex_joni> :-)
[12:29:42] <alex_joni> so.. what time is it over there?
[12:30:48] <rayh> 7:30
[12:31:28] <rayh> Question about export DESTDIR. Does it gather up all the installed files and move them?
[12:31:45] <alex_joni> rayh: DESTDIR is just a prefix to the path where files get installed
[12:32:08] <alex_joni> so instead installing rtapi conf to /etc/emc2/rtapi.conf it will be /tmp/emc/etc/emc2/rtapi.conf
[12:32:13] <rayh> Okay. So it doesn't drag stuff around.
[12:32:30] <alex_joni> what do you mean by drag stuff around?
[12:33:45] <rayh> Will the locations of stuff like sample configs and all be correct within the /tmp/xxx tree.
[12:34:08] <alex_joni> yes
[12:34:23] <alex_joni> everything will be installed in there, and it won't run :)
[12:34:26] <rayh> I was hoping that it would move stuff from etc, usr and such.
[12:34:43] <alex_joni> no, it's doing another install ..
[12:34:46] <rayh> It won't run?
[12:34:55] <alex_joni> nope, because the paths are not right
[12:35:02] <rayh> Okay.
[12:35:18] <alex_joni> this 'hackery' as it might seem is used by package building processes
[12:36:00] <alex_joni> for example during building a deb, all stuff gets installed to a temp folder, than that structure gets packaged, and lateron when the user installs the package, everything gets copied to the proper place under /
[12:36:33] <rayh> I see.
[12:37:28] <alex_joni> same for rpm's
[12:37:33] <rayh> I'm not a lover of the spread out install
[12:38:24] <alex_joni> rayh: I understand, but it follows the LFS
[12:38:58] <rayh> Right. I never was much on one to follow authority.
[12:39:06] <rayh> of one
[12:39:06] <alex_joni> and for keeping things a bit less spread out you can use './configure --with-prefix=/usr/local' or './configure --with-prefix=/opt/emc2'
[12:39:29] <alex_joni> but those have the disadvantage that you need to mess with PATHs to make all things work lateron
[12:39:32] <rayh> really
[12:39:53] <alex_joni> the prefix /usr/local would be instead of the default prefix /usr
[12:39:58] <rayh> You have to mess with path with --enable-run-in-place
[12:39:59] <alex_joni> so this doesn't affect /etc stuff
[12:40:08] <alex_joni> rayh: yes and no :)
[12:40:21] <alex_joni> you can use '. scripts/emc-environment'
[12:40:26] <alex_joni> and then everything works
[12:40:42] <alex_joni> man pages, bins, libs
[12:41:00] <rayh> so run scripts/emc-env and it fixes all the locations.
[12:41:34] <alex_joni> use . scripts/emc-environment
[12:41:41] <alex_joni> '.' is a special instruction for bash
[12:41:48] <alex_joni> to source the following file
[12:42:20] <alex_joni> notice I didn't write './scripts/emc-environment' but '. scripts/emc-environment'
[12:42:25] <SWPadnos> it won't change the location of the current install ;)
[12:42:40] <SWPadnos> oh - I hould scroll down before responding ;)
[12:42:42] <SWPadnos> should
[12:42:51] <rayh> ...context of your shell...
[12:42:55] <SWPadnos> I should get coffee before scrolling down. brb
[12:43:11] <alex_joni> # Execute this file in the context of your shell, such as with
[12:43:11] <alex_joni> # . @EMC2_HOME@/scripts/emc-environment
[12:43:11] <alex_joni> # and your shell environment will be properly configured to run commands like
[12:43:11] <alex_joni> # comp, halcmd, halrun, iosh, and python with the emc modules available.
[12:43:22] <alex_joni> rayh: exactly :)
[12:43:30] <rayh> oh dot scripts
[12:43:47] <rayh> but only for that run of the shell.
[12:43:51] <SWPadnos> you can also use the command 'source' - I think it's equivalent to '.'
[12:44:10] <SWPadnos> and may make more sense since it doesn't look like someone forgot a '/' after the '.'
[12:44:16] <alex_joni> rayh: yup, unless you put that in .bash_rc :)
[12:44:20] <alex_joni> then it will always be true
[12:44:35] <alex_joni> ~/.bash_rc I mean
[12:44:57] <SWPadnos> or /etc/bash_profile, for everyone
[12:45:07] <alex_joni> SWPadnos: that doesn't make sense
[12:45:08] <rayh> okay. i can see that
[12:45:15] <alex_joni> SWPadnos: this is for RIP only
[12:45:33] <alex_joni> very unlikely that someone has the RIP in a common location for all users :)
[12:45:35] <SWPadnos> well, I didn't say it made any sense, just that you can do it ;)
[12:45:43] <alex_joni> and the setuid won't work ..
[12:46:22] <alex_joni> * alex_joni is happy that 2.1.2 is out
[12:47:32] <SWPadnos> or is it 2.1.3 now?
[12:47:40] <rayh> Several nice fixes in there.
[12:47:54] <SWPadnos> do you see 2.1.2 in the repo or 2.1.3?
[12:48:08] <alex_joni> 2.1.2
[12:48:11] <SWPadnos> hmmm
[12:48:17] <alex_joni> pre-2.1.3
[12:48:20] <rayh> that is what I see also
[12:48:36] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/VERSION?graph=1
[12:48:38] <SWPadnos> Chris made a change late last night - I wasn't sure if he ended up making a new point rev or not
[12:48:40] <rayh> but I'm not done downloading yet.
[12:49:09] <SWPadnos> ok. test cutter comp with a zero-radius or nonexistent tool
[12:49:16] <SWPadnos> I don't know what the problem looks like though
[12:49:29] <alex_joni> SWPadnos: yeah saw that.. probably missed this release
[12:49:43] <SWPadnos> I know it missed 2.1.2, he was going to change the packages
[12:49:57] <alex_joni> SWPadnos: as long as it's only bugs found by us, I'm not _that_ worried
[12:50:05] <rayh> I ran and tested cutter comp with 0 a lot the other day.
[12:50:10] <rayh> What happened.
[12:50:19] <SWPadnos> I think jmk and I both suggested bumping to 2.1.3, since we don't know if anynone installed 2.1.2
[12:50:38] <SWPadnos> rayh, I'm not exactly sure what the effect was, but it was different from before (for some value of before)
[12:50:47] <alex_joni> rayh: might be that one of the latest fixes broke part of that, but I'll let cradek tell you specifics (I only read it in the irc log this morning)
[12:50:59] <alex_joni> SWPadnos: and some value of different
[12:51:05] <SWPadnos> heh
[12:51:06] <alex_joni> SWPadnos: and some value of effect
[12:51:13] <alex_joni> :-P
[12:51:26] <rayh> okay. I'll test with my new install when it gets here.
[12:51:43] <SWPadnos> ok. it would help to know what the problem was, but I can't help you there
[12:52:24] <rayh> Neat article in dr dobbs p10, "Open-Source Globalization."
[12:52:35] <alex_joni> rayh: did you have any other issues with mini on TRUNK?
[12:52:39] <rayh> Didn't find it on their web site though.
[12:52:45] <SWPadnos> hmmm. I wonder if I let my subscription lapse
[12:53:10] <alex_joni> globalization? wonder who got that strange idea...
[12:53:13] <rayh> No the one you fixed seemed to make it work.
[12:53:56] <rayh> I do like the idea of changing the menu in tkemc to utilities and move halshow in there as well.
[12:54:13] <alex_joni> ok, I can do that much of tcl code :D
[12:54:26] <rayh> Then if we added the same menu in the others it would allow us to point users to those things more easily.
[12:54:32] <SWPadnos> oooh oooh - I can change the menu name!!
[12:54:41] <SWPadnos> (for some value of "can")
[12:54:47] <rayh> There you go.
[12:56:25] <alex_joni> * alex_joni grabs some cerials
[12:56:38] <SWPadnos> carials?
[12:56:42] <SWPadnos> cerials?
[12:57:02] <alex_joni> Cerials And Milk
[12:57:15] <SWPadnos> oh - cereal
[12:57:31] <alex_joni> sorry.. :)
[12:57:32] <SWPadnos> maybe I should do that too
[12:57:36] <SWPadnos> np :)
[12:57:40] <alex_joni> I had saussages for breakfast though
[12:57:43] <alex_joni> :-P
[12:57:50] <SWPadnos> prick
[12:58:07] <SWPadnos> I've had 4 sips of coffee so far
[12:58:11] <SWPadnos> maybe 5
[12:58:17] <alex_joni> http://www.oetker.de/wga/oetker/html/frameset/admn-4gznj4.de.html?key=admn-4gznj4
[12:58:46] <alex_joni> * alex_joni hates frames
[12:59:14] <SWPadnos> oooh - chocolate and ?? (mint?)
[12:59:28] <SWPadnos> no - nuts
[12:59:42] <alex_joni> banana :)
[12:59:51] <SWPadnos> damn. I woiuld have gotten there eventually
[12:59:56] <SWPadnos> (for soem value of eventually)
[13:00:38] <alex_joni> really yummy
[13:00:43] <rayh> * rayh adds a util menu to mini
[13:01:36] <SWPadnos> hmmm. aren't ballscrews non-backlash by design?
[13:01:51] <SWPadnos> and only get backlash when they're worn (or the nuts/balls are)
[13:01:53] <alex_joni> SWPadnos: should be
[13:02:55] <SWPadnos> so this comment is proabbly wrong: "The .002-.005 of a ballscrew withOUT an anti-backlash compensated nut is something that many folks can comment upon. It is VERY normal."
[13:03:13] <SWPadnos> ie, "it's normal for a ballscrew to have 0.001 to 0.005 backlash ..."
[13:03:20] <SWPadnos> err - 0.002
[13:03:36] <alex_joni> maybe I only saw compensated nuts?
[13:03:56] <SWPadnos> no, I think you saw reasonably good ballscrews instead of crap ones
[13:04:39] <alex_joni> hmm.. this is interesting
[13:04:55] <alex_joni> err.. let's move this to #emc
[13:06:22] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[15:58:09] <cradek> *** /usr/local/src/emc2.trunk/tests/counter-encoder.0: FAIL: test run exited with 1
[16:42:27] <SWPadnos> hmmm - that manual thing reminds me - are we keeping old revisions of the documentation on the website?
[16:42:36] <SWPadnos> if not, we should be
[16:45:09] <jepler> for instance, the manual that went out with emc 2.1.1? No, those aren't kept anywhere but in the .debs
[16:45:21] <SWPadnos> ok
[16:45:56] <jepler> /docs/2.1/ always holds the latest docs built from the v2_1_branch, and /docs/devel/ always holds the latest docs built from the TRUNK
[16:46:23] <SWPadnos> ok. I think it would be good to have an archive of those, though I'm not sure what the best way of doing that is
[16:46:37] <SWPadnos> not for TRUNK, that's too ephemeral
[16:51:23] <cradek> I'm not sure it's obvious, but remember you could rebuild any version's manual from cvs - they are tagged with RELEASE_ tags just like the source
[16:52:04] <SWPadnos> yes. you or I could, but for a quick look at the same docs soem user is using, that's a pain
[16:52:25] <cradek> ok, I didn't know your goal
[16:53:28] <SWPadnos> the goal was to have an archival section of the doc library, not just a current reference section
[16:53:39] <cradek> I understand
[16:54:02] <SWPadnos> on one level, it's just storage, and there's plenty of that available. on another lvel, it's joomla/website maintenance ...
[17:15:14] <christel> [Global Notice] Hi all. Services are going down for a quick re-start, hold on to your ops and we'll see you on the flipside. Thank you for flying freenode and have a great day!
[18:18:52] <cradek> hmm, I can't step over a G4 or to the end of the program (M2)
[18:21:08] <rayh> step?
[18:21:13] <cradek> yeah
[18:21:38] <rayh> Displaying the text or what?
[18:21:57] <rayh> execute one step at a time.
[18:22:31] <cradek> I don't understand
[18:22:58] <cradek> to reproduce, put a G4 in the middle of a program, and step through the program
[18:24:04] <rayh> Got it. The g4 waits after the step time px
[18:24:27] <rayh> It does execute the line after the time has passed.
[18:25:04] <rayh> That is with today's upgrade.
[18:26:07] <cradek> not for me - I have to hit resume to get it to continue
[18:27:01] <jepler> me too
[18:27:14] <jepler> I notice that in AXIS, no line is shown as "executing"
[18:27:41] <cradek> I think only motion-causing lines can ever be shown
[18:27:46] <rayh> IMO we ignore paul's latest post completely.
[18:28:06] <cradek> yeah, he's just being silly
[18:28:17] <skunkworks> oops - how do I unsend an email? :) just kidding.
[18:28:20] <rayh> Active line in tcl only stops on motion that takes time.
[18:28:27] <cradek> wonder if the -lGL thing is a bug, or if he's just not installed the right packages
[18:28:38] <rayh> Isn't there an unsend button.
[18:28:48] <cradek> sometimes I wish there was!
[18:29:20] <rayh> me also more than once.
[18:29:49] <jepler> emc.so should be linking libGL; it does contain opengl calls
[18:31:43] <jepler> (this is the Python extension module you get when you 'import emc'; the opengl calls are related to the position logging for the AXIS backplot)
[18:32:00] <cradek> ok, he must be making a fuss (and not installing opengl support) just for fun then
[18:33:24] <jepler> incidentally, when I remove libgl1-mesa-dev and reconfigure TRUNK I get
[18:33:25] <jepler> configure: error: Required OpenGL header missing. Install it, or specify --disable-python to skip the parts of emc2 that depend on Python
[18:34:05] <cradek> good to know
[18:34:27] <jepler> (I made configure fail a lot more readily for 2.2 than for previous versions, because there were a fair number of reports about failed builds when configure "succeeded")
[18:34:38] <cradek> great
[18:34:43] <SWPadnos> damn. I wanted to flame a little and tell him I'm going to stop hosting his distro for him
[18:34:52] <jepler> though his error indicates that he had the header but not the shared library; I don't know what combination of screwed up options he used
[18:35:23] <cradek> hard to say, without a real bug report
[18:35:26] <jepler> of course, --disable-python is not well tested. He is bound to find problems there if he looks.
[18:35:42] <SWPadnos> rayh, skunkworks there is an unsend feature in GroupWise, but that's not important right now :)
[18:40:30] <rayh> go for it -- SWPadnos>damn. I wanted to flame a little and tell him I'm going to stop hosting his distro for him
[18:40:39] <SWPadnos> heh
[18:42:18] <petev> SWPandos, u get a chance to look at that tarball?
[18:42:19] <jepler> remember to tell him it's me, not jmk, who wrote the current brittle build system
[18:42:59] <SWPadnos> jepler, will do ;)
[18:43:21] <SWPadnos> petev, not yet, but I may have a solution (unless you've already thought of it and it doesn't work ;) )
[18:43:46] <petev> I just put in some inlines to call the base class, but I'm not really happy with having to do that
[18:43:51] <rayh> brittle I'm pretty happy with it and I compile quite often.
[18:44:00] <petev> so if you come up with something better, I'm all for it
[18:44:16] <SWPadnos> I think that was it :)
[18:44:20] <petev> oh
[18:44:35] <SWPadnos> did you try virtual?
[18:44:46] <SWPadnos> nevermind
[18:44:51] <petev> how would that help in this case?
[18:45:10] <petev> the problem is the way overloading works in C++
[18:45:24] <SWPadnos> yep
[18:45:37] <petev> if you overload in a derived class, it blocks visibility of all base class methods of the same name
[18:45:44] <SWPadnos> yep
[18:46:06] <SWPadnos> ok - I should look at the code before commenting more - gimme a minute
[18:46:11] <petev> ok
[18:47:08] <jepler> "Trash Manager" -- item in the joomla administrative interface
[18:47:27] <SWPLinux> heh
[18:47:32] <SWPLinux> that's for the pr0n section
[18:48:02] <petev> I must have gotten rid of 300+ lines in loadAxis, and it's still too big
[18:48:11] <petev> we need a better way to send axis params to the hal
[18:48:24] <SWPLinux> that code isn't what sends things to HAL
[18:48:26] <SWPLinux> (I think)
[18:48:27] <petev> a function call and error checking per param is crazy
[18:48:53] <petev> hmm, looked like they were calls to motion to send to HAL
[18:48:56] <petev> maybe I mis understood
[18:49:13] <rayh> does crazy = inefficient?
[18:49:22] <rayh> or more?
[18:49:26] <petev> rayh, very from a coding standpoint
[18:49:34] <SWPLinux> unmaintainable, unreadable, inefficient
[18:49:37] <petev> yes
[18:50:18] <rayh> Okay. Was trying to unload the term just a bit.
[18:50:29] <petev> rayh, look at the comments someone put at the top of motion/command.c
[18:55:36] <petev> what are the conventions for module names? I see things like emcinifile, emc_ini_file, and emcIniFile
[18:55:47] <petev> most are of the first variety, which is least readable
[18:57:18] <rayh> cradek: stepping through a block containing a g4p5 works here with mini. I do have to wait the 5 seconds.
[18:58:11] <cradek> rayh: strange! what version?
[18:58:48] <rayh> today's update 2.1.2 i think
[18:59:47] <cradek> ok I will test some more - that really changes the diagnosis
[19:22:17] <SWPadnos> cradek, did you replace the 2.1.2 packages or make a 2.1.3?
[19:22:35] <cradek> neither yet
[19:22:42] <SWPadnos> ok :)
[19:23:01] <cradek> I want to wait and hear about ed and jmk's stepgen results
[19:23:09] <SWPadnos> ah - good idea
[19:23:19] <SWPadnos> but that's in HEAD, and represents an ini parameter unit change
[19:24:55] <cradek> he could hack it
[19:25:13] <cradek> I don't have an opinion, but I know I should wait to hear about it
[19:28:14] <SWPadnos> heh
[19:29:35] <SWPadnos> cradek, what do you suppose the difference is between these URLs (other than the location of the file):
[19:29:50] <SWPadnos> http:/www.linuxcnc.org/emc2/dists/dapper/emc2.1/binary-i386/emc2_2.1.2_i386.deb
[19:30:03] <SWPadnos> /emc2/dists/dapper/emc2.1/binary-i386/emc2_2.1.2_i386.deb
[19:30:45] <jepler> SWPadnos: should be "
http://..." for the first one?
[19:30:59] <SWPadnos> well, this is in the access logs for yesterday
[19:31:10] <cradek> I don't follow
[19:31:30] <SWPadnos> there are two entries containing emc2_2.1.2 from yesterday
[19:31:39] <cradek> they look the same except they are both incomplete URLs
[19:31:47] <SWPadnos> the first one I posted was accessed 9 times yesterday, the second only once
[19:32:15] <SWPadnos> sure - I'm sure they're relative or some short form for the log
[19:32:45] <jepler> SWPadnos: what was the referrer for http:/www.linuxcnc.org/... ?
[19:32:52] <jepler> was it really only one slash after http:?
[19:33:07] <SWPadnos> yes, it's one slash. the referrer is in another file
[19:33:19] <SWPadnos> I think these are analog logs, not direct from apache
[19:34:20] <SWPadnos> 92 .deb requests overall (yesterday)
[19:34:31] <jepler> if the referer to "http:/www.linuxcnc.org/..." is our own site we should fix the URL
[19:37:51] <SWPadnos> there are 27 lines that start "http:/www.linuxcnc.org" here:
http://pastebin.ca/392256
[19:38:33] <SWPadnos> I'm not positive what the unmbers are - they may be requests and failures or requests and successes ??
[19:38:34] <SWPadnos> numbers
[19:45:48] <jepler> SWPadnos: can you access the raw log?
[19:46:23] <SWPadnos> no, I don't think so
[19:46:33] <SWPadnos> I may be able to get support to send me a filtered copy
[19:56:30] <SWPadnos> well, if that URL exists on linuxcnc.org (not in the joomla sql database), I'll find it - I've got grep looking for it
[19:56:57] <SWPadnos> (looking for anything beginning with "http:/www")
[19:57:01] <SWPadnos> er - containing
[19:58:03] <jepler> I looked in both of the install.sh scripts and their URLs look right --
http://
[19:58:14] <jepler> those certainly look like files automatically requested by apt-get
[19:58:24] <jepler> I mean, who else is going to download Release.gpg?
[19:58:35] <SWPadnos> yeah
[19:59:09] <SWPadnos> I'll check the log dir once this grep is done to see how often that occurs
[19:59:37] <jepler> how often is this log file updated?
[19:59:43] <jepler> are there any entries that say "
http://..."?
[19:59:45] <SWPadnos> daily
[20:00:04] <SWPadnos> no, only the form /path/to/file and the malformed ones
[20:00:35] <SWPadnos> heh - found a couple of typos in the IRC logs
[20:02:43] <jepler> tomorrow, look if this URL has shown up in the log: swpadnos/I/am/looking/at/you
[20:03:01] <SWPadnos> ok
[20:03:11] <SWPadnos> with a leading / ?
[20:03:20] <jepler> GET
http://www.linuxcnc.org/swpadnos/I/am/looking/at/you
[20:03:25] <SWPadnos> ok
[20:03:50] <jepler> I expect it to show up as 'http:/www...' if the log analysis software is doing something like trying to "canonicalize" URLs by removing repeated slashes
[20:04:18] <SWPadnos> hmmm
[20:04:42] <jepler> of course the log may not show you URLs that were 404'd
[20:05:00] <SWPadnos> there are only those 27 items with the bad addrs, out of a 150k or so (I think) file
[20:05:12] <SWPadnos> kbytes, not krequests
[20:05:56] <SWPadnos> ok. it's not in plaintext anywhere except in the logs (including today's :) )
[20:06:06] <SWPadnos> IRC logs, that is
[20:10:15] <SWPadnos> hmmm. there are a lot of them. the earliest is from 4/25/06, and there are 211 days since then in which that kind of request was received
[20:22:25] <rayh> cradek: I tested a bit more here with interpreter in step mode and it does both pause and m2 correctly.
[20:25:06] <rayh> I don't see the activeline move ahead until the dwell has timed out.
[20:25:59] <rayh> Activeline never gets to the m2 line but the interpreter does go from running to idle.
[20:26:16] <alex_joni> http://www.peters-cnc-ecke.de/forumupload/uploadFiles/5829_115672635306_Tastatur40.png
[20:28:28] <SWPadnos> what's the one next to hand for (looks like a lowercase Rho or something)
[20:30:53] <jepler> blower?
[20:31:54] <SWPadnos> coolant - could be ??
[20:32:13] <alex_joni> SWPadnos: no clue :)
[20:32:21] <alex_joni> but it's nice for a pendant
[20:32:32] <SWPadnos> yeah - it looks pretty good
[20:39:22] <SWPadnos> question regarding the nasty awful make "bug" Paul pointed out (missing -lGL): what is the actual problem there?
[20:39:42] <SWPadnos> is it that make misses the nonexistence of openGL
[20:41:17] <alex_joni> SWPadnos: it's probably a borken system where configure finds the proper header, but the linking can't find the library
[20:41:54] <cradek> hard to say - we don't even know what he's trying to build
[20:42:03] <SWPadnos> emc.so ??
[20:42:08] <cradek> what tree
[20:42:09] <SWPadnos> "python module emc.so"
[20:42:12] <SWPadnos> damfino
[20:42:23] <SWPadnos> I see two other reports of this problem ion the user/deve lists
[20:42:30] <cradek> jepler said he improved some configure tests on trunk
[20:42:45] <SWPadnos> in both cases, the response was that the proper libs aren't there or are improperly installed
[20:42:57] <SWPadnos> JonE had the problem last November
[20:43:06] <SWPadnos> someone else last June maybe
[20:43:20] <SWPadnos> JonE was on a BDI at the time
[20:43:42] <cradek> I doubt we should mess with configure on the branches - and I think jepler fixed this on trunk
[20:44:00] <SWPadnos> message date 11/21/06, title "error while compiling EMC2"
[20:44:07] <SWPadnos> ok
[20:44:44] <cradek> if paul (hi paul!) wants to try that configure test in trunk, maybe he'll let us know if it works on bdi
[20:45:12] <alex_joni> heh...
[20:45:19] <SWPadnos> isnt there still a BDI compile farm slot?
[20:45:24] <SWPadnos> err - VM
[20:45:30] <cradek> yes but it has the needed packages installed
[20:45:34] <SWPadnos> heh
[20:46:08] <SWPadnos> do you know offhand why gl is needed for emc.so? it seems they're separate realms
[20:46:37] <SWPadnos> not that separating whatever functions would fix the problem - just move it
[20:47:33] <alex_joni> SWPadnos: emc.so is used by AXIS
[20:47:39] <alex_joni> and it contains preview parts
[20:48:24] <SWPadnos> is it only used for AXIS?
[20:48:37] <alex_joni> yes
[20:49:04] <SWPadnos> ok, and AXIS is only built if both python and openGL are detected (and presumed sane)
[20:49:38] <alex_joni> right
[20:50:13] <SWPadnos> ok, so it's possible that there's a bug in the "presumed sane" part (fixed by jepler in trunk), or that the users have bad / unexpected installs
[20:50:24] <SWPadnos> possibly fixed, I should say
[20:50:38] <SWPadnos> (possible problem possibly fixed ;) )
[20:52:05] <alex_joni> possibly watch me probably not caring
[20:52:16] <SWPadnos> already doing it ;)
[20:52:45] <SWPadnos> I don't think there's a problem, but I don't want to be a complete prick about saying it
[20:52:52] <SWPadnos> though I shouldn't care
[21:21:48] <jepler> SWPadnos: bah I don't know why you want to dignify him with a response
[21:22:16] <SWPadnos> I don't , but then again I don't want all the 600+ users to see his misinformation as the truth
[21:22:27] <SWPadnos> userlist subscribers that is
[21:22:39] <cradek> you have to weigh answering a bug report with 'feeding the troll'
[21:22:47] <SWPadnos> yes, I know - not an easy task
[21:24:05] <cradek> because his message was both
[21:24:05] <jepler> that's why the board should vote to remove him from the mailing lists <1/2 wink>
[21:24:05] <cradek> in the past, no matter what the response, more trolling happens afterward
[21:24:05] <SWPadnos> the problem is that he's a smart guy. even though he's being a prick, there is a problem somewhere (BDI installation, makefile, emc2, .. - who knows)
[21:24:33] <SWPadnos> if it's just with installation of the few users that have reported the problem, then "problem solved"
[21:24:35] <cradek> that's why I hope he (hi paul!) tests trunk and gets back to us
[21:24:40] <SWPadnos> heh
[21:24:51] <alex_joni> yeah right
[21:25:04] <alex_joni> * alex_joni lost that hope quite a while ago
[21:25:10] <jepler> we do know it builds on a "properly configured" bdi system
[21:25:38] <jepler> checking for glBegin in -lGL... no
[21:25:38] <jepler> configure: error: Required GL library missing. Install it, or specify --disable-python to skip the parts of emc2 that depend on Python
[21:25:47] <jepler> I tested with just the /usr/lib/libGL.so symlink removed, and it also detects that
[21:26:42] <SWPadnos> crap. I should just ge tthe free VMWare and be done with it. this getting a new workstation license every few months is getting annoying
[21:27:14] <SWPadnos> I have a BDI VM on which I can test, and until a couple of days ago, I had a real BDI 4.30-ish install also
[21:28:06] <jepler> next time I have too much free time, I should see what it takes to make emc2-sim .deb build on etch or whatever the debian of the day is called
[21:30:36] <SWPadnos> hey - as long as we're talking about building - I know I can build sim / RIP on my dapper Opteron box, but I can't seem to do it on my edgy install
[21:31:00] <SWPadnos> I think it's having a hard time finding the KERNELDIR - I haven't unpacked the kernel source, though I do have headers installed
[21:31:19] <cradek> does /usr/src/linux-headers-`uname -r` exist?
[21:31:22] <SWPadnos> this is a problem with asm/bitops.h
[21:31:35] <cradek> oh
[21:31:39] <jepler> sim should not be using kernel headers at all, and should build fine without any kernel-headers package installed
[21:31:58] <jepler> the file it expects to find is /usr/include/asm/bitops.h
[21:32:13] <cradek> % dpkg -S /usr/include/asm/bitops.h
[21:32:13] <cradek> linux-kernel-headers: /usr/include/asm/bitops.h
[21:32:40] <SWPadnos> ok - rtapi is flagging this as an error, in rtapi_bitops.h
[21:32:48] <SWPadnos> this isn't i386
[21:33:18] <jepler> defined(ASM_BITOPS_H_USABLE)
[21:33:32] <jepler> looks like the question is: why did configure not find ASM_BITOPS_H_USABLE?
[21:34:13] <jepler> .. it checks that a file which includes <asm/bitopts.h> has no errors or warnings ..
[21:34:16] <SWPadnos> right
[21:34:28] <SWPadnos> I can see that KERNELDIR = (nothing)
[21:35:06] <SWPadnos> i can also see that /usr/src/linux-headers-`uname-r'/asm/bitops.h exists
[21:35:18] <jepler> KERNELDIR = (nothing) is right for sim
[21:35:19] <SWPadnos> err ^^include/ in there
[21:35:26] <jepler> is there a /usr/include/asm/bitops.h?
[21:35:42] <SWPadnos> ok, so thno
[21:35:44] <SWPadnos> no
[21:35:57] <alex_joni> SWPadnos: make prepare-all usually creates the links
[21:36:14] <jepler> no header in /usr/src/linux-headers is going to be used by the sim build
[21:36:39] <SWPadnos> alex_joni, I thought the prepare-all step was no longer needed
[21:36:52] <alex_joni> SWPadnos: it might be for RT, but not for sim
[21:37:10] <jepler> use apt-file to find out what package (if any) installs /usr/include/asm/bitops.h
[21:37:17] <SWPadnos> ok - this is sim I'm trying to build
[21:37:49] <SWPadnos> err - I have no apt-file
[21:37:59] <alex_joni> :-O
[21:38:31] <alex_joni> apt-get install apt-file ?
[21:38:31] <jepler> bbl
[21:38:42] <SWPadnos> see you
[21:38:47] <SWPadnos> heh - I have apt :)
[21:58:24] <anonimasu> lol
[22:00:02] <alex_joni> SWPadnos: apt-get moo
[22:03:37] <SWPadnos> nice. is there an apt-get bunny? :)
[22:03:55] <alex_joni> no, the apt has super cow powers
[22:04:01] <SWPadnos> ah
[22:04:08] <SWPadnos> it's moooo-rific!
[22:04:17] <alex_joni> SWPadnos: apt-get help
[22:04:28] <alex_joni> See the apt-get(8), sources.list(5) and apt.conf(5) manual
[22:04:29] <alex_joni> pages for more information and options.
[22:04:29] <alex_joni> This APT has Super Cow Powers.
[22:04:40] <SWPadnos> heh
[23:00:04] <SWPadnos> jepler, thanks
[23:00:46] <SWPadnos> it makes sense that ASM_BITOPS_H_USABLE isn't set, since there's no kernel dir and I don't have bitops under /usr/include
[23:01:31] <jepler> the kernel dir won't help you, it will never look there
[23:01:35] <jepler> (without modfying configure, that is)
[23:02:06] <SWPadnos> hmmm
[23:02:40] <jepler> the boot screen doesn't look right in vmware
[23:02:56] <SWPLinux> what was the command to find out which package owns a particular file?
[23:03:07] <SWPLinux> dpkg -S ?
[23:03:17] <jepler> an installed file, yes
[23:03:22] <SWPLinux> ok
[23:03:25] <jepler> apt-file search will search for files you haven't installed
[23:03:54] <SWPLinux> ok
[23:04:14] <SWPLinux> I'm looking on my dapper system - it's provided by linux-kernel-headers on this machine
[23:04:39] <SWPLinux> what package provides apt-file?
[23:04:51] <SWPLinux> (I guess I could find it, if I had apt-file)
[23:05:41] <alex_joni> apt-get install apt-file
[23:05:49] <SWPLinux> :)
[23:05:50] <alex_joni> but I told you that already, didn't I :)
[23:05:57] <alex_joni> * alex_joni is not kidding
[23:06:00] <SWPLinux> did you? maybe I'm deaf
[23:06:18] <alex_joni> 23:31 < alex_joni> apt-get install apt-file ?
[23:06:35] <alex_joni> 00:58 < SWPLinux> did you? maybe I'm deaf
[23:06:42] <SWPLinux> what?
[23:07:56] <alex_joni> the other time I told you .. was about 1.5 hours ago
[23:08:37] <SWPadnos> yeah yeah - I see it in the buffer :P
[23:09:43] <alex_joni> SWPadnos: I usually use apt-cache search for commands
[23:10:00] <SWPadnos> ah - indeed
[23:12:19] <jepler> install mostly finished
[23:12:22] <jepler> 77%
[23:12:33] <SWPLinux> hmm
[23:13:13] <SWPLinux> apt-file search bitops returns nothing
[23:13:24] <SWPLinux> on the edgy system and on the dapper system
[23:14:00] <jepler> did you do "apt-file update"? I think it prompts you to do that the first time..
[23:14:18] <jepler> my 64-bit dapper system says:
[23:14:17] <jepler> jepler@tall:~$ apt-file search /bitops.h | wc -l
[23:14:17] <jepler> 43
[23:14:22] <SWPLinux> no, and I didn't get prompted. thanks
[23:14:32] <jepler> doh
[23:15:09] <SWPLinux> oh. that's a rather large download
[23:17:46] <jepler> installed and rebooting
[23:31:10] <SWPLinux> well, there's no linux-kernel-headers package for edgy (that installs anything to /usr/include/asm)
[23:31:32] <SWPLinux> the only package that puts anything in /usr/include/asm is linux-libc-dev
[23:33:30] <jmkasunich> what is the problem? no bitops on a non-rt system?
[23:33:36] <SWPLinux> yep
[23:33:44] <SWPLinux> sim/edgy/a64 no worky here
[23:34:00] <SWPLinux> (not that I'm demanding or anything :) )
[23:35:15] <alex_joni> apt-demand get-me /usr/include/asm/bitops.h
[23:35:19] <jmkasunich> you've done a "find / -name bitops.h" with no luck?
[23:35:38] <SWPadnos> I have plenty of bitops under /usr/src/linux ...
[23:35:57] <jmkasunich> so yse one of em
[23:36:31] <SWPadnos> sure - I can probably get it to compile that way, but I'm not sure that's a good "fix" for the "problem" - ie, something that I'd recommend to users
[23:37:08] <jmk-vm02> /usr/include/linux/bitops.h
[23:37:08] <jmk-vm02> /usr/include/asm/bitops.h
[23:37:08] <jmk-vm02> /usr/include/asm-i386/bitops.h
[23:37:08] <jmk-vm02> /usr/include/asm-x86_64/bitops.h
[23:37:18] <jmk-vm02> is what I find on a breezy non-rt VM
[23:37:29] <jmk-vm02> which may be totally irrelevant, but
[23:38:30] <SWPadnos> there are 57 of them on my edgy install
[23:38:39] <SWPadnos> (!)
[23:41:18] <jmkasunich> I thought there was an apt-cache invocation that would tell you what package a file came from?
[23:41:28] <SWPadnos> yep - done that
[23:41:38] <jmkasunich> man apt-cache is not being helpfull
[23:41:42] <SWPadnos> /usr/include/bitops.h is not available in any package on edgy
[23:41:59] <jmkasunich> I want to run it here, see where my asm/bitops came from
[23:42:12] <alex_joni> dpkg -S
[23:42:15] <alex_joni> or apt-file
[23:42:21] <SWPadnos> it's apt-file (installable with apt-get install apt-file, then use apt-file update before searching)
[23:42:38] <alex_joni> jmkasunich: or dpkg -S for an existing file
[23:42:38] <SWPadnos> on dapper, it's provided by linux-kernel-headers
[23:42:53] <SWPadnos> oh right - he has it already (duh)
[23:44:26] <jmkasunich> same on breezy
[23:44:51] <SWPadnos> there's just no linux-kernel-headers package for edgy, which is a bummer
[23:44:57] <SWPadnos> I should check feisty
[23:45:06] <jmkasunich> well thats fscked
[23:45:20] <jmkasunich> how can there not be a kernel headers package?
[23:45:29] <SWPadnos> yeah - no kidding
[23:45:36] <alex_joni> jmkasunich: the linux-kernel-headers is a placeholder
[23:45:53] <alex_joni> the actual package is of the name linux-kernel-headers-'uname -r'
[23:46:00] <SWPadnos> there are headers packages, but none that install to /usr/include
[23:46:04] <jmkasunich> a placeholder that serves a valid purpose
[23:46:40] <SWPadnos> I have two linux-kernel-headers-... packages, but they're in /usr/src/linux-*
[23:46:45] <alex_joni> SWPadnos: and apt-cache search linux kernel headers turns out empty ?
[23:47:37] <SWPadnos> there are plenty of headers, but the only package that installs anything to /usr/include/asm is linux-libc-dev
[23:48:14] <SWPadnos> (according to apt-file)
[23:49:18] <alex_joni> http://packages.ubuntulinux.org/cgi-bin/search_packages.pl?keywords=linux-kernel-headers&searchon=names&subword=1&version=all&release=all
[23:51:07] <SWPadnos> well, there's a relatively simple solution: even if compiling for sim, find the appropriate kernel bitops.h header and use it :)
[23:52:07] <alex_joni> SWPadnos: how about installing linux-kernel-devel
[23:52:28] <jmkasunich> but he's not doing kernel development
[23:52:42] <jmkasunich> (if he was willing to use the kernel version of the header, its already installed)
[23:52:44] <SWPadnos> eight
[23:52:46] <SWPadnos> right
[23:53:17] <SWPadnos> I have no problem with it, but I don't remember the reason that rtapi_bitops is a copy of some kernel code, rather than using the kernel code
[23:53:21] <jmkasunich> for user space use of bitops, what lib actually contains the functions?
[23:53:40] <SWPadnos> I don't know - it just gets included in rtapi.h
[23:53:51] <SWPadnos> I was thinking that as well - disable the include if SIM
[23:54:23] <jmkasunich> ah, they are inline functions
[23:54:50] <SWPadnos> yep - "lightweight mutex"
[23:55:01] <jmkasunich> yeah, I knew what they were used for
[23:55:06] <SWPadnos> heh
[23:55:10] <jmkasunich> just didn't recall that we had copied the code
[23:55:37] <SWPadnos> the kicker is that they're probably work OK on x86_64, but they're protected by an if (i386)
[23:55:39] <jmkasunich> so your problem is that you are compiling for x86_64, not i386 ?
[23:55:43] <SWPadnos> yes
[23:55:54] <SWPadnos> sim, edgy, x86_64
[23:56:05] <jepler> my first impulse is to put a copy of the x86_64 version of the file in the rtapi_bitops.h header
[23:56:06] <SWPadnos> at least this isn't the SMP machine and RT ;)
[23:56:14] <jmkasunich> probalby the reason that code is in bitops is because we had this problem before on i386
[23:56:17] <SWPadnos> yep
[23:56:29] <jmkasunich> do you get the message from the bottom of the file?
[23:56:33] <jepler> in fact I'm trying this, and it is compiling
[23:56:53] <jepler> I notice that on edgy there's /usr/include/asm/atomic.h but it has different atomic operations (e.g., test and increment) than are currently used
[23:56:54] <jmkasunich> the "rtapi does not yet have support" message?
[23:58:31] <jmkasunich> SWPadnos: in your kernel tree, do you have both 386 anc 86_64 versions of bitops.h?
[23:58:44] <jmkasunich> s/anc/and
[23:59:50] <jmkasunich> "Package linux-kernel-headers is a virtual package provided by:
[23:59:50] <jmkasunich> linux-libc-dev 2.6.17.1-10.34"
[23:59:56] <SWPadnos> I think so - I was just about to look at the differences
