Back
[17:35:06] <jepler> argh there's still a timing-dependent startup problem in sim-rtapi
[17:35:21] <jmkasunich> race condition?
[17:36:13] <jepler> HAL: ERROR: function 'motion-command-handler' not found
[17:36:22] <jepler> this kind of thing
[17:36:48] <alex_joni> isn't that motion.command-handler ?
[17:37:17] <alex_joni> * alex_joni asks without looking at the code
[17:37:32] <jepler> I dunno, I just copied and pasted that
[17:38:13] <jmkasunich> jepler's version is correct
[17:39:58] <jmkasunich> so its trying to execute an addf line before the loadrt is completed?
[17:40:06] <alex_joni> a full cvs checkout takes a while
[17:41:04] <jepler> jmkasunich: I think so
[17:41:19] <jepler> I've only had it happen on one out of ten runs so it's hard to duplicate :(
[17:41:31] <jmkasunich> I hate those
[17:44:46] <jmkasunich> what if you put an intentional delay before the export of motion-command-handler so it happens more often?
[17:45:38] <jepler> well that's exactly what I was doing
[17:45:43] <jepler> actually I put a sleep before the return of hal_init()
[17:45:46] <jepler> and it works just fine
[17:46:35] <jepler> aha .. there it is
[17:47:03] <jepler> I have to sleep in the RTAPI hal_init but not the ULAPI one
[17:52:56] <alex_joni> jepler: when I shutdown puresim I get lots of '%'
[17:53:33] <alex_joni> more than 20 pages of them
[17:57:00] <jepler> return EMCMOT_COMM_SPLIT_READ_TIMEOUT;
[17:57:10] <jepler> it's because of this
[17:57:35] <jepler> I mean, it's that code in usrmotintf.cc that prints %%
[17:57:49] <alex_joni> I see...
[18:02:29] <jepler> ah, found the race condition problem. rtapi_app slaves exit right away, which 'loadusr -W' was treating as meaning the component loaded properly
[18:03:42] <jmkasunich> ah
[18:04:03] <jmkasunich> I have a question/suggestion
[18:04:35] <jmkasunich> what if rtapi_app is only used as the master, and the load/unload functionality (writing to the fifo) is embedded in halcmd loadrt and unloadrt?
[18:05:34] <jmkasunich> the sim version of "realtime start" would be "rtapi_app &", the sim version of "realtime stop" would be "kill rtapi_app" (not literally of course)
[18:09:57] <jepler> I considered that too, but the implementation ended up not needing to be that way
[18:10:04] <jmkasunich> ok
[18:10:38] <jmkasunich> re: the last commit msg, I assume that when the process exits with an error you don't wait for "ready" (that would be a long wait)
[18:11:21] <jepler> that's what I intended to write but I didn't check that case before checking the code in
[18:11:25] <jepler> it looks like I got it wrong
[18:11:31] <jepler> ../bin/halcmd loadusr -W false
[18:11:32] <jepler> Waiting for component 'false' to become ready.............
[18:33:29] <skunkwork> jmkasunich: the psudo pwm - at 20uS period - 50khz is it 50khz only approching 100% and 0% duty cycle?
[18:34:19] <jmkasunich> at 20uS period, the interrupts happen at 50KHz
[18:34:30] <jmkasunich> the PWM can never go faster then 25KHz (one on and one off)
[18:34:40] <jmkasunich> and that happens only at 50:50 duty cycle
[18:35:30] <jmkasunich> at 90% duty cycle you get 9 on and 1 off, total 10, for a 5KHz PWM
[18:35:59] <skunkwork> Ok - totally reverse of what I was thinking :)
[18:37:59] <jmkasunich> decent high frequency PWM (pseudo or otherwise) needs hardware
[18:38:54] <skunkwork> There seems to be a limit of the ir2111 - at around 100khz plus its delays (on off)
[18:39:24] <skunkwork> so it should not be a problem in this situation
[18:39:30] <jmkasunich> not at all
[18:40:26] <skunkwork> still excited :) - hope to make a new circuit board this week-end.
[20:13:40] <jmkasunich> jepler: when you take a break from coding, I have a few administrivia questions about the nort stuff... don't let it interrupt your train of thought though.
[20:16:48] <jepler> jmkasunich: I can take a brake
[20:16:56] <jepler> break even
[20:16:59] <jmkasunich> ;-)
[20:17:11] <jepler> so fire waway
[20:17:14] <jmkasunich> alex and I were thinking about the 2.1 release
[20:17:20] <jmkasunich> nort would be a good thing for that
[20:17:25] <jmkasunich> questions are:
[20:17:36] <jmkasunich> 1) about how long till its ready to merge with head
[20:17:47] <jmkasunich> 2) how do you feel about the risk of it changing normal RT operation
[20:17:51] <alex_joni> "jepler nort_testing * emc2/src/ (configure configure.in): the
[20:17:52] <alex_joni> simulator is usable"
[20:17:56] <alex_joni> ;-)
[20:17:57] <jmkasunich> I saw that
[20:18:08] <alex_joni> I know.. just stating the obvious..
[20:18:17] <jepler> the answer to "1" is when the chance of "2" is pretty small
[20:18:28] <jepler> and I think it is pretty small
[20:18:49] <jmkasunich> when you think it is small, we should merge
[20:19:12] <jmkasunich> cause it won't be _really_ small till lots of people use it, and they won't use it until its merged
[20:19:17] <jepler> yeah
[20:19:51] <jepler> I changed a lot of files -- for instance, when I got rid of "#ifdef MODULE" and added "hal_ready()" everywhere, but those are low-impact
[20:20:09] <jepler> I didn't change the way rtai creates its threads, or the logic of the components
[20:20:20] <jepler> for instance
[20:20:35] <jepler> I'm just about to run the nist lathe from the nort_testing branch...
[20:20:42] <jmkasunich> ok
[20:21:14] <alex_joni> I ran the nort_testing branch on a vanilla kernel earlier
[20:21:18] <alex_joni> worked OK
[20:21:54] <jmkasunich> I should think about a vanilla compile farm slot
[20:22:11] <alex_joni> actually not quite vanilla, but the default dapper kernel (2.6.15-27)
[20:22:30] <alex_joni> jmkasunich: ubuntu kserver jumps to mind
[20:22:37] <alex_joni> without the k
[20:23:19] <jmkasunich> I _really_ wish I could switch the farm over to virtual machines
[20:24:38] <alex_joni> vmware server is quite good for that
[20:24:50] <alex_joni> but you need lots of ram (1g+)
[20:24:59] <jmkasunich> doesn't the "free" license keep expiring and you need to renew it?
[20:25:38] <alex_joni> the license doesn't
[20:25:56] <alex_joni> the software does .. I had to get a new version of it after a couple of months
[20:26:01] <alex_joni> but only once so far
[20:27:34] <jepler> the version of vmware I have installed now (apparently 1.0.0 build-28343) says: "License expiration: No expiration" and "Product expiration: No expiration".
[20:27:45] <jepler> though it does tell me every time I start to download a new version...
[20:28:18] <jepler> the lathe seems to be running just dandy
[20:28:19] <alex_joni> jepler: I had that with the old version, after a while I couldn't start it anymore.. had to download or change my date back 1 month
[20:28:22] <jmkasunich> donch hate whiney software
[20:28:27] <alex_joni> jepler: with hardware?
[20:28:39] <jepler> yeah I have a borrowed cnc lathe
[20:28:47] <alex_joni> great :)
[20:28:54] <jmkasunich> if I'm gonna seriously consider VMs I guess I need a new PC ;-)
[20:29:09] <alex_joni> jmkasunich: a serious new pc :D
[20:29:29] <jmkasunich> maybe after I get paid for my current machining job
[20:29:33] <jepler> Any slot, even one with RT, would be fine for testing that the simulator builds
[20:29:46] <jepler> er, any machine
[20:30:15] <jmkasunich> jeplers brings us back on topic
[20:30:36] <jmkasunich> thats true, I could set up another "slot" on this box
[20:30:41] <alex_joni> jepler: how about headers? do you need those?
[20:30:50] <jepler> alex_joni: what headers?
[20:30:53] <alex_joni> kernel headers
[20:30:57] <jepler> shouldn't
[20:30:59] <jepler> it's all userspace
[20:31:12] <alex_joni> I imagine RTAI headers aren't needed because of rtapi
[20:31:14] <jepler> maybe you do but it would be by accident not by design
[20:31:32] <jmkasunich> it would be a little more satisfying to do it on a machine that doesn't even have RT, so you _know_ its not pulling kernel stuff in by accident
[20:31:47] <jepler> Makefile.modinc and comp --compile both need to know about the simulator...
[20:31:58] <alex_joni> jmkasunich: it can still pull kernel stuff even without RT
[20:32:12] <jmkasunich> s/kernel stuff/rt stuff/
[20:32:52] <alex_joni> jepler: does configure figure out to work only in sim mode if it doesn't find a RT kernel?
[20:33:30] <jmkasunich> I wouldn't do that - make the user explicitly specify non-rt mode
[20:34:01] <alex_joni> and fail otherwise?
[20:34:13] <jmkasunich> otherwise someone might compile and try to run a big dangerous machine without even realizing they have no RT
[20:35:03] <jmkasunich> actually, how do hardware drivers work in sim? inb() and outb() are supported from user space?
[20:35:24] <jepler> the hardware drivers are not compiled
[20:35:30] <jmkasunich> ah
[20:35:53] <jmkasunich> you have some flag that says "this is HW, skip it" or just skip the hal/drivers directory?
[20:35:59] <jepler> # Subdirectory: hal/drivers
[20:35:59] <jepler> ifneq ($(BUILD_SYS),sim)
[20:35:59] <jepler> obj-$(CONFIG_HAL_PARPORT) += hal_parport.o
[20:36:09] <jepler> basically I just bracketed those items in the Makefile
[20:36:19] <jmkasunich> ok
[20:37:17] <alex_joni> which gets us back on topic.. it sounds good enough to port to HEAD
[20:37:23] <jmkasunich> yeah
[20:37:31] <alex_joni> that way it's easier (not much work on HEAD makes merging easier)
[20:39:10] <jepler> in theory you could arrange for rtapi_app to run with access to the I/O ports, just like the userspace hal_parport could.
[20:39:21] <jepler> but you'd have to give that access to everything inside rtapi_app
[20:39:42] <jmkasunich> I'd rather not
[20:40:11] <jmkasunich> if you try to make the drivers run in userspace, what happens to the calls to reserve an I/O port range, for example
[20:40:30] <jepler> I think you get runtime errors because those functions aren't actually defined
[20:40:36] <jepler> I could make them always fail, I suppose...
[20:41:05] <jmkasunich> my point is, it won't work well in user space, so why complicate things trying to make it work there
[20:41:10] <alex_joni> indeed
[20:41:20] <alex_joni> hardware won't work in userspace anyways
[20:42:18] <jmkasunich> some will, some won't (the old user space parport driver would) but screw it
[20:42:37] <jmkasunich> if drivers are skipped, we can have configure auto-fallback to simulation if RT is not found
[20:42:48] <jmkasunich> with no danger of someone trying to run a machine with the sim
[20:47:42] <jepler> I'm game if the rest of you are
[20:50:43] <alex_joni> I agree
[20:50:56] <alex_joni> with the mention we should print a big warning
[20:51:37] <jepler> "print" -- where?
[20:51:45] <alex_joni> after the ./configure
[20:52:20] <jmkasunich> you mean if configured to use the sim?
[20:52:29] <alex_joni> if configure falls back to sim
[20:54:32] <jepler> I'll leave that to whomever implements the fallback
[20:54:43] <alex_joni> fair enough :)
[20:58:56] <jmkasunich> thats a big diff (3249 lines)
[20:59:00] <jepler> I'm reading through this before I actually commit it:
http://emergent.unpy.net/index.cgi-files/sandbox/nort-rev4.patch
[20:59:23] <jepler> how'd you generate your diff? Mine's not quite the same size.
[20:59:37] <jepler> $ wc nort-rev4.patch
[20:59:38] <jepler> 3681 14083 116745 nort-rev4.patch
[20:59:39] <alex_joni> might not be -u
[21:00:40] <jmkasunich> went to my head checkout, did "cvs diff -u -r HEAD -r nort_testing >tmp.diff
[21:00:41] <alex_joni> jepler: do you want the change on sim/axis.ini ?
[21:00:48] <alex_joni> -BASE_PERIOD = 50000
[21:00:48] <alex_joni> +# no need for it to be fast on a simulator
[21:00:48] <alex_joni> +BASE_PERIOD = 1000000
[21:02:12] <jepler> alex_joni: yes -- it makes the simulator run much better
[21:02:34] <jmkasunich> base period should be at least a little faster than the servo period
[21:02:55] <jepler> oh? Why's that?
[21:03:05] <alex_joni> jepler: another thing.. I notice classicladder_rt is/was mentioned twice in the list of KBUILD modules
[21:03:08] <jepler> I remembered another thing that's not done yet: parsing of array arguments in rtapi_app
[21:03:12] <jmkasunich> uhhh... I dunno
[21:03:17] <alex_joni> -../rtlib/classicladder_rt: $(addprefix objects/rt,$(classicladder_rt-objs))
[21:03:17] <alex_joni> -../rtlib/rtapi.o: $(addprefix objects/rt,$(rtapi-objs))
[21:03:19] <alex_joni> ...
[21:03:28] <alex_joni> -../rtlib/classicladder_rt.o: $(addprefix objects/rt,$(classicladder_rt-objs))
[21:04:43] <jepler> ah I hadn't noticed that
[21:05:02] <jepler> the line without the .o should have been removed .. now either of the lines with $(RTLIB_EXT) can be removed.
[21:05:08] <alex_joni> indeed
[21:24:48] <cradek> merge!! woo!
[21:24:54] <alex_joni> yeah
[21:25:15] <jepler> be brave
[21:25:20] <jepler> it's time for me to leave for sunday dinner
[21:25:24] <jmkasunich> lol
[21:26:01] <jmkasunich> jepler's way: here's a 3000 line diff, bye
[21:26:02] <jmkasunich> ;-)
[21:26:34] <cradek> haha
[21:26:41] <jmkasunich> jepler: enjoy dinner, and thanks! massive accomplishment
[21:27:01] <jepler> all you guys have to do is work out the bugs
[21:27:32] <jepler> 4000 lines .. about 40000 bugs?
[21:27:52] <alex_joni> jepler: I cleared about 100 lines
[21:27:56] <alex_joni> s/100/1000/
[21:28:04] <alex_joni> by inspecting the diff
[21:28:17] <alex_joni> so it's probably down to 20000 :)
[21:33:44] <alex_joni> jepler: found one change that's debateable
[21:33:46] <alex_joni> -static long period1 = 0;/* thread period - default = no thread */
[21:33:46] <alex_joni> +static long period1 = 1000*1000;/* thread period - default = no thread */
[21:34:19] <jepler> alex_joni: oh yeah
[21:34:24] <jepler> I added that before I could pass arguments
[21:34:36] <jepler> feel free to revert
[21:34:41] <jepler> or if not, fix the comment
[21:34:47] <alex_joni> will do in a sec
[21:59:51] <alex_joni> jepler: I like this one
[21:59:52] <alex_joni> +#ifndef LINUX_VERSION_CODE
[21:59:52] <alex_joni> +#define LINUX_VERSION_CODE 0
[21:59:53] <alex_joni> +#endif