Back
[01:01:00] <SWPadnos> hi there jmk
[01:31:58] <jmkasunich> hi
[01:33:12] <SWPadnos> how are things?
[01:34:07] <jmkasunich> so many things to do, so little time
[01:34:21] <SWPadnos> heh
[01:34:26] <jmkasunich> was just housecleaning one of the farm slots - disk was 97% full
[01:35:03] <SWPadnos> bummer
[01:35:09] <SWPadnos> I have that problem on my main machine
[01:35:14] <jmkasunich> its only a 2G disk
[01:35:16] <SWPadnos> and it's a 120G drive ;)
[01:35:21] <jmkasunich> lol
[01:35:29] <jmkasunich> I bet your housecleaning takes longer
[01:35:38] <SWPadnos> actually, it's down to 1.33% free
[01:35:49] <SWPadnos> I may need to clean out a few (dozen) of those ISOs
[01:35:52] <jmkasunich> you, sir, suffer from bloat
[01:36:03] <SWPadnos> mmmmm - donuts
[01:36:24] <jmkasunich> was it you that was wondering if I found tape drives in my trashpicking?
[01:36:32] <SWPadnos> Alex, I think
[01:36:42] <SWPadnos> I was wondering as well, but not as urgently ;)
[01:37:03] <jmkasunich> is DAT-8 worthwhile, or obsolete
[01:37:20] <SWPadnos> obsolete, I'd say
[01:37:29] <SWPadnos> if that's 8MM, then possibly not
[01:37:47] <SWPadnos> I think most DAT has been replaced by DLT, then AIT or Ultrium
[01:37:50] <jmkasunich> google to the rescue:
http://www.rql.kiev.ua/RQL/old/HP/STORAGE/SureStore_DAT8.htm
[01:38:07] <SWPadnos> .../old/... in the URL should tell you ;)
[01:38:18] <jmkasunich> heh, didn't notice that
[01:38:42] <jmkasunich> seems those kind of things obsolete faster than many
[01:38:54] <SWPadnos> hmmm. should I join the Agilent TEST advisory panel or not? ...
[01:39:11] <SWPadnos> I could win prizes, so maybe the answer is yes
[01:39:18] <jmkasunich> ;-)
[01:39:27] <jmkasunich> what do they expect in return?
[01:39:45] <SWPadnos> that I take surveys about test equipment from time to time
[01:40:46] <jmkasunich> go for it
[01:40:50] <SWPadnos> done.
[01:41:13] <SWPadnos> who knows, maybe they'll be annoyed that I chose Sorensen as my primary Power Supply supplier ;)
[01:42:55] <jmkasunich> got a question that is at least loosly related to emc ;-)
[01:43:01] <SWPadnos> oooh
[01:43:22] <jmkasunich> right now, there is only one user space HAL component
[01:43:26] <jmkasunich> (VCP)
[01:43:38] <jmkasunich> its at src/hal/user_comps/vcp
[01:43:50] <jmkasunich> the subdir is because there are multiple source files
[01:44:01] <jmkasunich> I have another user space component, a joystick driver
[01:44:03] <jmkasunich> single file
[01:44:13] <SWPadnos> hmmm
[01:44:17] <jmkasunich> should I make a subdir for it, or stick it right in user_comps?
[01:44:32] <SWPadnos> tough one
[01:44:53] <SWPadnos> I was just thinking of things like a "netHAL", and where it should go
[01:45:18] <SWPadnos> it probably makes sense for a drivers/ subdir
[01:45:27] <SWPadnos> not sure if it should be called that though
[01:45:34] <SWPadnos> devices
[01:45:54] <SWPadnos> I think I like a devices dir
[01:46:01] <jmkasunich> under user_comps?
[01:46:06] <SWPadnos> yes
[01:46:31] <jmkasunich> I'm not sure if there will be many other _user space_ device drivers
[01:46:35] <SWPadnos> or hardware/
[01:46:57] <SWPadnos> well, anything that uses a file and presents stuff to HAL would/could be userspace
[01:47:04] <jmkasunich> the joystick driver doesn't actually talk to the joystick HW, it talks to /dev/js
[01:47:10] <jmkasunich> thats why its userspace
[01:47:15] <SWPadnos> precisely - it uses a file
[01:47:32] <SWPadnos> so something that uses /dev/usb/... would also be
[01:47:52] <jmkasunich> true
[01:48:03] <jmkasunich> I think I favor devices/ over hardware/
[01:48:13] <SWPadnos> ok - was just pondering that
[01:48:48] <jmkasunich> next question - name for the executable
[01:49:00] <SWPadnos> hal_hoystick?
[01:49:04] <SWPadnos> joystick
[01:49:17] <jmkasunich> joystick might collide with something else
[01:49:29] <SWPadnos> was correcting my typo ;)
[01:49:33] <SWPadnos> hal_joystick
[01:49:55] <jmkasunich> hal_joystick is ok, I guess, but I'm not real crazy about sticking hal_ in front of every stinkin program and file in the tree ;-/
[01:50:06] <SWPadnos> heh, at least it would be consistent ;)
[01:50:28] <SWPadnos> remember that these things may live somewhere under /usr on installed systems
[01:50:42] <jmkasunich> thats true
[01:50:52] <SWPadnos> along with 17000 other programs
[01:51:36] <jmkasunich> yeah, you convinced me
[01:51:52] <jmkasunich> hal_joystick or haljoystick?
[01:52:00] <SWPadnos> I'd leave the underscore in
[01:52:05] <jmkasunich> we have halmeter and halscope and halcmd
[01:52:17] <SWPadnos> find / -name hal_* then becomes useful
[01:52:20] <SWPadnos> true
[01:52:27] <SWPadnos> and the RT modules are hal_
[01:52:34] <SWPadnos> and halconfig
[01:52:37] <jmkasunich> IOW, there is no consistency
[01:52:56] <SWPadnos> ok. then use the one you like
[01:53:00] <jmkasunich> halcmd would really suck with the _ because you type it a lot
[01:53:02] <SWPadnos> haljoystick
[01:53:05] <SWPadnos> yep
[01:53:09] <jmkasunich> thats not true for hal_joystick
[01:53:10] <SWPadnos> halstick
[01:54:32] <jmkasunich> hmm, we already have something called keystick
[01:54:44] <SWPadnos> heh, I thought about that
[01:55:04] <SWPadnos> but it's not in emc2 yet ;)
[01:55:48] <jmkasunich> I'm leaning toward hal_joystick, or hal_js ( goes with dev/js<n> )
[01:55:57] <SWPadnos> true enough
[01:56:10] <SWPadnos> though js = javascript in most other contexts
[01:56:18] <jmkasunich> good point
[01:56:35] <jmkasunich> thats decided then: src/hal/user_comps/devices/hal_joystick.c
[01:56:44] <SWPadnos> heh, OK. :)
[01:56:56] <jmkasunich> now I just have to recode the main loop
[01:57:16] <jmkasunich> want to use select() instead of read(), so it can handle multiple sticks
[01:57:21] <SWPadnos> cool
[01:57:36] <jmkasunich> also need to clean up the shutdown
[01:57:41] <jmkasunich> the existing one does:
[01:57:44] <SWPadnos> I think you said it presents all the inputs the stick provides, right?
[01:57:47] <jmkasunich> while ( 1 ) {
[01:57:53] <jmkasunich> read (/dev/js0)
[01:57:56] <jmkasunich> do stuff
[01:57:59] <jmkasunich> }
[01:58:01] <jmkasunich> correction
[01:58:05] <jmkasunich> while (!quit)
[01:58:22] <jmkasunich> there is a signal handler for SIGTERM that sets quit
[01:58:26] <SWPadnos> yep
[01:58:42] <jmkasunich> but if its blocked in the read waiting for you to move the stick, it doesn't shut down
[01:58:49] <jmkasunich> (until you touch the stick)
[01:58:51] <SWPadnos> since this is userspace, you can just have multiple instances, you don't need to have one executable present all sticks
[01:59:27] <jmkasunich> thats true, but I'd still have to pass it the device number I want it to use
[01:59:41] <jmkasunich> and I need to give it a unique name for HAL
[01:59:47] <SWPadnos> either that or it can ask HAL what js* components are loaded
[02:00:27] <jmkasunich> don't like that, what if for some reason the only stick on a box is js1?
[02:00:48] <SWPadnos> you definitely need to tell it the dev node to use
[02:00:49] <jmkasunich> or the only one you want to use with hal is js1, the other one is for games ;-)
[02:01:06] <SWPadnos> I was thinking f the HAL pin names
[02:01:14] <jmkasunich> oh, that...
[02:01:16] <SWPadnos> js0.button1
[02:01:19] <jmkasunich> those will match the dev node
[02:01:31] <SWPadnos> making separate instances know that there are others
[02:01:35] <SWPadnos> I wouldn't do that
[02:01:43] <SWPadnos> USB joysticks may change name
[02:01:44] <jmkasunich> ?
[02:02:12] <SWPadnos> there should even be a way of making sure that the number of inputs is correct
[02:02:29] <jmkasunich> you're starting to lose me
[02:02:31] <SWPadnos> if I plug in a second USB stick one day, then the one I used to use with HAL may change names
[02:02:40] <jmkasunich> number of inputs per stick, or number of sticks?
[02:02:58] <SWPadnos> phone - one sec
[02:03:52] <SWPadnos> back
[02:04:00] <SWPadnos> the inputs on the stick you want to use with HAL
[02:04:19] <SWPadnos> you'd want to be sure that the number of buttons and analog axes is the same
[02:04:39] <jmkasunich> dev/js generates "init events" for each axis and button on the stick, and the driver exports HAL pins accordingly
[02:05:08] <jmkasunich> so that part is pretty easy
[02:05:18] <jmkasunich> the tricky part is making sure the driver uses the right stick
[02:06:23] <SWPadnos> yep
[02:06:38] <SWPadnos> I'm not sure how you can identify a joystick programmatically
[02:06:53] <jmkasunich> are you saying that if there are two USB sticks plugged into a PC, you can't rely on dev/js0 always being the same one?
[02:07:00] <SWPadnos> yep
[02:07:11] <SWPadnos> especially if they get unplugged from time to time
[02:07:18] <jmkasunich> well that's annoying
[02:07:31] <SWPadnos> I think that's the case. USB is very annoying in this regard
[02:08:21] <SWPadnos> that's where a lot of the trouble regarding disk labels came from - hotplugging of USB devics
[02:08:33] <jmkasunich> I'm trying to think "what should the man page for this program say"
[02:08:46] <SWPadnos> "Use at your own peril" ;)
[02:08:58] <SWPadnos> oops - "Use ISB at your own peril"
[02:09:01] <SWPadnos> USB
[02:09:09] <jmkasunich> hal_joysctick <nothing> should open dev/js0 and export pins joystick.0.blah
[02:09:16] <SWPadnos> yep
[02:09:35] <jmkasunich> hal_joystick <stuff> should let you mix and match different dev nodes and pin labels
[02:09:35] <SWPadnos> I wonder if it's possible to search fro a USB joystick by name
[02:09:39] <SWPadnos> by using lsusb or the like
[02:09:59] <jmkasunich> I don't want to go there - conventional analog joysticks use the same driver
[02:10:13] <jmkasunich> I'd prefer to keep my head in the sand about USB
[02:10:18] <SWPadnos> well - thinking of a "find by name or ID" option
[02:10:21] <SWPadnos> yeah
[02:10:29] <SWPadnos> that probably makes sense for this application
[02:10:37] <SWPadnos> I'd have at most two parameters:
[02:10:41] <SWPadnos> 1) the dev node to use
[02:10:45] <jmkasunich> especially since 0.001% of the EMC user base will ever use a joystick, and 0.0000001% will have two
[02:10:47] <SWPadnos> 2) an optional "unit number"
[02:10:55] <SWPadnos> yep
[02:11:36] <jmkasunich> so the app would only ever use one stick, if you want another one you start another instance of the program
[02:12:23] <jmkasunich> and if unit number for the second instance collides with the first, it will just print an error message and exit, try again with a differnet unit number
[02:13:09] <jmkasunich> sounds reasonable
[02:13:10] <SWPadnos> yep
[02:13:15] <jmkasunich> one more...
[02:13:24] <jmkasunich> how do I have them spec the device node?
[02:13:26] <SWPadnos> ja
[02:13:31] <jmkasunich> /dev/js0, or just 0?
[02:13:38] <SWPadnos> /dev/whatever
[02:13:44] <SWPadnos> hmmm
[02:13:53] <jmkasunich> that is more clear, but what if they do /dev/hda1
[02:13:58] <SWPadnos> I'd like to fiddle with some USB joysticks before I say that
[02:14:15] <SWPadnos> you should be able to stat the node to find out what kind of thing it is
[02:14:38] <SWPadnos> make sure it's a char device, and the right device number
[02:15:55] <jmkasunich> you're right
[02:16:13] <jmkasunich> on the laptop I used before, I could swear it was /dev/js0
[02:16:19] <jmkasunich> here its /dev/input/js0
[02:16:50] <SWPadnos> yep
[02:16:57] <jmkasunich> so major/minor number is the right way to make sure its a joystick?
[02:17:06] <SWPadnos> I think so, but I'm not sure
[02:17:48] <jmkasunich> I wonder what /dev/input/ts0 is?
[02:17:57] <SWPadnos> hmmm
[02:18:13] <SWPadnos> touchscreen 0
[02:18:30] <jmkasunich> 'cept I ain't got one of those
[02:18:36] <SWPadnos> odd.
[02:18:38] <SWPadnos> is this ubuntu?
[02:18:43] <jmkasunich> yes
[02:18:55] <jmkasunich> the js0 entry comes and goes when I plug and unplug the stick
[02:19:03] <jmkasunich> but maybe others are permanent
[02:19:29] <SWPadnos> I have js0-3, and no joystick
[02:19:46] <SWPadnos> this is on BDI 4.30
[02:20:05] <SWPadnos> I'm not sure that this motherboard has a joystick port at all, and there are no usable USB ports
[02:20:47] <SWPadnos> all of the devices under /dev/input are major number 13
[02:20:54] <SWPadnos> including mice, joysticks, etc.
[02:21:05] <jmkasunich> joysticks are minor 0-3, right?
[02:21:12] <SWPadnos> yes
[02:21:22] <jmkasunich> js0 here was 13,0
[02:21:40] <jmkasunich> I think ubuntu uses udev or something, dynamic device nodes
[02:22:01] <jmkasunich> 4.30 uses static nodes,
[02:22:21] <jmkasunich> is it udev, or devfs?
[02:22:25] <SWPadnos> ok, devices.txt in kernel source/Documentation is your friend ;)
[02:22:32] <SWPadnos> 13 is input core
[02:22:38] <SWPadnos> 0-31 are joystick
[02:22:59] <SWPadnos> then mice, unified mice (whatever that means)
[02:23:17] <SWPadnos> i5 is analog joystick
[02:23:29] <jmkasunich> 15 you mean?
[02:23:42] <SWPadnos> oops. 15 is "joystick", 0-127 analog, 128-255 digital
[02:23:44] <SWPadnos> yes
[02:23:48] <SWPadnos> that's major 15
[02:24:18] <jmkasunich> hmm, so it could be either 13,0-31, OR 15,0-255
[02:24:33] <SWPadnos> yes, but the protocols may not be the same
[02:24:57] <SWPadnos> check to see if one of the js0 entries is a link to the other
[02:25:00] <jmkasunich> that would suck
[02:25:11] <SWPadnos> /dev/js0 is "joystick"
[02:25:22] <SWPadnos> /dev/input/js0 is "input core" version
[02:25:39] <SWPadnos> or /dev/djs0 for digital sticks ;)
[02:26:10] <jmkasunich> /dev/js0 is a link to /dev/input/js0
[02:26:25] <SWPadnos> ok good. then it's the same protocol
[02:26:34] <jmkasunich> strange, when I looked before there was no /dev/js0
[02:26:42] <jmkasunich> maybe I didn't wait long enough after plugging it in
[02:27:16] <SWPadnos> that would be a udev delay, probably
[02:27:37] <jmkasunich> so:
[02:28:00] <jmkasunich> hal_joystick [dev-node] [stick-num]
[02:28:16] <SWPadnos> yep
[02:28:30] <jmkasunich> both args optional default for node is /dev/js0, default for stick-num is 0
[02:28:39] <SWPadnos> yep
[02:29:00] <jmkasunich> if only one arg is specified, assume its a device node
[02:29:21] <SWPadnos> yes, or use options to set weach individually
[02:29:25] <jmkasunich> (or, look at it and try to make a smart decision, is it a node or a stick number)
[02:29:32] <SWPadnos> hal_joystick -d /dev/js0 -n 0
[02:29:40] <SWPadnos> hal_joystick -n 0
[02:29:46] <SWPadnos> ...
[02:29:54] <jmkasunich> yeah, that makes sense
[02:30:08] <SWPadnos> gives you experience with getopt as well ;) (hint, hint)
[02:30:14] <jmkasunich> NO!
[02:30:17] <SWPadnos> heh
[02:30:26] <jmkasunich> someday I'll use getopt
[02:30:29] <jmkasunich> but not for this program
[02:30:45] <jmkasunich> it is already written and works, I just need to clean it up a bit
[02:30:49] <SWPadnos> ok, ok - I won't badger you ;)
[02:30:53] <jmkasunich> no major rework if I can avoid it
[02:30:56] <SWPadnos> yep
[02:31:04] <jmkasunich> ok, we got the command line
[02:31:53] <jmkasunich> for -d, stat it, check major and minor against 13,0-31 and 15,0-255
[02:32:14] <SWPadnos> yep
[02:32:32] <jmkasunich> for -n, check it against 0-99? and print it in the names as joystick.00.blah?
[02:32:46] <jmkasunich> or joystick.0.blah, only go to two digits if more than 10?
[02:33:05] <SWPadnos> option 2
[02:33:19] <SWPadnos> no sense having people with <10 sticks need 2 digits
[02:33:23] <jmkasunich> right
[02:33:57] <jmkasunich> for things like parport pin numbers I used 01, 02, etc so all the names would be the same length
[02:34:04] <jmkasunich> and so they'd sort properly
[02:34:07] <SWPadnos> right
[02:34:19] <jmkasunich> not really gonna be an issue here
[02:34:29] <SWPadnos> I don't think so
[02:34:52] <jmkasunich> should I accept an arbitrary string, or just a number?
[02:35:29] <SWPadnos> hmmm. it might be nice to allow ini [section]setting, but that's probably overkill
[02:35:44] <SWPadnos> I'd think just a number, but it's actually harder to do
[02:36:43] <jmkasunich> not much
[02:36:47] <jmkasunich> atoi
[02:37:05] <SWPadnos> sure, but do you exit/error if it's not a number?
[02:37:28] <jmkasunich> yeah
[02:37:52] <jmkasunich> "invalid stick number '12q4'"
[02:38:18] <SWPadnos> names could be handy, actually
[02:38:30] <SWPadnos> imagine a panel with a couple of 1 or 2 axis sticks
[02:38:56] <SWPadnos> in fact, it might be nice to just allow a HAL prefix
[02:39:05] <SWPadnos> like -p "left_stick"
[02:39:24] <SWPadnos> and use that instead of "joystick.n."
[02:39:36] <jmkasunich> hmmm
[02:40:18] <jmkasunich> have to watch out for length, but thats not too hard to enforce
[02:40:27] <jmkasunich> (HAL names have a fixed max length)
[02:40:47] <SWPadnos> right. what's the worst case for a button or axis?
[02:40:58] <jmkasunich> button.99, axis.99
[02:41:16] <jmkasunich> actually not 99, I have some #define'd max limits
[02:41:25] <SWPadnos> ok, so 10 chars (including the leading '.')
[02:41:35] <SWPadnos> I thikn 2 digits should suffice though
[02:41:38] <jmkasunich> that leaves about 30 for the user
[02:41:43] <SWPadnos> yep
[02:42:03] <jmkasunich> the max limits are less than 99, I think 8 axis and 32 buttons IIRC
[02:42:17] <SWPadnos> is there a limitation in the joystick driver?
[02:42:25] <jmkasunich> not in the linux one
[02:42:30] <jmkasunich> but in the HAL one
[02:42:45] <jmkasunich> making the size of the struct dynamic is messy
[02:43:00] <SWPadnos> well, this is userspace. there may not need to be arbitrary limits
[02:43:15] <jmkasunich> because you don't know how many buttons or axis there are until you start getting init events from them
[02:43:17] <SWPadnos> you can read in all the stick parameters, and then create one struct, or see if there's enough memory for it
[02:43:28] <jmkasunich> too much like work
[02:43:30] <SWPadnos> heh
[02:43:36] <jmkasunich> the struct is in the HAL shmem area
[02:43:57] <SWPadnos> there can be a userspace struct first, then make an appropriate HAL struct
[02:44:04] <SWPadnos> but I'd say that's for later
[02:44:12] <jmkasunich> I say again, too much work
[02:44:21] <jmkasunich> ;-)
[02:44:28] <SWPadnos> I think the driver is a very cool thing as it is, so I'd just commit it with the simple command line (even leave out the name spec)
[02:44:34] <jmkasunich> the stick events can come fast and furious once it starts
[02:44:41] <SWPadnos> maybe put in comments with possible later enhancements
[02:44:55] <jmkasunich> the first event for each item (axis, button) says "this is an init event" and also has the position or state
[02:45:03] <SWPadnos> yeah, breathe on the thing and you can get 3 axis events at the same time
[02:45:04] <jmkasunich> later events just have pos/state
[02:45:29] <jmkasunich> so in theory, I could get init event, then state event for that item, then another init event for another item
[02:45:49] <SWPadnos> true
[02:45:59] <jmkasunich> the existing driver will just export each pin when the init event arrives, there is already a place for the pos/state data
[02:46:03] <SWPadnos> I suppose you never know that you've gotten all init events
[02:46:22] <jmkasunich> if an init event arrives for axis 500, I just print a message and don't export
[02:46:29] <SWPadnos> heh - right
[02:46:38] <jmkasunich> right, there is no "init done" event
[02:46:46] <SWPadnos> can you tell that the device has disappeared if the user unplugs it?
[02:46:57] <jmkasunich> good question
[02:47:09] <jmkasunich> with a static /dev entry, I bet not
[02:47:14] <jmkasunich> you'll just stop getting events
[02:47:24] <SWPadnos> right
[02:47:35] <jmkasunich> with udev, the actual dev entry goes away, so you might get an error from your read() or select() call
[02:47:39] <SWPadnos> even with a dynamic one, it should still be accessible until you close it
[02:48:03] <SWPadnos> files are guaranteed to exist as long as there's at least one reference to them
[02:48:32] <jmkasunich> oh, good
[02:49:04] <SWPadnos> so, I guess the only feature request I have is that you include a list of feature requests in the file ;)
[02:49:09] <jmkasunich> since I'm only handling one stick now, I can probabluy stick with read
[02:49:24] <jmkasunich> but clean shutdown is still an issue
[02:49:30] <SWPadnos> specifying the number of buttons / axes to export, and which they should be might be a useful feature
[02:49:39] <SWPadnos> select or poll are pretty easy
[02:49:58] <jmkasunich> they are mostly for multiple files
[02:50:10] <jmkasunich> handing signals with select is still non-trivial
[02:50:19] <jmkasunich> I was reading this afternoon
[02:50:28] <SWPadnos> I thought select finished if a signal occurred
[02:50:47] <jmkasunich> I think thats only if its an unhandled signal
[02:50:55] <SWPadnos> hmmm
[02:51:14] <SWPadnos> oh right, there's a timeout
[02:51:17] <jmkasunich> I need to handle sigs, so I can exit my main loop and call hal_exit to free the hal resources
[02:51:21] <SWPadnos> just make the timeout 0.1 second or so
[02:51:41] <jmkasunich> thats a possiblilty, handle the signal, set the "quit" flag, and let the timeout do its thing
[02:51:48] <SWPadnos> yep
[02:52:06] <jmkasunich> messy tho, with the timeout it is essentially polling
[02:52:10] <SWPadnos> not too much of a CPU hog
[02:52:47] <jmkasunich> well thats annoying
[02:52:57] <SWPadnos> try pselect instead
[02:53:11] <jmkasunich> my old BDI-4.27 install had man pages for things like read() and select()
[02:53:16] <jmkasunich> this ubuntu doesn't
[02:53:33] <SWPadnos> hmmm - did you use "man 2 select" ?
[02:53:40] <jmkasunich> from my reading, linux doesn't have a true pselect
[02:53:47] <SWPadnos> I suppose it should find it anyway
[02:54:07] <jmkasunich> man 2 didn't work, apropos didn't work
[02:54:11] <jmkasunich> those pages just aren't here
[02:54:12] <SWPadnos> it appears to, I learned about it with the linux select manpage ;)
[02:54:21] <SWPadnos> weird
[02:54:26] <SWPadnos> I'm running it on a BDI 4.30
[02:54:32] <jmkasunich> ok, mabye what I was reading was out of date
[02:54:32] <SWPadnos> and they are there
[02:54:40] <SWPadnos> you may need some "developer docs" package
[02:54:45] <jmkasunich> I bet its an ubuntu thing
[02:54:58] <jmkasunich> linux for the masses is what they're all about
[02:55:06] <SWPadnos> yep
[02:55:20] <SWPadnos> I think the next update (in April) will be a good one
[02:57:19] <jmkasunich> manpages-dev
[02:57:59] <SWPadnos> ah
[02:58:31] <jmkasunich> dat's mo betta
[03:01:53] <jmkasunich> pselect allows one to
[03:01:53] <jmkasunich> first block signals, handle the signals that have come in, then call
[03:01:53] <jmkasunich> pselect() with the desired sigmask, avoiding the race.) Since Linux
[03:01:53] <jmkasunich> today does not have a pselect() system call, the current glibc2 routine
[03:01:53] <jmkasunich> still contains this race.
[03:02:08] <SWPadnos> ah
[03:02:21] <SWPadnos> my bad
[03:02:32] <jmkasunich> its buried in the fine pring
[03:02:34] <jmkasunich> print even
[03:02:56] <jmkasunich> only the fact that I spent an hour reading this afternoon helped me spot it
[03:03:06] <SWPadnos> yep - who reads the BUGS section ;)
[03:04:17] <jmkasunich> there is another trick they suggest
[03:04:39] <jmkasunich> have the signal handler write to a pipe, then make the pipe one of the things that select waits on
[03:04:48] <SWPadnos> yep - I saw that
[03:05:05] <SWPadnos> seems a bit convoluted just to avoid checking a file handle every 0.1 second
[03:05:10] <jmkasunich> yeah
[03:05:48] <jmkasunich> I think its intended for applications where the signals may also be coming in fast and furious, and you want to handle them quickly
[03:05:55] <jmkasunich> overkill for simple shutdown
[03:06:00] <SWPadnos> yep
[03:07:32] <jmkasunich> how did it get to be 10 already
[03:07:55] <SWPadnos> too much programming time ;)
[03:07:59] <SWPadnos> err - talking
[03:08:02] <jmkasunich> right
[03:08:13] <jmkasunich> I wish it was programming time, I haven't even started that yet
[03:08:20] <SWPadnos> you only logged on at 7:45 anyway - geez
[03:08:38] <jmkasunich> I have another HAL component I want to tackle one of these days
[03:08:42] <jmkasunich> RC servo outputs
[03:08:57] <SWPadnos> that kind of PWM you mean?
[03:09:06] <jmkasunich> yeah
[03:09:22] <jmkasunich> 0.1mS to 2.4mS, with 1.5mS as center position
[03:09:43] <jmkasunich> update frequency a couple hundred Hz
[03:09:51] <SWPadnos> yep.
[03:10:12] <jmkasunich> somebody last night asked if EMC could control a robot and gave a URL
[03:10:24] <SWPadnos> I guess it depends on the resolution you want, and what happens if the pulse (or space) gets stretched
[03:10:25] <jmkasunich> the robot was a hobby kit, an arm with three RC servos
[03:11:02] <SWPadnos> can siggen make a non-square wave?
[03:11:09] <SWPadnos> ie, specified duty cycle
[03:11:10] <jmkasunich> resolution = base period
[03:11:15] <jmkasunich> not today
[03:11:18] <SWPadnos> ok
[03:11:26] <jmkasunich> siggen would be too slow anyway
[03:11:34] <jmkasunich> its signals are floats
[03:11:44] <jmkasunich> what I have in mind would work like stepgen
[03:11:44] <SWPadnos> actually, those RC servos only need about 20-100 updates/second, I think
[03:12:10] <jmkasunich> two functs, one running as fast as possible, no FP, that sets the output bit, then clears it some time later
[03:12:22] <SWPadnos> right. a number of periods "period", and a number (probably an S8) for the setting
[03:12:47] <jmkasunich> the input pin would be a float, -1.0 to 1.0
[03:13:01] <SWPadnos> that works, too
[03:13:22] <jmkasunich> the slow function would convert to pulse width in nS and store in an internal var
[03:13:52] <jmkasunich> the fast function would be doing "now += period_ns", then comparing "now" to the width
[03:14:00] <SWPadnos> yep
[03:14:16] <jmkasunich> you could control 12 axis with one parport ;-)
[03:14:19] <SWPadnos> and the update frequency isn't that critical
[03:14:38] <SWPadnos> that would be fun ;)
[03:14:58] <jmkasunich> my plan was that when "now" exceeds 2.5ms, it stops incrementing
[03:15:23] <jmkasunich> when the slow thread sees "now" > 2.5mS, it updates the pulsewidths, resets "now" to zero
[03:15:38] <jmkasunich> when the fast thread sees now = 0, it sets all output channels true
[03:15:49] <jmkasunich> then as each channel times out, its is set false
[03:15:59] <SWPadnos> hmmm - probably a bad plan, that last
[03:16:07] <jmkasunich> ?
[03:16:15] <SWPadnos> wait a sec, I misread it
[03:16:17] <SWPadnos> good plan
[03:16:23] <jmkasunich> ;-)
[03:17:01] <SWPadnos> I might use a set of "shadow settings", and have all updates done by the fast thread
[03:17:01] <jmkasunich> if the slow thread is 1mS, then the actual repetition will be 3mS
[03:17:24] <jmkasunich> fast thread won't have FP
[03:17:29] <SWPadnos> that would allow for different pulse rates for different channels
[03:17:35] <SWPadnos> fast thread doesn't need it
[03:17:59] <jmkasunich> what do you mean by "all updates" then?
[03:18:03] <SWPadnos> the slow thread recalculates the input float -> long as it needs to, and puts it in a "holding register"
[03:18:12] <SWPadnos> the fast thread reads fromt he holding register when it sees fit
[03:18:29] <SWPadnos> and puts that number into an "active register"
[03:18:30] <jmkasunich> which would be when it reaches 2.5mS probably
[03:18:49] <SWPadnos> it would allow for the fast thread to run separate timebases for the different outputs
[03:18:57] <jmkasunich> yeah
[03:19:08] <jmkasunich> I was assuming that different repetition rates wasn't needed
[03:19:16] <jmkasunich> and was optimizing for speed instead
[03:19:17] <SWPadnos> not that it's probably all that important to do that
[03:19:19] <jmkasunich> only one "now"
[03:19:23] <SWPadnos> right
[03:19:27] <jmkasunich> and have the timeouts sorted
[03:19:52] <jmkasunich> so if you have 12 channels, you don't have to compare "now" to 12 times every pass
[03:20:09] <jmkasunich> something like:
[03:20:16] <jmkasunich> now += period;
[03:20:28] <SWPadnos> I suspect that would be less efficient, since you'd have to find the correct channel if one times out
[03:20:30] <jmkasunich> while ( now > width[n] ) {
[03:20:53] <jmkasunich> output[chan[n] = 0;
[03:20:57] <jmkasunich> n++;
[03:20:58] <jmkasunich> }
[03:21:12] <jmkasunich> the width and chan arrays are both sorted from first to last timeout
[03:21:23] <jmkasunich> (sort done in the slow thread)
[03:21:24] <SWPadnos> ok
[03:21:29] <SWPadnos> hmmm
[03:21:37] <jmkasunich> n = 0 at startup
[03:21:48] <SWPadnos> and only resorted when now>2.5 ms?
[03:21:49] <jmkasunich> when n reaches num_chans, you know all pulses have ended
[03:22:30] <jmkasunich> yeah
[03:22:41] <SWPadnos> that sounds un-simple to me ;)
[03:23:03] <jmkasunich> why?
[03:23:42] <SWPadnos> well, the slow thread can't do anything until the fast thread is in some state (kind of arbitrarily chosen at compile-time)
[03:24:03] <jmkasunich> exactly, thats how you avoid races
[03:24:14] <jmkasunich> fast thread is inc'ing now
[03:24:17] <SWPadnos> the fast thread doesn't control its own settings, since they're changed once that limit is reached
[03:24:26] <jmkasunich> when now > 2.5mS, fast thread sleeps
[03:24:34] <SWPadnos> shadow / active time settings also do that
[03:24:39] <jmkasunich> slow thread updates all the pulse widths
[03:24:47] <jmkasunich> resets now, that wakes up fast thread
[03:25:09] <SWPadnos> and it prevents the fast thread from using multiple timebases
[03:25:26] <jmkasunich> a tradeoff I'm willing to make
[03:25:34] <jmkasunich> I want the fast period as fast as possible
[03:25:40] <jmkasunich> for better resolution
[03:25:55] <SWPadnos> true
[03:26:08] <jmkasunich> without the sort, the fast thread needs to do N compares every single time if you have N channels
[03:26:24] <jmkasunich> this way does only one compare, unless you actually have a timeout
[03:26:24] <SWPadnos> it's a single cache line in either case
[03:26:30] <SWPadnos> or possibly 2
[03:26:53] <jmkasunich> worst case (if all timeouts are the same) you do N compares once per output pulse
[03:27:11] <jmkasunich> if N is 12 and the width is a long, thats 48 bytes
[03:27:14] <jmkasunich> multiple lines
[03:27:26] <SWPadnos> sure - your method has N + (max setting/period) comparisons
[03:27:33] <SWPadnos> rather than
[03:27:37] <SWPadnos> sure - your method has N * (max setting/period) comparisons
[03:27:42] <SWPadnos> -sure
[03:27:59] <SWPadnos> argh - you get it though
[03:28:04] <jmkasunich> yeah
[03:28:06] <jmkasunich> ;-)
[03:28:16] <jmkasunich> actually, I should probably code it up both ways and time it
[03:28:17] <SWPadnos> silly me for up-arrowing too quickly
[03:28:24] <SWPadnos> that might make sense
[03:28:38] <jmkasunich> my method is much faster in the average case
[03:28:44] <SWPadnos> yes
[03:28:44] <jmkasunich> worst case, about the same
[03:29:01] <SWPadnos> "much faster" is relative though
[03:29:17] <jmkasunich> exactly, hence the need to measure
[03:29:19] <SWPadnos> if there are 150 cycles of overhead, and the method is 20 cycles faster, then it's not that big a deal
[03:29:20] <SWPadnos> yep
[03:29:43] <SWPadnos> damn - I just got a craving for some mackerel sushi
[03:29:52] <SWPadnos> or possibly pickled herring
[03:29:55] <jmkasunich> I'm assuming N might be large, like 10+
[03:29:56] <SWPadnos> (in cream sauce)
[03:30:07] <SWPadnos> yep
[03:30:31] <jmkasunich> for ( n = 0 ; n < N ; n++ ) {
[03:30:42] <jmkasunich> if ( now > width[n] ) {
[03:30:52] <jmkasunich> output[n] = 0;
[03:30:55] <jmkasunich> }
[03:30:57] <jmkasunich> }
[03:31:06] <SWPadnos> have you timed a stub function in a thread?
[03:31:14] <jmkasunich> no
[03:31:28] <SWPadnos> maybe I'll do that, to see the overhead
[03:31:38] <jmkasunich> some of the functions in "blocks" are pretty close to stubs
[03:31:43] <jmkasunich> mux2 for instance
[03:31:50] <SWPadnos> right
[03:31:55] <jmkasunich> heh, we could have a block called nop
[03:32:01] <SWPadnos> funny
[03:32:10] <jmkasunich> exports no pins or params, but does export a function
[03:32:15] <jmkasunich> function is empty
[03:32:35] <SWPadnos> "buffer" - out=in
[03:32:42] <jmkasunich> yeah
[03:32:49] <jmkasunich> that one actually serves a real purpose
[03:33:00] <jmkasunich> if you schedule it right, it becomes a 1 sample delay
[03:33:11] <SWPadnos> true
[03:33:35] <jmkasunich> if I ever get the "automatic scheduler" working it would be needed to break loops
[03:34:18] <jmkasunich> I was thinking about starting another multi-function module like blocks
[03:34:20] <jmkasunich> call it math
[03:34:39] <jmkasunich> move things like integ, ddt, sum from blocks
[03:34:53] <jmkasunich> add things like mult, abs
[03:35:15] <jmkasunich> maybe even sqrt (but how to deal with negative....)
[03:35:25] <SWPadnos> blocks should be integer only, and math do the FP stuff (with the exception of mux, possibly)
[03:35:30] <jmkasunich> even "mag" which calculates the magnitude of a vector
[03:35:40] <jmkasunich> sqrt(x*x+y*y+z*z)
[03:35:53] <SWPadnos> yep
[03:35:53] <jmkasunich> yeah
[03:36:14] <jmkasunich> btw, mux can do some interesting things besides just mux
[03:36:33] <jmkasunich> feed it output back to one input, put a signal on the other input, presto, a sample and hold
[03:36:43] <SWPadnos> man - mux2 has a max time of 3141 cycles
[03:36:49] <SWPadnos> there must be something wrong there
[03:36:51] <jmkasunich> thats insane
[03:37:10] <jmkasunich> how are you running it? with EMC? or standalone?
[03:37:11] <SWPadnos> sorry - the thread with mux2.0 only in it has that as the max
[03:37:16] <SWPadnos> standalone
[03:37:52] <jmkasunich> a thread with only one function should have the same time as the function itself
[03:37:57] <SWPadnos> it does
[03:38:13] <SWPadnos> the normal seems to be in the 800-1000 range
[03:38:22] <jmkasunich> thats still nutz
[03:38:25] <SWPadnos> I haven't connected any signals to the mux, just loaded it
[03:38:52] <SWPadnos> halcmd: show param
[03:38:54] <SWPadnos> Parameters:
[03:38:55] <SWPadnos> Owner Type Dir Value Name
[03:38:57] <SWPadnos> 02 s32 R- 995 mux2.0.time
[03:38:58] <SWPadnos> 02 s32 RW 3141 mux2.0.tmax
[03:39:48] <SWPadnos> oh, and this is what the thread time / max time looks like:
[03:39:50] <SWPadnos> Realtime Threads:
[03:39:52] <SWPadnos> Period FP Name (Time, Max-Time)
[03:39:53] <SWPadnos> 999849 YES test (795, 3141)
[03:39:55] <SWPadnos> 1 mux2.0
[03:40:05] <SWPadnos> though I think I added spaces around the parens before committing
[03:40:49] <jmkasunich> 02 s32 R- 98 mux2.0.time
[03:40:49] <jmkasunich> 02 s32 RW 1663 mux2.0.tmax
[03:40:49] <jmkasunich> j
[03:41:05] <SWPadnos> hmmm
[03:41:09] <jmkasunich> 98 is a lot more sane than 900
[03:41:14] <SWPadnos> I agree
[03:41:31] <jmkasunich> but 1600 is still pretty wild
[03:41:59] <SWPadnos> yeah - there must be some interrupt interrupting the thread executor (or something like that)
[03:42:37] <jmkasunich> shouldn't be, if its the fastest RTAI task, no other IRQs are allowed (I think)
[03:42:50] <jmkasunich> I take that back
[03:43:15] <jmkasunich> I don't think other IRQs are masked in hardware, so they still happen
[03:43:41] <jmkasunich> but RTAI/adeos just logs them, and doesn't invoke the Linux handler
[03:44:04] <SWPadnos> ok, so the "save for later" code probably runs
[03:44:09] <jmkasunich> when a timer interruppt happens, RTAI suspends linux and runs the RT task
[03:44:22] <SWPadnos> I'm running over remote X right now, so there are probably a lot of network interrupts happening
[03:44:42] <jmkasunich> if a Linux interrupt happens while the RT task is running, the interrupt still happens, and RTAI spends a uS or two logging it
[03:44:59] <jmkasunich> Linux will only get to handle it later, when the RT isn't running
[03:45:16] <SWPadnos> that's 500-1000 cycles on this machine
[03:45:57] <jmkasunich> that uS or 2 is out of my hat, I have no idea how long it actually takes
[03:46:28] <jmkasunich> for "time" I'm saw a low of 58
[03:46:34] <jmkasunich> typical seems to be 100-200
[03:46:34] <SWPadnos> sure - but it seems possible, given the numbers we're seeing
[03:47:26] <SWPadnos> 635 is the lowest I've seen
[03:47:31] <jmkasunich> wow, tmax is 13491 now
[03:47:34] <SWPadnos> max is up to 4054
[03:47:44] <SWPadnos> what's your thread period?
[03:47:51] <jmkasunich> 100uS
[03:48:08] <SWPadnos> ok. I set this one to 1 mS
[03:48:14] <SWPadnos> so I get fewer samples
[03:49:12] <jmkasunich> I get sub-100 about half the time
[03:49:37] <SWPadnos> hmmm - I can't seem to stop realtime
[03:49:45] <SWPadnos> this is a problem that the runscript has sometimes as well
[03:49:46] <jmkasunich> ?
[03:50:02] <jmkasunich> any messages, or does it just not work?
[03:50:15] <SWPadnos> well, I had an interactive halcmd running, and I exited from it
[03:50:32] <SWPadnos> then did scripts/realtime stop
[03:50:37] <SWPadnos> which didn't work
[03:50:53] <SWPadnos> so I used halcmd to do stop / unloadrt blocks / stop again
[03:50:59] <SWPadnos> and realtime stop still doesn't work
[03:51:10] <SWPadnos> I see a couple of lines in ps:
[03:51:12] <jmkasunich> define "doesn't work"
[03:51:17] <SWPadnos> 10289 ? D 0:00 /sbin/insmod /lib/modules/2.6.12.6-magma/rtai/rtai_up.ko
[03:51:19] <SWPadnos> 10290 ? D 0:00 \_ /sbin/insmod /lib/modules/2.6.12.6-magma/rtai/rtai_up.ko
[03:51:32] <SWPadnos> localhost:/Project/emc2# scripts/realtime stop
[03:51:34] <SWPadnos> ERROR: Module hal_lib is in use by threads
[03:51:35] <SWPadnos> ERROR: Module rtapi is in use by threads,hal_lib
[03:51:37] <SWPadnos> ERROR: Module rtai_sem is in use by rtapi
[03:51:38] <SWPadnos> ERROR: Module rtai_shm is in use by rtapi
[03:51:39] <SWPadnos> ERROR: Module rtai_fifos is in use by rtapi
[03:51:41] <SWPadnos> ERROR: Module rtai_up is in use by rtapi,rtai_sem,rtai_shm,rtai_fifos
[03:51:43] <SWPadnos> ERROR: Module rtai_hal is in use by rtapi,rtai_sem,rtai_shm,rtai_fifos,rtai_up
[03:51:44] <SWPadnos> ERROR: Module adeos is in use by rtai_up,rtai_hal
[03:51:45] <SWPadnos> ERROR: Could not unload 'hal_lib'
[03:51:47] <SWPadnos> ERROR: Could not unload 'rtapi'
[03:51:49] <SWPadnos> ERROR: Could not unload 'rtai_sem'
[03:51:50] <SWPadnos> ERROR: Could not unload 'rtai_shm'
[03:51:52] <SWPadnos> ERROR: Could not unload 'rtai_fifos'
[03:51:53] <SWPadnos> ERROR: Could not unload 'rtai_up'
[03:51:55] <SWPadnos> ERROR: Could not unload 'rtai_hal'
[03:51:56] <SWPadnos> ERROR: Could not unload 'adeos'
[03:51:59] <SWPadnos> that's my definition of "doesn't work" ;)
[03:52:04] <jmkasunich> ok ;-)
[03:52:20] <jmkasunich> first error msg: you can't unload hal_lib while other HAL modules are loaded
[03:52:33] <SWPadnos> same as all the others
[03:52:40] <jmkasunich> that explains the first failure, but not the oen after unloadrt
[03:52:54] <jmkasunich> right, the others follow from the first
[03:53:04] <SWPadnos> the weird part is that those two insmods are still in the process list
[03:53:13] <jmkasunich> yeah
[03:53:29] <SWPadnos> and I never did those - they're from halcmd or the realtime script
[03:53:34] <jmkasunich> lsmod still shows all the modules loaded, including threads and blocks?
[03:53:38] <SWPadnos> realtime
[03:53:43] <SWPadnos> yep - they're all there
[03:53:57] <SWPadnos> those insmods should have a parent somewhere, I think
[03:53:57] <jmkasunich> rtai_up.ko is the RTAI uniprocessor scheduler
[03:54:01] <SWPadnos> yep
[03:54:14] <jmkasunich> it was loaded by the realtime script, not halcmd
[03:54:15] <SWPadnos> that would be one of the first things the realtime script loads
[03:54:29] <jmkasunich> rtai_up.ko is "special"
[03:54:33] <jmkasunich> its a symlink
[03:54:54] <SWPadnos> hmmm
[03:54:59] <jmkasunich> from rtai_ksched.ko I think
[03:55:08] <jmkasunich> I fought with this over a year ago
[03:55:25] <jmkasunich> there is what I consider a bug in the way insmod/rmmod works
[03:55:50] <SWPadnos> I guess I agree, at this point
[03:55:54] <jmkasunich> insmod doesn't treat symlinks like most other apps
[03:56:13] <SWPadnos> no - you're supposed to use modules.comf or conf.modules or whatever it is
[03:56:20] <jmkasunich> I forget the details, but the end result is that you have to insmod it with one name and rmmod it with another
[03:56:44] <SWPadnos> I had this problem eysterday, and I was never able to get rid of it
[03:56:50] <SWPadnos> I rebooted
[03:57:02] <SWPadnos> (yesterday - still fiddling now)
[03:57:07] <jmkasunich> bin/halcmd unloadrt doesn't remove _any_ modules?
[03:57:21] <SWPadnos> I had only loaded one - blocks
[03:57:27] <jmkasunich> and threads?
[03:57:33] <SWPadnos> yep
[03:57:53] <jmkasunich> according to your error messages, threads is still there
[03:58:02] <SWPadnos> better - thanks ;)
[03:58:24] <jmkasunich> but unloadrt should have removed that
[03:58:31] <SWPadnos> it didn't
[03:58:52] <SWPadnos> that wasn't the problem yesterday - I had just run emc, and hadn't loaded threads
[03:59:07] <SWPadnos> I might have manually loaded scope_rt or something, but I manually removed it
[03:59:37] <SWPadnos> I didn't even notice that there was a problem until long after I had shut down axis
[04:00:18] <jmkasunich> can't duplicate it here
[04:00:29] <jmkasunich> not too surprising, we have completley different kernels
[04:00:34] <jmkasunich> and versions of RTAIU
[04:00:59] <SWPadnos> 2.6.12.6-magma here
[04:01:03] <jmkasunich> so its _all_ better now? everything unloaded as it should?
[04:01:08] <SWPadnos> you have .9 or .12, right?
[04:01:14] <SWPadnos> yes, and I've reloaded
[04:01:24] <jmkasunich> 2.6.12-magma
[04:01:25] <SWPadnos> I wanted to change the period to 100 uS or so ;)
[04:01:40] <SWPadnos> ok, so the kernels are pretty similar then
[04:01:54] <jmkasunich> any insmod entries in ps now?
[04:02:37] <SWPadnos> yep - those same two
[04:02:43] <SWPadnos> well, not the same PID
[04:03:07] <SWPadnos> but still two, detached from any process owned by my shells
[04:04:41] <SWPadnos> very interesting
[04:04:51] <SWPadnos> my times are now similar to yours
[04:04:59] <SWPadnos> with a 20 uS thread period
[04:06:05] <jmkasunich> bizarre
[04:06:47] <SWPadnos> using watch -n 1, I see most of the times well under 100, and the max is now 3527
[04:06:55] <jmkasunich> I don't get insmod's in ps, but I do get:
[04:07:09] <jmkasunich> 11350 ? 00:00:00 RTAI_KTHRD_M:0
[04:07:09] <jmkasunich> 11351 ? 00:00:00 F:HARD:0:1
[04:07:29] <SWPadnos> are they parent/child? (use ps axf)
[04:08:06] <jmkasunich> duh, they are insmods
[04:08:12] <jmkasunich> 11350 ? D 0:00 /sbin/insmod /usr/realtime-2.6.12-magma/modules/rtai_up.ko
[04:08:13] <jmkasunich> 11351 ? D 0:00 \_ /sbin/insmod /usr/realtime-2.6.12-magma/modules/rtai_up.ko
[04:08:22] <SWPadnos> ok, same as me
[04:08:42] <SWPadnos> I like that f option, I'm glad cradek mentioned it one time ;)
[04:08:48] <jmkasunich> heh, before I was trying to figure out what the \_ in your paste was
[04:08:57] <SWPadnos> indeed
[04:09:23] <SWPadnos> hmmm - the thread period is reported in ns
[04:09:29] <jmkasunich> yeah
[04:09:34] <jmkasunich> and the "times" in clocks
[04:09:45] <jmkasunich> kinda sucks, but....
[04:09:56] <SWPadnos> right - the thread number is returned from RTAI
[04:10:22] <SWPadnos> I was thinking that the same code could be used for reporting ns in the execution times
[04:10:37] <jmkasunich> we certainly don't want to be specifying thread periods in clocks ;-/
[04:10:43] <SWPadnos> no way
[04:10:55] <SWPadnos> I'd prefer the execution times in human units ;)
[04:11:16] <jmkasunich> I have mixed feeling about that
[04:11:30] <jmkasunich> clocks is actually interesting when we're comparing two different CPUs
[04:11:38] <SWPadnos> true
[04:11:47] <jmkasunich> our numbers should be reasonable similar, since the code is the same
[04:11:58] <jmkasunich> otherwise we'd have to correct for CPU speed
[04:12:09] <SWPadnos> try a thread period of 1 ms, and see what happens
[04:12:21] <jmkasunich> stand by
[04:13:46] <jmkasunich> freaky, same results as you
[04:13:57] <SWPadnos> good, it's reproducible ;)
[04:14:06] <jmkasunich> most time its a couple hundred, I think the lowest I saw is 196
[04:14:10] <jmkasunich> max is only 1700
[04:14:19] <jmkasunich> 2193 now
[04:14:42] <jmkasunich> 10673 now
[04:15:02] <SWPadnos> the max seems pretty constant, but the average is way lower with a shorter period
[04:15:31] <jmkasunich> my average is running around 1000
[04:15:41] <SWPadnos> ok, same as mine was
[04:15:42] <jmkasunich> all I can say is wtf?
[04:15:53] <SWPadnos> can't argue with that
[04:16:01] <jmkasunich> gonna take a couple more data points
[04:16:04] <jmkasunich> 10mS, etc
[04:16:25] <SWPadnos> right. mine is at 20 uS, whereas you did 100 at first
[04:16:31] <jmkasunich> try 900uS
[04:16:44] <SWPadnos> can you change thread periods without reloading HAL/RTAI?
[04:17:05] <jmkasunich> I'm not sure
[04:17:10] <jmkasunich> play it safe, reload
[04:17:21] <SWPadnos> ok
[04:18:35] <jmkasunich> 10mS seems same as 1mS
[04:20:20] <jmkasunich> 900uS was bad, 500uS seems good
[04:20:37] <SWPadnos> sorry - writing a short script to aid me ;)
[04:20:58] <jmkasunich> good idea
[04:21:27] <jmkasunich> is the bash history accessible (to paste into the editor)?
[04:21:28] <SWPadnos> want it?
[04:21:36] <SWPadnos> I can paste it in
[04:21:43] <jmkasunich> ok
[04:21:57] <SWPadnos> le me just check that it unloads cleanly
[04:21:58] <jmkasunich> I have my 8 lines in the terminal window, I could copy that I guess
[04:22:25] <SWPadnos> #!/bin/bash
[04:22:26] <SWPadnos> # a very simple HAL thread execution time tester
[04:22:27] <SWPadnos> scripts/realtime start
[04:22:29] <SWPadnos> bin/halcmd loadrt threads name1=test period1=$1 || exit 1
[04:22:31] <SWPadnos> bin/halcmd unloadrt threads
[04:22:32] <SWPadnos> bin/halcmd loadrt blocks mux2=1
[04:22:34] <SWPadnos> bin/halcmd addf mux2.0 test
[04:22:35] <SWPadnos> bin/halcmd start
[04:22:37] <SWPadnos> watch -n 1 bin/halcmd -s show thread
[04:22:39] <SWPadnos> bin/halcmd stop
[04:22:40] <SWPadnos> bin/halcmd unloadrt blocks
[04:22:42] <SWPadnos> scripts/realtime stop
[04:22:43] <SWPadnos> the arg is the period to test in ns
[04:22:47] <SWPadnos> I suppose I could have made that in microseconds
[04:22:59] <jmkasunich> ns is fine ;-)
[04:23:45] <SWPadnos> ctrl-C to stop the watch, of course
[04:24:56] <jmkasunich> oops
[04:25:06] <jmkasunich> I don't have your latest halcmd
[04:25:14] <jmkasunich> I was doing show param mux2.0.t
[04:25:26] <SWPadnos> ah - easy to change in the script
[04:25:40] <jmkasunich> done
[04:25:58] <SWPadnos> I guess the exit 1 isn't the best idea there
[04:27:01] <jmkasunich> 600uS is good, 700 bad
[04:27:17] <SWPadnos> weird
[04:27:34] <SWPadnos> 1 second, 100 ms, and 10 ms are all bad
[04:28:23] <SWPadnos> your processor is a sempron 2800, at 1.6 GHz, right?
[04:28:28] <jmkasunich> yes
[04:28:49] <SWPadnos> well that doesn't help ;)
[04:29:15] <SWPadnos> I don't see any "normal" boundary in the 600-700 uS range at 1.6 GHz
[04:30:44] <SWPadnos> unless it's simply cache getting cold
[04:30:58] <jmkasunich> yes!
[04:31:27] <jmkasunich> now I have a different wtf
[04:31:30] <SWPadnos> interesting test if that's it
[04:31:35] <jmkasunich> looking at .time with scope
[04:31:48] <jmkasunich> it appears to be at 50 most of the time
[04:31:59] <jmkasunich> with spikes that go much higher
[04:32:13] <jmkasunich> but the watch _never_ sees it that low
[04:32:32] <SWPadnos> what thread period?
[04:33:02] <jmkasunich> duh, the watch invokes halcmd which gets loaded from disk (or at least disk cache), so when halcmd is looking at .time, .time is guaranteed to be not so good
[04:33:34] <SWPadnos> halcmd doesn't execute in the thread
[04:33:48] <SWPadnos> and the disk cache wouldn't affect the processor cache all that much
[04:33:49] <jmkasunich> no, but halcmd and watch executing flushes cache
[04:33:53] <SWPadnos> right
[04:33:56] <SWPadnos> hmm
[04:34:07] <jmkasunich> watch, bash, the kernel loading halcmd, halcmd itself, etc
[04:34:19] <jmkasunich> scope on the other hand samples in the RT thread
[04:34:25] <SWPadnos> right
[04:34:34] <jmkasunich> the display code would flush cache, but that is less often
[04:34:48] <SWPadnos> ok, but in the 20 uS case, it's faster than the cache can get flushed (on this machine)
[04:35:13] <jmkasunich> its gotta be cache
[04:35:15] <SWPadnos> is your cache 256k or 512k?
[04:35:37] <SWPadnos> probably 512
[04:35:41] <jmkasunich> changed the scope to 16K samples of one channel, the trace is 10 seconds long
[04:35:42] <jmkasunich> yes
[04:35:51] <jmkasunich> and I see a burst of high times every second
[04:36:03] <SWPadnos> okk, when the watch fiires
[04:36:15] <SWPadnos> eeeenteresting
[04:36:21] <jmkasunich> gonna find out, changing the watch to 2 seconds
[04:37:11] <SWPadnos> we've had discussions regarding cache, and the assumption that it would be totally cold at the servo rate
[04:37:26] <SWPadnos> I guess that's true, unless you want to get that rate down to 500 uS
[04:37:42] <jmkasunich> the bursts are now 2 seconds apart
[04:37:52] <SWPadnos> cool
[04:38:09] <jmkasunich> the baseline execution for mux2.0 is about 48clocks
[04:38:18] <SWPadnos> so, with halscope, this is a good cche eviction tester ;)
[04:38:38] <SWPadnos> I saw 54 a lot, then toggling to 78
[04:38:43] <SWPadnos> at 20 uS period
[04:39:11] <cradek> hi guys
[04:39:18] <SWPadnos> hi
[04:39:30] <SWPadnos> oops, 58 toggling to 74
[04:39:51] <SWPadnos> cradek, what's your CPU?
[04:40:10] <jmkasunich> I think I've got 43, 47, then a wide variety of higher times
[04:41:00] <cradek> SWPadnos: my good machine is a sempron 3200 I think (2GHz)
[04:41:18] <SWPadnos> ok. are you on a machine that can run RTAI right now?
[04:41:33] <jmkasunich> we're finding out all kinds of fun things about cache flushing and such
[04:41:37] <cradek> I can ssh to it
[04:41:58] <SWPadnos> ok. if you can scroll back a bit, there's a script that tests thread execution time
[04:42:00] <cradek> model name : AMD Sempron(tm) Processor 3300+
[04:42:05] <SWPadnos> cool
[04:42:19] <SWPadnos> if you have the latest halcmd, with thread time printed for show thread
[04:42:40] <SWPadnos> if not, then there's a simple change for the script
[04:43:15] <cradek> insmod: error inserting '/home/chris/emc2.head/rtlib/threads.ko': -1 Invalid parameters
[04:43:31] <cradek> [1397256.239288] threads: `' invalid for parameter `period1'
[04:43:34] <SWPadnos> try using a period as an argument to the script
[04:43:45] <jmkasunich> script 100000
[04:43:48] <SWPadnos> of course, now you have to clean up after my stupid script ;)
[04:44:02] <jmkasunich> bin/halcmd unloadrt all ; scripts/realtime stop
[04:44:17] <jmkasunich> THREAD test
[04:44:17] <jmkasunich> MAXCHAN 1
[04:44:17] <jmkasunich> HMULT 1
[04:44:17] <jmkasunich> HZOOM 1
[04:44:17] <jmkasunich> HPOS 4.890000e-01
[04:44:18] <jmkasunich> CHAN 1
[04:44:19] <cradek> ok it's running
[04:44:20] <jmkasunich> PARAM mux2.0.time
[04:44:23] <SWPadnos> ooooh - I didn't know about unloadrt all
[04:44:24] <jmkasunich> VSCALE 7
[04:44:26] <jmkasunich> VPOS 1.000000
[04:44:28] <jmkasunich> VOFF 0.000000e+00
[04:44:30] <jmkasunich> TMODE 1
[04:44:38] <jmkasunich> RMODE 1
[04:44:39] <cradek> 99733 YES test mux2.0
[04:44:40] <jmkasunich> stuff the above into .scope.cfg
[04:44:48] <SWPadnos> ok - ctrl-c out of the watch
[04:45:05] <SWPadnos> you should use the halscope method, if you have X available
[04:45:21] <jmkasunich> in the script, change the watch line to "watch -n 1 bin/halcmd -s show param mux2.0.t"
[04:45:26] <SWPadnos> or change the script to use halcmd show param mux instead of show thread
[04:47:41] <cradek> blocks s32 R- 87 mux2.0.time
[04:47:42] <cradek> blocks s32 RW 18501 mux2.0.tmax
[04:47:43] <jmkasunich> wow, X redraws really fsck it up
[04:47:51] <SWPadnos> heh - AGP?
[04:48:49] <jmkasunich> I dragged the scope window around for a second while it was acquiring
[04:49:24] <SWPadnos> apparently, there are a lot of warnings about AGP and linux/RT
[04:49:34] <jmkasunich> it goes from ~50 with occaisional spikes of 150, to a massive fuzzball, minimum around 200, max about 1000
[04:49:34] <SWPadnos> though those are Ingo's RT patches, not RTAI
[04:49:56] <SWPadnos> just whip the mouse arounda lot, see what happens
[04:50:30] <jmkasunich> similar, but a lot milder
[04:50:35] <SWPadnos> ok
[04:50:45] <SWPadnos> hardware accelerated mouse, probably ;)
[04:51:37] <jmkasunich> its gotta be cache effects
[04:51:46] <jmkasunich> but I'm amazed how severe they are
[04:51:53] <jmkasunich> changed to 50uS period
[04:52:06] <jmkasunich> still a lot of fuzz when I drag the window around
[04:52:09] <jmkasunich> but not as tall
[04:52:11] <SWPadnos> well - we were talking about the relative cpu/bus speeds a few days ago
[04:53:10] <jmkasunich> with 50uS, the fuzz from dragging a window is bursty
[04:53:15] <jmkasunich> seems like 16mS or so
[04:53:24] <jmkasunich> (which corresponds to the frame rate ;-)
[04:53:39] <SWPadnos> heh
[04:54:11] <jmkasunich> most of that fuzz tops out at about 400
[04:54:46] <SWPadnos> are you getting much tearing when you drag windows around?
[04:54:52] <jmkasunich> tearing?
[04:54:59] <jmkasunich> you mean screen nastyness?
[04:55:11] <jmkasunich> not really
[04:55:15] <SWPadnos> umm - the window not updating in a single chunk - like horizontal lines where it's cut
[04:55:32] <jmkasunich> nope
[04:55:37] <SWPadnos> ok
[04:55:58] <jmkasunich> this is a nvidia card, but I don't think its using a nvdia binary driver
[04:56:04] <jmkasunich> that is known to be bad for RT
[04:56:28] <jmkasunich> thats a different thing anyway, that is interrupt latency (I think)
[04:56:37] <jmkasunich> .time won't show latency
[04:56:47] <SWPadnos> hmmm - maybe I won't try getting RTAI / amd64 / smp / ubuntu / nvidia working on my big machine then ;)
[04:57:56] <cradek> it makes me sad that the nvidia driver is broken
[04:58:08] <cradek> I love my nvidia card
[04:58:10] <jmkasunich> just got 13,000 clocks
[04:58:17] <SWPadnos> damn
[04:58:29] <SWPadnos> I like mine as well - a 7800GT
[04:58:48] <SWPadnos> it seems to run great with the non-RT SMP kernel
[04:59:48] <cradek> it runs with the rt kernel, but gl updates cause latency glitches
[04:59:57] <cradek> err overruns
[05:00:01] <SWPadnos> like the ones jmk is seeing?
[05:00:05] <SWPadnos> ah - real ones
[05:00:05] <jmkasunich> I wonder what makes the really bad ones.... I've got the scope set to trigger on 1000
[05:00:19] <jmkasunich> its gone close to a minute with no trigger
[05:00:22] <cradek> I don't know
[05:00:44] <SWPadnos> it does seem weird that after the thread execution function loads, there would be such a change
[05:01:04] <SWPadnos> the mux2 code must be around 100 bytes long or less
[05:01:17] <SWPadnos> plus a couple of regions of memory for pointers and vars
[05:01:19] <jmkasunich> we're talking about a chunk of code that is maybe 10 lines of C or less, normally takes 43-47 clocks to run
[05:01:32] <jmkasunich> and every few minutes, it takes thousands of clocks
[05:02:26] <SWPadnos> hmmm - well, that makes sense then
[05:02:45] <jmkasunich> what makes sense?
[05:02:54] <SWPadnos> consider that the cache may need up to 256 bytes, since there are the function pointers, the thread timing vars, etc
[05:03:09] <SWPadnos> then there's the function itself (both the thread executor and the mux function)
[05:03:39] <SWPadnos> memory runs at 1/4 the CPU clock, so that would be several hundred clocks
[05:04:22] <SWPadnos> actually, DDR400 at CL2 is probably 16 clocks for a 4-word transfer (2-2-2-5 + a couple for commands)
[05:04:40] <jmkasunich> so 4 clocks per word, 1 per byte (more or less)
[05:04:42] <SWPadnos> though those words should be 8 bytes each, so it's still 2 bytes per clock
[05:04:46] <SWPadnos> sure
[05:05:00] <SWPadnos> the 256 byte estimate is just off the top of my head
[05:05:13] <jmkasunich> probalby a bit high
[05:05:29] <SWPadnos> no wait, it's 2 CPU clocks per byte, 1/2 memory clock
[05:05:50] <jmkasunich> ok, 2 clocks per byte, that means 1000 or so for 256 bytes
[05:05:57] <SWPadnos> well, the thread execution function, plus the mux function, plus every region containing a var referenced by either
[05:06:20] <jmkasunich> I can buy that, when I drag around a window thats about what I see
[05:06:24] <SWPadnos> just accessing the 3 pins for the mux2 could be 2 cache lines
[05:06:43] <jmkasunich> the pins aren't connected to anything
[05:06:56] <SWPadnos> they're conected to the dummy signals
[05:06:59] <SWPadnos> ?
[05:07:00] <jmkasunich> all three pin ptrs are in the same struct, probalby the same line
[05:07:07] <SWPadnos> ok - could be
[05:07:11] <jmkasunich> the dummies are likely to be in different lines
[05:07:35] <jmkasunich> hmm, if I make a signal, and connect all three pins to it....
[05:07:41] <SWPadnos> yep - each pin is guaranteed to be a separate line, since the struct is larger than a line
[05:07:51] <SWPadnos> no, because you still go double-indirect
[05:08:05] <SWPadnos> *(pin->ptr)
[05:08:27] <SWPadnos> so pin, ptrm and whatever it points to are all accessed
[05:08:32] <SWPadnos> ptr
[05:09:04] <jmkasunich> pin only gets accessed once
[05:09:24] <SWPadnos> 2 pins, plus 1 param
[05:09:29] <jmkasunich> never mind me
[05:09:33] <SWPadnos> heh
[05:10:13] <jmkasunich> anyway, by linking all three pins to a sig (and the sel pin to another sig) I probably eliminate 2, maybe 3 cache lines
[05:10:24] <jmkasunich> but there are probably dozens total
[05:10:32] <SWPadnos> probably
[05:10:36] <jmkasunich> dozen anyway
[05:10:42] <jmkasunich> 2-3-4 for code
[05:10:56] <SWPadnos> look at the thread execution function
[05:10:58] <jmkasunich> one for the function entry struct
[05:11:14] <jmkasunich> one for the function struct (time. tmax)
[05:11:24] <SWPadnos> one or 2 CPU cycles can burn through 10 bytes of code
[05:11:25] <jmkasunich> a couple for stack vars
[05:11:49] <jmkasunich> you know what this means?
[05:11:56] <SWPadnos> uh - no
[05:12:36] <jmkasunich> when coding for RT control (where loops with N = 50, 100, 10000 are rare), nothing, absolutely nothing, matters as much as code size and data size
[05:12:53] <SWPadnos> partly true
[05:13:10] <SWPadnos> the larger the function, the lower the percentage penalty for cold cache, especially with loops ;)
[05:13:30] <SWPadnos> but data affinity is pretty critical
[05:13:48] <jmkasunich> how big is a line? 16 or 32?
[05:14:00] <SWPadnos> I think it's 32 bytes, 4 cycles at 8 bytes each
[05:14:23] <jmkasunich> even 32 isn't much when most variables are 4 bytes
[05:14:24] <SWPadnos> it may vary by CPU type though
[05:14:28] <SWPadnos> right
[05:15:01] <jmkasunich> code size matters a lot too
[05:15:27] <SWPadnos> true - I was rethinking my previous statement, and the delay is linear in code size
[05:15:50] <SWPadnos> but less of an issue when functions are reused or with loops
[05:15:52] <jmkasunich> if the initial (cold cache) fetch takes 10+ times as long as subsequent fetches, a loop over say 3 axis is nearly irrelevant
[05:16:12] <jmkasunich> s/irrelevant/free/
[05:16:15] <SWPadnos> hmm - that means that optimizing for code size may be better than for speed, unless gcc is very smart about cache
[05:16:18] <jmkasunich> except for the data fetches
[05:16:42] <jmkasunich> and loop unrolling is _not_ a good idea
[05:16:47] <SWPadnos> right
[05:16:50] <cradek> -Os
[05:17:05] <SWPadnos> do you think gcc is very smart about cache?
[05:17:12] <jmkasunich> no idea
[05:17:30] <SWPadnos> Os is size, right?
[05:17:36] <jmkasunich> no idea
[05:17:39] <jmkasunich> ;-)
[05:17:39] <SWPadnos> cradek
[05:17:43] <SWPadnos> heh
[05:17:47] <cradek> eh
[05:17:52] <cradek> yes, that's size
[05:17:57] <SWPadnos> yep - got it
[05:17:59] <cradek> I use it all the time on atmels
[05:18:05] <SWPadnos> heh
[05:18:10] <SWPadnos> no cache there ;)
[05:18:26] <cradek> 2k of program rom...
[05:18:32] <jmkasunich> what's bugging me now isn't the 50 to 500 slowdown, its the 10,000 slowdown
[05:18:37] <SWPadnos> 2313 all the way
[05:18:45] <SWPadnos> or tiny / mega version now
[05:19:34] <cradek> I did a localtime+UTC clock with ntsc display on a (very full) 2313
[05:19:57] <SWPadnos> in C? that's impressive
[05:19:59] <cradek> for display on a camera viewfinder crt
[05:20:11] <SWPadnos> cool
[05:20:13] <cradek> just a little unrolled asm
[05:20:20] <cradek> but almost all C
[05:20:37] <SWPadnos> interesting. interrupts in asm, most of the rest in C?
[05:21:11] <cradek> no, the asm part is lpm & clock out the data to generate the characters
[05:21:21] <SWPadnos> ah
[05:21:27] <cradek> interrupts in C (the trick is to put the thing to sleep before the next intr comes)
[05:21:42] <cradek> otherwise the timing can be off an instruction
[05:21:47] <SWPadnos> how is gcc with the various memory types these days (eeprom, flash, sram, etc)?
[05:22:22] <cradek> I use mostly the older chips, but I could write to eeprom etc with some trickery I forget now
[05:22:24] <jepler> Normal instructions only address sram
[05:22:24] <SWPadnos> that was the biggest impediment to me using a compiler for a long time
[05:22:39] <jepler> you make special calls to read flash, eeprom
[05:22:45] <cradek> right
[05:22:58] <jmkasunich> I just did a "du /" which thrashed the disk pretty hard for about a minute
[05:22:59] <SWPadnos> ok, are there register vars, or are they all used by gcc?
[05:23:00] <jepler> there are _p versions of some APIs to take strings from flash
[05:23:07] <jmkasunich> got about 10 of those 10,000 clock delays during that
[05:23:18] <SWPadnos> SATA or IDE?
[05:23:21] <jmkasunich> IDE
[05:23:24] <SWPadnos> hmm
[05:24:28] <jmkasunich> is running make while the code is running in place a bad idea
[05:24:56] <SWPadnos> depends on how the linker writes the output files
[05:25:45] <SWPadnos> (similar to the text editor / emc GUI question we discussed ages ago)
[05:27:58] <cradek> goodnight, guys
[05:28:02] <jmkasunich> night
[05:28:05] <SWPadnos> see you later
[05:28:07] <cradek> I hope to fix the last known bug in the tp this weekend
[05:28:12] <SWPadnos> hmm - that reminds me
[05:28:14] <jmkasunich> yay!
[05:28:14] <cradek> maybe we'll make another TESTING release
[05:28:18] <SWPadnos> kewl
[05:28:26] <cradek> well actually it's not the tp, it's in task
[05:28:39] <jmkasunich> strange, now I'm getting:
[05:28:40] <SWPadnos> what is it?
[05:28:40] <jmkasunich> ERROR: Removing 'blocks': Operation not permitted
[05:28:40] <jmkasunich> HAL:0: ERROR: rmmod failed, returned 255
[05:28:40] <jmkasunich> E
[05:28:51] <jmkasunich> duh
[05:29:00] <SWPadnos> sudo?
[05:29:03] <jmkasunich> the make removed setuid from modulehelper
[05:29:08] <SWPadnos> ah
[05:29:30] <jmkasunich> yep, that fixed it
[05:29:41] <SWPadnos> sudo make setuid is your friend
[05:29:58] <jmkasunich> not running make while the program is going is also my friend
[05:30:06] <SWPadnos> heh
[05:30:17] <SWPadnos> maybe compiling the kernel would be better ;)
[05:30:25] <SWPadnos> takes longer, too
[05:30:35] <jmkasunich> too much like work
[05:31:00] <jmkasunich> wow, 16000 samples takes a long time at 100Hz
[05:31:06] <SWPadnos> indeed
[05:31:58] <jepler> I wonder how long
[05:32:13] <SWPadnos> hmmm. 2 minutes 40 seconds, perhaps?
[05:32:27] <jmkasunich> a lot longer than I was expecting, since the last time I ran it the sample rate was 50KHz
[05:33:01] <SWPadnos> I was fiddling with the new scope yesterday - it's really fast
[05:33:14] <jmkasunich> what kind?
[05:33:22] <SWPadnos> Agilent MSO6104A
[05:33:28] <jmkasunich> how fast?
[05:33:35] <jmkasunich> GS/sec
[05:33:37] <jmkasunich> ?
[05:33:37] <SWPadnos> 1 GHz, 4 analog + 16 digital channels, 4 GSamples/sec
[05:33:44] <jmkasunich> nice
[05:33:49] <SWPadnos> color 1024x768 LCD
[05:33:54] <jmkasunich> is that RT or ET sampling
[05:33:58] <SWPadnos> RT
[05:34:03] <jmkasunich> zoomy
[05:34:10] <SWPadnos> it's got 1 GHz bandwidth
[05:34:33] <jmkasunich> there are scopes that have high bandwidth, but low RT sample rates
[05:34:34] <SWPadnos> the probe setup lets you calibrate each channel for probe delays
[05:34:39] <SWPadnos> yep
[05:34:46] <jmkasunich> they do ET sampling on repetitive signals
[05:34:50] <SWPadnos> I hate EQTS - it's useless for glitch capture
[05:34:54] <jmkasunich> right
[05:35:10] <jmkasunich> our Tek's will switch into ET if you turn the sweep rate too fast
[05:35:21] <jmkasunich> if you aren't paying attention, you wind up cussing later
[05:35:28] <SWPadnos> that's part of why I don't like Teks much
[05:35:49] <SWPadnos> LeCroy or Agilent, but I like the UI for the Agilent better
[05:36:09] <SWPadnos> and LeCroy starts at around the cost of a house
[05:38:47] <jmkasunich> well, my eyes are starting to slam shut
[05:38:52] <SWPadnos> heh
[05:38:58] <SWPadnos> it is getting late
[05:39:00] <jmkasunich> never did get going on the joystick code
[05:39:10] <SWPadnos> oops - my fault ;)
[05:39:35] <jmkasunich> I'm very easily distracted
[05:40:08] <SWPadnos> and I'm oh so distracting
[05:40:08] <jmkasunich> hmh, even with a 10mS period (plenty of time for cache to get cold) I don't see anything over 2500 or so
[05:40:22] <jmkasunich> triggering on 5000, its been five minutes plus, nothing
[05:40:29] <SWPadnos> there must be some interrupts or something that are doing it
[05:40:53] <jmkasunich> tried the du / again, but I think most of the dirs were in disk cache, it was 10 times faster
[05:41:08] <jmkasunich> whats an easy way to thrash disk?
[05:41:18] <SWPadnos> updatedb?
[05:41:34] <SWPadnos> or copy a large tree and then sync
[05:44:28] <jepler> find / | xargs md5sum ?
[05:44:39] <SWPadnos> heh
[06:16:21] <jmkasunich> that actually works pretty well
[06:16:23] <jmkasunich> ;-)
[06:16:38] <jmkasunich> tried it on a much smaller tree first
[06:17:08] <jmkasunich> but its been chewing on / for about 15 mins, and I get a 10,000 clock hit every minute or so
[06:17:31] <jmkasunich> seems like it must be disk related
[07:09:51] <SWPadnos> SWPadnos is now known as SWP_Away
[16:05:34] <alex_joni> hi jeff
[16:06:28] <alex_joni> anyone around?
[16:06:59] <jepler> hi alex
[16:07:24] <alex_joni> what's up?
[16:07:32] <alex_joni> at home I hope..
[16:07:52] <jepler> yeah, at home
[16:08:17] <jepler> oh I thought I found the right tool to help create a live cd with the realtime kernel but I can't get it to work. "kernel-wedge".
[16:08:54] <alex_joni> wedgie?
[16:10:07] <jepler> I'm not sure why it's called that
[16:10:56] <alex_joni> http://www.wedgiegirls.com/chooseyourwedgie.htm
[16:10:57] <alex_joni> LOL
[16:12:14] <alex_joni> probably not related
[16:13:03] <jepler> where the heck did you find that website?
[16:13:05] <jepler> you're creeping me out
[16:13:17] <alex_joni> ROFL
[16:13:21] <alex_joni> google
[16:13:29] <alex_joni> one of the first hits on wedgie
[16:13:41] <alex_joni> lol... never seen it before, I swear ;)
[16:15:12] <alex_joni> * alex_joni needs to go home..
[16:15:21] <alex_joni> it's saturday 18:15, and I'm stll at work :(
[16:19:28] <jepler> yes, go home!
[16:27:01] <alex_joni> I hate LCD's
[16:27:07] <alex_joni> especially when I need to move them
[16:27:18] <alex_joni> and I need to remove that foot
[16:27:32] <alex_joni> those things weren't designed to be removed after you mount them once
[16:44:29] <Roguish> good morning, anybody here?
[16:55:28] <alex_joni> not really
[16:55:30] <alex_joni> :-P
[16:56:55] <alex_joni> * alex_joni goes home..
[16:56:58] <alex_joni> later everyone
[16:57:08] <Roguish> what is the status of the 'testing' end of emc2?
[16:57:47] <alex_joni> TESTING is the one you should use
[16:58:00] <alex_joni> HEAD has some improvements, but may be broken at any time
[16:58:12] <alex_joni> when HEAD is found to be ok, TESTING gets moved
[16:58:45] <Roguish> i have it installed and compiled and running as of several weeks ago. should i update? if so, how?
[16:58:53] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?EmcVersion2_Release_Status
[16:59:08] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?Testing
[17:00:04] <Roguish> ok. sounds good, thanks.
[17:02:58] <Roguish> is there a list of available signals in hal?
[17:07:52] <SWP_Away> SWP_Away is now known as SWPadnos
[17:08:35] <SWPadnos> Roguish, not really. The signals available are dependent on what modules / drivers are loaded, load-time options, and what hardware is detected
[17:11:47] <Roguish> should i be over at emc, rather than here at emc-devel?
[17:13:34] <SWPadnos> for this kind of question, it's probably more appropriate ;)
[17:13:48] <SWPadnos> I don't think there are a lot of the regulars in there right now, though
[17:14:51] <Roguish> i am trying to get the big picture of emc2, hal, etc...... i have a mesa 5i20 card and 'testing' installed.
[17:15:11] <SWPadnos> ah. in that case, there will be a *lot* of pins in your HAL ;)
[17:15:22] <SWPadnos> you can find them all by running halcmd show pin
[17:15:40] <SWPadnos> (with emc running)
[17:16:13] <Roguish> yes, i've been there. i'm trying to find a cross-reference to the hal pin to phyical pin. any clue?
[17:16:33] <SWPadnos> ah, I'm not sure how the m5i20 driver maps pins
[17:16:50] <SWPadnos> hold on one sec - let me take a look at the source
[17:18:15] <SWPadnos> hmmm.
[17:18:22] <SWPadnos> well, the source isn't all that instructive
[17:18:27] <Roguish> that's what i mean.
[17:18:30] <SWPadnos> heh
[17:19:09] <SWPadnos> I think the vhdl files are from mesa electronics, so if there's a pinout on their site, that would be a place to start
[17:19:23] <Roguish> i've been all over, through the hal files, through the driver file, and even into the fpga programming files.
[17:19:52] <SWPadnos> well - I can say for sure that you've ideintified a needed piece of documentation
[17:19:57] <SWPadnos> (in case you couldn't tell ;) )
[17:20:41] <Roguish> great.......check the file: hostm54e.pin
[17:21:20] <SWPadnos> yeah, that's really useful without a schematic
[17:21:37] <SWPadnos> there may be a schematic on the mesa site though
[17:22:34] <Roguish> unfortunately not. mesa is just a few miles away. i picked up the card at their office. very nice folks.
[17:22:57] <SWPadnos> hmmm
[17:23:40] <Roguish> may have to go back for a little more info. i have contacted peterv a while ago, but my last email (last night) seemed to bounce back.
[17:24:00] <SWPadnos> hmmm
[17:24:17] <SWPadnos> actually, there is a pinout on their site
[17:24:31] <SWPadnos> http://www.mesanet.com/pdf/parallel/5i20ds.pdf
[17:24:52] <SWPadnos> it shows what header pins connect to which IC pins
[17:25:36] <Roguish> checking that...........
[17:26:01] <SWPadnos> that pdf, along with the hostm54e.pin file will tell you what you need (sort of)
[17:26:58] <SWPadnos> oh, I hadn't noticed the port pin column in hostm54e
[17:27:05] <Roguish> i am looking for the extra io's. there are supposed to be 8 each, but i can't really tell which header and pin they go to.
[17:27:27] <SWPadnos> what are the HAL names?
[17:29:16] <SWPadnos> might those extra 8 pins be the LEDs?
[17:29:27] <Roguish> looking at m5i20_io.hal: the MistOn signal goes to m5i20.0.out-05 where is out-05?
[17:30:20] <SWPadnos> hmm - OK, now I understand the question ;)
[17:31:37] <Roguish> again, looking at the hostm54e.pin file, i see where all the encoder lines and motor signal go. but not those ancillary io's.
[17:32:36] <SWPadnos> ok. it looks like REGMAP4E has some more info there
[17:34:00] <Roguish> great, been there also. that's one i don't really follow too well.
[17:34:07] <SWPadnos> I think it's the top 8 bits od PORTA
[17:34:09] <SWPadnos> of
[17:34:50] <SWPadnos> so, PORTA16-23, on P3
[17:35:44] <Roguish> ok, it could be. if i cycle that hal signal, some header pin should also go up and down, correct?
[17:35:51] <SWPadnos> yep
[17:36:05] <SWPadnos> how good are you with halcmd?
[17:37:02] <Roguish> not very. just starting, but i have been playing with classicladder and can probably do it with that while emc2 is running.
[17:37:37] <SWPadnos> it's probably easier to test with halcmd - fewer variables
[17:37:46] <Roguish> how did you figure 16-23, and not 12-19?
[17:38:16] <SWPadnos> if you look at m5i20.h, the M5I20_DIGITAL_OUT_SHFT is 16
[17:38:31] <SWPadnos> and the mask also supports that
[17:38:35] <SWPadnos> 0x00FF0000
[17:39:22] <Roguish> ok, that where my weakness is. i am not a progammer. i am a mechanical designer!!!!!!!!!!!!
[17:39:35] <SWPadnos> heh - good thing I'm a programmer :)
[17:40:00] <Roguish> i'll trade ya a little..................................
[17:40:19] <SWPadnos> heh, OK. I still need to finish my BP retrofit ;)
[17:40:39] <SWPadnos> I'll tell you how to use halcmd if you design mea space saver X axis motor mount ;)
[17:41:09] <Roguish> got a series 2 in the garage shop with a control system that a friend put together.
[17:41:47] <SWPadnos> cool. mine's a series 1 vari-speed with chrome ways (and new ballscrews ...)
[17:42:32] <Roguish> runs good in straight lines, but goes point to point in curves, very slow. series 2 is 5000 pounds. quite a chore to move into the garage.
[17:42:59] <SWPadnos> heh - one reason that I didn't get one of those instead
[17:43:09] <SWPadnos> plus I have a raised ranch, so the garage is only 8' high
[17:43:53] <Roguish> is yours a standard model? and is your x axis the long table direction? size of table?
[17:44:06] <SWPadnos> yes, yes, 42"
[17:44:29] <SWPadnos> I suppose I could make X be the short axis, but I see no need for that
[17:44:52] <Roguish> no. just checking. what's your x motor?
[17:45:19] <SWPadnos> I have a set of Baldor MTE-4070BLBCE, 28 in-lb, 100l encoders (plus tach)
[17:45:36] <SWPadnos> max 2500 RPM, cont. current 9.7A, max 37
[17:45:59] <Roguish> dc brushed?
[17:46:03] <SWPadnos> yep
[17:46:14] <SWPadnos> got a good deal on eBay - $325 for the set of 3
[17:46:35] <Roguish> youi trying to direct drive it, or going through a belt or gears or something?
[17:46:37] <SWPadnos> one encoder was bad, but I found a place with 50 oz-in motors with the same encoder, so I swapped them around
[17:46:43] <SWPadnos> 2:1 belt reduction
[17:47:08] <SWPadnos> I'm using Geckodrives, so I won't get full speed, but I wouldn't want to see the ballscrew going >900 RPM anyway
[17:48:20] <Roguish> dont' know about the geckos, are they real pwm servos? lot's of current?
[17:48:40] <SWPadnos> they're "step-to-servo" drives
[17:48:50] <SWPadnos> http://www.geckodrive.com/
[17:49:19] <SWPadnos> they take step/dir inputs, 80V/20A max drive
[17:49:45] <Roguish> so you're haveing emc put out step info? the system is only half closed? no encoder back to emc?
[17:50:04] <SWPadnos> I have Jon Elson's USC (plus an M5I20), so emc will close the loop
[17:50:23] <SWPadnos> the Geckos are $114 each, which is well below just about any analog drive I've seen
[17:52:21] <Roguish> what ya doing with the 5i20?
[17:52:45] <SWPadnos> well, I'm a programmer/electrical engineer, and I have my own consulting business - I bought it for experimentation
[17:53:13] <SWPadnos> it's the least expensive reconfigurable FPGA board I've seen
[17:54:21] <Roguish> i think it's the way to go. $200 is a good price. i really want to use it. i have several clients with assorted machines that need retrofitting. if i can figure out how to program theme a bit i can actually make some money.
[17:54:35] <SWPadnos> that would be nice ;)
[17:55:03] <SWPadnos> It's a great card. the thing it lacks (without daughtercards) is industrial isolation and protections
[17:55:15] <SWPadnos> it's just a "normal" PCI card as it sits
[17:56:04] <Roguish> i have already downloaded Zilinx programming . i suggested to mesa they do a usb version so it doesn't touch the pc. and they also definitely need the isolation.
[17:57:00] <SWPadnos> USB isn't too useful for realtime machine control
[17:57:17] <Roguish> why not? not fast enough?
[17:57:31] <SWPadnos> it has plenty of data transfer speed, it's latency that gets you
[17:57:58] <Roguish> what's better? firewire?
[17:58:03] <SWPadnos> USB works on a 1ms timebase, so there's no way to have emc do full servo control with less than 2ms of latency
[17:58:13] <SWPadnos> nope - direct to the PCI bus is the best
[17:58:54] <SWPadnos> additionally, the structure of Linux (and most OSes) is that you can't use standard device drivers in RT code, so you need direct access to the hardware
[17:59:12] <SWPadnos> you can't get that with USB or Firewire
[17:59:39] <Roguish> how about sercos, or some like it?
[17:59:41] <SWPadnos> ethernet hs possibilities, but you really needa separate network
[17:59:45] <SWPadnos> *has
[18:00:01] <SWPadnos> isn't sercos just a protocol sitting on RS-232?
[18:01:37] <SWPadnos> err - nope. (looking at www.sercos.com now)
[18:01:47] <Roguish> definitely. i would never consider running a machine across a standard communications net. only a machine only net. control cpu to motion controller and plc and drives. it's a safety thing.
[18:02:13] <SWPadnos> ok. sercos looks like it's good, it was designed for servo control
[18:03:46] <SWPadnos> they do say that sercos is usually used in "position command mode", which means that the computer isn't closing the servo loop
[18:03:55] <Roguish> there are several like it. again. i'm not a programmer, just a user. but i do like the fpga idea.
[18:03:58] <SWPadnos> that's a lot like the Gecko G-Rex
[18:04:10] <SWPadnos> (which operates over USB, and generates step pulses)
[18:04:29] <SWPadnos> yep. FPGAs are great, especially if you can figure out how to reprogram them
[18:04:55] <SWPadnos> I like the idea that I can make a PWM or step/dir or parallel output, depending on what I need today
[18:05:34] <SWPadnos> well. I've got to run. post back here, or to the developer's list when you find out where those outputs go ;)
[18:05:55] <Roguish> exactly. i need to customize the io's. and i would like it to replace a good portion of the classicladder.
[18:05:56] <SWPadnos> SWPadnos is now known as SWP_Away
[18:06:03] <Roguish> thanks for the assistance.
[18:06:19] <SWP_Away> sure. we can talk later about reconfiguring the FPGA ;)
[18:06:32] <Roguish> caio.
[18:42:58] <alex_joni> cradek: around?
[18:54:40] <jmkasunich> anybody around who understands the new build system?
[18:55:01] <alex_joni> jmkasunich: a little bit, but I can look
[18:55:05] <alex_joni> and google ;)
[18:55:22] <jmkasunich> src/hal/user_comps/vcp/Submakefile
[18:55:54] <jmkasunich> any idea why ../lib/libemc.a and ../lin/libnml/so appear in that file
[18:55:56] <alex_joni> ok..
[18:56:06] <jmkasunich> they certainly aren't needed to build halvcp
[18:57:21] <alex_joni> try removing them ;)
[18:58:38] <alex_joni> jmkasunich: I think hexapods owrk ok on emc2
[18:58:40] <jmkasunich> I need to create another submake file (I think) in another directory
[18:58:48] <jmkasunich> owrk!
[18:58:48] <alex_joni> what for?
[18:58:57] <alex_joni> s/owrk/work/
[18:59:03] <jmkasunich> I know ;-)
[18:59:20] <alex_joni> just pulling my leg, eh?
[18:59:28] <jmkasunich> want to add the joystick driver, its a user space component
[18:59:44] <alex_joni> I've had a 60+ hours week so far
[19:00:28] <alex_joni> and there's still tomorrow (driving for about 7-8 hours + working in the evening a few more hours)
[19:00:41] <jmkasunich> ouch
[19:01:10] <alex_joni> eh, had harder times.. so I guess it's ok
[19:09:54] <alex_joni> jmkasunich: you should try to start from Submakefile.skel
[19:10:05] <alex_joni> sorry.. had to change connections, that's why it too a while
[19:10:23] <alex_joni> s/too/took/
[19:11:07] <jmkasunich> where is the .skel?
[19:11:18] <alex_joni> src/
[19:13:00] <alex_joni> guess that's where the ../lib/libemc.a came from
[19:13:09] <jmkasunich> yeah ;-)
[19:14:18] <jmkasunich> I think I have the submakefile right now
[19:20:24] <alex_joni> anyone of you getting Pro7 ? (a german TV channel)
[19:29:18] <alex_joni> ever seen a Wok-WM ?
[19:29:35] <jmkasunich> don't think so
[19:29:47] <jmkasunich> I wouldn't recognize one if I did see it, what is that?
[19:29:58] <alex_joni> you know what a wok is ?
[19:30:08] <alex_joni> the chinese pan
[19:30:18] <jmkasunich> yeah
[19:31:13] <alex_joni> ok, so using one of those under your ass, you climb into a bob-sleigh track
[19:31:25] <alex_joni> then you try to go as fast as you can ;)
[19:31:26] <jmkasunich> roflma
[19:31:39] <alex_joni> pretty crazy
[19:32:09] <alex_joni> WM comes from Weltmeisterschaft ( world championship)
[19:32:38] <alex_joni> http://tvtotal.prosieben.de/show/specials/wokwm2005/
[19:33:32] <jmkasunich> looks like 2 woks, one for butt, one for feet
[19:34:57] <jmkasunich> I hope the ice isn't too bumpy, not much cushion in a wok ;-)
[19:48:07] <jmkasunich> hi ray
[19:48:20] <rayh> Hi John.
[19:48:44] <rayh> I got another ubuntu box setup for machine testing.
[19:49:07] <cradek> what kind of machine hooked to it?
[19:49:52] <rayh> This is the 4 axis sherline.
[20:02:28] <rayh> make: *** No rule to make target `../configs/hexapod-sim/emc.nml', needed by `configs'. Stop.
[20:04:13] <alex_joni> rayh: did you checkout using -d ?
[20:04:28] <alex_joni> seems like you don't have the configs/hexapod-sim/ dir
[20:04:40] <rayh> Yes -dP
[20:05:20] <alex_joni> can you check for that dir?
[20:05:33] <rayh> ah wait a minute. I just upped src.
[20:05:37] <rayh> will go back.
[20:06:13] <rayh> Hi alex.
[20:06:28] <alex_joni> hello ray
[20:06:50] <alex_joni> I put a 6-axes minitetra into configs/
[20:06:58] <alex_joni> it seems to be working ok..
[20:08:54] <rayh> I see that. Wish I had the cable hex machine here.
[20:09:17] <jmkasunich> we need to build one of those
[20:09:27] <jmkasunich> portable
[20:09:42] <rayh> We need to get NIST to put their's on perminant loan to us.
[20:09:58] <jmkasunich> that sounds easier ;-)
[20:10:10] <rayh> Matt brought it to NAMES a couple times.
[20:10:32] <rayh> So it fit's in the back of a oldsmobile.
[20:10:56] <jmkasunich> does it knock down, or is it just small?
[20:11:12] <rayh> It knocks down.
[20:11:54] <rayh> 9 struts and the moving platform.
[20:12:07] <jmkasunich> 9? I thought it would be 12
[20:12:14] <rayh> Uses 2 boxes of mightydrives.
[20:12:24] <jmkasunich> 3 for base triangle, 3 for top triangle, 6 to hold it up
[20:12:33] <rayh> Yep you're right.
[20:12:53] <rayh> exactly.
[20:13:14] <rayh> We should try to get it to the cnc-workshop.
[20:13:29] <jmkasunich> yeah
[20:13:55] <alex_joni> heh, you're just saying so I feel bad of not coming to cnc-workshop
[20:14:28] <rayh> You bet. I thought you were coming.
[20:18:56] <alex_joni> rayh: unfortunately not
[20:19:29] <rayh> Well we will have to at least get you on line as soon as we arrive.
[20:19:38] <alex_joni> jmkasunich: 4-person wok coming up ;)
[20:20:03] <alex_joni> actually 4 people in 4 connected woks
[20:20:24] <cradek> rayh: will we have a good net connection?
[20:20:38] <cradek> rayh: I'll probably bring my desktop, so we can talk to alex live if we want
[20:20:44] <jmkasunich> DSL or better
[20:20:53] <cradek> that'll be great
[20:21:03] <rayh> Yes. It is a DSL for the whole thing. But it seemed to work well the last two times.
[20:21:05] <alex_joni> cradek: you need to setup some video too ;)
[20:21:18] <alex_joni> lol..
[20:21:21] <jmkasunich> shoot, an EMC fest without a net connection wouldn;t be worth the trip
[20:21:26] <cradek> alex_joni: I thought you said that was windows only
[20:21:30] <rayh> We should do something like that. At least at times.
[20:21:33] <jmkasunich> gotta be able to commit and update
[20:21:55] <rayh> We did get spoiled by Smithy's 1/2t1
[20:21:58] <cradek> yeah I hope sf has a good week
[20:22:21] <jmkasunich> SF downtime could really screw us
[20:22:27] <rayh> I'm planning to offer several install sessions.
[20:22:39] <cradek> rayh: did you ever receive your ubuntu cds? I haven't yet
[20:22:39] <jmkasunich> how good is linux's support for webcams?
[20:23:03] <cradek> jmkasunich: not sure at all
[20:23:12] <rayh> Don't know.
[20:23:30] <rayh> I know that I can plug my Canon in and download any pics.
[20:23:45] <cradek> yeah we will certainly have regular cameras
[20:23:52] <cradek> I'm sure jepler will have his
[20:23:57] <cradek> (he doesn't leave the house without it)
[20:24:04] <jmkasunich> * jmkasunich envisions a webcam taking a snap every 10 mins or so, ftping it to Linuxcnc.org (use the same name, so it just overwrites and doesn't fill up Steve's disk)
[20:24:30] <rayh> That sounds good to me.
[20:25:42] <rayh> Could just put the image on www.cnc-workshop and keep it close to us.
[20:25:59] <jmkasunich> if Roland wants to give one of us write access
[20:26:25] <jmkasunich> close is relative anyway, he doesn't host his own site does he?
[20:26:36] <rayh> Yes he does.
[20:26:57] <jmkasunich> his server is there at the shop?
[20:27:06] <jmkasunich> thats gotta be hard on the DSL
[20:27:06] <rayh> For that reason it would be better to send away. So the downloads don't clutter the line.
[20:27:11] <jmkasunich> right
[20:27:12] <rayh> Yes I think so.
[20:27:34] <alex_joni> * alex_joni is having connection problems
[20:27:36] <rayh> Either that or at his net guy's (Jim) site.
[20:27:48] <alex_joni> cradek: I think webcam support is pretty extensive nowadays in linux
[20:27:53] <alex_joni> never tried it though :)
[20:28:13] <jmkasunich> I'll investigate the camera side, I think my wife has a usb webcam (one of those little round ball things)
[20:28:26] <alex_joni> jmkasunich: sounds (for 1:1 talking) is taking up very little bandwidth (<4-5kB/s)
[20:29:03] <jmkasunich> something like skype you mean?
[20:29:08] <alex_joni> yeah
[20:29:20] <alex_joni> I know chris just set up skype on his box ;)
[20:29:30] <jmkasunich> I have no mic or speaker, so I don't do that kind of thing
[20:29:31] <cradek> I have a good skype deb for ubuntu if anyone wants it
[20:29:53] <cradek> (took a little fiddling)
[20:48:30] <alex_joni> http://smt.robotics.e-symposium.com/robots/images/1.jpg <- that's a nice machine
[20:48:34] <alex_joni> odd-looking though :D
[20:49:19] <cradek> quadrapod?
[20:49:39] <alex_joni> no idea )
[20:50:33] <alex_joni> The call it a Tricept
[20:50:39] <alex_joni> drilling / milling ;)
[20:50:56] <alex_joni> http://smt.robotics.e-symposium.com/robots/images/5.jpg
[20:51:17] <alex_joni> http://smt.robotics.e-symposium.com/robots/images/4.jpg
[20:51:21] <alex_joni> lots of those buggers
[20:53:20] <alex_joni> http://www.equipmatching.com/used_equipment/14/164/4460.php
