Back
[01:15:38] <jmkasunich> jepler: I have no objection
[01:16:23] <jmkasunich> my background doesn't include unix/linux, so I was unaware of the existing codes when I started rtapi/hal
[01:17:14] <jepler> jmkasunich: OK
[01:17:24] <jepler> I have a set of patches ready but they'll be easier to apply once we're on git
[01:17:27] <jepler> as long as I don't lose track of them
[01:18:25] <jmkasunich> heh
[01:18:30] <jepler> and actually I need to go over it again -- there are cases where it now makes more sense to return the error from the called function, rather than just -EINVAL (which was HAL_INVAL before my change)..
[01:21:00] <jmkasunich> I wonder how many other places I ignored unix-y ways of doing things
[01:23:56] <jepler> heh
[01:24:42] <jmkasunich> I never really thought about it before, but EMC is the first time I ever coded on a multi-user OS
[01:25:36] <jmkasunich> TRS-80 (basic and Z-80 assy), then Kaypro2 (CP/M, C and Z-80 assy), then PC clones with DOS (C and x86 asm) is my history
[01:26:02] <jmkasunich> MMU? swap? what's that?
[01:26:48] <jepler> I must have something like 15 years unix programming now, and spent only a few years between pre-DOS PCs and linux
[01:26:52] <jmkasunich> oh, and some 8051 assy in there too
[01:27:18] <jepler> it's safe to say that the vast majority of my programming is unix; second after that is probably Commodore BASIC but that's all forgotten now
[01:27:52] <jmkasunich> I remember being very offended when a college prof said that basic ruins people's minds for programming
[01:28:00] <jmkasunich> because that was all I knew at the time
[01:28:12] <jepler> I think we turned out OK
[01:28:16] <jmkasunich> heh
[01:28:37] <jmkasunich> that particular prof was a major fan of APL (shudder)
[01:29:04] <jepler> oh dear
[01:29:41] <jmkasunich> I had to do my numerical methods class using APL, on a timeshare mainframe with weird terminals for the strange character set
[01:29:57] <jepler> I also missed mainframes .. we had unix by the time I was in college
[01:30:18] <jmkasunich> I caught the tail end of them
[01:30:38] <jmkasunich> my freshman computer class was the first one at CWRU that didn't use punch cards
[01:30:55] <jmkasunich> we got to use terminals, running TOPS-20 on some DEC mainframe
[01:32:45] <jepler> RATIONALE
[01:32:45] <jepler> None.
[01:32:49] <jepler> ^^ from a manpage
[01:32:57] <jmkasunich> heh
[01:33:01] <jmkasunich> at least they admit it
[01:35:45] <jepler> in hal, some data grows from each end of the shared memory area, right?
[01:36:15] <jepler> if we stored names outside the pin/param struct, so that they didn't have to be fixed-length, which direction would it make sense for them to grow?
[01:36:29] <SWPadnos> in userspace
[01:36:42] <jmkasunich> I'm not sure I follow the question
[01:37:04] <jmkasunich> oh, I see
[01:37:10] <jepler> right now one of the things that takes up a lot of hal shared memory is names
[01:37:25] <jepler> I was thinking: don't have a fixed-length name record, but allocate them according to the required length
[01:37:28] <jmkasunich> if we're going to do any significant restructuring of the hal internals, it would make sense to separate all the metadata
[01:37:35] <jepler> yeah
[01:37:41] <jepler> that probably makes more sense
[01:37:44] <SWPadnos> the only time the metadata is needed in RT is during object creation
[01:37:56] <jepler> though it can't be "userspace" as SWPadnos suggests, since rt components access it when they create hal items
[01:38:06] <jepler> I see SWPadnos realized that before I could say it, though
[01:38:13] <SWPadnos> and that could be shoved into userspace with a complete rewrite :)
[01:38:28] <SWPadnos> heh
[01:38:29] <jepler> I don't know what you mean by "userspace", then
[01:38:32] <jmkasunich> that is the obstacle - the "hal restructure" that never happened was going to move the metadata into userspace
[01:38:37] <jepler> I don't know what you mean by "userspace", then
[01:38:48] <jepler> you mean swappable data?
[01:38:49] <SWPadnos> out of kernel shared memory
[01:39:03] <SWPadnos> yes, it could be swappable
[01:39:03] <jmkasunich> but we never came up with a clean way to call the metadata manipulating functions (like hal_pin_new) from kernel space
[01:39:45] <SWPadnos> right, that's the problem - we still don't know how to do the equivalent of RPC between kernel and user space
[01:39:49] <jepler> yeah, you'd want to figure out how to make the name buffer not be statically sized
[01:39:56] <SWPadnos> ioctl notwithstanding
[01:40:00] <jepler> otherwise you're stuck with two statically-sized buffers that you have to carefully choose sizes for
[01:40:25] <SWPadnos> if we used variable-sized names, then we'd eventually end up with a fragmentation problem
[01:40:30] <jepler> my scheme, such as it is, would at least preserve a single area yet save memory on average
[01:40:32] <SWPadnos> assuming anything gets deleted
[01:40:43] <jmkasunich> the existing approach puts signals (accessed in RT) at one end of the buffer, and metadata at the other
[01:40:46] <jepler> we have fragmentation now, since pin and param structs are different sizes (but they maintain linked free lists)
[01:41:15] <SWPadnos> but any new pin could re-use the space that had been taken by a deleted pin
[01:41:23] <jmkasunich> hal memory management sucks
[01:41:25] <SWPadnos> that wouldn't be true with variable length records
[01:41:34] <SWPadnos> wouldn't necessarily be true, that is
[01:41:58] <SWPadnos> hmmm
[01:42:03] <jmkasunich> the metadata structs can be reused because of the free lists, but every comp usually allocates a block of data (one or more structure instances) in shared memory
[01:42:16] <SWPadnos> I wonder if there's a way to make userspace helpers responsible for creating HAL objects
[01:42:20] <jepler> .. you could 'compact' the strings anytime you had the hal lock. maybe you could even compact pins and params
[01:42:22] <jmkasunich> those struct sizes are unique to the comp, and never get freed
[01:43:21] <jmkasunich> things currently in shared memory:
[01:43:32] <jmkasunich> 1) pin/param metadata, including names
[01:43:45] <jmkasunich> 1A) names - if pulled out of the metadata structs
[01:44:10] <jmkasunich> 2) component HAL structure instances
[01:44:31] <jepler> oh yeah -- I'd forgotten about them
[01:44:48] <jmkasunich> 3) signal metadata (which includes the actual signal value, which must be accessible from RT)
[01:45:15] <lerman_> 1 -- Memory is free.
[01:45:24] <jmkasunich> I bet most of the space is metadata/names, but most of the fragmentation comes from the structure instances
[01:45:35] <jmkasunich> because the metadata space is reclaimed by the free-lists
[01:45:45] <lerman_> 2 -- In actual use, we don't allocate and deallocate hal stuff all the time.
[01:46:10] <jmkasunich> kernel memory is less free than general user space memory, but you are mostly correct
[01:46:16] <jmkasunich> and 2 is entirely correct
[01:46:59] <lerman_> While we could be more elegant; there really isn't much point to it. :-)
[01:47:33] <jepler> yeah -- compared to my proposal (use less space for most names), doubling the buffer once more will stave off hitting the limits for at least as long, and is much less effort
[01:48:25] <jmkasunich> it can be annoying when you already have "loadrt something count=3", to have to change count to 4, rather than just loading another instance of the component when and where you need it
[01:49:10] <jmkasunich> at one time we talked about having a "newinst", distinct from loadrt - loadrt would load the component into kernel space, and newinst would export the pins, etc, for one instance of the component
[01:49:25] <jepler> that'd still be nice
[01:49:46] <jepler> for other reasons, such as the "hal scripts as components" idea from the mailing list
[01:50:04] <jmkasunich> newinst would also let you name the instance, so instead of pid.0.Pgain, you could have X-pid.Pgain, or whatever you like
[01:50:21] <jepler> btw I snuck that feature into all comps, though you have to do the naming on the original loadrt line
[01:50:40] <jepler> loadrt and2 names=larry,curly,moe
[01:51:09] <jmkasunich> nobody uses it that I'm aware of - I wonder if that is because they don't know it exists, or because it isn't really that usefull?
[01:51:13] <jepler> I dunno
[01:51:21] <jepler> half a pound of one, and eight ounces of the other?
[01:51:44] <jmkasunich> letting people name things whatever they want might actually make it harder to help them
[01:53:02] <jmkasunich> in the same way that many of us have decided that having a bunch of little hal files isn't really a feature
[01:53:29] <jepler> it turns out hal doesn't have support for the right kind of modularity for that to be a win
[01:53:44] <SWPadnos> sadly, what it needs is some stuff that LabView has
[01:53:48] <jmkasunich> yeah - and lack of newinst is part of that
[01:55:08] <SWPadnos> the "macro" thing from the list is one part of it, but as he pointed out, we can't create new instances of something after the initial load
[01:55:54] <SWPadnos> there should be a way to do that (by having the module notice that it has already been loaded), but then the name (and2.N) wouldn't be what you expect
[01:56:11] <jmkasunich> you are talking about newinst
[01:56:15] <SWPadnos> yes
[01:56:27] <jepler> I'll pay the guy who implements all this five dollars
[01:56:35] <SWPadnos> there's a related concept, which would make a lot of things easier as well - they're called "bundles" in LabView
[01:56:40] <jmkasunich> the obstacle to newinst is the same RPC issue, really
[01:56:49] <SWPadnos> they're essentially struct connections instead of simple data types
[01:56:51] <SWPadnos> yes
[01:57:29] <SWPadnos> that's also the main obstacle to being able to make configurations on machines that don't have the hardware installed
[01:57:37] <SWPadnos> or sim configs that just don't talk to hardware
[01:57:53] <SWPadnos> but still have all the pins/params available
[01:58:05] <SWPadnos> (I haven't though about functs enough yet)
[01:58:08] <jmkasunich> you mean "sim drivers" ?
[01:58:12] <SWPadnos> sort of
[01:58:34] <SWPadnos> but also the ability to make a configuration for e.g. a 5i20 on a machine that doesn't have one installed
[01:58:36] <jepler> btw I retract my original suggestion about names
[01:58:53] <jmkasunich> can-o-worms eh?
[01:58:56] <jepler> indeed
[01:59:03] <SWPadnos> heh
[01:59:14] <jepler> #if 0 /* newinst deferred to version 2.2 */
[01:59:30] <SWPadnos> too many advanced features to think about, and most of them are irrelevant to the actual operation of the machine
[01:59:30] <jepler> hm, I just ran across this comment again, as I'm going through all lines that match 'return -E' in my source tree
[01:59:36] <jmkasunich> - #if 0 /* newinst deferred to version 2.2 */
[01:59:40] <jmkasunich> + #if 0 /* newinst deferred to version 2.5 */
[01:59:44] <jepler> 3.0?
[01:59:46] <SWPadnos> I noticed that one in Wichita and got a chuckle
[01:59:47] <jepler> 5.7?
[02:01:20] <jmkasunich> one of these days I should grep FIXME in the hal source tree, and actually try to fix some of them
[02:02:16] <jmkasunich> never happen tho - designing and building machines is much more fun
[03:09:13] <jepler> well reading through every line in emc with 'return -E' was sure a fun way to spend my evening
[03:09:42] <jepler> what are the odds I got all 55 changes I ultimately made right?
[03:09:57] <cradek> jepler: did you fix the pid tuner thingy on the branch?
[03:10:12] <jepler> the hm2-specific one?
[03:10:28] <cradek> no, emccalib
[03:10:34] <cradek> or was it just a hm2 problem?
[03:10:45] <cradek> the thing that made it show only an empty screen
[03:10:52] <jepler> there were two problems -- one was TRUNK-specific, one was hm2-specific
[03:11:01] <cradek> oh ok, then forget it
[03:11:02] <jepler> I think both may have behaved similarly
[03:11:15] <jepler> it's not that it wouldn't be nice for hm2 tuning to work in 2.3..
[03:11:45] <cradek> oh right, that would be good.
[03:11:50] <jepler> it's commit 4e11c1f7cfceedbcda454a6546b980e386c40063 if you want to test it on your system .. but you're not using the hm2-servo configs, are you
[03:12:38] <cradek> no, nothing like them
[03:13:58] <jepler> I should use my external brain to keep track of this
[03:14:00] <CIA-48> EMC: 03jepler 07v2_3_branch * 10emc2/TODO: maybe this will help me remember
[03:14:06] <jepler> goodnight
[03:14:21] <cradek> goodnight again, thanks
[10:24:51] <rob__> rob__ is now known as robh_
[11:47:01] <skunkworks> hm2 tuning?
[12:27:04] <jepler> skunkworks: if you use the hm2-servo configuration, the window used for servo tuning doesn't display properly
[12:27:33] <jepler> this is because hm2-servo uses a syntax in hal files that the tuning program doesn't understand
[19:42:04] <alex_joni> hi all
[19:43:26] <skunkworks_> Hi alex!
[19:44:13] <alex_joni> * alex_joni is back
[19:45:34] <micges> hi alex
[19:45:36] <alex_joni> MMTB
http://www.newegg.com/Product/Product.aspx?Item=N82E16819115212
[19:47:21] <SWPadnos> cheap
[19:47:27] <SWPadnos> NOT!
[19:47:45] <alex_joni> stupid
[19:47:47] <alex_joni> YES!
[19:48:20] <SWPadnos> yeah
[19:48:34] <SWPadnos> I put toghether a complete quao-core Phenom II system for $1300
[19:48:37] <SWPadnos> quad
[19:49:09] <SWPadnos> and that wasn't skimping on anything: 1TB disk, 8GB RAM, GTX275 video, 23" LCD, 955 CPU ...
[19:51:50] <alex_joni> yup
[19:53:27] <SWPadnos> oh, and an Antec Sonata III acse :)
[19:53:29] <SWPadnos> case
[19:55:08] <jepler> nice
[19:55:16] <jepler> you remembered to enter my shipping address, right?
[19:55:41] <alex_joni> jepler: I'm sure he wants to test it and install a LTS first
[19:55:45] <alex_joni> before shipping it to you
[19:55:54] <jepler> that's nearly ideal, then
[19:56:04] <SWPadnos> it has 9.04, sorr
[19:56:06] <SWPadnos> y
[19:56:08] <alex_joni> maybe even do a 1weeks uptime test
[19:56:13] <alex_joni> 1-2
[19:56:24] <alex_joni> Microsoft renames netbooks 'low cost small notebook PCs' <- ROFL
[19:56:55] <SWPadnos> it worked nicely at the Movie Awards, with about 18 clients attached
[19:57:58] <jepler> did I hear correctly that opterons are now in 6-core models?
[19:58:15] <SWPadnos> I haven't seen that
[19:58:20] <SWPadnos> there are 3-core ones though
[19:58:36] <SWPadnos> there are 6-core Intels
[19:59:06] <jepler> http://news.google.com/news?pz=1&um=1&ned=us&ncl=d_6kKPW1XNZutWM&cf=all
[19:59:18] <SWPadnos> oh. cool
[19:59:24] <SWPadnos> I haven't seen them available yet
[19:59:55] <alex_joni> how about the Octeon from Cavium Networks? 16 cores ;)
[20:00:23] <SWPadnos> http://www.newegg.com/Product/Product.aspx?Item=N82E16819117176
[20:00:25] <jepler> or the propeller from parallax with 8 cores
[20:00:39] <SWPadnos> or an FPGA with 100 cores!
[20:01:15] <alex_joni> there's the 40C18 from SEAforth with 40 cores
[20:02:01] <alex_joni> http://upload.wikimedia.org/wikipedia/en/9/92/Asap2.diephoto.300x327.touchedup.jpg <- 167 cores
[20:02:49] <alex_joni> http://en.wikipedia.org/wiki/Asynchronous_array_of_simple_processors cool
[20:23:30] <alex_joni> good night all
[20:30:52] <jepler> see you alex_joni
[20:35:59] <skunkworks_> jepler: getting the bits togather?
[20:36:17] <skunkworks_> together
[20:38:06] <jepler> skunkworks_: bet you don't hold your breath
[20:38:28] <skunkworks_> awww
[20:38:34] <skunkworks_> :)
[20:38:36] <jepler> s/bet/best/
[20:44:28] <robh_> SWPadnos, i did abit more diggin with my problem from earlyer with max overall velecoty if u rember, using the sim i see you can jog all 3 axis (using my 166.67 velecoty) and u can get 17m or so fine, but when u switch to MDI and command a move g0 x y z this si where it seems to get stuck at the 10m max on all 3 axis hope this makes sence
[20:44:43] <skunkworks_> All I really want to see is one axis hooked up.. (then you can stop working on it)
[20:44:47] <skunkworks_> ;)
[20:46:44] <robh_> hooked up?
[20:48:18] <skunkworks_> jepler has servo stuff now - some assembly reqired.
[20:50:41] <cradek> robh_: pastebin your ini file again. I think you still have an incorrect TRAJ setting, although you said earlier you removed it.
[20:51:04] <robh_> http://pastebin.ca/1447603
[20:52:19] <cradek> hm, looks fine to me
[20:52:25] <robh_> yea, i just tryed it out on sim setup to see, and i got what i said above (just changed max velecity for axis) and all commanded moves max out at 10m, while u can job all 3 at once at 17m which seemed odd no?
[20:54:31] <cradek> ohhhh
[20:54:40] <cradek> what does your max velocity slider say?
[20:55:01] <SWPadnos> does that affect MDI?
[20:55:06] <cradek> sure
[20:55:11] <SWPadnos> oh. odd
[20:55:19] <SWPadnos> that is limited to 10 in the DISPLAY section
[20:56:41] <robh_> slider for vel is 10 it shows
[20:57:06] <SWPadnos> I didn't realize that setting mattered for MDI
[20:57:20] <SWPadnos> you should change [DISPLAY]MAX_VELOCITY to 20 or so
[20:57:22] <cradek> it's for all coordinated mode
[20:57:32] <SWPadnos> and then move the slider
[20:59:18] <cradek> mv = inifile.find("TRAJ","MAX_VELOCITY") or inifile.find("AXIS_0","MAX_VELOCITY") or 1.0
[20:59:22] <cradek> vars.maxvel_speed.set(float(mv)*60)
[20:59:29] <cradek> I think this is wrong. that is bogus for mixed-units machines
[21:00:34] <cradek> err
[21:00:34] <cradek> vars.max_maxvel.set(float(mv))
[21:00:38] <cradek> so confuuuuused
[21:00:43] <cradek> too many settings
[21:02:53] <SWPadnos> mixed-units as in degrees and mm, or mixed like mm and inch?
[21:02:55] <SWPadnos> or both
[21:03:36] <cradek> degrees and (mm or inch)
[21:05:27] <cradek> bbl
[21:05:46] <robh_> yes if you change the slider so it can set value grate to say 20m like u say, MDI etc will then allow all axis to travel at there max speed
[21:06:10] <robh_> that is max velocity slider
[21:06:19] <SWPadnos> yeah - I just didn't realize that the slider limit was a limit for all coordinated motion
[21:07:45] <SWPadnos> otherwise geo01005's suggestion to look at that line would have prompted a different response :)
[21:09:37] <robh_> well thx for ur time at least i now know :)
[21:09:44] <SWPadnos> me too! :)
[21:36:37] <SWPadnos> huh. I wonder if my crashing problem on Jaunty+RTAI was actually due to the AMD64 problem Dewey Garrett (?) submitted a patch for
[21:37:05] <SWPadnos> the system has been up for a couple of days now, which is more than it ever did with this kernel
[21:37:14] <SWPadnos> I haven't run EMC2 this boot
