Back
[01:16:43] <jepler> tool touch off should show the tool it is about to modify the entry for
[01:26:25] <mozmck> jepler: for the stepconf height problem, what about using a vertical scrollwindow to put the whole druid in?
[02:04:46] <jepler> wizards don't usually have scrollbars
[02:05:57] <LawrenceG> 11
[02:10:16] <mozmck> maybe just on the page that needs to be taller? I've seen some like that...
[07:50:46] <CIA-1> EMC: 03micges 07master * rd5c3b2a4b2c7 10/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh): Remove unused EMC_SET_DIO_INDEX_TYPE and EMC_SET_AIO_INDEX_TYPE nml messages
[07:50:47] <CIA-1> EMC: 03micges 07master * r2f39866fed2e 10/src/emc/usr_intf/axis/scripts/emctop.py: Make some fields more readable
[07:53:28] <CIA-1> EMC: 03micges 07master * rd41599fde635 10/src/emc/usr_intf/axis/scripts/emctop.py: fix typo, constants are from emcmodule
[08:22:15] <micges1> micges1 is now known as micges_plasma
[09:51:32] <micges1> micges1 is now known as micges
[11:06:36] <micges> hi alex
[11:37:33] <alex_mobile> Hi
[12:42:23] <CIA-1> EMC: 03jepler 07master * rbcb8aafd854b 10/src/emc/motion/command.c: fix tcss.ngc bug
[12:42:25] <CIA-1> EMC: 03jepler 07master * r54c20223167d 10/src/ (configure configure.in): make "run in place" the default
[12:42:26] <CIA-1> EMC: 03jepler 07master * r164a783b42a5 10/configs/sim/lathe.ini: allow spindle to go up to 2krpm. don't turn off spindle to change tools
[13:01:20] <jepler> cradek: here's a clue for tcss2.ngc: Was waiting for atspeed on motion id 5, but reached id 6
[13:01:24] <jepler> I added that new error message
[13:25:48] <steves_logging> steves_logging is now known as steve_stallings
[13:37:25] <steve_stallings> I understand the difference between axes and joints but have not played with any non-trivial kinematics. What limitations exist in the current EMC with respect to joints?
[13:37:52] <steve_stallings> Curious about new branch to support joints.
[13:37:57] <jepler> hi steve_stallings
[13:38:29] <cradek> the big limitation currently is that vel/acc constraints are in axis-space ("world")
[13:38:49] <cradek> the assumption is that they map 1:1 onto joints (which is true in an orthogonal type machine)
[13:43:00] <steve_stallings> Ah that could get one into trouble. Are both axis and joint jogging supported currently?
[13:43:11] <cradek> somewhat
[13:43:20] <cradek> currently there is no incremental jog or jogwheel for axes
[13:44:00] <cradek> we talked about that a bit at fest, but no coding was accomplished
[13:46:02] <steve_stallings> It is great to see the EMC2 community grow and new participants take on significant enhancements. I wish some of the other high tech open source projects were as successful.
[13:47:05] <jepler> it's nice that micges is actively working on this
[13:47:09] <cradek> yes we even have several new developers lately - it makes me happy to see that.
[13:47:30] <jepler> one reason there's been little progress over time is that none of the developers have had more than an academic interest in it
[13:48:02] <cradek> so true - it's the nature of the thing that we write what we need.
[13:48:33] <steve_stallings> so far I haven't even done that, waiting seems to work 8-)
[13:49:02] <steve_stallings> quick, where can I hide
[13:50:00] <jepler> cradek:
http://emergent.unpy.net/files/sandbox/0001-fix-tcss2.ngc-bug.patch
[13:50:32] <cradek> speaking of writing what we need, jeff and I rigid-tapped some parts on my lathe last night
[13:50:53] <cradek> 4-40 form tap held solid in a big drill chuck
[13:50:54] <jepler> I wrote lathe gcode for the first time, then cradek had to spend the evening debugging it
[13:51:30] <cradek> it was fine - we just had to do the usual amount of fiddling.
[13:52:07] <steve_stallings> did you use the normal threading G codes?
[13:52:14] <jepler> G33.1
[13:52:15] <cradek> jepler: oh hey, does that fix it? that looks simple and clean.
[13:52:23] <jepler> cradek: it fixes my one test case
[13:52:29] <cradek> yeah G33.1 is our rigid tap cycle
[13:52:55] <jepler> only thing is, I'm still not sure why G33 didn't show the same bug..
[13:52:57] <steve_stallings> G33.1 handles the spindle reverse to back out
[13:53:02] <steve_stallings> ?
[13:53:03] <cradek> yes
[13:53:14] <steve_stallings> neat
[13:53:23] <jepler> G33.1 Z[.5-.375] K[1/40]
[13:53:27] <jepler> what could be simpler
[13:54:26] <cradek> form taps are cool. no chips left in the hole.
[13:55:00] <steve_stallings> diameter of hole is more critical, as is lube
[13:55:11] <cradek> yep
[13:55:19] <steve_stallings> but it also makes stronger threads
[13:55:40] <cradek> this lathe has cutting oil
[13:59:35] <steve_stallings> ah, the smell of sulphur in a high pressure cutting lube is even better that WD40 8-)
[14:02:07] <cradek> this stuff is great - it's mostly soybean oil - if anything, it smells like french fries
[14:02:13] <cradek> it has almost no smell
[14:03:40] <cradek> "SoyEasy NuCut Lite" or at least I think it's the Lite one that I have
[14:05:34] <jepler> "soyeasy lite" sounds like a terrible product targeted at vegetarians
[14:06:00] <cradek> yeah, I don't claim it's a good name
[14:06:44] <cradek> it was expensive but it works great and I spend zero time messing with it (unlike the water-based stuff)
[14:08:22] <steve_stallings> I saw a fancy Citizen screw machine used to make copper soldering iron tips once. It ran some fancy vegetable oil for both the cutting oil and for all machine lubrication. Strange, but it avoided the issue of lube oil contaminating the cutting fluid.
[14:13:08] <cradek> yeah that sounds like a nice solution
[14:13:16] <steve_stallings> It had many axes, two chucks that could hand off the part for first and second operation on the back end of the parts, live tooling and a C axis to allow engraving of part numbers around the tips, and a bar feeder with stacking input.
[14:13:56] <cradek> wow, sounds complicated for soldering iron tips.
[14:13:56] <mozmck_work> interesting, I'll have to look that stuff up. I already decided to not use way after reading this page
http://yarchive.net/metal/way_oil.html and to look for some non water-based cutting fluid.
[14:14:26] <steve_stallings> It ran 24/7 and could go a couple of days. Critical tools were duplicated and a touch probe decided when a tool was dull so the next one could be used.
[14:16:09] <mozmck_work> I wonder how those touch probes work?
[14:16:30] <mozmck_work> to tell if a tool is dull..
[14:16:33] <cradek> mozmck_work: I use way oil for ways...
[14:17:09] <mozmck_work> I've been using standard motor oil but was going to get way oil. after reading that I think I'll stick to motor oil
[14:19:43] <steve_stallings> The tool is just moved into contact with the probe tip just like touching off. You sense the edge that is expected to wear the most. The machine knows when it should contact and if the distance is too great, it is dull. Probe accuracy is several times greater than minimum movement increment.
[14:21:10] <steve_stallings> Large machines that take heavy cuts sometimes sense spindle power (mills) or tool flexure (strain gages on lathes).
[14:21:27] <mozmck_work> That's interesting. Just based on actual distance vs expected for a sharp tool. I've always wondered when I've heard about automatic measurements like that.
[14:22:03] <steve_stallings> New tools are calibrated when installed, so it is a delta measurement.
[14:23:22] <mozmck_work> i see.
[14:26:34] <steve_stallings> Of course, the concept only works on precision machines that can actually move by amounts small enough to provide actual measurements equivalent to the wear on a dull tool.
[15:04:55] <steve_stallings> steve_stallings is now known as steves_logging
[15:35:48] <cradek> seb!
[15:35:57] <cradek> I did a bunch of stuff on my hostmot2 machine last night
[15:36:01] <cradek> like usual, it worked perfectly
[15:36:04] <seb_kuzminsky> cool :-)
[15:36:08] <seb_kuzminsky> wow it worked?!
[15:36:19] <cradek> haha
[15:36:46] <skunkworks639> what stuff? :)
[15:36:51] <seb_kuzminsky> may i draw your attention to lines 221-224 of
http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/hal/drivers/mesa-hostmot2/stepgen.c;h=1e7616ce332b3508a9c804ae09598490ba8a032d;hb=9a3531d8681e14641f437527001eec88621fab50
[15:37:22] <seb_kuzminsky> this block confounds me
[15:38:22] <cradek> what do you mean?
[15:38:23] <seb_kuzminsky> depending on the values of steplen & stepspace, the print (HM2_ERR) sometimes happens once and then shuts up (as expected) and sometimes happens once per servo loop, hosing the computer
[15:38:43] <cradek> ouch!
[15:39:03] <seb_kuzminsky> if i insert a print between lines 223 & 224 printing maxvel or physical_maxvel, the problem goes away and everything looks sane
[15:39:36] <seb_kuzminsky> if i print *steplen* on line 223.5 the problem goes away...
[15:39:41] <seb_kuzminsky> i'm stumped
[15:39:48] <seb_kuzminsky> i'm guessing a gcc error right now
[15:40:05] <seb_kuzminsky> hal_float_t and double are both double, so i think it's not a rounding error
[15:40:22] <cradek> I bet it's nan because physical_maxvel is 0
[15:40:27] <cradek> errr
[15:40:31] <cradek> because position_scale is 0
[15:40:43] <cradek> that would make the > always fail, even though nan = nan
[15:40:52] <cradek> er no
[15:41:00] <cradek> think first, type second
[15:41:00] <seb_kuzminsky> hmm, i agree position_scale needs to be checked at the top of this function, but i think that's not the problem
[15:41:03] <seb_kuzminsky> heh
[15:41:15] <seb_kuzminsky> printing physical_maxvel reveals it to contain the expected value
[15:41:18] <cradek> if the comparison fails, it would not give the error
[15:41:30] <seb_kuzminsky> and position_scale is checked in another function in the callgraph
[15:41:54] <cradek> there are several unprotected divides here
[15:42:10] <cradek> nan could propogate if steplen + stepspace = 0
[15:42:11] <seb_kuzminsky> (since rtai can preempt lower-priority threads, it can't be safe from TOCTOU)
[15:42:33] <seb_kuzminsky> cradek: agreed, but in this case i think that's not happening
[15:42:40] <cradek> yeah, still that doesn't explain the error
[15:42:57] <SWPadnos> what about steplen and stepspace?
[15:43:10] <seb_kuzminsky> halcmd show param shows the maxvel has the expected value (to 6 decimal places) even while the syslog is filling up
[15:43:11] <SWPadnos> there should be a minimum bound on those
[15:43:16] <cradek> is s->hal.param.maxvel also a double type?
[15:43:19] <seb_kuzminsky> SWPadnos: 1 ns?
[15:43:27] <SWPadnos> no, it's part of the hardware
[15:43:29] <seb_kuzminsky> param.maxvel is hal_float_t, which is "volatile double"
[15:43:47] <SWPadnos> you can't output more than one step every 2 FPGA clocks (nad probably less than that even)
[15:43:50] <cradek> ok, the assignment should be exact
[15:43:52] <SWPadnos> s/nad/and/
[15:44:12] <SWPadnos> that probably shouldn't be volatile
[15:44:27] <seb_kuzminsky> SWPadnos: volatile seems fine to me there
[15:44:35] <SWPadnos> you want to use exactly one snapshot of all these values during any given run through this function
[15:44:46] <SWPadnos> if some change midway through, you're hosed
[15:45:40] <SWPadnos> (that doesn't necessarily explain the problem though)
[15:45:46] <seb_kuzminsky> SWPadnos: the stepgen module in the fpga is clocked at 33 MHz, so minimum steplen & stepspace is 3 ns
[15:46:15] <seb_kuzminsky> yeah i believe that none of those inputs are changing while the code is running
[15:47:04] <seb_kuzminsky> calling printk after the assignment makes the problem go away. even if i print something other than maxvel. that's just strange
[15:47:07] <SWPadnos> 33 or 50 MHz I guess
[15:47:12] <seb_kuzminsky> SWPadnos: right
[15:47:20] <seb_kuzminsky> 33 in this case, it's on a 5i20
[15:47:42] <SWPadnos> right. maybe add a check for that to the TO-DO list :)
[15:48:46] <jepler> hi seb
[15:48:50] <seb_kuzminsky> hi jeff
[15:49:44] <jepler> a temporary is being kept in a register. any function call forces the store to stack, magically fixing it.
[15:49:56] <jepler> (floating point register precision is 64 bits, stored as a double it's 53 bits)
[15:52:44] <jepler> for example in decimal with short precisions, the calculated physical_maxvel is 1.0009 and maxvel is 1.001, so the > comparison is true. But the properly rounded value of 1.0009 to 3 places is 1.001, and that is stored in hal.param.maxvel
[15:53:38] <seb_kuzminsky> jepler: i thought a double was the same in a register as in memory
[15:53:43] <jepler> no
[15:53:47] <seb_kuzminsky> but you know way more about doubles than me ;-)
[15:53:53] <SWPadnos> the registers are 80 bits total
[15:54:09] <SWPadnos> they're EXT or "tenbyte" type
[15:54:10] <jepler> On x86 temporaries are kept in "long double" format with 64-bit mantissa
[15:54:16] <seb_kuzminsky> ah ok
[15:54:36] <jepler> well, the x87 floating point stack is
[15:54:54] <jepler> gcc keeps things on the stack when it can, because usually the added precision acts to improve the accuracy of calculations
[15:55:15] <seb_kuzminsky> is there a good way to do this, better than having some small fudge factor hardcoded into the assignment?
[15:55:38] <seb_kuzminsky> explicitly cast everything to double or float in the comparison and assignment?
[15:55:46] <jepler> no, an explicit cast won't help
[15:56:31] <jepler> I don't know what the good solution is
[15:57:03] <jepler> in software stepgen, I have a separate "error printed" flag
[15:58:14] <jepler> I'd be tempted to try this:
[15:58:14] <jepler> static double force_precision(double d) __attribute__((noinline)) {
[15:58:14] <jepler> return d;
[15:58:14] <jepler> }
[15:58:33] <jepler> then physical_maxvel = force_precision(physical_maxvel)
[15:59:07] <seb_kuzminsky> i'm still missing something
[15:59:26] <seb_kuzminsky> physical_maxvel is a temporary, so gcc puts it in a register and leaves it there
[15:59:38] <seb_kuzminsky> maxvel lives out in memory
[16:00:04] <seb_kuzminsky> when maxvel is fetched, it's expanded from 64 bits to 80 bits
[16:00:13] <seb_kuzminsky> all the work is done in 80 bits
[16:00:47] <seb_kuzminsky> when maxvel gets written out to memory, it gets squished down to 64 bits, possibly losing enough precision that the comparison will fail again next time through
[16:01:01] <seb_kuzminsky> so why does "early eviction" help?
[16:01:33] <jepler> that makes the comparison be 1.001 > 1.001 instead of 1.001 > 1.0009
[16:02:05] <seb_kuzminsky> oh, by converting *physical_maxvel* down to 64 and then back up to 80 fixes it, i see
[16:02:16] <jepler> I think so, but I'm not sure
[16:02:46] <seb_kuzminsky> but wait, even if i put a do-nothing function call *after* the assignment (between lines 223 & 224), the problem goes away
[16:09:38] <jepler> that I can't explain
[16:09:42] <jepler> http://emergent.unpy.net/files/sandbox/tim.c
[16:10:05] <jepler> here, compiling it without -DBUGFIX prints 'REDUCED LIMIT' and two long doubles in hex notation
[16:10:24] <jepler> you can see that they differ in the last place, which is a part of the mantissa that would be discarded in double precision
[16:10:33] <jepler> if you build with -DBUGFIX it doesn't.
[16:11:36] <cradek> man, is there anything floating point can't do
[16:11:49] <jepler> floating point is a terrible idea
[16:11:51] <SWPadnos> represent numbers exactly
[16:12:07] <jepler> it can represent numbers exactly
[16:12:17] <SWPadnos> for certain values of "numbers" :)
[16:12:22] <jepler> just not very many of them
[16:12:35] <jepler> but then, so-called ints don't represent a very large fraction of all integers either..
[16:12:56] <SWPadnos> yet they do have 100% coverage over their effective ranges, unlike floats
[16:15:02] <cradek> yeah you can have that if the number of values in a range is countable
[16:15:21] <SWPadnos> yep. the deck is a little bit stacked in the ints favor there
[16:16:37] <seb_kuzminsky> thanks jeff
[16:16:43] <seb_kuzminsky> i'll try it tonight
[16:16:46] <jepler> seb_kuzminsky: I have something for you before you go
[16:16:53] <jepler> seb_kuzminsky: I want to get rid of configure and config.h.in from git
[16:16:54] <seb_kuzminsky> i'm not going anywhere ;-)
[16:17:08] <jepler> seb_kuzminsky: can you get autoconf installed on the buildbots?
[16:17:18] <seb_kuzminsky> sure, hold on
[16:17:22] <jepler> seb_kuzminsky: and you'll have to change the "configuring" step to run a new command, ./autogen.sh
[16:17:33] <jepler> shall we do that now? I have a patch prepared..
[16:26:19] <jepler> (oh and I had to compile tim.c with -O2 to get the weird behavior)
[17:02:24] <seb_kuzminsky> jepler: ok try your patch and we'll see what happens
[17:04:32] <seb_kuzminsky> jepler: i didnt touch your buildslave of course
[17:43:40] <jepler> seb_kuzminsky: back from lunch
[17:43:54] <seb_kuzminsky> was it delicious
[17:44:10] <jepler> yes
[17:44:40] <CIA-1> EMC: 03jepler 07master * rc2bc8cf37a7d 10/src/emc/kinematics/tp.c: fix tcss2.ngc bug
[17:44:44] <CIA-1> EMC: 03jepler 07master * rd98d47d13abf 10/src/ (Makefile autogen.sh config.h.in configure): don't keep autoconf-generated files in git
[17:45:07] <jepler> I think the 'master' buildslaves need to: ./autogen.sh; ./configure ...
[17:45:18] <seb_kuzminsky> right, that's what they do now
[17:47:31] <cradek> BUILD FAILED: failed configuring configure
[17:47:32] <cradek> ha
[17:48:14] <seb_kuzminsky> oh it's called src, not source
[17:48:18] <seb_kuzminsky> i think i knew that...
[17:51:19] <seb_kuzminsky> hm, why is it building the 2.3 branch?
[17:51:32] <jepler> I dunno; my push only changed master!
[17:52:00] <seb_kuzminsky> then i fixed the master.cfg and told it to rebuild your most recent push
[17:52:32] <jepler> I loaded one-box-per-builder before your last restart. they were already building then
[17:55:04] <jepler> or "pending", I guess
[18:00:05] <seb_kuzminsky> loosk to me like the force-build button is broken in buildbot 0.7.9, it sends the build to all builders, bypassing the schedulers' branch restrictions
[18:01:57] <seb_kuzminsky> that's more like it
[18:03:15] <jepler> ugh, now "failed git"s?
[18:03:28] <seb_kuzminsky> no that was me killing it
[18:03:34] <seb_kuzminsky> "interrupt"
[18:04:56] <jepler> oh
[18:05:11] <cradek> heh, I think they're all gittting at the same time again
[18:05:53] <jepler> whee, looks good
[18:06:05] <seb_kuzminsky> hm
[18:06:25] <seb_kuzminsky> jepler: are you going to commit that to the 2.3 branch too? i changed the builders before i thought to ask you...
[18:07:28] <seb_kuzminsky> plus, if you do, it'll properly rebuild on the 2.3 buildslaves and the board will be green again ;-)
[18:08:17] <jepler> seb_kuzminsky: no, I don't want to do that on the 2.3 branch yet (maybe never)
[18:08:28] <seb_kuzminsky> ok i'll undo that in the buildbot
[18:08:46] <jepler> sorry, I should have said..
[18:08:55] <seb_kuzminsky> no prob, i just assumed
[18:10:04] <cradek> now 6 of them...
[18:10:26] <cradek> too bad it's not possible to do scotty's accent over irc
[18:12:10] <SWPadnos> jepler, can you add autoconf to the build-deps and/or emc2-dev?
[18:15:33] <jepler> SWPadnos: it doesn't make sense in emc2-dev, but it should be listed in the Build-Depends of master
[18:16:36] <SWPadnos> ok. I wasn't sure it would be appropriate for emc2-dev
[18:19:12] <jepler> nope, that's not what emc2-dev is for
[18:19:43] <jepler> if the emc2-cvs-build-dep package was still being updated it would make sense to list it there (and change the name, of course)
[18:22:48] <CIA-1> EMC: 03seb 07master * r3542b04917dd 10/debian/rules.in: debian/rules needs to run autogen when building
[18:24:53] <CIA-1> EMC: 03jepler 07master * r870bd24fc750 10/debian/control.in: building now requires autoconf
[18:25:28] <skunkworks639> http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/emc/kinematics/genhexkins.c;h=1fa4967b6a6efcb9ce9109559efa61548b3c4fe9;hb=b7b3b24502aa7afb95b68a76b66b571274344b33
[18:25:54] <CIA-1> EMC: 03jepler 07master * r8c4cd5d51ebb 10/src/emc/kinematics/tp.c: let's enable these warnings and see what turns up
[18:26:28] <skunkworks639> in the third paragraph it says The values stored in these arrays are defined in the header file genhex.h. = shouldn't it be genhexkins.h
[18:27:03] <jepler> /* comments are always false */
[18:27:09] <skunkworks639> heh
[18:27:41] <SWPadnos> the comments also imply that a variax configuration would be supported
[18:27:54] <skunkworks639> heh - sort of what I was getting.
[18:27:57] <SWPadnos> since the strut end positions are independent of each other
[18:31:40] <jepler> skunkworks639: but yes, you're right. feel free to submit a patch.
[18:32:34] <seb_kuzminsky> bbl - lunch
[19:58:39] <skunkworks639> cradek: how small of wire did you need?
http://cgi.ebay.com/MAGNET-WIRE-41AWG-155C-4-000ft_W0QQitemZ370226835368QQcmdZViewItemQQptZBI_Connectors_Switches_Wire?hash=item56333d2fa8&_trksid=p3286.c0.m14&_trkparms=65%3A12%7C66%3A2%7C39%3A1%7C72%3A1205%7C293%3A1%7C294%3A50
[19:59:21] <skunkworks639> that has to be around .0026 diameter\
[20:01:20] <skunkworks639> or
http://cgi.ebay.com/Enameled-Copper-Magnet-Wire-27oz-42-Ga-80-000-ft_W0QQitemZ160348606897QQcmdZViewItemQQptZBI_Connectors_Switches_Wire?hash=item25558591b1&_trksid=p3286.c0.m14&_trkparms=65%3A12%7C66%3A2%7C39%3A1%7C72%3A1205%7C293%3A2%7C294%3A50
[20:01:27] <skunkworks639> smaller yet..
[20:02:02] <skunkworks639> and smaller yet
[20:02:04] <skunkworks639> http://cgi.ebay.com/43-Magnet-Wire-1-Lbs-10-Ozs-108900-Feet_W0QQitemZ290330316109QQcmdZViewItemQQptZBI_Connectors_Switches_Wire?hash=item4399090d4d&_trksid=p3286.c0.m14&_trkparms=65%3A12%7C66%3A2%7C39%3A1%7C72%3A1205%7C293%3A2%7C294%3A50
[20:02:05] <skunkworks639> heh
[20:02:27] <SWPadnos> because everyone needs ~109000 feet of wire :)
[20:03:26] <skunkworks639> the table I have stops at 40 which is .00314
[20:07:32] <cradek> #53 I think it was
[20:07:59] <cradek> no, #54
[20:09:01] <skunkworks639> oh
[20:11:15] <cradek> http://www.planetengineers.com/product.asp?pid=1235
[20:11:24] <cradek> wow, here's some available for cheap
[20:11:45] <cradek> I bet they don't actually have it
[20:14:39] <skunkworks639> can't buy it by the foot? ;)
[20:25:37] <cradek> skunkworks639: you really can't respool it - you can't pull it off the spool without breaking it. I think it takes very special hardware (yes I have a design in mind!)
[20:26:08] <cradek> so you get whatever spool size the manufacturer put it on
[20:26:18] <skunkworks639> Neat :) Emc - hal involved? ;)
[20:26:29] <cradek> yes hal would be involved
[20:32:52] <CIA-1> EMC: 03micges 07joints_axes3 * rd5119ce55792 10/src/emc/ (ini/initraj.cc task/taskintf.cc): Add debug code to traj vel/acc/unit config code
[20:42:12] <micges> good night all