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