Back
[02:24:58] <christel> [Global Notice] Hi all, as many of you are asking about where to send your condolences, we have set up condolences@freenode.net - e-mails to that address will be posted to the "Book of Memories" section we are putting up on the website, as well as passed on to Rob's wife. On behalf of freenode staff I would also like to thank you all for reaching out to us today with well wishes and support.
[06:27:27] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[14:05:46] <steves_logging> steves_logging is now known as steve_stallings
[15:53:42] <alex_joni> hello
[15:53:53] <jmkasunich> hi
[15:53:54] <alex_joni> jmkasunich: care to look at a patch for backlash correction?
[15:54:05] <jmkasunich> maybe
[15:54:07] <jmkasunich> I saw the post
[15:54:26] <alex_joni> sent you the patch, I think we might want to add him as a developer
[15:54:41] <jmkasunich> and he correctly identifies the issue - the accel and vel of the correction is added to the accel and vel of the main move, hard to make sure the sum remains below limits
[15:54:47] <alex_joni> even if he didn't fully solve the backlash problem (needs some parts in TP aswell), I think it's better than before
[15:54:52] <alex_joni> right
[15:55:50] <alex_joni> I think the only way to make sure is to generate it from the TP
[15:55:58] <alex_joni> but then again, what do I know :)
[15:56:29] <jmkasunich> wow, thats a lot of added code
[15:56:59] <jmkasunich> and its something like the 3rd place where we do S-curve stuff
[15:57:03] <jmkasunich> the free mode TP does it
[15:57:09] <jmkasunich> the limit3 block does it
[15:57:22] <jepler> hm I must have missed this post
[15:57:30] <alex_joni> jepler: it was a private email
[15:57:36] <jepler> oh
[15:57:37] <alex_joni> he asked for developer status
[15:57:37] <jepler> ok
[15:57:37] <jmkasunich> the patch was private
[15:57:42] <alex_joni> I asked for a ptach first
[15:57:52] <jmkasunich> he did post on the list about backlash in general
[15:58:04] <alex_joni> I assumed it will probably end up in CVS sooner or later anyways
[15:58:13] <alex_joni> but if you feel like reading, I can mail you a copy ;)
[15:58:25] <jepler> no thanks
[15:58:36] <jmkasunich> darn
[15:58:48] <alex_joni> jepler: :(
[15:58:50] <jmkasunich> this is a tough problem, I was hoping for more eyes on it
[15:59:03] <jepler> I just want to veg today
[15:59:07] <jmkasunich> ok
[15:59:24] <jmkasunich> I know the feeling, I have to travel all this week, and I'm not looking forward to id
[15:59:28] <jmkasunich> it
[15:59:35] <alex_joni> jmkasunich: I heard.. poor you
[15:59:40] <jepler> that's too bad
[15:59:53] <jmkasunich> fortunately this is the last week of that training
[15:59:55] <alex_joni> at least I won't travel next week
[16:00:09] <alex_joni> I moved my second trip to germany to about 2 weeks from now
[16:02:50] <alex_joni> jepler: I tried some bbqed plums today.. they are really great :D
[16:03:52] <alex_joni> jmkasunich: didn't you tackle this one?
http://sourceforge.net/tracker/index.php?func=detail&aid=1372949&group_id=6744&atid=106744
[16:04:59] <jepler> him and/or cradek
[16:05:25] <jmkasunich> yeah
[16:05:32] <jmkasunich> cradek mostly
[16:05:53] <jmkasunich> IIRC it covers only the servo thread, not the base thread
[16:06:41] <jmkasunich> (its implemented as part of motmod, not inside hal_lib where it would apply to all threads)
[16:18:04] <jepler> yes, that's true
[16:20:18] <jmkasunich> the problem with a hal_lib implementation is communicating the results to the outside world
[16:21:27] <alex_joni> jmkasunich: I think the problem is in defining a path for a non-EMC communication
[16:22:09] <alex_joni> I can imagine it pretty easy if you only take the emc2 case, but making a generic HAL solutions is kinda hard
[16:22:42] <jmkasunich> yep
[16:23:16] <jmkasunich> the same problem happened with thread_time and thread_tmax
[16:23:24] <jmkasunich> at one time, those were params
[16:23:43] <jmkasunich> but params belong to components, and threads don't
[16:25:16] <jmkasunich> if we could solve that "param associated with thread" problem, then each thread could have a param called "overruns"
[16:25:16] <alex_joni> unless there is a component to which all threads belong
[16:25:27] <alex_joni> then it would make sense that params belong to that component too
[16:25:33] <jmkasunich> yeah
[16:25:46] <jmkasunich> we do have the "threads" component, but its used to create threads
[16:26:03] <jmkasunich> you can unload the component and the thread(s) remain
[16:26:13] <jmkasunich> in fact you can load it again to create more threads
[16:26:36] <jmkasunich> and motmod creates threads itself, without using the threads component
[16:26:43] <alex_joni> yeah, I know
[16:34:00] <jmkasunich> assume for a minute that we figure out how to associate params with threads
[16:34:17] <jmkasunich> then the low level code for detection of overrun can be done, and increment the overrun param
[16:34:30] <jmkasunich> how would we inform the user?
[16:34:39] <jmkasunich> of course he can look at the overrun param with halmeter
[16:34:48] <jmkasunich> but what if he as no clue that he's getting overruns
[16:35:11] <jmkasunich> cradek's emc-only solution uses EMC's ability to pop up a dialog
[16:36:37] <rayh> seems to me that the error reporting system could be used for this.
[16:37:03] <jmkasunich> which error reporting system? hal doesn't have one (other than writing to dmesg)
[16:37:47] <alex_joni> I think ray is referring to emc's error reporting system
[16:37:49] <alex_joni> and I agree
[16:37:54] <rayh> Oh right. EMC's errors are separate.
[16:38:08] <alex_joni> once in userspace it will go through UserReportError or whatever it's called
[16:38:19] <alex_joni> OperatorMessage or something like that
[16:38:34] <jmkasunich> this conversation is a result of alex_joni saying "I can imagine it pretty easy if you only take the emc2 case, but making a generic HAL solutions is kinda hard"
[16:39:02] <rayh> I saw that.
[16:39:24] <jmkasunich> it would indeed be easy for motmod to copy the overruns count to the emc status structure
[16:39:25] <rayh> The error does not need to be reported in rt but has to be passed some way.
[16:39:28] <alex_joni> jmkasunich: maybe it would be interesting for HAL to have some sort of generic error reporting
[16:39:37] <jmkasunich> and then let the higher level code deal with it
[16:39:45] <alex_joni> with a defined function interface
[16:39:58] <jmkasunich> alex_joni: has to be pretty darned generic tho
[16:40:04] <jmkasunich> hal doesn't even require X
[16:40:06] <alex_joni> so if someone wants (either EMC or some other GUI) it can connect there, and get some strings
[16:40:18] <alex_joni> jmkasunich: simple strings don't require X
[16:40:28] <jmkasunich> so popping up a dialog, which is the right thing to do if you have X, isn't the right thing to do in other cases
[16:40:46] <rayh> maybe not strings just numbers like the interpreter.
[16:40:51] <alex_joni> I agree.. but in all cases it's getting a parsed string then do something else with it
[16:41:08] <jmkasunich> hmm, numbers would allow translations
[16:41:13] <jmkasunich> and reduce the amount of code in RT
[16:41:20] <alex_joni> rayh: even numbers.. but I find it hard to imagine how to make that a general solution
[16:41:30] <alex_joni> jmkasunich: you have the writing to syslog .. right?
[16:41:37] <jmkasunich> yes
[16:41:37] <alex_joni> even the _ERR
[16:41:52] <jmkasunich> rtapi_print from RT goes to syslog, from user code goes to stdout
[16:41:55] <alex_joni> how about having a 'pin/place' where a function could connect and get errors like that
[16:42:06] <alex_joni> like a pipe
[16:42:12] <rayh> The end user would have to write a lookup table
[16:42:36] <jmkasunich> hal_err_msg.h - could contain the #defines for the numbers, and the english strings
[16:42:53] <jmkasunich> any user space code could include that, as well as translation stuff
[16:43:05] <jmkasunich> RT code would include the same file if it wants to generate errors
[16:43:13] <jmkasunich> so they stay in sync as new messages are added
[16:44:06] <alex_joni> jmkasunich: so how does the mechanism work in the end?
[16:44:13] <alex_joni> have a pin with error number?
[16:44:18] <jmkasunich> I dunno, I'm making it up as I go along
[16:44:46] <jmkasunich> do we want each hal component to have an independent error reporting path? or one path for everything?
[16:45:04] <alex_joni> I see it like this: we already have a path for everything
[16:45:08] <alex_joni> which is the syslog
[16:45:18] <jmkasunich> that is _really_ everything
[16:45:27] <alex_joni> jmkasunich: ok, then maybe only errors
[16:45:46] <jmkasunich> and its not simple at all for a user space program to poll the syslog and pop up a dialog when a hal error occurs
[16:45:53] <alex_joni> indeed it's not
[16:46:07] <alex_joni> that's why I was thinking of another mechanism, in paralel to the syslog
[16:46:12] <jmkasunich> I was thinking more like a single location in hal shmem
[16:46:26] <jmkasunich> any error in RT (or maybe even user space) would write an error code to that location
[16:46:33] <alex_joni> because only looking at the syslog you won't know if it's HAL or something else, only by looking at the things written there
[16:46:53] <alex_joni> I was thinking of the rtapi_print(MSG_ERR,..) calls
[16:46:55] <jmkasunich> the user space prog would read it and print the message (several differnet version, one uses dialog, one to stdout, one integrated with emc's error reporting, etc)
[16:48:50] <jmkasunich> there are different classes of errors too
[16:48:57] <alex_joni> jmkasunich: I'm not sure I explained what I was thinking about obvious enough
[16:49:21] <jmkasunich> maybe not
[16:49:46] <alex_joni> currently there are a lot of error checks, and rtapi_print's all over the code
[16:49:57] <jmkasunich> rtapi_print() from RT is 95% at init time (when loading the module)
[16:50:27] <alex_joni> why not use the infrastructure, and make the rtapi_print not only in the syslog, but to another location (error-related) probably in SHM
[16:50:29] <jmkasunich> motmod is probably the only component with significant runtime errors that would call rtapi_print
[16:50:52] <jmkasunich> oh, I understand
[16:51:06] <alex_joni> maybe only 1-2 error messages at once
[16:51:10] <jmkasunich> it would need to be a decent sized fifo
[16:51:19] <alex_joni> just overwrite older messages
[16:51:25] <jmkasunich> and the messages would be english only - there is no practical way to translate in kernel space
[16:51:27] <alex_joni> user can look in syslog for more of them
[16:51:58] <alex_joni> unless it's translated at compile time
[16:52:20] <jmkasunich> does .po and associated stuff work at compile time?
[16:52:23] <alex_joni> but I see how the fifo can be a limitation
[16:52:27] <alex_joni> no, at runtime
[16:52:32] <jmkasunich> thats what I thought
[16:52:39] <jmkasunich> I don't want to invent a new translation system
[16:52:58] <alex_joni> :)
[16:53:00] <alex_joni> brb
[16:57:04] <alex_joni> back
[16:57:52] <jmkasunich> the idea of routing rtapi_print into user space has pros and cons
[16:57:59] <alex_joni> right..
[16:58:02] <jmkasunich> pro: no change to all the code that calls rtapi_print
[16:58:10] <jmkasunich> con: no translation
[16:58:13] <alex_joni> not necessarely a pro
[16:58:22] <jmkasunich> why not?
[16:58:23] <alex_joni> err.. yeah
[16:58:29] <alex_joni> I was thinking of changing rtapi_print
[16:58:41] <alex_joni> but at that point it's too late to change from text to number :D
[16:58:50] <alex_joni> so, it's a pro
[16:59:09] <jmkasunich> right - rtapi_print can print _any_ string, so it allows new messages to be added trivially
[17:01:00] <jmkasunich> one problem (even with a fifo) is that rtapi_print can in theory be called by one RT thread, prints half of a string, then that thread gets interrupted by another RT thread, and that one also calls rtapi_print
[17:01:21] <jmkasunich> I dunno how the syslog deals with that
[17:01:25] <jmkasunich> maybe it doesn't
[17:01:53] <alex_joni> wonder if those are atomic operations
[17:02:05] <alex_joni> or maybe they happen at once
[17:02:34] <jmkasunich> printk can't be atomic, unless they completely disable interrupts during it
[17:02:40] <jmkasunich> which would be bad for realtime
[17:02:51] <alex_joni> right
[17:04:32] <jmkasunich> I think motmod is the _only_ module that calls rtapi_print in actual realtime code
[17:04:53] <jmkasunich> lots of them call it during init code, while exporting pins, etc
[17:05:12] <alex_joni> right
[17:05:29] <alex_joni> because so far we had no real components with error checking
[17:05:43] <alex_joni> like a driver which reports a bad read from an encoder counter
[17:06:01] <jmkasunich> the general philosophy for any realtime component is to fake it and carry on
[17:06:15] <jmkasunich> perhaps increment an error counter
[17:06:58] <jmkasunich> remember, if a thread is running every 50uS, and something busts that results in an error every time it runs, thats 20,000 messages per second into the syslog (or wherever)
[17:07:49] <jmkasunich> motmod is very carefull to avoid that when it calls rtapi_print
[17:08:18] <alex_joni> I know
[17:08:50] <jmkasunich> imagine a component where pin 'out' = sqrt(pin 'in')
[17:09:14] <jmkasunich> if in is negative, it should set out to some documented value, probably either zero, or sqrt(fabs(in))
[17:09:21] <jmkasunich> but _not_ print any messages
[17:10:44] <alex_joni> yeah, I do know why we don't have any prints from the components
[17:11:10] <alex_joni> I just said it's probable that one day there will be more components which inform the user of an error
[17:13:02] <jmkasunich> hmm, I just grepped control.c and command.c
[17:13:14] <jmkasunich> the only rtapi_print used for an error is the overrun code
[17:13:58] <jmkasunich> command.c uses reportError, not rtapi_print
[17:24:00] <alex_joni> and there are some rtapi_prints in the command checking
[17:24:02] <alex_joni> I think
[17:24:14] <jmkasunich> nope
[17:24:32] <jmkasunich> (well, yes, but they only print the name of the command, and are for debugging, not error-reporting)
[17:25:12] <jmkasunich> like rtapi_print_msg(RTAPI_MSG_DBG, "SET_POSITION_LIMITS");
[17:25:34] <jmkasunich> compared to reportError("Can't jog out of range axis %d.", joint_num);
[17:27:02] <alex_joni> oh, right..
[17:27:12] <alex_joni> isn't there one at the end with can't recognize command or similar?
[17:27:59] <jmkasunich> rtapi_print_msg(RTAPI_MSG_DBG, "UNKNOWN");
[17:27:59] <jmkasunich> reportError("unrecognized command %d", emcmotCommand->command);
[17:28:10] <alex_joni> ok :)
[17:29:25] <jmkasunich> there are two...
[17:29:26] <jmkasunich> rtapi_print_msg(RTAPI_MSG_ERR, "ERROR: index out of range, %d not in [0..%d] (increase EMCMOT_MAX_DIO)\n",index,EMCMOT_MAX_DIO);
[17:29:34] <jmkasunich> rtapi_print_msg(RTAPI_MSG_ERR, "emcmotAioWrite called, yet not implemented\n");
[17:29:49] <jmkasunich> but I think those are bugs, they should use reportError like the rest
[17:30:32] <alex_joni> right
[18:04:30] <steve_stallings> steve_stallings is now known as steves_logging
[18:17:58] <alex_joni> SWPadnos: around?
[18:20:47] <alex_joni> SWPadnos: there is a small problem involving access rights on DH
[18:29:32] <alex_joni> I think the wiki folder needs to be owned by cncman, I can't chance my preferences
[18:47:52] <alex_joni> s/chance/change/
[20:26:58] <Lerneaen_Hydra_> Lerneaen_Hydra_ is now known as Lerneaen_Hydra
[20:54:10] <cradek> alex_joni: I think I can't edit the wiki
[20:54:20] <cradek> cant write /home/.jared/cncman/www.linuxcnc.org/wiki/data/keep/T/TroubleShooting.kp: Permission denied at emcinfo.pl line 2848.
[20:54:37] <alex_joni> cradek: check a few lines above..
[20:55:03] <cradek> ah
[20:55:08] <alex_joni> I think the webserver gets spawned as cncman
[20:55:17] <alex_joni> and I have some doubt about making the files 666
[20:55:33] <cradek> ok let's wait for swp to look at it then
[20:55:33] <cradek> thanks
[20:57:32] <jepler> huh -- I edited a page (sandbox) just fine
[20:57:44] <jepler> that was when alex first announced the wiki had been moved
[20:58:01] <alex_joni> jepler: really?
[20:58:05] <alex_joni> does that still work?
[21:00:43] <rayh> I get an error also when trying to save an edit to a wiki page.
[21:01:08] <jepler> if the SandBox says 'moomoomoo' then it works for me.
[21:01:15] <jepler> This is a sandbox page. Try out editing here because there is nothing important or sacred on this page moomoomoomoo
[21:01:58] <alex_joni> Try out editing here because there is nothing important or sacred on this page moomoomoomoo
[21:02:47] <alex_joni> hmm.. that seems to work
[21:03:51] <alex_joni> I think I have a clue now
[21:06:36] <alex_joni> cradek: try now..
[21:09:03] <cradek> yay
[21:09:08] <cradek> thanks
[21:10:19] <alex_joni> np
[21:10:28] <alex_joni> but we still want SWPadnos to look at it ;)
[21:37:06] <rayh> I am able to edit the emc wiki now. Thanks alex.
[21:38:56] <alex_joni> np rayh
[21:39:00] <cradek> we may have to split the available accel between tp and backlash comp
[21:39:11] <alex_joni> I know we usually forget and start typing in the wrong channel
[21:39:23] <alex_joni> jmkasunich: why is it bad to plan reversals too?
[21:39:27] <cradek> because if you wait until you have accel available to do the comp, you could be off the path
[21:39:56] <jmkasunich> alex_joni: do you want comp during jogs and such? or only things planned by the TP?
[21:40:03] <alex_joni> both ;)
[21:40:04] <jmkasunich> and how do you transition from one to the other?
[21:40:12] <alex_joni> seemlessly
[21:40:17] <alex_joni> * alex_joni has nfc
[21:40:22] <cradek> heh
[21:40:34] <alex_joni> jmkasunich: probably 2 comps
[21:40:39] <jmkasunich> * jmkasunich wonders if he made a mistake way back when
[21:40:41] <alex_joni> one for the free mode planner
[21:40:47] <alex_joni> one for the TP and coord
[21:40:49] <jmkasunich> splitting the free mode planner out from the coord planner
[21:41:20] <jmkasunich> dammit, where'd I put my fitzall?
[21:41:30] <alex_joni> fitzall?
[21:41:38] <jmkasunich> crescent wrench
[21:42:33] <jmkasunich> adjustable spanner on that side of the pond I think
[21:43:37] <alex_joni> oh that :)
[21:43:39] <alex_joni> * alex_joni ducks
[21:44:14] <jmkasunich> we joke about needing the "metric crescent wrench" or the "inch crescent wrench" at work
[21:44:57] <alex_joni> in .ro we call it a "french key"
[21:44:57] <jmkasunich> as soon as I find the damned thing and tighten two nuts I can focus on backlash for a few minutes
[21:45:11] <jmkasunich> this:
http://en.wikipedia.org/wiki/Crescent_wrench ?
[21:45:17] <alex_joni> if you tighten it too much, then you won't have any backlash
[21:45:34] <alex_joni> jmkasunich: yeah, that one
[21:46:18] <cradek> I call that the nut-destroying apparatus
[21:46:26] <cradek> they're a curse
[21:47:02] <jmkasunich> there is a time and place for everything
[21:47:09] <jmkasunich> critical or extra tight nuts ain
[21:47:15] <jmkasunich> ain't the place for a crescent
[21:47:21] <cradek> yes, they're good for beating on things if you can't find the hammer
[21:47:59] <jmkasunich> this is really annoying - I found a 6" crescent and finished what I was doing
[21:48:12] <jmkasunich> but the 10" one that I used this morning has vanished from the face of the earth
[21:48:39] <cradek> Bas was around earlier in #emc but he left
[21:48:45] <jmkasunich> yeah
[21:49:24] <alex_joni> he's trying to learn IRC at least ;)
[21:49:29] <alex_joni> which is a good sign
[21:49:36] <cradek> it would be nice if he was in on any discussion
[21:49:39] <cradek> might be worth waiting
[21:49:45] <jmkasunich> more than you can say for a certain board member ;-/
[21:50:17] <alex_joni> I just dropped an email to Bas, instructing him what to do