Back
[00:04:08] <skunkworksemc> 2. kinematics Now a separate kinematics module must be loaded before MOTMOD, as shown in [this diff].
[00:06:18] <skunkworksemc> jepler: my core_sim.hal already has
[00:06:19] <skunkworksemc> # kinematics
[00:06:19] <skunkworksemc> loadrt trivkins
[00:08:56] <skunkworksemc> jepler: never mind - I got it. Forgot there was a emc2 directory with my original files in it. duh The sim from the emc2-head works
[00:09:43] <skunkworksemc> jepler: ? something to worry about? HAL: WARNING: blocks is deprecated, please use the subcomponents generated by 'c omp' instead
[00:14:26] <jmkasunich> skunkworksemc: nothing to sweat over
[00:14:45] <jmkasunich> eventually you should use "ddt", "sum2", etc, instead of "blocks ddt=3 sum2=1"
[00:15:07] <jmkasunich> version 2.1 will support both, version 2.2 will support the new way only
[00:21:10] <skunkworksemc> Thanks
[00:21:31] <jmkasunich> how's the h-bridge working out?
[00:22:39] <skunkworksemc> only played with it a little bit. had it running as a spindle you saw the other day. Working great :)
[00:23:01] <jmkasunich> cool
[00:23:05] <skunkworksemc> pretty low current right now - waiting for some mica insulators.
[00:23:12] <jmkasunich> how many amps/volts have you run thru it?
[00:23:34] <skunkworksemc> oly 60v around 2 amps
[00:23:54] <jmkasunich> without heatsink? not bad
[00:24:11] <skunkworksemc> not very long - but no real heat
[00:24:52] <skunkworksemc> I have some copper clad coming - do you want a few of the boards to play with?
[00:25:12] <jmkasunich> not right now, I
[00:25:27] <jmkasunich> I've got to many projects and too little time
[00:25:59] <jmkasunich> I may take you up on that offer in the future tho, thanks
[00:26:06] <skunkworksemc> same here. I got head so I could play with your pwm hal module
[00:26:30] <skunkworksemc> Hoping tomorrow
[00:26:39] <skunkworksemc> have to read your source for it :)
[00:26:55] <jmkasunich> I should write a man page
[00:30:39] <skunkworksemc> I had mentioned the other day about maybe being able to do spindle speed regulation thru emc - with an encoder. Seems to have gotten some more wheels turning :)
[00:31:43] <skunkworksemc> Then on a laith for instance - you could do the spindle as an axis, spindle speed regulation and sync (threading)
[00:32:11] <skunkworksemc> (trying to let emc do most of the work - with minimal electronics)
[00:34:12] <skunkworksemc> on a side note - do you see any problem with the circuit being that the 2 low mosfets are on when not pwm signal is present.
[00:35:13] <skunkworksemc> meant that as a question. Boy I like that gaim does spell checking :)
[00:36:50] <jmkasunich> no prob with the two bottom fets on, IMO
[00:37:37] <jmkasunich> since the high side drivers are bootstrapped, you should use the max-dc parameter to limit the duty cycle to about 98% or so to keep the bootstrap from getting discharged
[00:37:50] <jmkasunich> but the low side can be on all time with no problem
[00:39:15] <skunkworksemc> I noticed that with it running as a spindle - at 550 the pwm was pretty close to 100% - at 560 it was and shut the spindle off. :)
[00:39:22] <skunkworksemc> S550
[00:40:24] <jmkasunich> full voltage gets you 550 RPM with your motor?
[00:40:27] <jmkasunich> doesn't seem that fast
[00:41:16] <skunkworksemc> no - I was just using what ever scaling was in the nist laith setup. I never actually measured the servo.
[00:41:31] <jmkasunich> oh
[00:42:00] <skunkworksemc> servo rpm. Was just excited that it seemed to work
[00:42:53] <jmkasunich> ok
[00:43:10] <skunkworksemc> with the way it was set - S550 was pretty close to 100% S560 was
[00:43:16] <jmkasunich> right
[00:44:19] <jmkasunich> * jmkasunich needs to make chips
[00:44:28] <jmkasunich> IRC = procrastination
[00:44:34] <skunkworksemc> was having a hard time getting the scope to sync on it but it was pretty cool to watch.. Have fun. :)
[00:44:46] <jmkasunich> you were scoping the PWM?
[00:44:50] <skunkworksemc> yes
[00:44:56] <jmkasunich> how did the FET voltages look?
[00:45:17] <jmkasunich> mainly spikes from drain to source during turn-off?
[00:45:53] <skunkworksemc> I will check.. I was scoping after the interface - before the h-bridge.
[00:45:58] <jmkasunich> ok
[00:46:08] <jmkasunich> its always good to check the switching behavior
[00:46:15] <skunkworksemc> will do.
[00:46:20] <jmkasunich> you will get spikes at turn off that exceed the supply voltage
[00:46:39] <jmkasunich> the low inductance layout should minimize them, but its good to know what you have before you increase the power level
[00:47:35] <skunkworksemc> your procrastinating again
[00:47:43] <skunkworksemc> ;
[00:47:45] <skunkworksemc> ;)
[00:47:46] <jmkasunich> yeah
[00:48:14] <jmkasunich> you know, if it wasn't for procrastination, this project would have been done months ago
[00:48:35] <skunkworksemc> I am the expert at that.
[00:48:41] <jmkasunich> now the end is in sight, and I'm still doing it
[00:48:54] <jmkasunich> * jmkasunich gets to work
[01:44:02] <jmkasunich> 3 pieces finished, 9 to go
[02:15:35] <jmkasunich> 6 done, 6 to go
[02:55:01] <jmkasunich> 9 done, 3 to go
[03:15:05] <jepler> ==6815== Conditional jump or move depends on uninitialised value(s)
[03:15:05] <jepler> ==6815== at 0x43A499D: compute_screw_comp (control.c:2200)
[03:15:05] <jepler> ==6815== by 0x43A0FB4: emcmotController (control.c:338)
[03:15:30] <jepler> (gdb) frame 0
[03:15:30] <jepler> #0 0x043a499d in compute_screw_comp () at emc/motion/control.c:2200
[03:15:30] <jepler> 2200 if (joint->vel_cmd > 0.0) {
[03:15:30] <jepler> (gdb) print joint->vel_cmd
[03:15:30] <jepler> $2 = 2.6807239546590355e-285
[03:15:34] <jepler> yep, that error message sure is right
[03:16:37] <jepler> I guess I'll look at it later
[03:39:35] <jmkasunich> 12 pieces done
[03:39:39] <jmkasunich> jepler: you still here
[03:39:43] <jmkasunich> ?
[03:39:53] <cradek> I'm sure he's not...
[03:40:20] <cradek> what are your 12 parts?
[03:40:31] <jmkasunich> for the CIM jig
[03:40:36] <jmkasunich> 8 "sample plates"
[03:40:40] <jmkasunich> 2 "fixed plates"
[03:40:45] <jmkasunich> 2 "moving plates"
[03:41:00] <jmkasunich> all 12 needed a 1.500" dia by 3/8" deep bore in the center
[03:41:07] <cradek> jeez aren't those things done yet?
[03:41:10] <jmkasunich> (they are all 10.0" x 10.5" plates)
[03:41:12] <jmkasunich> I wish
[03:41:15] <jmkasunich> getting close
[03:41:40] <jmkasunich> the fixed plates (2) need a non-precision rectangular pocket milled in the bottom
[03:41:50] <jmkasunich> then the fixed and moving plates need attached to the frames
[03:42:20] <jmkasunich> (drill and tap about 28 1/4-20 holes, then drill and ream about 12 1/4" dowel pin holes)
[03:42:56] <jmkasunich> then I can pack and ship (packing will take a couple hours - 50+ lbs per jig, need padded carefully
[03:44:15] <cradek> think you might finish this weekend?
[03:45:19] <jmkasunich> no
[03:45:29] <jmkasunich> not gonna try that hard
[03:45:43] <jmkasunich> I'm leaving for finland monday
[03:45:55] <jmkasunich> I'll finish them up when I get back
[03:46:43] <jmkasunich> hmm, dunno why that vel_cmd wasn't initialized
[03:47:00] <jmkasunich> motion.c, line 857: joint->vel_cmd = 0.0;
[03:47:13] <jmkasunich> in a loop thats supposed to init all joints
[03:47:44] <cradek> huh
[03:48:07] <jmkasunich> my gdb skills are seriously lacking (like non-existant)
[03:49:53] <cradek> could that code run before init_comm_buffers?
[03:50:06] <jmkasunich> don't see how
[03:50:20] <jmkasunich> init_comm_buffers runs when the module is insmodded
[03:50:30] <jmkasunich> screw_comp is part of the RT code, runs in the thread
[03:51:17] <jmkasunich> I'm assuming that the non-rt sim still runs the init code before the thread code
[03:51:44] <jmkasunich> pretty much has to - the init code exports the "rt" functions, they can only be added to a thread after they are exported
[03:52:11] <cradek> would have been interesting to see the rest of the things in the joint struct
[03:52:37] <jmkasunich> I gotta wonder if the pointer is scrogged and its pointing to the wrong struct
[03:52:45] <cradek> maybe
[03:53:44] <jmkasunich> I wonder under what conditions he saw that
[03:54:36] <cradek> didn't give us much to go on
[03:54:45] <cradek> not sure if i can figure out how to run valgrind or not
[03:56:05] <jmkasunich> is that what he was doing? or was he just using gdb?
[03:56:29] <cradek> the 'conditional jump depends ...' is valgrind output
[03:56:47] <cradek> I think you can cause valgrind to dump you into gdb at the point of the error
[03:58:03] <jmkasunich> I put this
[03:58:04] <jmkasunich> if (( joint->vel_cmd > 100 ) || ( joint->vel_cmd < -100 )) {
[03:58:04] <jmkasunich> rtapi_print_msg(RTAPI_MSG_ERR, "joint %d has bad vel_cmd\n", joint_num );
[03:58:05] <jmkasunich> }
[03:58:14] <jmkasunich> right above the point of the error
[03:58:15] <jmkasunich> no hit
[03:58:25] <cradek> that won't catch e-285
[03:58:34] <jmkasunich> why not?
[03:58:44] <cradek> e-285 ~= 0
[03:59:08] <jmkasunich> duh
[03:59:14] <jmkasunich> MINUS 285
[03:59:15] <cradek> for some reason many uninitialized values seem to be very close to zero
[04:00:01] <jmkasunich> I wonder what joint number that was?
[04:00:24] <cradek> I checked that both loops work on the same number of joints
[04:00:38] <jmkasunich> the init loop and the comp loop? I checked that too
[04:00:43] <cradek> yeah
[04:01:33] <jmkasunich> its not just the init code
[04:02:07] <jmkasunich> get_pos_cmds also runs before screw_comp (every time) and it also sets the value of vel_cmd
[04:03:29] <cradek> strange!
[04:04:01] <jmkasunich> how exactly does valgrind do its thing?
[04:04:06] <jmkasunich> it actually runs the code?
[04:04:12] <jmkasunich> or just reviews it, like lint?
[04:04:22] <cradek> it checks stuff at runtime
[04:05:30] <jmkasunich> inserts its own code between every line of C or something?
[04:06:33] <cradek> I think it runs the program on a 'pretend CPU'
[04:06:55] <jmkasunich> hmm
[04:07:06] <jmkasunich> I wonder how well it understands multiple threads
[04:07:34] <jmkasunich> that shouldn't matter tho - get_pos_cmds and screw_comp are in the same thread
[04:08:23] <jmkasunich> I'll talk to jeff about it tomorrow
[04:08:32] <jmkasunich> its after midnight, time for sleep
[04:09:36] <cradek> goodnight
[04:20:20] <cradek> I think I figured out how to run it, but I don't get that error.
[04:20:47] <cradek> oh hey look at that
[04:20:50] <cradek> yes I do
[04:21:26] <cradek> as soon as I hit f5 to go into mdi? mode
[04:23:29] <cradek> joint_num 6
[04:24:13] <cradek> I guess this is another one of those things where some parts think we have 6 joints and some think 8
[04:25:07] <cradek> also in process_inputs() the same thing happens with joint_num=6
[04:26:04] <cradek> why is it 8 in the motion controller anyway?
[04:35:47] <jmkasunich> damned if I know
[04:36:34] <jmkasunich> the fact that you don't get the error right away means its not truly a failure to init
[04:36:39] <jmkasunich> (I think)
[04:37:43] <jmkasunich> * jmkasunich goes to sleep
[14:40:15] <jepler> I found two ways to fix that valgrind error. First, in kinematicsInverse(), always set all the joints, including those that aren't used. Second, in get_pos_cmds(), set the entries of double positions[] all to 0 at the start of the function
[14:40:59] <jepler> the latter will fix all kinematics types, and the price is not high (setting 64 bytes to 0 once per traj cycle)
[14:53:50] <jepler> .. so that's the change I checked in ..
[15:06:47] <jepler> hi skunkworks
[15:06:49] <skunkworks> Hi
[15:06:50] <jepler> how goes the CVS version?
[15:07:08] <skunkworks> After the brain flatulance last night - good..
[15:07:19] <SWPadnos> you may find that there's no execution speed penalty, since cache issues are a big factor in thread init time
[15:08:00] <SWPadnos> ie, setting all those bytes to 0 may actually eliminate some reads that may have otherwise been encvessary, and make the cache "hot" for other code
[15:08:10] <SWPadnos> necessary, that was supposed to be
[15:08:46] <jepler> I see your point. I don't plan to benchmark it to find out one way or the other, though
[15:09:13] <SWPadnos> nope ;)
[15:13:23] <jepler> wow, I wish I hadn't looked at the generated code for that
[15:13:40] <jepler> it seems to have generated a copy, not a set-to-zero
[15:13:48] <jepler> 0xb7c768cc <get_pos_cmds+43>:repz movsl %ds:(%esi),%es:(%edi)
[15:15:46] <SWPadnos> hmmm, that's not so good.
[15:16:34] <SWPadnos> and you can't even do ugly code like positions[0] = positions[1] = ... = 0
[15:17:54] <SWPadnos> hmmm - one could do *really* ugly code, using a preprocessor pacro that actually takes EMCMOT_MAX_AXIS into account (using a really grross looping construct)
[15:18:03] <SWPadnos> macro, not pacro
[15:19:31] <jepler> or use memset()
[15:19:47] <SWPadnos> hey - that's even easier ;)
[15:20:12] <SWPadnos> * SWPadnos has a "duh" moment
[15:29:41] <Roguish> Did anyone see this:
http://www.linuxdevices.com/news/NS9566944929.html
[15:30:35] <SWPadnos> "Additionally, embedded Linux developers or normal desktop users wishing to build kernels capable of achieving millisecond-level real-time responsiveness will no longer have to apply patches"
[15:30:44] <SWPadnos> roughly 100 times too long for step generation
[15:35:58] <jepler> but good for servo systems or servo-like external step generators
[15:36:10] <jepler> .. if they actually meet the deadline every time ..
[15:36:41] <SWPadnos> the RT performance with Ingo's patches is very good
[15:36:57] <SWPadnos> not on a microsecond scale though
[15:37:19] <SWPadnos> last I saw (maybe 6 months ago) the jitter was on the order of 25 uS, IIRC
[15:49:39] <jepler> this is interesting:
http://emergent.unpy.net/index.cgi-files/sandbox/sample-time-simulator.png
[15:50:01] <jepler> there's clearly a hard minimum of around 200 cycles, and there's something very periodic that makes the function time very high
[15:50:15] <SWPadnos> that's actual time elapsed (from a hardware timer)?
[15:50:26] <jepler> yes
[15:50:37] <jepler> but because it's running in the simulator, it's being interrupted by other processes, etc
[15:50:44] <SWPadnos> sure
[15:51:02] <SWPadnos> what's the unit though, CPU cycles?
[15:51:10] <jepler> yes
[15:52:08] <SWPadnos> dose sim run "as fast as possible"? (I see the 100 0Hz sample rate, which should be way more than 200 cycles on any x86 CPU)
[15:52:15] <SWPadnos> 1000 Hz, that is
[15:52:31] <SWPadnos> or is that the time it takes to run?
[15:52:40] <SWPadnos> (more duh moments coming, I foresee)
[15:52:59] <SWPadnos> yeah - nevermind, execution time, not period.
[15:53:01] <SWPadnos> duh
[15:53:02] <SWPadnos> duh
[15:53:05] <jepler> scope.sample.time is the time it takes for the function scope.sample to run
[15:53:17] <SWPadnos> * SWPadnos hasn't had any coffee or tea yet today
[15:54:17] <jepler> this isn't indicative of much, except that the userspace latency is often quite bad on this machine and kernel
[15:54:46] <SWPadnos> as far as I see, that doesn't say anything about latency, except that it can be very high sometimes
[15:54:57] <SWPadnos> of course, that's what you just said.
[15:55:16] <SWPadnos> I think it's time to go to the coffee shop and get breakfast, with a healthy dose of caffeine ;)
[15:56:35] <jmkasunich> hi guys
[15:56:36] <jepler> see you
[15:56:39] <jepler> hi jmkasunich
[15:56:46] <jmkasunich> jepler - don't run away yet!
[15:56:52] <SWPadnos> hi jmkasunich, see you later (after caffeine)
[15:56:57] <jmkasunich> regarding that uninitialized error...
[15:57:07] <jmkasunich> motion.c inits all 8 axis
[15:57:20] <jepler> jmkasunich: but kinematics often sets fewer joint positions
[15:57:31] <jmkasunich> so even if get_pos_cmd only does 6, shouldn't the other 2 still be inited?
[15:58:02] <jmkasunich> duh
[15:58:08] <jmkasunich> kins is using locals isn't it
[15:58:19] <jmkasunich> and then copying all 8 to the main struct
[15:58:39] <jepler> you mean joint->coarse_pos?
[15:58:41] <jmkasunich> so the locals are uninited, and they overwrite the zero that the init code stuck in the main struct
[15:58:51] <jmkasunich> I don't know what I mean now
[15:59:05] <jepler> what I saw was that the local array positions[] in get_pos_cmds wasn't initialized
[15:59:17] <jmkasunich> ok
[15:59:42] <jepler> ignore what I said about coarse_pos, that has to do with the free planner
[16:00:33] <jmkasunich> good - I actually understand the free planner
[16:00:35] <jepler> anyway, I got the valgrind error to go away
[16:00:58] <jmkasunich> lines 1763 thru 1769 set vel_cmd
[16:01:17] <jmkasunich> unless vel_req is bogus
[16:01:46] <jepler> anyway, valgrind works by instrumenting the object code to also maintain "defined" and "addressible" bits for all memory, so that when a value is finally used (e.g., if(undefined < 0.0) it can tell that it was undefined
[16:02:42] <jmkasunich> so how can it trip on joint->vel_cmd in screw_comp, _after_ passing when joint->vel_cmd is accessed in get_pos_cmds?
[16:03:14] <jmkasunich> duh again
[16:03:24] <jmkasunich> if (GET_JOINT_ACTIVE_FLAG())
[16:03:24] <jepler> just writing 'a=b' or 'a=b+c' copies around the "defined" bits
[16:03:36] <jepler> only using the value (if(a<0)) triggers the warning
[16:03:42] <jmkasunich> the free mode planner doesn't execute for inactive axes
[16:03:48] <jmkasunich> and the screw comp should be the same
[16:03:57] <jmkasunich> thats the _correct_ fix
[16:04:15] <jepler> that makes sense to me too, but I wasn't sure how to check for "the joint is used"
[16:04:26] <jmkasunich> if (GET_JOINT_ACTIVE_FLAG(joint)) {
[16:04:27] <jepler> do you want me to revert my fix?
[16:04:35] <jepler> my "fix"
[16:04:38] <jmkasunich> I can do that, and insert the test
[16:04:42] <jepler> OK
[16:04:56] <jepler> ==8569== at 0x43A143D: process_inputs (control.c:462)
[16:05:07] <jepler> ==8569== at 0x43A1461: process_inputs (control.c:466)
[16:05:15] <jmkasunich> seems strange that using an undefined value in an expression isn't considered bad by valgrind
[16:05:18] <jepler> I saw errors in several other locations, maybe they all need that code added?
[16:05:27] <jmkasunich> I'll look
[16:06:00] <jmkasunich> the comment immediately above that test in get_pos_cmds says that alex added it at some time well after the first pass of the code
[16:06:07] <jmkasunich> it probably should be added to all, or none
[16:06:24] <jmkasunich> //AJ: only need to worry about free mode if joint is active
[16:06:52] <jmkasunich> otoh, maybe in non-free mode, we do need to care about all axes, and that test should be removed from get_pos_cmds
[16:07:21] <jmkasunich> to be honest, the real fix is to only export the proper number of joings
[16:07:25] <jmkasunich> joints
[16:07:45] <jmkasunich> its dumb to have hal pins for axis.7.pos-cmd when you have a 3 axis machine
[16:08:48] <steves_logging> steves_logging is now known as steve_stallings
[16:11:01] <steve_stallings> Does the "Additional real-time technology will be incorporated into the mainline Linux kernel starting with version 2.6.18" mean that it will show up in all versions including Ubuntu?
[16:11:16] <jmkasunich> not neccessarily
[16:11:32] <steve_stallings> So it is just another pre-patched kernel.
[16:11:34] <jmkasunich> I don't know if ubuntu routinely updates the kernel
[16:11:48] <jmkasunich> it _will_ show up in all 2.6.18 kernels
[16:12:01] <jmkasunich> but ubuntu may or may not update that - they may stick with 2.6.whatever
[16:12:20] <steve_stallings> Could cause some interesting work for RTLinux and RTAI folks.
[16:13:00] <jmkasunich> dunno
[16:13:17] <jmkasunich> those folks need to make changes for most kernel releases anyway I think
[16:13:37] <steve_stallings> Thinking of dueling APIs.
[16:13:40] <jmkasunich> their RT methods are independent of the kernel's approach, so they might be able to ignore it
[16:14:10] <jmkasunich> what _will_ be interesting is if we want to make a version of RTAPI that takes advantage of the new stuff
[16:15:23] <jepler> based on my experience making the simulator, my guess is that we could do it in a weekend
[16:15:48] <jmkasunich> maybe _you_ could do it in a weekend
[16:16:04] <jmkasunich> unfortunately I'be suffered bitrot since I last worked on RTAPI
[16:16:16] <jmkasunich> it would probably take me a weekend just to get up to speed on it again
[16:17:17] <jmkasunich> jepler: "cast happy code" ?
[16:18:25] <jepler> jmkasunich: read the gcc manpage about -fstrict-aliasing
[16:23:44] <Lerneaen_Hydra> IIRC the RT stuff was only soft-rt
[16:23:50] <Lerneaen_Hydra> not hard-rt
[16:50:24] <jmkasunich> very strange
[17:04:46] <jmkasunich> Mr. "Check My Kinematics" is very persistent...
[17:15:51] <jmkasunich> jepler: what do I need to do to run valgrind on emc?
[17:27:07] <jepler> jmkasunich: configure for simulator
[17:27:14] <jepler> jmkasunich: then run "valgrind rtapi_app"
[17:27:25] <jepler> jmkasunich: then start emc2 normally: emc2 configs/sim/axis.ini
[17:27:49] <jmkasunich> switching from RT to sim requires a make clean, right?
[17:27:53] <jepler> yes, I think so
[17:29:40] <jepler> hm, sim_rtapi_app doesn't work right with more than one thread
[17:51:02] <jepler> jmkasunich: if I have one thread at 1ms and one thread at 10ms, does rtapi need to guarantee that they are called in a 10:1 ratio?
[17:51:18] <jmkasunich> yes
[17:51:27] <jmkasunich> at least if you want things to work right
[17:51:38] <jepler> and the 10ms one should never interrupt the 1ms one
[17:51:59] <jmkasunich> yeah
[17:52:12] <jmkasunich> at least, when running true RT thats how it works
[17:52:18] <jepler> that's hard to do, at least with my poor understanding of pthreads
[17:52:45] <jmkasunich> they don't support the concept of priority?
[17:52:48] <jepler> I did find the obvious bug that was making multiple threads not work, though -- I was always returning RTAPI_SUCCESS from rtapi_thread_new
[17:55:46] <jmkasunich> would it be considered wrong for ./configure to invoke make clean if you've changed from RT to sim or vice versa?
[17:56:46] <jmkasunich> I guess it can't invoke make clean (or make anything) since when the script is actually running all the *.in files haven't been updated yet
[17:57:02] <jmkasunich> any automatic clean would have to be done in the makefile
[17:58:07] <jepler> it would be best to figure out what should be rebuilt but isn't, when switching
[17:58:10] <jepler> .. and fix it
[17:58:52] <jmkasunich> unfortunately the make system has evolved beyond my ability to understand it
[18:01:41] <jepler> yeah it's got too much clever in it already
[18:03:33] <jmkasunich> hmm, crapload of warnings
[18:05:43] <jepler> about atomic something?
[18:05:48] <jmkasunich> no
[18:05:56] <jmkasunich> I'd paste them, but they scrolled off
[18:06:10] <jmkasunich> something about declaration of "schedule"
[18:06:13] <jmkasunich> and memset
[18:06:30] <jmkasunich> I'll have the messages again in a minute
[18:07:08] <jmkasunich> I guess configure doesn't complain if you give it an unknown option
[18:07:32] <jmkasunich> I specified --disable-documentation instead of --disable-build-documentation, and it didn't say anything
[18:07:44] <jmkasunich> the spew from the docs scrolled the messages away
[18:08:14] <jmkasunich> In file included from objects/hal/components/minmax.c:2:
[18:08:14] <jmkasunich> /home/john/emcdev/emc2head/src/rtapi/rtapi.h: In function ‘rtapi_mutex_get’:
[18:08:14] <jmkasunich> /home/john/emcdev/emc2head/src/rtapi/rtapi.h:250: warning: implicit declaration of function ‘schedule’
[18:08:14] <jmkasunich> objects/hal/components/minmax.c: In function ‘export’:
[18:08:14] <jmkasunich> objects/hal/components/minmax.c:33: warning: implicit declaration of function ‘memset’
[18:08:16] <jmkasunich> objects/hal/components/minmax.c:33: warning: incompatible implicit declaration of built-in function ‘memset’
[18:08:53] <jmkasunich> got both of those in all the .comp components
[18:09:03] <jmkasunich> only the schedule one in the other hal components
[18:09:24] <jepler> did you update today?
[18:09:32] <jmkasunich> several times
[18:09:48] <jepler> #if defined(RTAPI) && !defined(SIM)
[18:09:48] <jepler> schedule();
[18:09:48] <jepler> #else
[18:09:48] <jepler> sched_yield();
[18:09:48] <jepler> #endif
[18:10:00] <jepler> sched_yield is the userspace function name
[18:10:16] <jepler> did I do the wrong thing here? (I added the !defined(SIM) part just today)
[18:10:18] <jmkasunich> is that supposed to be in rtapi.h?
[18:10:26] <jepler> yes
[18:10:42] <jmkasunich> I just updated again, and I don't have the SIM part
[18:10:43] <jepler> oh I didn't check that in, because I have an unrelated and controversial change in my rtapi.h
[18:11:29] <jmkasunich> I can add it here and check it in, or you can backup the unrelated change and check it in
[18:11:31] <jmkasunich> your call
[18:11:42] <jepler> why don't you check it in if it fixes that warning
[18:11:57] <jmkasunich> ok
[18:14:49] <jmkasunich> it fixed the schedule warning as expected
[18:15:11] <jmkasunich> looking into the memset one
[18:16:02] <jepler> do the generated comp files have '#include "rtapi_string.h"'?
[18:16:18] <jepler> that should include <string.h> in userspace, and my 'man memset' says to include string.h.
[18:17:09] <jmkasunich> where are the generated c files?
[18:17:16] <jepler> in objects/, confusingly enough
[18:17:19] <jepler> 13:09:30 <jmkasunich> objects/hal/components/minmax.c:33: warning: implicit declaration of function 'memset'
[18:17:40] <jmkasunich> duh
[18:17:48] <jmkasunich> no rtapi_string
[18:17:59] <jmkasunich> rtapi, rtapi_app, and hal
[18:18:02] <jepler> find src -name 'comp.*'
[18:18:36] <jepler> either I didn't check something else in (I'll look) or something's gone wrong and you didn't get your 'comp' program updated when you built
[18:19:02] <jmkasunich> I have comp.py, comp.g, and several others
[18:19:54] <jepler> touch hal/utils/comp.g and see if 'make' rebuilds bin/comp and the .c files
[18:20:07] <jepler> $ make
[18:20:07] <jepler> /usr/bin/yapps hal/utils/comp.g hal/utils/comp.py
[18:20:07] <jepler> Syntax checking python script comp
[18:20:07] <jepler> Copying python script comp
[18:20:07] <jepler> Preprocessing wcomp.comp
[18:20:16] <jepler> ^^ here's what I got after a 'touch .../comp.g'
[18:22:32] <jepler> I recall one machine where there was something left over in emc/usr_intf/axis/scripts about comp, and the version from hal/utils wasn't being used at all
[18:22:33] <jmkasunich> it rebuilt a ton of stuff, but not comp itself I don't think
[18:22:55] <jmkasunich> this?
[18:22:56] <jmkasunich> ./emc/usr_intf/axis/scripts/comp.py
[18:23:01] <jepler> yeah -- remove that
[18:23:05] <jepler> touch comp.g again
[18:23:15] <jepler> and see if the memset error is gone yet
[18:23:49] <jmkasunich> it rebuild comp this time
[18:24:10] <jmkasunich> memset warning is gone, but
[18:24:18] <jmkasunich> Compiling realtime objects/hal/components/maj3.c
[18:24:18] <jmkasunich> objects/hal/components/maj3.c: In function ‘export_1’:
[18:24:18] <jmkasunich> objects/hal/components/maj3.c:58: warning: implicit declaration of function ‘simple_strtol’
[18:25:05] <jepler> another change in rtapi.h that I didn't check in:
[18:25:06] <jepler> +#if defined(SIM)
[18:25:06] <jepler> +extern long int simple_strtol(const char *nptr, char **endptr, int base);
[18:25:06] <jepler> +#endif
[18:25:16] <jmkasunich> where does that go?
[18:25:59] <jmkasunich> any old place in the file?
[18:26:04] <jepler> I have it at the end of rtapi.h
[18:28:10] <jmkasunich> happy now
[18:28:56] <jmkasunich> and committed
[18:29:16] <jmkasunich> lunchtime
[18:29:36] <jepler> see you
[19:28:39] <jmkasunich> jepler: I was just looking at limit1.comp
[19:29:04] <jmkasunich> min and max are pins there, but in the blocks version of limit1 they are params
[19:29:07] <jmkasunich> was that on purpose?
[19:29:35] <jmkasunich> also, the original names were min and max, in the .comp they are min_ and max_
[19:32:32] <alex_joni> hi all
[19:32:38] <jmkasunich> hi
[19:32:43] <alex_joni> * alex_joni just got back
[19:32:48] <jepler> hi alex!
[19:32:53] <alex_joni> hey jeff
[19:33:15] <alex_joni> jmkasunich: saw in my away log you were looking at something I touched
[19:33:21] <jepler> jmkasunich: any trailing - is removed from a HAL name, so the pin/param names are still min and max.
[19:33:50] <jepler> jmkasunich: but min_ and max_ are used elsewhere (in a header) in a way that is incompatible with comp's pin and parameter macros
[19:33:55] <jmkasunich> the _ is to avoid collisions with library functs?
[19:34:00] <jepler> er, min and max are, so you have to use min_ and max_
[19:34:03] <jepler> right
[19:34:05] <jmkasunich> ok
[19:34:11] <jmkasunich> what about the change from pin to param?
[19:34:16] <jmkasunich> intentional or oversight?
[19:34:27] <jepler> that must have been after one of our conversations about whether params were even needed
[19:35:17] <jmkasunich> I see
[19:35:29] <jmkasunich> I think for now we should make the blocks replacements look just like the originals
[19:35:34] <jmkasunich> I'll go thru and fix em up
[19:35:36] <jepler> OK, fine by me
[19:35:55] <jmkasunich> I'm changing the stock configs to use the .comp versions so people don't get that warning
[19:36:04] <jmkasunich> otherwise we're gonna get tired of explaining it
[19:36:13] <jepler> that's a problem because not everyone has 'yapps'
[19:36:28] <jmkasunich> well crap
[19:36:38] <jepler> so .. take the warning out?
[19:36:50] <alex_joni> or include the generated .c files
[19:37:07] <jepler> or include 'yapps'
[19:37:12] <alex_joni> :D
[19:37:20] <jmkasunich> I'd add yapps to the list of build deps
[19:37:30] <jepler> I'm pretty sure it is there
[19:37:38] <jmkasunich> I certainly intend to add any new components as .comp files
[19:37:48] <jmkasunich> people without yapps are going to be SOL
[19:37:51] <jepler> but configure doesn't die if it's not available
[19:37:59] <alex_joni> jepler: maybe it should then
[19:38:04] <jepler> ISTR there was some problem getting it on to the older farm machines as well
[19:38:23] <jmkasunich> * jmkasunich prepares to fire a missile at the older farm machines
[19:39:07] <jmkasunich> arg
[19:41:36] <jmkasunich> yeah, the only farm machines with yapps are ubuntu and BDI-4.20
[19:42:11] <jmkasunich> not sure how bad it would be to get it for the others
[19:42:22] <jepler> at least one of them didn't have python installed by default either
[19:42:28] <jepler> iirc
[19:42:45] <jmkasunich> I'm starting to really question the desireability of supporting really old systems
[19:42:52] <cradek> starting?
[19:43:17] <jmkasunich> well, I've been one of the biggest advocates of it
[19:43:29] <jmkasunich> everybody else probably already decided its stupid
[19:44:41] <jmkasunich> this might be the last straw though
[19:44:55] <jepler> if people were actively using emc2 on those systems, my perspective would be different
[19:45:16] <jmkasunich> we don't neccessarily know what they are using
[19:45:21] <jepler> but there don't seem to be any, and so it mostly turns up "that program doesn't exist that long ago" gotchas
[19:47:44] <jmkasunich> the default repositores for BDI-Live rc46 don't contain yapps
[19:48:00] <jmkasunich> I'm not even gonna try to find it for the RH/rpm based ones
[19:48:51] <jmkasunich> I'm kinda surprized it isn't in the rc46 reps tho, they are debian
[19:49:06] <jepler> the .py files and the yapps script itself total 50kb .. we'd need to read the license before checking it into cvs though
[19:49:35] <jmkasunich> other than licenses, what are the gotchas
[19:49:55] <jmkasunich> we'd miss out on yapps bugfixes unless we remember to keep our copy current
[19:50:12] <jepler> that's probably about it
[19:50:20] <jepler> I don't think yapps2 is seeing much development anyway
[19:50:30] <jepler> /usr/share/doc/yapps2/copyright
[19:51:39] <jmkasunich> seems the license isn't a major issue
[20:11:22] <jmkasunich> jepler: take a look at ddt.comp
[20:11:40] <jmkasunich> you declare data as float ("option data float")
[20:11:51] <jmkasunich> but then you typdef a struct ddt_data
[20:12:12] <jmkasunich> the typedef is unused I think
[20:12:21] <jepler> yes, I think you're right
[20:12:26] <jmkasunich> ok, I'll delete it
[20:12:38] <jmkasunich> (I'm going thru blocks and making all the comps match up)
[20:13:31] <jmkasunich> actually, I'm not gonna delete it, I'm gonna use it
[20:13:41] <jmkasunich> thats the preferred way to handle internal data IMO
[20:13:53] <jmkasunich> option data ddt_data;
[20:14:10] <jmkasunich> out = (tmo - data.old) / (period * 1e-9);
[20:14:13] <jmkasunich> right?
[20:14:40] <jepler> yes
[20:14:42] <jepler> and data.old = tmp
[20:14:43] <jmkasunich> ok
[20:14:45] <jmkasunich> right
[20:15:18] <jmkasunich> the other way is usable for single vaules, but the name of the variable has to be 'data' which isn't as informative as 'old'
[20:15:32] <jepler> there'll be worse ahead, when you find I've abused parameters instead of using data
[20:15:42] <jmkasunich> and this way is required for multiple values, might as well make our examples demonstrate it
[20:15:52] <jmkasunich> if you
[20:16:00] <jmkasunich> if you've badly abused them I'll fix
[20:16:18] <jmkasunich> if there is reason to be able to see the data (scoping it to debug, etc) then params make sense
[20:16:42] <jmkasunich> if not, they waste memory and bloat the lists in halcmd, halmeter, etc
[20:17:36] <jmkasunich> I noticed a while back that you .comp'ed limit1 and limit2 but not limit3
[20:19:30] <jepler> limit3 looked hard
[20:19:48] <jmkasunich> it was
[20:20:15] <jmkasunich> just about blew a brain gasket writing that one
[20:23:12] <jepler> that's OK, I'm completely confused by this makefile now
[20:23:38] <jmkasunich> uh-oh
[20:23:41] <alex_joni> oh-oh
[20:34:10] <alex_joni> jepler: you've been really busy
[20:34:21] <jepler> alex_joni: you mean with the manpages?
[20:34:25] <jepler> that was 75% or more cut & paste
[20:35:04] <jmkasunich> just cause its monotonous work doesn't mean its not work
[20:35:14] <alex_joni> jepler: had 50 mails on the commit-list today
[20:35:24] <jepler> that'll teach you to go out of town!
[20:35:33] <jepler> thanks for noticing, though
[20:35:38] <alex_joni> jepler: if you keep it like that, I'll go right back
[20:36:12] <alex_joni> although I have a bad cold.. so I wouln't really enjoy it
[20:36:27] <jepler> I think the manpages are done, except for the proofreading that someone besides me has to do
[20:36:41] <jepler> though fifos and semaphores aren't documented, they aren't used either
[20:36:56] <jmkasunich> and thats just fine with me
[20:37:04] <jmkasunich> in fact I've been tempted to remove them
[20:37:29] <jmkasunich> since they probably have suffered from bitrot somewhere along the line
[20:38:27] <jepler> OK, I think that this patch to include a copy of yapps and make it mandatory is ready
[20:38:31] <jepler> shall I check it in and see what fur flies?
[20:38:50] <jmkasunich> sure
[20:39:18] <jmkasunich> I asked on the board channel whther to do:
[20:39:26] <jmkasunich> 1) include yapps
[20:39:35] <jmkasunich> 2) drop older systems
[20:39:45] <jmkasunich> 3) treat .comp comps as optional
[20:39:52] <jmkasunich> with the comment that 3 sucks
[20:40:00] <jmkasunich> no real answer
[20:40:09] <alex_joni> * alex_joni beeing sick said he didn't care much
[20:40:10] <jmkasunich> since you already did #1, thats fine by me
[20:40:22] <alex_joni> although #2 sounds like the easiest to do
[20:52:58] <jepler> looks like yapps requires at least python 2.0, and possibly newer
[20:53:08] <jepler> += was added in 2.0 if I recall correctly .. but maybe in 2.1.
[20:53:25] <jmkasunich> if BDI-2.0 is the only one that fails, I'll just remove it from the farm
[20:53:33] <jmkasunich> a 2.2 kernel is just too fscking old
[20:57:16] <alex_joni> TNG failed too
[20:57:35] <jmkasunich> yep
[20:57:43] <jepler> same error
[20:57:46] <jepler> it must also be python 1.5?
[20:58:20] <jmkasunich> 1.5.2 on slot 2
[20:58:46] <jmkasunich> same on slot 3
[20:59:12] <jmkasunich> 2.3.3 on slot 4
[21:01:25] <jepler> I've got to go
[21:02:05] <jmkasunich> oops
[21:14:41] <jmkasunich> the result of a conditional is either zero if false, or non-zero if true
[21:14:49] <jmkasunich> but not any specific non-zero value I don't think
[21:15:08] <jmkasunich> and HAL bits follow the same convention
[21:15:18] <jmkasunich> so maj3.comp has a bug
[21:16:52] <jmkasunich> fixed
[21:18:52] <jepler> jmkasunich: it also does -invert in a weird way, because maj3 was the first example and I wanted to have a parameter
[21:19:33] <jmkasunich> doesn't seem that weird to me
[21:19:33] <jepler> maybe maj3 should be removed, or moved to the examples section of the documentation
[21:19:57] <jmkasunich> I rewrote it like this:
[21:19:57] <jmkasunich> int sum = 0;
[21:19:58] <jmkasunich> if (in1) sum++;
[21:19:58] <jmkasunich> if (in2) sum++;
[21:19:58] <jmkasunich> if (in3) sum++;
[21:19:58] <jmkasunich> if(invert)
[21:19:59] <jmkasunich> out = sum < 2;
[21:20:01] <jmkasunich> else
[21:20:11] <jmkasunich> out = sum >= 2;
[21:22:19] <jmkasunich> so far I have everything from blocks except match8
[21:23:59] <jmkasunich> oh, and estop
[21:35:40] <SWPadnos> can that be renamed to latch or something?
[21:37:53] <jmkasunich> why?
[21:38:20] <jmkasunich> it has some estop specific stuff, like an oscillating pin for a chargepump
[21:38:22] <SWPadnos> isn't that what it is?
[21:38:26] <SWPadnos> ah, ok
[21:38:34] <SWPadnos> chargepump should be a separate comp though
[21:38:41] <jmkasunich> a simple latch wouldn't be a bad thing
[21:38:43] <SWPadnos> (and it is with freqgen)
[21:39:11] <jmkasunich> the assumption lately is that things like latching would be done with ladder rungs
[21:39:21] <jmkasunich> only JonE's stuff uses the hal estop component
[21:39:32] <SWPadnos> I just think it's a little misleading to call it estop when all it does is latch a pin (and generate a chargepump output)
[21:39:43] <SWPadnos> right, and he did some weird latching thing lately also
[21:40:20] <jmkasunich> well, I'm not against fixing that
[21:40:24] <SWPadnos> it's more of a set-reset latch, as I see it :)
[21:40:31] <jmkasunich> but it will break people who are using the existing one
[21:40:48] <jmkasunich> sort of
[21:40:59] <jmkasunich> reset dominant, and set edge triggered
[21:41:27] <SWPadnos> actually, a generic edge latch would be a good component (if it hasn't been done in comp yet)
[21:41:46] <jmkasunich> rising edge sets output?
[21:41:54] <jmkasunich> how would it reset? edge on another input?
[21:42:11] <SWPadnos> selectable edge sets output, another input tells it to reset (or hold at 0 as long as the input is high)
[21:42:42] <SWPadnos> I'm not sure how useful that would be, actually
[21:42:54] <jmkasunich> could always make a 7474.comp
[21:43:04] <jmkasunich> D, C, R, and S
[21:43:04] <SWPadnos> heh
[21:43:24] <jmkasunich> that can do all kinds of things
[21:43:33] <SWPadnos> all we need is components to mimic the 74 series and CD4000 series, and we'll be all set :)
[21:43:47] <SWPadnos> for all the old-skool EEs here
[21:43:50] <jmkasunich> I really don't want to go there
[21:44:00] <SWPadnos> heh (just kidding)
[21:44:20] <jmkasunich> classic ladder should the the method of choice for extensive binary logic
[21:44:44] <SWPadnos> did you see the message today about various features in later revisions of CL?
[21:44:51] <jmkasunich> yeah
[21:45:02] <jmkasunich> I didn't see anyone volunteering to port the newer CL over though
[21:45:13] <SWPadnos> that is true
[22:06:42] <alex_joni> night all
[22:06:49] <jmkasunich> goodnight alex
[22:29:05] <jmkasunich> dang, looks like you can't use a - in a component name
[22:29:51] <jmkasunich> tried 'component estop-latch "description"' and it barfed
[22:30:06] <jmkasunich> but 'component estop_latch "description"' worked fine
[22:30:49] <jmkasunich> underscores in pin names get converted to - in hal names, guess thats not true for component names
[23:31:32] <jepler> jmkasunich: I think that could be changed, but existing component names seemed to favor "_"
[23:32:04] <jepler> if your component is called "eat_at_joes" then its pins would be called eat-at-joes.0.example-pin
[23:32:15] <jepler> but the file will be called eat_at_joes.ko
[23:48:23] <jmkasunich> ok
[23:48:37] <jmkasunich> I have no prob with the filename having underscores
[23:48:46] <jmkasunich> wasn't sure if they'd become dashes in the names
