steves_logging is now known as steve_stallings
Have not fully caught up reading, but want to comment on spindle at speed feedback. My opinion - M3, and M4 should delay until at speed, otherwise spindle not running at commanded speed is an eStop event.
hi guys was reading what went on today and see you have a feed rate override on rapid is this true! very dangerous to dynamics on machine tool
roltek, it can't increase the rapid speed, since G0 is already at the MAX_VEL specified in the ini file (and FO will never cause a move exceed that)
that's not what they were saying earler
I think it is
feed rate override affects go and go1 in same way
roltek, have you used any controls where the rapids were effected by the same FO as for feed?
yes, but in all cases, the requested rate is clamped to the max set in the ini file
SWPadnos, where is the check done?
in the TP
so motion knows nothing about it?
it never exceeds the max accel and vel set for each axis in the ini, and the check is done after the scale factor is applied
doesn't motion contain the TP?
on machine controls rapid nobs have 100% 50% 25% and f0 which is stopped
so motion is looking at the INI settings for the AXIS section
err - wherever the TP is, that's where it happens
and since the TP is the last thing before the HAL position output pins (I think), it all works out
I thought the TP was doing higer level
task is higher level
and motion was interpreting between the points generated by the TP
well, it's likely I'm labeling something incorrectly. I do that a lot where the TP and motion are concerned
task sends things like "line" and "arc" to motion
what is the servo rate interpolation called?
motion handles lots of commands, but "line" and "arc" and a couple others are passed by motion to TP (part of the motion module)
interpolation is just another part of motion
ok, I guess I always viewed the low level servo rate stuff as motion, and the higer level as TP
so do the arc and line commands that are sent to motion contain any info about what generated them?
there isn't a lot of high level "planning" in EMC - there's no many-segment lookahead, multi-segment blending, etc (AFAIK)
basically, "motion" is motion.c (setup and init, no runtime stuff), command.c (handles commands coming from task), control.c (does the actual realtime control) and things in the kinematics directory, including tp.c and friends (the actual trajectory planner), called by control.c
jmk you still here
i have an extra book on fanuc lathe control should i send it to you or chris
my main area is the guts of the motion control, and device drivers
just trying to help with good g code
I'm just not the guy to talk to about g-code
I think cradek is around
maybe he'll pop his head up
roltek: I think I'd be the best person to get it, nobody else has done any of the lathe work
roltek: thanks for the offer - that stuff is hard to find without contacts
i just sent you an e-mail for an address
i'll get it out tomorrow
response on the way, thanks again
see you later guys
any body care to give me their opinions on the source dir structure for the higher layers under the emc dir?
as in "are they any good?
or "where is stuff"
or "how can I cahnge them"
I don't really follow the structure and it seems as if many files are C++ just to use RCSLIB
the code inside is C code
and the naming conventions don't seem to be anything standard
I think a lot of the high end stuff is C++ (RCS/NML, etc, also parts of the interp and the ini file handling)
headers don't match implementation name and function and var naming is totally inconsistent
no - I think this is a very good example of very bad CPP code
the shared headers for interfaces should either be in the emc dir (like for hal) or an include dir
I find the code a bit hard to follow
I suspect there are still some vestiges of the old system, which would create an include dir and copy .h files from all the various subdirs into it
I think it's very hard to follow
is the main resistance to changing things because it's such a pain with CVS?
just a map of what is where (as I think you're looking for) isn't trivial
I don't think so
is cradek running the CVS server now?
I suspect it's (a) lack of absolute necessity and (b) concern for unseen changes (bugs)
sort of. it's at jeplers place, I think
hmm, but this code realy needs to be understood and fixed in order to fix other things we discussed
I have been using svn for quite some time and moves/renames are easy
agreed. unfortunately, it's not very fun figuring it out, so without massive need, it doesn't get done
but I hate to see all the old revs be lost if a switch were made
I don't think we'll be moving to svn any time soon - just from conversations about it
I would be willing to take a shot a re-organizing it and making things into proper C++ classes
I can do svn on the same host that does linuxcnc.org
but I think it will be hard with CVS
I'll be bugging someone to make changes on the server all the time
there is the possibility of making a new module, (like emc3 or something) but that would definitely need discussion first
what's your schedulr around June 11-17?
nothing planned right now, but I rarely know that far in advance
that happens to be CNC workshop and EMC fest time
(in Galesburg, IL)
there are cheap hotels, and I can likely give you a ride from an airport (like O'Hare or Peoria)
That might be interesting, my dad and brother are still in IL
but it's a bit far off for getting this stuff fixed
yeah, I guess so
I don't think you'll find many objections to an at-speed pin, which is in effect feedhold (though there may have been implementation problems with that(
everything else being done in ladder/HAL for now
yes, I think there are
for one, I don't think the lower levels of motion know the diff between G0 and G1, 2, 3 moves
then there is the whole pre-conditions and where they should be specified
would be nicer for them to come from above like they do for other stuff
for a first shot, is it unacceptable to have g0 be held as well?
I guess it depends when it's held
for sure you can't have it held at all times when the spindle is off
so the new input would have to be ignored when the spindle is not on
well, I'd say that the first thing to do is write up some problem description and possible solutions and post that to the dev list. I wouldn't go too far with this without input from the experts
I posted something like that yesterday
after some consensus is reached on what to do, there will be less resistance to mucking about with CVS or whatever
ok - I saw something on the subject. I should reread it
I could try and make C++ classes out of things now, leaving the file names and dir structure as is, but things will be seriously broken for a while
I don't think you'd get much support for that. broken and C++ are two things that most people around here don't really like
well right now there seems to be this pile of code nobody wants to touch
but I don't see how we get past this without dealing with it
last time I looked at task, the e-stop handling scared me
well, remember it's not really "E" stop
I was very happy to see that get pushed lower
it used to be all handled in task
and there were plenty of bugs
the assumption was that an estop input was just a courtesy from the hardware, and that the machine would have already been shut down
so timing isn't an issue (though bugs still are, of course)
not how it worked in EMC1 and I never saw anybody using hte HW estops
I don't think anybody uses the HW support on motenc or m5i20
hmmm. I'm pretty sure that it was always meant to be hardware with a software notification, but that may not have been clear from whatever integrators documentation there was
I'm talking HW as in relays and power removal
not PC based driver cards
the standard motenc and m5i20 setups don't use the HW estop
couldn't it be done in another branch - like rigid tapping?
moving files around in CVS is a little trickier than making changes to existing files
another branch would help with the broken part
but CVS sux for this kind of stuff
what's with the untyped/tagged enums in emc.hh?
are you talking about the "digital IO point indices" (and analog)?
and all the miscellaneous other ones
actually, those are the only ones I see that are untagged
ugh. the code makes my head hurt. I think this cold is getting to me
I'll see you tomorrow - I think it's bedtime for me
steve_stallings is now known as steves_logging
alex_jon1 is now known as alex_joni
SWPadnos_ is now known as SWPadnos
SWPadnos_ is now known as SWPadnos
steves_logging is now known as steve_stallings
I have been looking at the higher level code
and I think there may be some steps we can take to make it more manageable
I'd bet on that
ask if you have problems in understanding the flow
did you see Matt's email?
first I think we can isolate 2 things
no, what email?
SWPadnos: not yet
on the dev list
* alex_joni watches bits dribbling in
I'm having problems with my developer email
regarding call trees and stuff
no, can you forward it?
[20:35:09] <SWPadnos> http://www.mattshaver.com/include_graphs/+index-by-size.html
[20:35:15] <SWPadnos> http://www.mattshaver.com/include_graphs/index-by-size.html
sorry about the plus sign there
ok - frowarded it to you (pete)
I started some notes of my own I'll share when they are more complete
I tried to capture the major important stuff in the flow
anyhow, back to the 2 things
I think the first is pretty easy
I would like to isolate all of the init file reading stuff
code is seriously duplicated and there are plenty of memory leaks
I think the IniFile class can be extended and then a new EmcConfig class derived from it
it should parse the whole INI file and then the config object passed to the other modules
petev: while you're at that..
[20:37:50] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?IniChanges
this will eliminate code duplication and isolate the file format
you don't want my thoughts on all that because I would redo it all in xml
that's not out of the question
but for now I think some layering and information hiding would help
but it's not very palatable for some folks due to the near-unreadability of XML for humans
I didn't get such warm reception to the idea before, so unless things have changed...
things have probably changed a bit
there are a bunch of editors that solve that
petev: the idea itself is not that bad
and do DTD checking as well
it would be even better if it's accompanied by a GUI to do configs
I already wrote a sample and DTD
yes, we could start with off the shelf editor and make custom GUI later
ok, the second item is NML
there's a "nearly-XML" format also, which eliminates a lot of unreadable crap by removing end tags and such
I know this is touchy, but is there any reason it has to polute the whole code base?
it shouldn't have to, but the ability to do a networked system is pretty central to EMC
why can't we isolate it to the communications links between the objects and not get it in the objects themselves?
networked as in I/O, motion, GUI can be on separate machines
I'm not saying ditch it, although I would replace it with RPC myself
no particular reason, probably
but lets make some clean object boundaris and put all the comm stuff in client/server modules
NML can be used on small (8-bit) microcontrollers. if you have an RPC implementation that can do that, then it may be possible
the UIs would like against the client side
sure, that likely makes sense
the server side would make calls to EMC objects
no NML or RPC or any other comm protocol anyhwere else
then it would be easy to use a comm channel or not
this second change is a bit larger, but I think it would really improve code readbility
after that, I think some real C++ classes are in order to better define the interfaces and get rid of globals and the like
what do you guys think?
number two is really two different topics: one is layering / "protocol hiding", the other is removal/replacement of NML
I think the NML is still layering/hiding
better layering is a no-brainer for me, removing NML is less so (only due to the fact that it's so interwoven in the code)
why is NML needed anywhere but for comm?
I only see it being used to talk to task and io, but maybe I missed something
it isn't (I think), but it's so intertwined with everything that changing it is a pain
it looks like motion goes straight to the SHMEM already
it's also usable to talk to remote machines, with different word sizes and endian-ness
I think io can be eliminated
that only leaves comm between UI and task
alex_joni: that guy is probably not subscribed?
cradek: too slow connection to look
if there's a "remote HAL" protocol of some sort, then it could, but having I/O separate from motion/task is pretty central to original EMC thinking (and may still be needed, though I'm not sure)
hmm, all IO is HAL based now
petev: I somehow favour a major change of ditching io altogether, and moving it into RT
I would like to see the NML queue removed and the SHMEM interface made into a queue
what I mean is having some I/O hardware on one computer (or device), and being able to get that data to another computer that's running task/motion ...
I think that would eliminate the bottle neck too
SWPadnos: use RTnet :P
why is that an issue?
just run HALUI and it sends NML or RPC to task
RTAI also has FIFOs, but they're not being used (for some reason I don't know at the moment)
I also want to fix the plan/execute stuff
SWPadnos: but seriously.. how many cases like that have you seen lately (in the last 5 years)?
RTNet schmaRTNet :)
plan executes some stuff directly which is just broken
does anyone have any stuff to incororate isagraph? plc??
there's been a raeasonable amount of discussion about the G-Rex or a serial (AVR-based) I/O card for a while
those are both hard with the current scheme, but I'd like to make sure they're no harder in a new scheme
both what, I lost you?
ethernet and/or serially connected I/O devices
there's been some work on HAL drivers for both types of device, but it's not too easy to work that into the RT system
NML is a partial solution, though it's not RT
never hrard of it
duerz: no isagraf
man - I need more caffeine
[20:52:45] <duerz> http://www.isagraf.com/
it will run in linux
SWPadnos: the RTnet HAL driver just links together some HAL pins (e.g. replicates tehm on the remote PC)
ok - I haven't looked at it - Eric checked it in though?
(looked lately, at least)
sent it as an email to the dev list
ok - I go that one
the only 9one
I'd like for there to be some reasonable replacement for the capabilities that NML gives us in I/O and UI connectivity before throwing NML away
I'm not saying throw it away
just isolate it like any comm should be
I would do RPC the same way
sure - that makes perfect sense
at least if it's isolated, it will be easier to understand and maintain
petev: one single aspect I'm worried about
one comment on point 1 (config info) - I don't know if you've seen the KDE config system, but they have some very nice provisions for systemwide settings, private settings, immutable settings, etc.
that during this cleanup you encounter some technical dificulties (because of libnml architecture) to complete the task
alex, if we don't bite the bullet and try, how do we ever get out of the state we are in?
nobody understands the code that well or wants to touch it
and we can't fix simple stuff like the spindle problem
we can do it in a branch or something if that helps
I don't see any problems with the config stuff
* alex_joni neither
petev: I think it's an interesting task.
I can't say for sure on the NML, because I still have to understand the internal queue better
the problem is that I've been too busy lately to even try..
I don't think the config would take long
the NML is a bigger job, but right now I can hardly follow the heirarchy of things
you must be a better c++ coder than me ;)
it seems like everything includes everything
(he is :) )
you talking about NML or the way emc uses it?
SWPadnos: that's trivial :P
the config stuff would probably take a good day if we stick with INI format
it would take longer to go to XML
I'm not totally clear on the structure of the queue between plan and execute in task
there have been discussions on config issues and additional features. if it's going to be done, let's try to get those concerns addressed
petev: interp_list ?
I need to understand the messages better and how the pre/post conditions are dealt with
(I don't remember all of them, but I can search the archives/IRC logs for that kind of thing)
petev: I suggested a thing a while ago.. but seems no-one liked it at the time
what was that?
I said the NML messages should have a flag field for the pre/port conditions
instead of hardcoding them in task
I'm leaning towards removing them and making them separate queue entries
anyone in here ever integrate OpenCNC?
so you could queue commands and conditions
conditions would just wait until met when executed
I also think the task code is a mess due to it really needing to be 2 threads, one for plan and one for execute
they are done as one with a state machine mess
petev: that's an older list I made on NML messages
is that current?
2 years old or so, I think
the current stuff is in there (except 1-2 messages)
there might be 3-4 others removed
ah - newer than the copy I have then :)
1 year old?
is it really 2 years since I did that?
I think so - you, Paul and I were working on that stuff
petev: use with a pinch of mistrust then ;)
but I know that not much has changed since
does this sound like something we want to start now?
* alex_joni is on a business trip away from his devel box :)
and it's 11ppm
just to really stir stuff up, what are the chances of moving the repository to svn to make refactor stuff easier?
oh, I didn't mean this instant
I mean - well, there may be some resistance
petev: ask cradek first
I hate to loose the old revs too, but cvs is painful
svn is available on DreamHost, though we wouldn't have full admin rights
why not run it on the same server we are using?
that would probably be the idea
I even run it on my doze box without trouble
:) I am not a contributer but from my perspective - things have slowed down and emc2 seems to be at a good spot to clean up.. (but that is just my opinion) :)
a laptop in Jeff's basement is the current CVS server
DH may be a little higher performance :)
SWPadnos: not from here
not for Ray either, I imagine
yeah, I think he's on dialup
actually I get better speeds from jeff's box sometimes
not my limitation
though it is 1000 miles closer to you
(Jeff, that is)
I planned to move all my hostings to DH
but I'm having second thoughts
hmm - that's too bad. is it slow for you often?
no.. only loong latencies at the beginning
I know they had some issues recently - a somewhat prolonged power outage was one of them
yep - sorry
anyway, svn is available, but with the CVS server tweaked as it is (security-wise), and other objections, I don't think a move to SVN is in the cards at the moment
but that is more of a cradek / board question
what would the problems be?
(remember that all the devs and users who compile for themselves need to be able to use svn)
the same clients are available
you mean "cvs up -dP" ... ?
you can use toroise for cvs or svn and linux has packages for both
most devs don't use a "client" other than the command line
is tortoise available for Linux?
yeah, there is svn command line
I use tortoise on doze
I use the command line on linux
I do as well, and I like it.
* alex_joni three
(minor segue) I'd love to see the same features that tortoise has integrated into nautilius or some other Linux shell
that would be cool
I think there are some gnome scripts that do that, but I haven't tried them yet
anyway - on configs, there has been a fair amount of discussion about combining HAL and ini (and possibly NML) config info into one file (or at least one format)
* alex_joni heads to bed
see you later
maybe I'll sneek in in a while..
wonder how I screwed that up - I thought I tested it