Back
[00:06:08] <jepler> hi jmk
[00:06:41] <jepler> think you'll get a chance to start on "sampler" any time soon? If not, I may work on it.
[00:08:00] <jmkasunich> actually I'm gonna work on it tonight
[00:08:11] <jepler> great
[00:09:24] <jepler> once that exists I'll see about making a test harness that will allow for functional and regression testing of hal modules.
[00:09:30] <jmkasunich> nice
[00:09:43] <jmkasunich> about sampler - got a few minutes to talk about functionality?
[00:10:04] <jmkasunich> the rt part is gonna be constantly sampling to a fifo I think
[00:10:13] <jmkasunich> maybe with a pin to enable/disable it
[00:10:29] <jmkasunich> the user part has several possibilities
[00:11:00] <jepler> for testing, I want to know that I got all the samples since the threads started (no overruns) and I want to exit after I have the desired number of samples.
[00:11:04] <jmkasunich> when you start it, it could begin with the data currently in the fifo (possibly several seconds old) or it could flush the fifo and start with data from that point in time
[00:11:40] <jepler> you mean, that would be the choice of the userspace part?
[00:11:56] <jmkasunich> I was thinking implement one or the other
[00:12:03] <jepler> in the case of testing, I would want to take the samples already available, because some samples will arrive between "halcmd start" and the sampler userspace process starting.
[00:12:25] <jmkasunich> true
[00:13:11] <jmkasunich> the user command line will be something like "sampler -n 1000 >foo" to capture 1000 samples to file foo
[00:13:35] <jmkasunich> I'm thinking if you omit the -n it just keeps running until you ctrl-C it
[00:13:42] <jepler> sure, that sounds good
[00:13:52] <jepler> it should handle a closed pipe gracefully, too
[00:14:12] <jepler> (in which case, 'sampler -n 1000 > foo' could just be written 'sampler | head -1000 > foo')
[00:14:36] <jmkasunich> I guess that means I need to figure out how to handle a closed pipe
[00:14:51] <jmkasunich> I was just planning on printf() for the output
[00:15:17] <jepler> by default, I think you get SIGPIPE which will cause your program to exit if it's not otherwise handled
[00:15:22] <jepler> in other words, you may have to do nothing
[00:15:40] <jepler> (the halcmd pipe problem was that it did have to do something: release the HAL lock)
[00:16:35] <jepler> some guests just arrived, talk to you later.
[00:19:45] <jmkasunich> ok
[00:20:14] <jmkasunich> it can't just exit... needs to unmap the shared memory
[01:32:10] <jmkasunich> oh leading a newbid thru config is such fun
[01:32:17] <jmkasunich> newbie that is
[01:39:20] <jepler> I'm back
[01:39:24] <jepler> is sampler done? :-P
[01:40:10] <jmkasunich> no
[01:41:02] <jepler> I was thinking, maybe rtapi or hal_lib should install default signal handlers that take care of stuff like unmapping memory
[01:41:23] <jepler> is calling rtapi_exit() enough?
[01:41:33] <jmkasunich> yeah
[01:41:54] <jmkasunich> actually, if you called hal_init, you should call hal_exit
[01:42:05] <jmkasunich> if you called rtapi_init you should call rtapi_exit
[01:42:16] <jmkasunich> hal_init/hal_exit call the rtapi ones for you
[01:43:19] <jepler> neither hal_exit or rtapi_exit would unlock a locked mutex, though
[01:44:39] <jmkasunich> no
[01:44:56] <jepler> some things can't be helped I suppose
[01:45:14] <jmkasunich> but sampler won't be grabbing the mutex, only halcmd and a very limited number of other apps do that
[01:46:42] <jepler> I think it might be possible to take a generic approch, in hal_init and/or rtapi_init, so that exiting on most signals would properly call the _exit()s
[01:46:55] <jmkasunich> that would be nice
[01:47:07] <jmkasunich> iirc it got hairy on halcmd
[01:47:22] <jmkasunich> oh, that was because of the mutex, not the _exit
[01:47:24] <jmkasunich> never mind
[01:48:43] <jepler> I won't be able to look at it before tomorrow
[01:48:50] <jmkasunich> thats ok
[01:48:59] <jmkasunich> at this rate I won't get much done
[01:49:07] <jmkasunich> heaven preserve us from complete newbies
[01:49:36] <skunkworks> ooh - that doesn't sound good. I have some good reading? :)
[01:50:46] <skunkworks> jmkasunich: I did some experimenting tonight with one of those mosfets. I have some pictures to show you :)
[01:52:07] <skunkworks> * skunkworks bets jmk thinks I blew one up. But I didn't.... yet :)
[01:52:34] <jepler> that's what I assumed
[01:53:21] <jmkasunich> so show...
[01:53:28] <skunkworks> uploading.
[01:54:21] <skunkworks> I can tell you right now - I hacked up a smallish heat sink for worst case senerio. At 20amps -it boils spit without a fan - with a fan it gets around 50c
[01:55:18] <jmkasunich> phew....
[01:55:39] <jmkasunich> flyboy is finally done (for now - I bet he comes back)
[01:56:34] <skunkworks> I think I was like that in the begining. I seem to remember getting yelled at for not saying the bdi version correctly :)
[01:56:46] <jepler> you mean, you didn't say "ubuntu"? or was it longer ago than that?
[01:57:00] <jmkasunich> well now, if you said any bdi you'd get yelled at ;-)
[01:57:58] <skunkworks> longer ago :)
[01:59:13] <skunkworks> here is the "test" setup :)
[01:59:14] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/DSC_2105.JPG
[01:59:28] <jmkasunich> jepler: I've been thinking about having sampler record one extra channel - a 32 bit unsigned int that starts at zero and increments for each sample
[02:00:00] <jmkasunich> sampler -t (for tag) would put that number at the start of each line, without the -t it wouldn't be printed
[02:00:13] <skunkworks> here is the heatsinks I plan on hacking apart.
[02:00:14] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/DSC_2107.JPG
[02:00:37] <skunkworks> here is 20 amps
http://www.electronicsam.com/images/KandT/servostart/DSC_2110.JPG
[02:01:12] <jmkasunich> serious sinkage
[02:01:55] <skunkworks> but it really starts to knee at anything over 20 amps :)
[02:02:11] <jmkasunich> I squared at your service
[02:03:06] <skunkworks> * skunkworks had to read that 3 times to get what you ment I^2 at your service.. Nice
[02:03:43] <skunkworks> notice the 3.9 volt junction voltage :) little higher than it should be
[02:04:24] <jepler> jmkasunich: that's a good idea, userspace can see overruns and the like that way as well
[02:05:07] <jmkasunich> I also thought about simply putting a * at the beginning of the first line after an overrun
[02:05:14] <jmkasunich> or printing a blank line, or something like that
[02:05:40] <jmkasunich> the number conveys a lot more info, if you go to the trouble of parsing it
[02:05:58] <jmkasunich> the * lets you easily say "there was (not) an overrun in this file"
[02:07:03] <jmkasunich> skunkworks: is the meter connected directly at the fet? those clipleads probably have non-trivial resisiance and may be adding to the drop
[02:08:03] <skunkworks> thru the alegater clips yes. - it measured the same right at the fet. I just got tired of shorting out the power supply. :)
[02:08:04] <skunkworks> thru the alegater clips yes. - it measured the same right at the fet. I just got tired of shorting out the power supply. :)
[02:08:18] <skunkworks> sorry
[02:08:55] <jmkasunich> just bits, they're cheap
[02:09:26] <skunkworks> the power supply is an old thing - only thing I have that puts out 30 amps.
[02:10:49] <jmkasunich> an hour and a half helping flyboy..... argh
[02:11:11] <jmkasunich> I should have known better than to say "hi" to an unfamiliar name
[02:11:25] <skunkworks> The gods smile at you though :)
[02:12:00] <jmkasunich> they do?
[02:12:22] <skunkworks> thats what the voices tell me.
[02:13:58] <jmkasunich> new, the god of be!
[02:14:29] <jmkasunich> I probably canceled out any smiles and got a frown for griping about it
[02:14:42] <jmkasunich> * jmkasunich shuts up before lightning strickes
[02:14:45] <jmkasunich> strikes
[02:17:29] <skunkworks> jmkasunich: did you get what I said this morning? about there being a amp vs case temp on the data sheet. It said for 44 amps the case temp needed to be 55c?
[02:17:53] <skunkworks> alex figured liquid nitrogen.
[02:18:08] <jmkasunich> yeah
[02:18:14] <jmkasunich> I thought you said 25C
[02:18:25] <jmkasunich> thats how alot of the specs are determined
[02:19:47] <skunkworks> yes. thats what I ment.
[03:06:24] <jepler> the problem with unix signals is that in reality you are allowed to do relatively little from inside them
[03:06:40] <jepler> you end up with weird failures, when the signal just happens to arrive during a call to malloc()
[03:07:10] <jepler> if the handler calls anything that might allocate memory
[03:07:18] <jepler> or free it
[03:07:22] <jmkasunich> yeah, signals scare me
[03:07:30] <jmkasunich> so I do as little as possible in a signal handler
[03:08:01] <cradek> so don't malloc or free in a signal handler
[03:08:06] <cradek> I thought that was common knowledge
[03:08:23] <jepler> quick: can you call printf() in a signal handler? sprintf()?
[03:08:48] <cradek> no idea
[03:09:58] <jepler> because hal_exit may call rtapi_print_msg(), for instance
[03:10:02] <cradek> it seems like you should be able to ... do you know the answer for sure?
[03:10:51] <jepler> I know stdio uses buffers, but maybe it didn't allocate them before this call to printf()
[03:11:15] <jepler> I'm not sure of the answer
[03:11:28] <cradek> I understand your complaint now
[03:11:39] <cradek> often signal handlers are of the form 'set some global flag that says to do something'
[03:11:58] <jmkasunich> my preferred thing to do in a signal handler is one line: "quit = 1;"
[03:12:03] <cradek> yeah like that
[03:12:29] <jmkasunich> that works _if_ the program is a live loop, and will soon get to "while (! quit ) {"
[03:12:35] <jepler> "The only routines that POSIX guarantees to be Async-Signal-Safe are listed in Table 5-2. Any signal handler can safely call in to one of these functions."
http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/MTP/p40.html
[03:12:47] <jmkasunich> but if the program is sitting waiting for a line from stdin, for example, that doesn't work
[03:13:40] <jepler> I had imagined a handler that called hal_exit() or rtapi_exit() and then re-raised the signal (so you still see that the program died with SEGV, but it cleaned up its hal pins)
[03:13:52] <jepler> but I suspect that this approach is theoretically wrong
[03:14:58] <jepler> goodnight
[03:15:03] <cradek> goodnight
[03:15:08] <jmkasunich> goodnight
[19:10:09] <alex_joni> jepler: around?
[19:13:42] <jepler> alex_joni: no
[19:14:09] <alex_joni> jepler: is puresim.ini still usefull?
[19:14:24] <alex_joni> cradek: around?
[19:20:53] <alex_joni> cradek: noticed a rather odd thing.. if you start sim/axis.ini, and run the default program (emc2 - axis) step by step, and zoom in, you can see that a step is not really a line, but the tool moves a certain amount into the next line aswell..
[19:21:22] <alex_joni> is that because of blending?
[19:23:00] <alex_joni> also .. sometimes while zoomed in the tool goes off the path
[19:23:52] <SWPadnos> the tool going off the path is probably due to quantization error in position feedback (at least that's what I think)
[19:24:37] <alex_joni> http://dsplabs.cs.utt.ro/~juve/dropbox/axis-off-path.png
[19:25:08] <SWPadnos> err - that doesn't look like quantiztion error ;)
[19:25:26] <alex_joni> that's what I thought too
[19:27:44] <SWPadnos> kinda cool:
http://www.otherpower.com/bartmil.html
[19:28:02] <cradek> step does go to the end of the blend - it always has done this, even in emc1
[19:28:35] <cradek> is that last one when you pause?
[19:29:08] <alex_joni> when I step
[19:29:10] <cradek> I mean the screenshot - what did you do to get it?
[19:29:20] <alex_joni> I stepped through the file
[19:29:26] <cradek> which was was it going?
[19:29:39] <alex_joni> after one certain step it went that way
[19:29:47] <alex_joni> and it seems to happen on all the similar corners
[19:29:54] <alex_joni> bottom of the X
[19:29:56] <alex_joni> bottom of the I
[19:30:15] <cradek> which direction does it go around those? clockwiseish?
[19:30:38] <alex_joni> yes
[19:30:49] <alex_joni> http://dsplabs.cs.utt.ro/~juve/dropbox/axis-off-path2.png
[19:30:50] <cradek> wild
[19:30:55] <alex_joni> this might prove usefull
[19:31:08] <alex_joni> it seems like it follows the line, only different direction
[19:31:23] <alex_joni> it's taken from above through the tool.. that's why it's milky
[19:31:54] <cradek> hmm it goes a surprising distance into the next segment for some steps
[19:32:22] <cradek> I think sometimes it definitely goes more than one segment
[19:33:23] <alex_joni> cradek: my impression too
[19:33:39] <alex_joni> check the I.. you'll see where it goes off path while stepping
[19:34:53] <cradek> no I'm not getting that
[19:35:40] <alex_joni> http://dsplabs.cs.utt.ro/~juve/dropbox/axis-off-path3.png
[19:35:53] <alex_joni> I was stepping there, then aborted, and jogged manually
[19:36:08] <alex_joni> the position of the spindle was outside the path when I started jogging... as you can see
[19:36:23] <cradek> oh so it takes an abort?
[19:37:06] <alex_joni> no.. while stepping I can see it clearly
[19:37:24] <alex_joni> but I aborted here to check if it's a display problem, or if the head really moves there
[19:37:47] <alex_joni> http://dsplabs.cs.utt.ro/~juve/dropbox/axis-off-path4.png
[19:37:56] <alex_joni> same as 3 but snapshot from above
[19:38:26] <cradek> so you stepped, it went off the path, then you aborted, and it didn't move, then you jogged?
[19:38:58] <cradek> (it's suspiciously parallel to that next line)
[19:41:11] <alex_joni> right
[19:41:30] <alex_joni> http://dsplabs.cs.utt.ro/~juve/dropbox/axis-off-path5.png
[19:41:37] <alex_joni> here you can see it only by stepping
[19:42:36] <alex_joni> for what it's worth.. right now it's configured --enable-run-in-place (no sim)
[19:43:36] <alex_joni> axis-off-path5.png I did only by stepping through the file.. no abort, no jogging, nothing else
[19:46:37] <jepler> that's wild
[19:46:44] <alex_joni> axis-off-path6.png is a zoom in on one of the glitches on the letter S
[19:47:24] <cradek> why am I not getting this??
[19:47:38] <alex_joni> configured for sim?
[19:47:45] <cradek> no
[19:48:13] <alex_joni> wild
[19:48:43] <cradek> alex_joni: let me know when you figure it out :-)
[19:48:46] <alex_joni> * alex_joni rebuilds emc2
[19:50:56] <jepler> I'm seeing weird things on step, "sim" configuration
[19:51:05] <jepler> I get some yellow bits, and then T doesn't work anymore
[19:51:45] <jepler> I can unpause and re-pause, but I can't step
[19:51:54] <jepler> http://emergent.unpy.net/files/sandbox/singlestep-weirdness.png
[19:52:00] <jepler> I haven't seen any wrong-direction-segments though
[19:53:45] <jepler> I also observed that "single step" sometimes goes more than one line
[19:54:20] <alex_joni> did you step up to the end of the program?
[19:55:01] <jepler> no, it got "confused" before that
[19:55:33] <alex_joni> :/
[19:59:24] <jepler> it shows interp_state is EMC_TASK_INTERP_WAITING so the step button is disabled inside axis
[19:59:25] <alex_joni> finished rebuilding.. same problem
[19:59:44] <alex_joni> by looking closely I can see that the letter E has the same symptoms
[20:00:23] <jepler> but even after I hit P to pause and the step button becomes enabled, it still does nothing to click it or press 't'
[20:00:33] <alex_joni> axis-off-path7.png
[20:01:31] <alex_joni> jepler: I noticed after pushing step intensively at one point it actually started running here.. but I thought I moved and hit the pause button instead
[20:02:08] <alex_joni> it seems after 10-15 fast clicks on step it starts to run normally, and the step button is greyed out
[20:02:32] <alex_joni> hmm.. 2-3 clicks are enough if they are fast enough
[20:03:06] <alex_joni> but they need to happen inside a segment.. so only the longer ones will work
[20:05:12] <alex_joni> cradek: after decreasing feed-override to 55% the errors are gone..will investigate now at what value they appear
[20:08:33] <jepler> are you trying to press the step button early or late in the segment?
[20:09:39] <alex_joni> jepler: how do you mean that?
[20:09:48] <jepler> umm
[20:09:59] <jepler> forget it
[20:10:04] <jepler> my question makes no sense
[20:10:06] <alex_joni> it goes one (line) then stops
[20:10:16] <alex_joni> then I hit step again, and it moves again
[20:11:13] <jepler> yeah
[20:11:19] <jepler> my question made no sense
[20:11:46] <jepler> I have run through nearly the whole program in single step mode by executing this Python program:
[20:11:49] <jepler> >>> while 1: time.sleep(1); c.auto(emc.AUTO_STEP)
[20:12:07] <jepler> I haven't seen anything like your screenshots, but there is yellow mixed in with the red
[20:12:40] <jepler> that code is basically the same as pressing the step button every second
[20:14:20] <alex_joni> I got that :)
[20:14:43] <alex_joni> try time.sleep(.1) does it run away then?
[20:14:57] <jepler> I can get it to "run away" but not to go the wrong way on lines
[20:15:17] <alex_joni> ok.. so at least one of the two is confirmed by you too
[20:18:19] <alex_joni> just tried 'stepper-xyza', same issues there
[20:25:24] <alex_joni> jepler: does that program get saved somewhere?
[20:25:30] <alex_joni> or generated on startup?
[20:26:53] <alex_joni> nm.. found it
[20:28:46] <alex_joni> cradek: I get the same behaviour on emc2.0.1 and axis1.4a0
[20:29:43] <alex_joni> except that it's worse.. stepping sometimes locks, so I need to push pause, then step, then pause again, then step again, etc
