cradek: how about the mmxavg.*
are those still used?
* alex_joni jummps from on etopic to another
kinematics/mmxavg.c and .h
any idea if they are used?
I have never seen those before... no idea
seems like a big waste of memory if they are used
(4 double + 4 ints )*100
and that times 6
in the emcmot_debug struct
maybe jmk knows
take it out and see if it builds...?
I'm trying that
motion/motion.c .h and usrmotintf.cc reference it
but nothing more than initializing the stuff
we've got a Makefile bug somewhere - I keep getting 'failed to remake makefile Makefile' warnings when depending
date / time issue?
it looks like those vars are only used to print them, or to initialize them to 0
SWPadnos: that was my impression too
all the code that would call those functions is inside #if 0 blocks
good night gents
cradek: thanks for cleaning up that hal_priv thing for me -- I had the change to hal_priv that you made, but apparently forgot to check it in
what do you call it when a person who is fully capable of developing and sending a patch just complains about something?
there are other explanations too in this case :-)
jepler: shouldn't cc-option detect that unit-at-a-time is not accepted for whatever compiler he's talking about?
(of course a real bug report would include that information)
cradek: yes, and I believe it does. witness that bdi2 compiles...
ok, without a real bug report we're pretty stuck, and I don't feel like playing 20 questions to get it out of him
the only other thing in his email that's possibly a bug is the cleanup problem, but I don't get that one.
some stuff does get depended for 'make clean' but I'm not about to get worked up over it
I'm not either, although I thought I fixed it once before.
found one thing...
* alex_joni got home early
is jmk around?
ok.. had a lot in the scrollback buffer ;)
you guys talk a lot
have you considered using the commentator to help speed developing up?
[17:10:06] <Lerneaen_Hydra> http://www.cenqua.com/commentator/
Lerneaen_Hydra: you're kidding .. right?
most definetly not
oh, btw alex, did you want a screenshot of emc & a lathe app?
that was my dream since I was a little baby :)
any things that you want to be included?
Lerneaen_Hydra: make it shiny ;)
mmkay, just a sec
Lerneaen_Hydra: you're a lathe user.. right?
Lerneaen_Hydra: still have lathe_test100.ngc ?
something that looked like a chess-pawn
I have a video of it
along with some pictures
yeah, that's right
if I wasn't so lazy I'd have it as CC-liscensed
ie free to use
alex_joni: your mail is alex.joni ... robcon.ro right?
any reason against doing the CC stuff?
too lazy :p
ie if you want to use it for anything with EMC's documentation then feel free
do you want a video that's got better resolution?
(iirc it was only 320x240 and low bitrate)
can you put a T1M6 in there?
e.g. change the cone to a tool-shape
Lerneaen_Hydra: the resolution on that video is fine
oh, so you see the cone in the screenshot?
also, which program would be better, that simple one or the test peice?
the test piece
maybe just send me the test piece program ;)
if it's no problem
yeah, that's easier for me too ;)
are you sure it was called lathe_test100.ngc?
becuase I only found lathe_test from 1 to 10
it says so in the pictures
I should still have the CAM file
just a sec
any will probably do
yeah I found the test file
any preference for more/fewer passes/depth?
not really :)
rather fewer passes than more
right now the file I have now does it in 7 passes
and a finish turn
should be ok
got it.. thanks
any restrictions on the file?
would you mind me adding it to CVS ?
oh, uh, I can clean it up a bit first then ;)
what? the comments?
I can take those out :D
yeah just strip out the comments
as they don't really add anything to the file
I have a version of the file with IJK arcs instead (which is what it was supposed to be, as radius arcs can have worse rounding errors) if you want
it probably doesn't matter in this case though
and maybe without those pasky N-words
oh, also I can remove the gouging limiter
(when doing the falling countour the CAM app limits the angle)
it should be an arc, not line+arc
so, remove N-words and fix the gouging?
I've turned of radius compensation too
so EMC can do that :D
what kind of tool would you do?
use I mean
usually one that is, uh, rhombic with an inner angle of 55°
if that says anything...
[17:56:30] <Lerneaen_Hydra> http://wiki.linuxcnc.org/uploads/angles.png
[17:57:31] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ToolTable
this says quite a bit :)
that file's all nice and good?
front and backangle are not right
in the tool table file
what values do you suggest?
hmm. this is a very problematic topic
becuase it depends on how much EMC knows about the lathe
I find the behavior like in this screenshot to be good: http://wiki.linuxcnc.org/uploads/angles.png
as in what they are called
it's quite uncommon though for a control system to know what to do with the side angle value though (except for the gui)
end angle is commonly used in roughing canned cycles
possibly somehow in normal straight-line movements too
right.. they mostly get used for GUI
so this is type 2 cutter.. right?
[18:08:51] <alex_joni> http://wiki.linuxcnc.org/uploads/cutting_orientation2.png
if the lathe is of the type where the tool is close to the operator
and the screenshot is of the type where the tool is away from the operator
usually all production scale machines are tool-away-from-operator
I allways read that as logger_devil
too stupid to qualify as a devil
any idea as to the recent borkification
unfortunately no :(
some issues with the ISP
the connection is worse
but I don't have anything palpable to complain
[18:35:32] <alex_joni> http://18.104.22.168/mrtg/mainping-year.png
<- don't think that qualifies
hmm, nope. not a good direction though :/
this is ping to the next hop (fiber)
so I don't understand the issues.. they shouldn't be possible
Lerneaen_Hydra: are you on cnczone?
anything in particular?
[18:38:38] <skunkworks1> http://www.cnczone.com/forums/showthread.php?t=26564
skunkworks1: have him look at nist-lathe
it's set up as a lathe display and all
skunkworks1: oh, I see
the only thing that he might not have are home switches which are present on the nist-lathe config
seems as though made for me ;)
the screenshot I just posted is using that config
ok - thanks
he needs to have X Y Z defined, but only X & Z get used
that is in head though isn't it?
this is because of triv kins
skunkworks1: is cnczone any good? or is it just the "help I need help with <subject>"?
skunkworks1: tell him to get sane things from here: http://cvs.linuxcnc.org/cvs/emc2/configs/nist-lathe/
not the whole config (that won't work on 2.0), but ideas
Lerneaen_Hydra: Its ok - lots of adds ;) but it is cool seeing what others are doing/
also.. not sure how much he can do with 2.0 regarding lathe
alex_joni: That is what I was wondering
afair there wasn't even a lathe= yes setting in 2.0
skunkworks1: are you going to reply?
this is crazy: http://www.cnczone.com/forums/showthread.php?t=19615
alex_joni: why? such and old emc version?
I was thinking more like the last reply to the thread
skunkworks1: yeah :D
[18:53:44] <skunkworks1> http://pastebin.ca/227903
bwahaha experts! :D err.. uh.. yeah..
* Lerneaen_Hydra wanders off and does something else
* alex_joni goes to take a bath
skunkworks1: I'd change this:
We don't know how much is in the 2.0 release.
sorry - I know that sounded bad
I'd say "emc 2.0 has very limited lathe capabilities"
for whatever that means :D
that sounds smoother ;)O
after all, the experts are omniscent
thank you http://www.cnczone.com/forums/showthread.php?p=211763#post211763
well... CNC power supply box is now completed... though the top is a little fucked cause my neighbour cut it bad.
I may go remake the top later on.
but it's really not needed... may do it anyways got shits and giggles
what's with the "step sizes 0.00025 0.00025" message lately?
oh that's some debugging thing that I should remove
jmkasunich: do you remember anything about mmxavg ?
looks like it's something that computes minimum, maximum, and average
m, mx, avg
yeah, but it only gets initialized
so take it out
and it takes up a bit of shm
I'm about to
28-Jun-2001 FMP fixed WPS's mmxavg debug structs; added STEPPING_TYPE
as a module parameter, just to be compatible with runs scripts that
pass this to freqmod.
now that's recent! ;)
looks like they track minimum, maximum, and average execution time of the servo thread
(to mix in some emc2 speak there)
heh, that can definitely go awa
ok, I'm doing that now
it's about 600x(4 doubles + 4 ints)
can't you do min, max, and mean without any storage?
not everyone can
make: Failed to remake makefile 'Makefile'.
jepler: again, ouch
argh, what did I f*** this time
it might be me
it's too bad make doesn't give a useful message in that case
I had that but a clean fixed it (figured it was probably bogus timestamps)
it is probably bogus timestamps
how can I touch all files?
ntpdate decide to change the time
I hope nobody was coding between 2:00 and 3:00 this morning
SWPadnos: it just did
find . -type f -print0|xargs -0 touch
then make clean :-)
hmmm - got a python / make type question
I see in some of the python programs (scripts/haltest.py, for example) "from hal import *"
SWPadnos: I know close to nothing about this, but theres some env set up before you can do that
I'm assuming this is what halmodule.cc is, but I don't see how python knows (a) where to look for the hal module or (b) how it gets created
scripts/emc-environment I think
SWPadnos_: Python searches PYTHONPATH for a matching item every time you 'import' something new
SWPadnos_: actually, PYTHONPATH is prepended to a built-in list of directories
. scripts/emc-environment will set this up for you
As for how it's built, look in hal/Submakefile from 'HALMODULESRCS :=' to the end...
I'm seeing that now. I also see in the makefile the PYOBJECTS (or similar) object list
jepler: the tests in emc2/tests/foo are intended to be automated only, right?
I shouldn't add ones that require user intervention?
jmkasunich: yes, that's right
what were you thinking of adding?
tests for the implementation of canonical encoder interface (spefically index pulse handling) for hardware drivers
because there is hardware involved, the test results are non-trivial to interpret
basicaly you would start the test, then turn the encoder shaft at whatever speed is convenient
so the results would be speed dependent
maybe I'll just put a test in there for the software encoder component, using the simulated encoder to generate the signals
and let people copy the hal config when testing hardware drivers
you can execute a program to check whether the results are right, but in that case you still have to gather it with sampler and that means knowing when you've gathered enough data
it would get ugly fast
what if the user turns the encoder the wrong way, for example
and of course, testing hardware drivers when you don't have the hardware also fails
so I don't want to mess up the test suite with tests that some folks can't run
other testing systems I am familiar with let you figure out whether to skip a test entirely
but there's nothing like that in our testsuite yet
I'm working on one
newinst has a few rough edges
In the Python test suite, for instance, you can turn on or off named resources such as 'network' and 'audio'
which rough edges did you run into?
so 'interactive' and each hardware driver could be a 'resource'
"newinst flipflop" exports something with no name
pins are just ".in", etc
"newinst flipflop name-that-already-exists" fails silently
and "help newinst" comes up empty
one of those is easy to fix :)
jepler@sofa:~/emc2$ halcmd newinst and2 x; echo $?
jepler@sofa:~/emc2$ halcmd newinst and2 x; echo $?
HAL:0: ERROR: systemv failed, returned 253
newinst failed: -1
hm, I must have implemented failure for sim but not for rt...
I'm running in interactive mode, dunno if that matters
i'd still hope you got 'newinst failed: -1' but maybe you don't.
darn I've been waiting half an hour on an cvs up :/
yeah, a commit just about went through.. but I had some up-to-date checks that failed :(
only 14 secs here
so it must not be on his end
yeah, I know
I have 2 secs to my next hop :(
gotta take the backup connection up
yikes, getting dark at 4:30
I better go do my outside work
jepler: you around?
jmkasunich: off and on
I'm trying to understand newinst
the realtime implementation in particular?
I added some help for it, and fixed the "newinst modname <nothing>" case
unfortunately I've lost track of how some of that stuff works
I'm not proud of the way newinst works, it should probably be improved .. but that said, here's how it works:
I notice that if you loadrt a module, then newinst some instances of it, then unloadrt the module, there are droppings left behind
the pins go away, but show comp still shows the instances
the instance registers a pointer in its component
oh yeah I completely missed that
'newinst' makes some pointers in the HAL data point at one of those functions, and reading (or was it writing?) an entry in /proc is the way the kernel is told to execute the code
that's where the sim and realtime implementations diverge: you make an rtapi_app call instead of using /proc
anyway .. I guess hal_exit needs to clean up the entries for insts, which are just entries in the linked list of components which have type=2
this is the rtapi app call: result = hal_systemv(argv);
I'm betting I didn't implement a return code for the non-sim case