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