Back
[01:39:53] <jepler> It would be nice to figure out a way to test realtime components
[01:40:08] <jmkasunich> ?
[01:40:13] <jepler> like a testsuite
[01:40:39] <jmkasunich> oh, like apply a command to stepgen and make sure the right stuff comes out?
[01:40:56] <jepler> basically, load streamer and the component under test, then check that the output matches the known-good output
[01:41:15] <jmkasunich> thats interesting
[01:41:27] <jepler> streamer is userspace -> realtime? Is there a realtime -> userspace version?
[01:41:39] <jmkasunich> not yet, but I intend to write it oneday
[01:41:41] <jepler> then after you have however many realtime samples you want, shut it all down
[01:41:49] <jmkasunich> it already has a name: sampler
[01:42:46] <cradek> jepler: I'm already taking realtime off my desktop...
[01:43:00] <jmkasunich> assuming sampler was written, you could test for "did the behavior of this component change", but not for "is this component correct"
[01:44:32] <jepler> if you are talking about short runs then it would be possible for a human to write the expected output file
[01:44:43] <jmkasunich> for simple components
[01:44:59] <jmkasunich> in which case you can probably verify the code by inspection
[01:45:14] <jmkasunich> I'd not care to try to write the expected output for stepgen or pwmgen
[01:45:47] <jepler> you could have a program analyze the sampler output, for instance to check that the actual duty cycle was very close to the requested value.
[01:46:18] <jmkasunich> true, but now you're getting in to writing programs to test programs, instead of just comparing previous vs current output
[01:46:21] <jmkasunich> much less generic
[01:46:38] <jmkasunich> and the tester program might be as subject to bugs as the program under test
[01:47:00] <jepler> and therefore all testing is worthless
[01:47:10] <jmkasunich> I didn't say that
[01:48:08] <jmkasunich> I'd love to have automated testing, both regression and functional
[01:48:09] <jepler> cradek: I'm sure thinking about doing the same, for my laptop
[01:48:36] <cradek> ok I even got nvidia to work, I'm staying here now
[01:48:46] <cradek> what a pain in the neck
[01:48:50] <jepler> jmkasunich: the basic structure of both would be the same, imo. set up a realtime system with the component under test, a sampler to capture the output, and maybe a streamer to create the input
[01:49:08] <jmkasunich> might even have several components
[01:49:33] <jmkasunich> for example, if you are testing limit3 (which limits accel and vel), you could put a pair of ddts on the output so you can actually see the accel and vel
[01:49:35] <jepler> so you need a .hal file to set it all up, and a way to shut down the simulator after the desired number of samples have been sampled
[01:49:54] <jepler> it's the last one that seems tricky
[01:50:03] <jmkasunich> yeah, synch in general might be tricky
[01:50:21] <jmkasunich> you want the sampler to start exactly when the streamer does, and end when the streamer data runs out
[01:50:29] <jepler> surely "halcmd start" gives you that
[01:50:45] <jmkasunich> true, I was thinking the "normal" way, where the threads are already running
[01:50:58] <jepler> you going to work on sampler anytime soon?
[01:51:07] <jmkasunich> to be honest I forgot about it
[01:51:21] <jmkasunich> if I wasn't playing with something else right now I would do it right away
[01:51:23] <jepler> if not, maybe scope_rt could be used
[01:51:36] <jepler> as long as the number of samples under test is small
[01:51:57] <jmkasunich> scope_rt has no mechanism for outputting the data
[01:52:02] <jmkasunich> I'd rather do sampler right
[01:52:10] <jmkasunich> its basically hal->stdout
[01:52:49] <jmkasunich> I wish the logger logs were searchable
[01:53:06] <jmkasunich> (you can search each days logs, but not a week or a month)
[01:53:14] <jepler> would you give the userspace component an "exit after N records" flag?
[01:53:23] <jmkasunich> I was thinking about that
[01:53:45] <jmkasunich> thats why I want to search the logs - when I was formulating streamer we also discussed sampler and how it might work
[01:53:53] <jmkasunich> duh, I can find that log... stand by
[01:54:59] <jmkasunich> streamer was committed 9/5 at 2123 UTC
[01:55:12] <jmkasunich> logger_devel: bookmark
[01:55:12] <jmkasunich> See
http://81.196.65.201/irc/irc.freenode.net:6667/emcdevel/2006-10-02#T01-55-12
[01:58:03] <cradek> jepler: I thought the speeds were right earlier, but now the tool moves a small fraction of the requested speed
[01:59:00] <jepler> cradek: hm really? I thought it was close.
[01:59:10] <jepler> this is based on the readout in AXIS?
[01:59:20] <cradek> yes, and the wall clock
[01:59:30] <cradek> both seemed right shortly after I made those changes to TP
[01:59:45] <jepler> was that with "puresim"?
[01:59:45] <cradek> unfortunately I've changed everything since then (my kernel)
[01:59:48] <cradek> yes
[01:59:51] <cradek> I bet it was
[01:59:56] <cradek> this is with the regular sim/axis
[02:00:33] <jmkasunich> well, no meaningfull discussion of sampler
[02:00:35] <cradek> ok puresim still works reat
[02:00:42] <cradek> great
[02:00:59] <jmkasunich> the way I see it, the RT part is constantly sampling and writing into a circular buffer
[02:01:06] <jepler> I get speeds in the neighborhood of 40-60 ipm with both
[02:01:14] <jmkasunich> if the buffer gets full, it keeps going, overwriting the oldest data
[02:01:28] <cradek> on the same program I get a solid 24 in puresim and a shaky 0-3 in sim
[02:01:36] <cradek> the program is F24
[02:01:49] <jepler> I am running the axis demo program
[02:02:06] <jepler> this is from the branch
[02:02:10] <cradek> yeah regular sim is terrible running that
[02:02:21] <jmkasunich> I'll let you guys focus on that issue, if you want to talk about sampler ping me
[02:02:22] <cradek> vel is often 0 and sometimes spikes to ~3
[02:02:32] <cradek> I'm running head now
[02:03:53] <cradek> -static long period1 = 1000*1000; /* thread period - default = no thread */
[02:03:56] <cradek> +static long period1 = 0; /* thread period - default = no thread */
[02:04:20] <jepler> that shouldn't matter, sim doesn't use the threads component
[02:04:23] <cradek> aside from a bunch of ***** $Revision$ and $Date$, this is the only difference between nort_testing and head
[02:04:32] <jepler> hmph
[02:04:51] <jepler> it's no surprise to me that the simulator runs slowly, but it is a surprise that it runs that slowly
[02:05:04] <jepler> I bet if you halscope the XYZvel it will look completely right
[02:05:08] <jmkasunich> what is the period shown by halcmd show threads?
[02:05:18] <cradek> were my changes to TP right?
[02:05:31] <jepler> I didn't read them
[02:06:13] <cradek> I think the motion controller calculated an apparent period for each run, I passed that into TP and used it for accel/vel calcs
[02:06:14] <jepler> with 'puresim', i was passing measured intervals in nsec as the period .. with the new rtapi_app it just passes in the requested period, regardless of how long since the last call
[02:06:51] <jmkasunich> passing to what? the functions in the thread(s)?
[02:07:06] <jepler> jmkasunich: the period parameter to the hal functions
[02:07:15] <jmkasunich> the latter is the correct approach to take
[02:07:45] <jmkasunich> the former results in the period parameter varying (possibly by orders of magnitude) between subsequent calls
[02:07:57] <jepler> yes
[02:08:09] <jmkasunich> some components don't even use that, some would take it instride (and produce better results) and some would barf
[02:08:44] <cradek> jepler: halmeter does show correct xyzvel
[02:08:47] <jmkasunich> how do you decide when to call the threads?
[02:08:57] <cradek> jepler: but where it should be 72 axis shows 16
[02:09:41] <jmkasunich> halmeter (ddt I assume) uses the hal thread period for its calcs
[02:09:50] <jmkasunich> is axis using wall clock time?
[02:09:53] <jepler> jmkasunich: yes
[02:10:11] <jepler> I get a very small Vel displayed by axis while running 3D_Chips
[02:10:19] <jepler> around 0.7 IPM
[02:10:33] <jmkasunich> how does rtapi_app decide when to invoke the hal functions in a thread?
[02:11:10] <jepler> jmkasunich: sim_rtapi's rtapi_wait() does a nanosleep of the requested period
[02:11:26] <jepler> which is completely bogus
[02:13:53] <cradek> can I just increase the period in the ini?
[02:14:07] <jepler> if I run 'f24 g1 x1' 'f24 g1 x0' with the axis splash screen loaded, the speed is pretty good. If I load a more complex file, the speed (measured against wall time) is much lower
[02:14:50] <cradek> I'd say we should nice axis, except it doesn't show up as much in top
[02:15:15] <jmkasunich> the "right" way to do a periodic thread (I think) is to calc the next time it should run (wall clock time), and if now <= next, run it
[02:15:32] <jmkasunich> the next time is always a delta off the previous next, not off the wall
[02:15:44] <cradek> if I increase the periods 10x, it goes at a breakneck speed
[02:16:07] <jmkasunich> so if rtapi_app gets suspended for 10 seconds, when it comes back it will run 10 seconds worth of threads as fast as it can
[02:16:21] <cradek> F24 programmed but F60 by wall time (spiral.ngc)
[02:21:24] <jmkasunich> I hesitate to say this because it involves significant changes....
[02:21:49] <jmkasunich> its probably possible to do the sim threads without using pthreads at all
[02:22:10] <jmkasunich> and get more accurate timings
[02:22:58] <jmkasunich> but I have no idea how free-running tasks would be implemented
[02:23:15] <jepler> right now free-running tasks aren't used
[02:23:18] <jepler> so it might not matter
[02:23:46] <jmkasunich> right now rtapi_clock_set_period is pretty much a do-nothing
[02:24:21] <jmkasunich> but suppose you keep a global called "next_tick"
[02:24:44] <jmkasunich> also suppose there is some thing you can call to get "now", ie wall clock time
[02:25:08] <jmkasunich> while ( 1 ) {
[02:25:25] <jmkasunich> if ( now() < next_tick ) {
[02:25:36] <jmkasunich> sleep(period);
[02:25:40] <jmkasunich> } else {
[02:25:47] <jmkasunich> next_tick += period;
[02:26:03] <jmkasunich> execute pending threads
[02:26:06] <jmkasunich> }
[02:26:35] <jmkasunich> the fastest thread would execute every time, others would not
[02:27:16] <jmkasunich> is this making sense?
[02:28:44] <jmkasunich> oh, actually I think freerunning tasks _could_ be handled
[02:28:46] <jepler> That's the logic I need to put in rtapi_wait(), I don't need to switch away from pthreads
[02:28:57] <jmkasunich> I think you are right
[02:29:05] <jmkasunich> each task needs a "next_run_time" value
[02:29:32] <jmkasunich> rtapi_wait would do "task->next_run_time += task->period"
[02:30:13] <jmkasunich> then "if (now < next_run_time) sleep(next_run_time - now)"
[02:30:44] <jmkasunich> for free running tasks, suspend would set next_run_time to "middle of next week"
[02:30:54] <jmkasunich> and resume would set it to now
[02:31:40] <jmkasunich> using now() is the trick to keeping it synced with wall clock time
[03:47:16] <rayh> I saw the note from jeppler about a feature add today.
[03:47:26] <rayh> Is this the pure sim?
[03:48:58] <jmkasunich> yep
[03:49:16] <rayh> that will be a great help
[03:51:07] <jmkasunich> alex, cradek, and I discussed released on the board list today
[03:51:34] <jmkasunich> its getting time for 2.0.4, there are four bugfixes in the 2.0 branch that would be worthwhile to get in users hands
[03:51:54] <rayh> Right.
[03:51:56] <jmkasunich> and we discussed a few things for the 2.1 release
[03:52:24] <rayh> what's the thinking for 2.1?
[03:52:51] <jmkasunich> hopefully we will do the 2.1 branch (feature freeze) in early to mid october, then have a month or so of testing before the release of 2.1.0
[03:54:19] <rayh> okay. that sounds good
[03:55:26] <rayh> we do need to get the additional features into general test use.
[03:55:44] <rayh> cradek: You around.
[03:56:42] <rayh> I need to make a new public key for the mazak.
[03:56:54] <jmkasunich> so you can commit from there?
[03:57:10] <rayh> right
[03:57:38] <jmkasunich> I thought we were already on the new server by the time the fest arrived?
[03:58:00] <rayh> right but it seems that all that work went away here.
[03:58:20] <rayh> I see now that the demo_mazak is behind.
[03:58:35] <rayh> iocontrol changed several pin names
[03:58:43] <rayh> estop
[03:58:56] <jmkasunich> arrg
[03:59:08] <rayh> yea.
[03:59:20] <rayh> I think that I can get that going okay.
[03:59:32] <jmkasunich> as the user base gets bigger maintaining compatibility from version to version becomes more important
[03:59:52] <rayh> that would seem to be the desirable path.
[04:00:18] <jmkasunich> yet if we're not carefull, we'll find ourselves rejecting good improvements because they introduce incompatibilities
[04:00:26] <rayh> It looks like the anti estop crew one out.
[04:00:33] <jmkasunich> ?
[04:01:01] <rayh> estop pins got changed to user-xxx names.
[04:01:30] <rayh> enable or some such word
[04:01:42] <jmkasunich> personally I think estop should be handled in RT for reliability
[04:01:52] <jmkasunich> but I've lost track of whats happened on that front
[04:03:09] <jmkasunich> managing incompatibilities is something the board should take a role in
[04:03:26] <rayh> user-enable-out is estop-out now
[04:03:56] <jmkasunich> need a fscking scoresheet to keep track of that stuff
[04:04:02] <rayh> right.
[04:04:25] <rayh> I think I can figure out the differences in the morning and get it running.
[04:05:09] <jmkasunich> in the future we should try to make incompatibilities happen only on major version changes (2.0 to 2.1, 2.1 to 2.2, etc)
[04:05:19] <jmkasunich> not on minor versions like 2.0.3 to 2.0.4
[04:05:25] <rayh> right
[04:05:38] <jmkasunich> and when possible we should support both ways of doing something for one major version
[04:05:43] <jmkasunich> for example, blocks....
[04:05:49] <rayh> and then we need to update all the configs when we make these kinds of changes.
[04:06:12] <jmkasunich> usually we do. dunno why the mazak got skipped
[04:06:15] <rayh> both ways may be tough
[04:06:29] <rayh> can't really start it without the machine.
[04:06:37] <jmkasunich> it depends on the specific thing
[04:06:48] <rayh> so there is probably a reluctance to touch it.
[04:07:06] <jmkasunich> right, but if somebody changes foo to bar, they should be able to grep the configs for foo and change it wherever it appears
[04:07:24] <rayh> Should be.
[04:07:41] <jmkasunich> the both ways thing depends on what you are changing. For example, we want to phase out blocks, and other components that have lots of little things in them
[04:07:51] <jmkasunich> replace them with jeffs .comp stuff
[04:08:07] <rayh> sure and that will allow both ways
[04:08:10] <jmkasunich> for 2.1, we'll have all the new .comps, _and_ we'll keep blocks
[04:08:26] <jmkasunich> but if you do halcmd loadrt blocks, it will print a warning that blocks is obsolete
[04:08:34] <jmkasunich> it will still load it, so the machine works
[04:08:40] <jmkasunich> in version 2.2, blocks will go away
[04:08:44] <rayh> okay
[04:08:47] <jmkasunich> that gives people a while to change over
[04:09:08] <jmkasunich> whereever possible we should do things that way
[04:09:23] <rayh> sounds good to me
[04:09:38] <rayh> I don't know anything about comps
[04:09:44] <rayh> time to start reading.
[04:09:56] <jmkasunich> its a nice way to write little hal components like ddt and such
[04:10:16] <jmkasunich> it handles all the boilerplate code, and even generates a man page for the component, automagically
[04:10:59] <jmkasunich> so instead of doing "loadrt blocks ddt=3 mux2=1 comp=2"
[04:11:01] <jmkasunich> you do:
[04:11:08] <jmkasunich> loadrt ddt count=3
[04:11:14] <jmkasunich> loadrt mux2 count=1
[04:11:24] <jmkasunich> loadrt comp count=2
[04:12:38] <rayh> I assume that ddt, mux2 and comp are stand alone code?
[04:12:58] <jmkasunich> they are individual components now
[04:13:25] <rayh> but are a part of blocks?
[04:13:41] <jmkasunich> for now, they exist in two places
[04:13:48] <rayh> oh okay
[04:13:53] <jmkasunich> they are available as part of blocks, or you can load them individually
[04:14:26] <jmkasunich> using blocks means that even if you only need on ddt, you load the entire thing (20+ differnet functions) into memory
[04:14:42] <jmkasunich> also, you need to know (or look up) what stuff is actually in docs
[04:14:49] <jmkasunich> actually in blocks
[04:14:52] <rayh> right and have to unload if you want to change them
[04:14:57] <jmkasunich> right
[04:15:21] <rayh> you don't need to know with comps?
[04:15:38] <jmkasunich> thats another improvement - most of the .comp things, if you initially said "loadrt ddt count=4" and later you figure out you need 5, you can do "halcmd newinst ddt" and get another one without deleting the first 4
[04:16:00] <rayh> nice
[04:16:01] <jmkasunich> I haven't played with that yet, don't know if I have the syntax right, but its something like that
[04:16:10] <rayh> fantastic
[04:22:15] <jmkasunich> well, its after midnight here, and I gotta work tomorrow
[04:22:17] <jmkasunich> goodnight
[04:25:19] <rayh> se you
[14:00:14] <jepler> "The v2_0_branch is the stable release branch for version 2.0. At this time it is only getting bugfixes, we are getting very close to an official release." -- compile farm page
[14:00:18] <jepler> perhaps this text should be changed?
[14:01:04] <jepler> "Note that the realtime portions of ECM1 do not (and will not) compile under kernel 2.6, so the results reported for BDI-4 systems are for the user space parts of EMC1 only." this text should be too (there's not a bdi-4 slot at all)
[14:30:02] <skunkworks> logger_devel: bookmarkd
[14:30:02] <skunkworks> See
http://81.196.65.201/irc/irc.freenode.net:6667/emcdevel/2006-10-02#T14-30-02
[20:31:39] <alex_joni> jepler: getting 2 warnings while compiling on sim
[20:31:42] <alex_joni> Compiling realtime hal/components/stepgen.c
[20:31:43] <alex_joni> hal/components/stepgen.c: In function ‘export_stepgen’:
[20:31:43] <alex_joni> hal/components/stepgen.c:1058: warning: pointer targets in assignment differ in signedness
[20:34:28] <alex_joni> http://pastebin.ca/189095
[20:34:44] <alex_joni> I'm a bit weary about commiting that myself.. not sure if it's quite OK
[20:42:14] <jepler> I seem to recall seeing that too
[20:43:08] <jepler> I don't understand why the cast is there anyway
[20:43:20] <jepler> oh, due to constness
[20:47:35] <jepler> I might go this route instead (it compiles, but is untested):
http://pastebin.ca/189110
[20:48:26] <roland-mazak> http://pastebin.ca/189111
[20:49:05] <cradek> ok give it a try
[20:49:13] <roland-mazak> cradek, got that pastebin.
[20:49:22] <cradek> yep it's ready
[20:49:33] <roland-mazak> Okay. Let me try.
[20:49:47] <roland-mazak> I should find the reason for tool load not working.
[20:50:28] <cradek> hope you didn't have another sensor go out, I seem to remember one didn't work but you got along without it
[21:03:49] <cradek> roland-mazak: having troubles?
[21:06:28] <roland-mazak> No talking
[21:06:40] <roland-mazak> I'll get to that test in just a bit.
[21:08:51] <cradek> ok I'm pretty sure it's set up right, I have to run soon, let me know if there is a problem
[21:30:21] <roland-mazak> will do, thanks