jepler: I have no objection
my background doesn't include unix/linux, so I was unaware of the existing codes when I started rtapi/hal
I have a set of patches ready but they'll be easier to apply once we're on git
as long as I don't lose track of them
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)..
I wonder how many other places I ignored unix-y ways of doing things
I never really thought about it before, but EMC is the first time I ever coded on a multi-user OS
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
MMU? swap? what's that?
I must have something like 15 years unix programming now, and spent only a few years between pre-DOS PCs and linux
oh, and some 8051 assy in there too
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
I remember being very offended when a college prof said that basic ruins people's minds for programming
because that was all I knew at the time
I think we turned out OK
that particular prof was a major fan of APL (shudder)
I had to do my numerical methods class using APL, on a timeshare mainframe with weird terminals for the strange character set
I also missed mainframes .. we had unix by the time I was in college
I caught the tail end of them
my freshman computer class was the first one at CWRU that didn't use punch cards
we got to use terminals, running TOPS-20 on some DEC mainframe
^^ from a manpage
at least they admit it
in hal, some data grows from each end of the shared memory area, right?
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?
I'm not sure I follow the question
oh, I see
right now one of the things that takes up a lot of hal shared memory is names
I was thinking: don't have a fixed-length name record, but allocate them according to the required length
if we're going to do any significant restructuring of the hal internals, it would make sense to separate all the metadata
that probably makes more sense
the only time the metadata is needed in RT is during object creation
though it can't be "userspace" as SWPadnos suggests, since rt components access it when they create hal items
I see SWPadnos realized that before I could say it, though
and that could be shoved into userspace with a complete rewrite :)
I don't know what you mean by "userspace", then
that is the obstacle - the "hal restructure" that never happened was going to move the metadata into userspace
I don't know what you mean by "userspace", then
you mean swappable data?
out of kernel shared memory
yes, it could be swappable
but we never came up with a clean way to call the metadata manipulating functions (like hal_pin_new) from kernel space
right, that's the problem - we still don't know how to do the equivalent of RPC between kernel and user space
yeah, you'd want to figure out how to make the name buffer not be statically sized
otherwise you're stuck with two statically-sized buffers that you have to carefully choose sizes for
if we used variable-sized names, then we'd eventually end up with a fragmentation problem
my scheme, such as it is, would at least preserve a single area yet save memory on average
assuming anything gets deleted
the existing approach puts signals (accessed in RT) at one end of the buffer, and metadata at the other
we have fragmentation now, since pin and param structs are different sizes (but they maintain linked free lists)
but any new pin could re-use the space that had been taken by a deleted pin
hal memory management sucks
that wouldn't be true with variable length records
wouldn't necessarily be true, that is
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
I wonder if there's a way to make userspace helpers responsible for creating HAL objects
.. you could 'compact' the strings anytime you had the hal lock. maybe you could even compact pins and params
those struct sizes are unique to the comp, and never get freed
things currently in shared memory:
1) pin/param metadata, including names
1A) names - if pulled out of the metadata structs
2) component HAL structure instances
oh yeah -- I'd forgotten about them
3) signal metadata (which includes the actual signal value, which must be accessible from RT)
1 -- Memory is free.
I bet most of the space is metadata/names, but most of the fragmentation comes from the structure instances
because the metadata space is reclaimed by the free-lists
2 -- In actual use, we don't allocate and deallocate hal stuff all the time.
kernel memory is less free than general user space memory, but you are mostly correct
and 2 is entirely correct
While we could be more elegant; there really isn't much point to it. :-)
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
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
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
that'd still be nice
for other reasons, such as the "hal scripts as components" idea from the mailing list
newinst would also let you name the instance, so instead of pid.0.Pgain, you could have X-pid.Pgain, or whatever you like
btw I snuck that feature into all comps, though you have to do the naming on the original loadrt line
loadrt and2 names=larry,curly,moe
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?
half a pound of one, and eight ounces of the other?
letting people name things whatever they want might actually make it harder to help them
in the same way that many of us have decided that having a bunch of little hal files isn't really a feature
it turns out hal doesn't have support for the right kind of modularity for that to be a win
sadly, what it needs is some stuff that LabView has
yeah - and lack of newinst is part of that
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
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
you are talking about newinst
I'll pay the guy who implements all this five dollars
there's a related concept, which would make a lot of things easier as well - they're called "bundles" in LabView
the obstacle to newinst is the same RPC issue, really
they're essentially struct connections instead of simple data types
that's also the main obstacle to being able to make configurations on machines that don't have the hardware installed
or sim configs that just don't talk to hardware
but still have all the pins/params available
(I haven't though about functs enough yet)
you mean "sim drivers" ?
but also the ability to make a configuration for e.g. a 5i20 on a machine that doesn't have one installed
btw I retract my original suggestion about names
#if 0 /* newinst deferred to version 2.2 */
too many advanced features to think about, and most of them are irrelevant to the actual operation of the machine
hm, I just ran across this comment again, as I'm going through all lines that match 'return -E' in my source tree
- #if 0 /* newinst deferred to version 2.2 */
+ #if 0 /* newinst deferred to version 2.5 */
I noticed that one in Wichita and got a chuckle
one of these days I should grep FIXME in the hal source tree, and actually try to fix some of them
never happen tho - designing and building machines is much more fun
well reading through every line in emc with 'return -E' was sure a fun way to spend my evening
what are the odds I got all 55 changes I ultimately made right?
jepler: did you fix the pid tuner thingy on the branch?
the hm2-specific one?
or was it just a hm2 problem?
the thing that made it show only an empty screen
there were two problems -- one was TRUNK-specific, one was hm2-specific
oh ok, then forget it
I think both may have behaved similarly
it's not that it wouldn't be nice for hm2 tuning to work in 2.3..
oh right, that would be good.
it's commit 4e11c1f7cfceedbcda454a6546b980e386c40063 if you want to test it on your system .. but you're not using the hm2-servo configs, are you
no, nothing like them
I should use my external brain to keep track of this
EMC: 03jepler 07v2_3_branch * 10emc2/TODO: maybe this will help me remember
goodnight again, thanks
rob__ is now known as robh_
skunkworks: if you use the hm2-servo configuration, the window used for servo tuning doesn't display properly
this is because hm2-servo uses a syntax in hal files that the tuning program doesn't understand
* alex_joni is back
I put toghether a complete quao-core Phenom II system for $1300
and that wasn't skimping on anything: 1TB disk, 8GB RAM, GTX275 video, 23" LCD, 955 CPU ...
oh, and an Antec Sonata III acse :)
you remembered to enter my shipping address, right?
jepler: I'm sure he wants to test it and install a LTS first
before shipping it to you
that's nearly ideal, then
it has 9.04, sorr
maybe even do a 1weeks uptime test
Microsoft renames netbooks 'low cost small notebook PCs' <- ROFL
it worked nicely at the Movie Awards, with about 18 clients attached
did I hear correctly that opterons are now in 6-core models?
I haven't seen that
there are 3-core ones though
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
I haven't seen them available yet
how about the Octeon from Cavium Networks? 16 cores ;)
[20:00:23] <SWPadnos> http://www.newegg.com/Product/Product.aspx?Item=N82E16819117176
or the propeller from parallax with 8 cores
or an FPGA with 100 cores!
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
good night all
see you alex_joni
jepler: getting the bits togather?
skunkworks_: bet you don't hold your breath
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
All I really want to see is one axis hooked up.. (then you can stop working on it)
jepler has servo stuff now - some assembly reqired.
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
hm, looks fine to me
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?
what does your max velocity slider say?
does that affect MDI?
that is limited to 10 in the DISPLAY section
slider for vel is 10 it shows
I didn't realize that setting mattered for MDI
you should change [DISPLAY]MAX_VELOCITY to 20 or so
it's for all coordinated mode
and then move the slider
mv = inifile.find("TRAJ","MAX_VELOCITY") or inifile.find("AXIS_0","MAX_VELOCITY") or 1.0
I think this is wrong. that is bogus for mixed-units machines
too many settings
mixed-units as in degrees and mm, or mixed like mm and inch?
degrees and (mm or inch)
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
that is max velocity slider
yeah - I just didn't realize that the slider limit was a limit for all coordinated motion
otherwise geo01005's suggestion to look at that line would have prompted a different response :)
well thx for ur time at least i now know :)
me too! :)
huh. I wonder if my crashing problem on Jaunty+RTAI was actually due to the AMD64 problem Dewey Garrett (?) submitted a patch for
the system has been up for a couple of days now, which is more than it ever did with this kernel
I haven't run EMC2 this boot