Ive been baking things today
in your powder oven?
and mostly they come out looking great :)
heres something ...
the color of the powder coat in the box
is almost entirely unrelated to the color of the finished article
is not the same one after baking
ok, so reds are red, and greys are grey ..
but its changes quite a lot more than I expected
everything turns black ?
certainly they seem to go darker usually, yes
it is without doubt, the way to finish metal though
so what other news?
wow, 857 packages ;)
yes - need to split most of the dev package out without breaking the deps.
sigh .. I wish I had time to play with emc again
the ide of CNC'ing a pressbrake with emc is sounding fun though
I can get a Amada RG3520 for $trivial I think
thats a 35 tonne, 2m press
with a manual backguage they go for about 3k5
alex_joni: As soon as you're done with the check.list, I can build another CD
with a 2 axis CNC, they go for $oodles
like, ... 11k or more
paul_c: I'm all over it...
but it's not that easy ;)
the only downside is that it will involve lots of deep hackery in emc ... or hijacking of messages
anybody can tell me a getch() substitute?
alcohol is not the way
what are you trying to do ?
hes trying to code something, Im trying to get drunk
getchar() is ok for me
I decided I can't autotest the version stuff
so I'll put myself to decide if the version is ok or not
so you mean in a shell script?
Make the assumption that the version nubers are OK
so only name checking?
03paul_c 07pc_2_6_test * 10emc2/ (36 files in 7 dirs): Merge HEAD in to the 2.6 branch prior to importing the working sources from an off-site repository.
03paul_c 07pc_2_6_test * 10emc2/src/ (74 files in 7 dirs): Merge HEAD in to the 2.6 branch prior to importing the working sources from an off-site repository.
03paul_c 07pc_2_6_test * 10emc2/src/ (31 files in 4 dirs): Merge HEAD in to the 2.6 branch prior to importing the working sources from an off-site repository.
guess that puts you way up on the CIA stats ;)
can you make a check.list that doesn't include any version info?
yup - No.1 today
perl-base (>= 5.6.0), passwd (>= 961025), debconf
should be :
perl-base, passwd, debconf
paul: I have the following not found:
fsckit... Another group missing.
New list with perl-5.8 added.
I really appreciate your checks - It is trapping a number of errors.
although a lot can slip .. it's 3 am here.. so I'm not at my fittest form
Hmmm... auto-configure failed the math check on 2.6.9
indeed, not in the local repo.
kbd (but it's optional : console-tools (>= 1:0.2.3dbs-54) | kbd
which package requires python-rhpl ?
jmk_away is now known as jmkasunich
* alex_joni is trying a different approach
pythn-rhpl is missing - It is a meta-package for python2.3-rhpl
found cl-defaults missing
data-dumper provided by perl-base
fsckit - Don't want anything that depends on udev & hal - So going to need to fix lsb-defaults
libapr0 & libapr0-dev
Requires: mesag-dev (>> 5) | mesag-glide2-dev (>> 5) | mesag3+ggi-dev (>> 5)
neither mesag-dev, mesag-glide2-dev, mesag3+ggi-dev found
Can you email a full list in the morning ?
one more now: pkg-config
yup, but it's missing
fix up auto-conf
03paul_c 07pc_2_6_test * 10emc2/ (configure configure.in): Tweak configure for 2.6 rtai based installs
I sent you the list
it is very short ;)
8 names ;)
* alex_joni is switching to runlevel: 0
See you tomorrow.
hope I'll make it tomorrow
I just finished installing doze on a Compaq desktop
I find it pretty neat (the machine...)
it's an old PII-300 MHz (passive cooling)
Will update the list with the missing packages, then split the dev stuff out.
with an built-in speaker (connected to the soundblaster)
send me the list if you want me to recheck it
a binary tarball of AXIS for BDI 46 is now available
jepler: will AXIS go on the emc cvs?
alex_joni: I don't know. If there are other people who want to develop AXIS, that would be the easiest way to do it. While it's just me and Chris, hosting CVS locally is easier.
A debian package for the emc repository ??
good day gents...
has anyone but us used it yet?
talking about axis?
about to install it..:D
* alex_joni : sending all proceses the KILL signal
a bit off, does anyone know where I can get the pinouts for Vital System Montec-100 card.?is it the sme as STG?
[02:15:55] <paul_c> http://www.vitalsystem.com/motion/motenc-pin.pdf
[02:16:16] <paul_c> http://www.vitalsystem.com/motion/mtref.pdf
getting late...didn't read the fine print..:D thanx a mill Paul...
If you go for one of those cards, get the breakout boards as well.
allready have...and was a smart ass (figured I can manage the cables better ) and have to buy it separatly...
cradek: One suggestion, re the tarball...
docs in /usr/share/doc/axis-1.0b1
and a symlink from /usr/doc
yeah, that sounds like a good idea, though I'm not sure Python's bdist can create the symlink.
on my system, nothing else puts anything in /usr/doc
I think it's just a mistake
Do you fancy doing a Debian package for the next BDI CD ?
doc dir fix committed
also, LICENSE-Togl wasn't included in setup.py
paul_c: there's some rumor that they're adding support for building debian packages to Python's "distutils", in which case it would be easy.
paul_c: I'm not sure I've picked up enough Debian yet to build a package on my own
I dreaded the prospect, but it wasn't too bad once you try...
emc2 has a basic debian rule set you can use as an example.
paul_c: I hope we get some good feedback about the beta so we can determine what it will take to release 1.0
Well..... If you wanted (or need a hand to) build a deb for BDI-3, I can fit it in
how much time do we have?
Already have the support packages included.
thank you all...night gents...
I had hoped to resolve the final dependency issues tomorrow
and build a final beta before Monday
that's not long .. we won't have anything to call a 1.0 release by then
A pre-1.0 is fine
it's pretty late for the US folks to give this a try before tomorrow's meeting, but maybe we'll hear from some of you guys in Europe
I can look at creating a .deb package on my rc46 machine
I don't think it will build on my test boxes
EMC for BDI-3 uses libnml from emc2 along with the make system.
it will probably still work
as an aside, does that mean BDI-3 won't have my jog-after-abort fix?
Just one return statement in emctaskmain.cc wasn't it ?
In that case, Yes.
yes it will, or yes it won't?
Diffed the code this evening and made the change
if you also think it's right, you could check it in to emc2
then it will be your fault too
Cheers Pal !
also have a fix for axis runaway under screwball situations.
that sounds like a good one too
And there is a /proc entry for debugging purposes
hacking the kernel module, and want to see what a variable is doing...
add it to the proc code, and cat /proc/emc
with a little bit of work, can do a /dev node too.
paul_c: where do I get /usr/bin/debuild?
paul_c: I'm trying out the experimental python support for building debian packagfes, but it says "error: can't find /usr/bin/debuild; you should have the debuild package installed", while apt-get says "couldn't find package debuild"
apt-get install devscripts
[02:43:29] <paul_c> http://www.debian.org/distrib/packages
paul_c: well I have here a file that ends in .deb
for download, or did you want to mail it over ?
[02:49:13] <jepler> http://axis.unpythonic.net/index.cgi-files/downloads/01102198430/python2.3-axis_1.0b1-0.1_i386.deb
OK... We'll need to add a dependency for emc/rcslib/nml at some point.
the .deb appears to work on my system, though it's easy to be wrong about that since I already had AXIS installed
and, yeah, I'm sure the deps are all wrong
I'll try it out on the test box in the morning
because I didn't have to specify any
Unless a bad bug turns up this is probably the only version there will be between now and monday
python2.3-opengl & Co need to be added to the deps.
But I can set the install up so that they are in a mandatory list.
Looks like Ray has a question for you on the user's list...
'night all, see you at 14:00 GMT
* danfalck is away: going out to the shop...
Hi, is anybody around?
jepler: well, I don't think anyone has run it yet
cradek: maybe not
these things take time guys ;-)
jmk_away is now known as jmkasunich
but everyone should be as excited about it as we are!
have to install phyton on TNG-BDI
Imperator_: somehow I think you must be talking to me each time you say "jep".
I guess I need to learn that's not true
it is true
hopw i understand you the right way
* Imperator_ has downloaded phyton 2.4
my cat thinks he can dig his way under a closed door.
jepler: One thought on the GREAT gui.
Lube ought to be labeled coolant.
cradek: Wants at your keyboard?
rayh: hm, okay. I wonder where we got the idea to call it lube.
Probably from me.
There is a "Lube" alarm in tkemc and emc that watches a pin.
jepler: are you changing it or should I?
cradek: I've changed it
Most of the commercial machines have lube alarms that deal with way oil and ball nut oil levels or pressure.
That was quick.
I only wish that I could download the packages needed to run it.
why can't you?
On a good day.
And I'm pushing apt-get as the future -- who'd figure.
rayh: BDI-3 will have all the python packages on it
so how does ray get the BDI-3 iso ;-)
I see that. Fantastic.
Bought it from a t1 shop in Chicago.
? you just ask them to "download such-and-such an iso, burn it and mail it to me"?
The big gray dog met me at the highway.
Snow shoes and all, 'cause the county hadn't plowed the drive yet.
dang ray, you _are_ up in the wild north!
Got a spare bedroom if anyone needs to get away for a while.
Gee bandwidth and weather... such a deal!!!
I'd have DSL withdrawl
get away from ... my 2Mbit connection??
When it gets really cold, 0f the other morning, the bits arrive very slowly.
do you have hot chocolate ready for them when the get there?
could somebody glance at my last post to emc-users? I posted emc2 checkout and compile instructions, want to make sure they're right before I add them to the emc2 page at linuxcnc.org
This thing defaults to a Brit dictionary, anything else needed ?
(particuluarly the cvs checkout)
add a note about the RT path just in case the usr has use /tmp/foo or ~/RTsommat
exactly what should said note say? (I've not done anything with non-standard paths)
"if you've installed your realtime patches at /home/foo/relatime, then do ./configure --with-rtai=/home/foo/realtime" ?
to be honest, such notes should be in README or INSTALL, not on a webpage
yes - With a similar format for --with-rtlinux
* rayh <nitpick> dislikes the word "do" in that context. </nitpick>
If you are an emc developer at SF, checkout a current copy from CVS:
the page is mostly to tell folks how to download it, once they have it they should no longer need the page, all instructions should be contained in the checkout
good day gents
Question regarding Axis.
I've now read both the README in the tarball and the install page
I'm confused by the use of directory terminology
A BDI uses /usr/local to house emc and rcslib
The emc source directory is /usr/local/emc/src
oh, is there a copy of the source tree there?
-bash: cd: /usr/local/emc/src: No such file or directory
not on my rc46 machine
Ah. You untar the bz in /usr/local to get the sources.
You mean to use /usr/local/emc/plat/linux_rtai
oh, I untarred it in /usr/local/src on my machine
* rayh grabs a bit of breakfast.
* alex_joni prepares to try axis
if you untarred from /usr/local, then you would have to build with EMCSOURCEDIR=/usr/local
but if you're using bdi, give the binary tarball or the .deb package a try
Just did a CVS update to the EMC2 installation on my laptop (BDI-RC46). The new config stuff worked fine, at least as far as I can tell without a real machine attached. Thanks Alex et all.
steve: glad to hear that
did you update the kernel & rtai packages ?
oh..hi paul ;)
rayh: And untarring isn't enough, you have to build. Otherwise, the headers are not in the location setup.py expects, and there's no librcs.a
Hi alex_joni - You only just crawled out of bed ?
Who me? No, just the EMC2 tree. I have never compiled rtai or kernel stuff.
paul: no... I just got home (was at some friends 100 km from here)
paul: do you have a new list for me to test?
SteveStallings: Sorry, I thought you'd done an apt-upgrade.
alex_joni: eight broken packages to fix (version probs)
Last Wednesday there was a commit by cradek to fix a jog bug in EMC1. Do we know if EMC2 needs the same fix?
Do you want to do the fix ?
Learn by doing... sink or swim... whatever, I'm chicken. I have never been a C programmer. I can just barely read the stuff. I am an assembly language dinosaur. Happier with hardware....
if it's any consolation, people who are fond of languages like Python think C is too much like assemly language and too little like a high-level language.
paul: I'll comit cradeks fix to emc2 too
worry about the number of bits in an integer? check. forced to manually allocate memory? check.
03paul_c * 10emc2/src/emc/task/emctaskmain.cc: Commit Chris Radek's abort bug fix
jepler: what packages do I need to run axis?
python, python-dev, python-opengl ?
[15:58:56] <cradek> http://axis.unpy.net/index.cgi/installing
yeah yeah, just RTFM
cradek: re: HLL vs C: know exactly what is going on, check!
Okay.... The only packages with borked deps are all libXXX-dev packages.
jmk: that was jepler ;)
but it's ok, I agree
oops... sorry cradek
yeah, cradek would have written AXIS in C and we'd be contemplating a beta next May or so
(all the languages I know are at least 20 yrs old ;-)
Yeah, I don't think Python's much more than 12 years old
well, that's probably true
at least you know they don't change anymore (after 20 years)
but only because you wouldn't have helped me
alex_joni: that's probably one of the reasons I like them - I _hate_ change!
alex_joni: that's not true... compared the C you know to C99?
Yay, doing CVS checkout of emc as a developer, not as anonymous
jepler: I agree some stuff gets changed once in a while
and I'm not that 100% c-fan
What's your favorite, then?
it is what I like most
but I don't like it 100%
there is stuff I like in other languages better
but hey, that's just me ;)
don't seem to fina a xlibmesa-dev on SuSE
mesa or mesagl
* alex_joni is fighting with SuSE install CD-s
alex_joni: on this fedora core 2 machine I think the package required is xorg-x11-devel. It's the package that provides <GL/gl.h>
on my redhat9 machine it's XFree86-devel
so you may already have it
try locate gl.h
take a look at http://linuxcnc.org/EMC2-description.html
and tell me what you think
(hopefully this will eliminate the need to explain the CVS commands on the lists)
JMK - You might include some instruction about setting up a directory to contain all the new stuff (for true Linux newbies like me - grin)
jmk: for dev CVS checkout
actually, if you run the cvs command from your home directory, it will create a directory called emc2 below your home dir
include de dev_name in the command
Ouch.... is it written in MS-Word??
oops - I did include it, but it was like this "<devname>", and the <> make HTML think it was a tag
* jmkasunich fixes
otherwise it sounds ok
jmkasunich: Side note - Played around with mailman again, and should have fixed the notices from the Trackers.
good - they were getting annoying
checkout command should be fixed now
indeed it is
SteveStallings: is what written in MS-Word?
Paul - I would NOT recommend www.linuxnewbies.org to anyone. It is mostly adware and tries to set your homepage defaults, tries to launch popups, and other ill conceived behavior.
The comment about MS-Word was a jab at Paul..... Linux newie docs should be in MS-Word format... 8-)
seconded - I didn't see the ill bahavior cause I used Konqueror, but it is _not_ usefull to newbies
My system is set up such that all the ill behavior was trapped, but it still annoyed me.
SteveStallings: Appologies - I wasn't aware of linuxnebies.org popups
What I really need is just the time to -USE- Linux. Skill comes from exersize.
* paul_c hands SteveStallings a M$ erase utility.
Somehow I don't trust something here.....
I broke my Yast
wat's a Yast?
Yet another setup tool
it's SuSE's tool for sysadmin
install packages & such
I seem to have flushed the list of installable packeges somehow :(
now I gotta install everything manually.. that's a PITA
* jmkasunich wonders how much preload is too much on a ballnut
alex. My last problem might have been caused by some yast stuff I did.
SuSE problem that is.
I know ;)
cradek: is axis realy tested on EMC2 ?
Preload will depend a lot on how precision the screw is made. Also, is it a rigid preload or a spring preload.
spring - a thick wavey washer between the two ballnuts, with a threaded collar that compresses it, trying to push the nuts apart
Roland at Cardinal uses a couple of belville washers between two ballnuts on that cheap thompson.
this is a surplus assembly, already had the two nuts, collar and wave washer
He sets the force to be just a bit more than the cutting force he wants.
Spring is much more forgiving. Preload should be equal to max cutting force in order to be effective. Affect on screw life is another matter.
this is a Z axis (quill)
the upper nut is rigidly attached to a bearing, (nut rotates), screw attached to quill
lower nut is spring loaded downward
so when drilling, the spring will compress
when milling or just holding the weight of the quill, the rigidly mounted nut will be in play
* jmkasunich can't really measure the spring force
It would be better if the situation could be reversed. That way the preload would only have to deal with force to pull quill up.
in my Bosch Rexroth katalog they say preload has not to be more thane one thired of the middle load (don't know if that information helps you)
Imperator_: I tried it, yes
Imperator_: cradek built emc2 and used it to run his maxnc mill. axis works, though there's a problem displaying jogs.
cradek: oh, you are still here
I'm not paying much attention, I'm afraid.
jepler: I'm here off and on
i have made the symlink in ..../emc2/bin
oh are you trying it now?
but it says .../emc2/bin/axis is a directory
can you "ls -l emc2/bin/axis" ?
SteveStallings: I think I like it better this way, if it was the other way and I was milling a slot, cutter downforce (from spiral endmill) might "pull" it down and make the slot too deep
yes i can do that
what do i have to type for building it ?
I put the assy on my drill press table and used the drill press chuck to compress it... the spring flattens completely at force levels similar to what I would use to drill 3/8" in steel
I think I'll adjust it to 2/3 or 3/4 flat
Imperator_: in the AXIS source directory, you type something like 'env PLAT=nonrealtime EMCSOURCEDIR=/usr/local python setup.py'.
it will flatten out during heavy drilling, but should be stable for milling where depth control is more critical
if you're on a pure emc2 machine, you may have to change lines 47 and 51 of setup.py to refer to "emc2" instead of "emc"
jmkasunich: IMO it should not compress at all under normal cutting forces.
jepler: it segfaults here :(
it's not that stiff
alex_joni: did it leave a core file?
in /usr/bin/ ?
I'd have to adjust it completely flat if I didn't want it to compress when drilling
alex_joni: Probably in /usr/local/emc ?
I think that's why Roland used the Belville washers. He can get them stronger than the cutting force.
I'm afraid if I did that here I might have accelerated screw wear
alex_joni: try running 'ulimit -c unlimited' before starting emc with axis
I adjusted it nearly flat, it takes quite a bit of force to flatten it - milling should not deflect it, nor would drilling moderate size holes, or large holes with a pilot hole
but drilling large holes from the solid would
acceptable tradeoff, I think
ok... core dumped
now, "gdb python core", and /msg me the traceback
jmkasunich: close enough.
total compression is less than 0.005, it's rare that depth control on a drilled hole is that critical
and this is a cheap chinese 3-in-1 anyway - probably more flex than that in the head itself :-(
JMK - That answers my un-posed question. So you are not trying to CNC the Van Norman. A friend of mine also has a #12. He, like most, is not lucky enough to have the head with a quill. I was wondering if you were so lucky.
nope - #12 never had a quill - only the #1RQ
I have a question about the Vital pci card...does the vitalAmpEnable funcion have an association witht eh output wins on j6?
File "setup.py", line 42
togl = Extension("_togl", ["extensions/_toglmodule.c"], **get_togl_flags())
SyntaxError: invalid syntax
ottos - Should do...
there's a very droolworthy 1RA at http://www.toolbit.net/vn/,
but the server seems to be down right now
make that 1RQ
Paul is the spindle and aux I/o going the old way (pport ) or has it been changed?
strange - after about 1-1/2" of travel the ballnuts seem to get tighter all of a sudden
Imperator_: what version of Python? 2.2 or greater?
the newst 2.4
Imperator_: on your terminal, what was the ^ below? Over here, it looks like it's past the end of the line
under the second star
ottos: For the Vital card ?
PCi Motenc-100 8axis
Currently, sindle on/off, etc are via the parallel port
but sindle speed should work through the Vital card
Imperator_: make sure that you are getting python2.4 when you type "python". It should print a banner with the version number.
ottos: It wouldn't take much to get all the IO working through the Vital card.
or run "python2.4 setup.py", that's another way to make sure you're getting the right version
jepler: Does axis require Python2.4, or is it OK with 2.3 ?
Paul , might sound crazy but I was hoping to make a complete docs/ I/o map for easy Motenc install..any suggestions?
hmmm "Pyhton 1.5.2"
paul_c: It's supposed to work on 2.2 and 2.3. It's mostly tested with 2.3
ottos: We can work on the IO shortly - I need to get this new CD finished before tackling anything new.
ok...sure thing...thanx again..
jepler: ok with "env PLAT=nonrealtime EMCSOURCEDIR=/home/martin/develop/emc2 python2.4 setup.py" it is much better but setup.py would like to have a additional command now
setup.py build, then setup.py install as root
Imperator_: if you're on a pure emc2 machine, you may have to change lines 47 and 51 of setup.py to refer to "emc2" instead of "emc", otherwise you'll get lots of compiler errors when it tries to build the emc module.
(i said that earlier, but without your name, so I don't know if you caught it)
also, EMCSOURCEDIR is the directory where emc (or emc2) and rcslib directories exist, so you may need /home/martin/develop, not /home/martin/develop/emc2
i think i have to change much more than emc --> emc2
it don't find rcs.hh emc.hh and inifile.h
You probably need to change $EMCSOURCEDIR/plat/$plat/include with your $EMC2/include
it expects to find inifile.h in $EMCSOURCEDIR/emc/$PLAT/nonrealtime/include/inifile.h, etc
no PLAT stuff at all in emc2
you can change setup.py to hard-code the proper include and library directories, lines 47 to 52 or so
DEFAULT_NMLFILE (you need to change that to %s/configs/emc.nml)
DEFAULT_NMLFILE isn't important for axis, only for gplot
martin: os.path.join(emcsourcedir, "emc2", "include") should be enough
and the same one for library_dirs
probably you need to replace rcs with libnml too (line54)
I#m getting closer
step by step
you're really on the cutting edge to build axis on emc2
rayh: anyone else: any news about Fest 2005?
building 'emc' extension
c++ -pthread -shared build/temp.linux-i586-2.4/extensions/emcmodule.o -L/home/martin/develop/emc2/lib -L/home/martin/develop/emc2/rtlib -lemc2 -llibnml -lm -lstdc++ -o build/lib.linux-i586-2.4/emc.so -Wl,-rpath,/home/martin/develop/emc2/rtlib
/usr/bin/ld: cannot find -lemc2
collect2: ld returned 1 exit status
error: command 'c++' failed with exit status 1
and setup.py looks now like this:
togl = Extension("_togl", ["extensions/_toglmodule.c"], **get_togl_flags())
emc = Extension("emc", ["extensions/emcmodule.cc"],
define_macros=[('DEFAULT_NMLFILE', '"%s/emc2/emc.nml"' % emcsourcedir)],
os.path.join(emcsourcedir, "emc2", "include"),
os.path.join(emcsourcedir, "emc2", "rtlib")
library_dirs = [
os.path.join(emcsourcedir, "emc2", "lib"),
os.path.join(emcsourcedir, "emc2", "rtlib")
libraries = ["emc2", "libnml", "m", "stdc++"],
extra_link_args = ['-Wl,-rpath,%s' %
os.path.join(emcsourcedir, "emc2", "rtlib")]
Imperator_: where is libemc2.a or libemc2.so?
Imperator_: That directory needs to be listed in library_dirs
it is in ..../emc2/lib
that is stll listed, or ???
os.path.join(emcsourcedir, "emc2", "lib"),
what files are in /home/martin/develop/emc2/lib?
but it is libemc.a not libemc2.a
then the item in libraries must be "emc", not "emc2".
jmkasunich: Sorry away working. Been looking for someone to coordinate. Nothing so far.
Must get to work on that.
there are : hal_lib.o libemc.a libnml.a libnmld.a libpm.a ulapi.o
then try libraries = ["emc", "libnml", "m", "stdc++"]
that gives me the same error
i think the problem is that there are some spaces missing, or
/usr/bin/ld: cannot find -llibnml
I left out the comma that must be at the end of that line, did you include it?
libraries = ["emc", "nml", "m", "stdc++"],
^^ try this
/usr/bin/ld: cannot find -llibnml
Is anyone else working on hardware interfaces for EMC2?
if the file is libnml.a or libnml.so, then you have to have "nml", not "libnml" in libraries
I was thinking it would be easier if maybe we standardized the
way we'd present HAL pins for things like the STG, Vital and my PPMC boards.
* jmkasunich is up to his elbows in little steel balls (repacking a ballnut)
give me 10 mins
Yes, it would be easier, or yes others are working on interfaces?
yes we should standardize
Umm, ballnuts, that can be messy. I have a neat trick for
cleaning inside a ballnut without disassembling. You coat the
screw with grease and run the nut back and forth a few times.
much better now, but there are some warnings and then it breaks
The grit ends up sticking to the screw, and you can wipe it off.
I had it apart to machine the ends
I did one that was kind of tricky, the wipers on the end would
In file included from thirdparty/togl.c:36,
/usr/include/GL/glx.h:428: warning: function declaration isn't a prototype
In file included from extensions/_toglmodule.c:2:
make it a bit hard to use a plug to keep the balls in the nut.
thirdparty/togl.c: In function `Togl_Cmd':
thirdparty/togl.c:1247: warning: `main' is usually a function
thirdparty/togl.c: In function `Togl_CreateWindow':
thirdparty/togl.c:1597: warning: unused variable `winPtr'
extensions/_toglmodule.c: In function `get_interpreter':
extensions/_toglmodule.c:9: parse error before `long'
extensions/_toglmodule.c:11: `interpaddr' undeclared (first use in this function)
extensions/_toglmodule.c:11: (Each undeclared identifier is reported only once
extensions/_toglmodule.c:11: for each function it appears in.)
error: command 'gcc' failed with exit status 1
So I just machined the screw with the nut covered and taped
must i have a newer wersion of gcc ??? maybe it is pretty old !
I know what this error is...
cradek: have you fixed that _toglmodule bug in CVS? If not, please do
yes I did
jmk: did you notice the hal_stg driver?
[18:08:56] <cradek> http://unpy.net/cgi-bin/viewcvs.cgi/*checkout*/axis/extensions/_toglmodule.c?rev=HEAD&content-type=text/plain
Imperator_: can you download the latest _toglmodule.c with that url?
not jepler ;)
* jmkasunich is ready to talk drivers
alex_joni: noticed it yes, examined it closely, no
there is not much to examine
only some LS7266 stuff in there
should get some testing... (someday)
There's an STG driver? I'll have to look at that!
didn't know you had a STG card Jon?
Jon: you'll be disappointed.. not much there yet
but if you test...I can develop ;)
Well, actually I DO! My Bridgeport mill is STILL run on an STG I,
with analog servo amps, and a Dec 1999 version of EMC! Yikes, that's
cobblers kid, eh... I would have expected it to be running PPMC
That will happen some time! Yeah, I just hate to tear it apart, as I will surely have a mad scramble to get it all back together when I need to make something.
well, don't do it until after we test the HAL STG driver ;-)
If I rip that system apart, it will need a massive updating. It is
yay.. axis sorta runs ;)
a 100 MHz Pentium classic with 16 (well, maybe 32) MB ram and a 1 GB hard drive.
alex_joni: you have axis running with emc2 ?
here now it build with some warnings
i have installed it but if i start emc2 with ./scrips.emc.run it says at the emd ............/emc2/bin/axis is a directory
Imperator_: give me 5 mins
is that symlink at the wrong dir ?
I just had a crashcourse in python :D
I did some debugging.. it crashed on my SuSE
Imperator_: emc2/bin/axis should be a symlink to /usr/bin/axis, which is the file installed by "setup.py install".
something is fishy with it
I have to go, see all you guys later
Jon: how long can you stay online?
don't know anything about pyhton, thats the problem
I'll try to make it work for emc2, and I'll talk to you bout it
jmk: I'm interested on the drivers issues
Oh, I'll be around a while.
thanks for hepling
right - that's why I asked Jon how long he could stay - hopefully he can wait until you wrap up with AXIS
I can delay that
wanna talk drivers then?
Imperator_ won't mind.. (I hope)
I mean now ;-)
I will try to take over helping with AXIS problems
can you do that on /msg ?
ok, STG driver (and drivers for Jon's boards) has encoders, outputs (either stepgen or DAC), and digital IO
ok so far
let's start another channel #emc_AXIS
encoder will be similar to encoder.c (with changes)
Imperator_: join me there
digital I/O will be similar to parport
there is hal_tiro.c (which has LS7166 in it)
and hal_stg.c (for the STG adresses)
yes - forgot about that one
almost the same code
code will get cut and pasted from all over the place
And, my encoders work prety much the same way as the 7166, too.
but right now I'm talking about how they look to the HAL
Jon: can you look at either file?
(pins, params, etc)
* jmkasunich opens encoder.c, tiro.c, hal_parport.c, stepgen.c, and freqgen.c in an editor ;-)
hal_stg.c is not in the source generation I have (must be new) but
[18:23:53] <alex_joni> http://cvs.sourceforge.net/viewcvs.py/emc/emc2/src/hal/drivers/hal_stg.c?rev=126.96.36.199&view=markup
jmk: sorry it's py again :-)
Well, I'm looking at hal_tiro.c now.
* jmkasunich does "cvs up -dP"
and opens stg.c as well ;-)
* alex_joni opens HARDMAN1-STG.doc
well that was unexpected
where is the bad position suppression done, and where is sign extension done?
ditto for indexing
and for DACs & IO
OK, well those are things that we can worry about later. The overflow extension is what I really meant, that can come later.
Jon: as I don't have a STG, I don't know if the code written works
The old EMC did NOT change the encoder count value when index was detected, it just reported that the index was seen.
oh, one more thing to open - http://www.linuxcnc.org/Hal_Introduction.pdf
wouldn't want to write the whole driver, and then rewrite it because it wasn't ok
Oh, my! Well, I guess at some point I could drag a few boxes
around and test it for you.
are you familiar with IPulse ?
how it's done on the STG?
It is possible that there might be some STG I cards floating around that could be borrowed for a while.
Of course, ISA slots are getting harder to find, too.
I have isa slots here - I would love to be able to borrow an STG
index pulse handling
page 51 of Hal_Introduction.pdf
there is a block diagram of the software based encoder counter
Yes, I have used the index pulse to refine the home switch position on the boards that I make. It DOES work!
on emc1, it does... not yet on emc2/hal
ok, AFAIK index pulse can be implemented in a LOT of ways
you guys see fig 3.7 yet?
Yes, that's THE problem! Which way should it be handled? I think this
HAS to be standardized for different hardware to keep the HAL
I meant first the HW part...
interface as consistent as possible.
does the index pulse reset the counter or not?
should that be an option for HAL to know or not?
alex_joni: that's what we're here to decide
You have your choice, both in the 7166-based products and mine.
I was just typing the question out loud
The old EMC does NOT reset the count. But, the 7166 hardware
the software encoder in encoder.c resets the counter if HAL pin "index_enable" is true
ok, so we agree that some cards do the resetting, some don't
permits you to set a mode where that WOULD happen. The old EMC
would see this as a sudden and potentially large jump in position.
Jon - can you type your whole sentence before hitting return? easier to read that way
Yeah, sorry for the confusion - I rarely use IRC.
ok, so some HW permit reseting the count, some don't... agreed?
So, the point is that if we are going to reset the position counter, EMC is going to have to be able to handle the sudden jump in the count.
Well, the hardware I have looked at closely ALL permit you to do this.
in fact, we should standardize - even if the HW doesn't reset the count, the driver can emulate a reset
so on the HAL side of the driver, it resets for all drivers
and EMC would then expect that to happen
Well, I guess it only is important back to the PID code.
another picture - http://www.linuxcnc.org/EMC2_Code_Notes.pdf,
page 10, Fig 3.1
we have to bear in mind that the index pulse is used during homing (so it can count how far it overshot the index pulse)
ewww, just realized something
I was thinking that if emc altered it's command at the same time as the FB jumps, that the PID would see no change (because error doesn't change)
but the PID would see a step in the command, and the FF terms would be affected
note that right now, EMC2 does _not_ expect the driver to change it's output when it hits an index pulse
Yes, if that is just carried over from the old EMC.
actually, the lowest level of the motion controller is all new
(but keeps some of the same ideas)
homing has been completely rewritten
But, if you followed the original math, then it works the same way.
what math? PID stuff?
The old homing was as close to impenetrable and anything in EMC :(
that's why I rewrote it from scracth
Yes, basically the whole path from the trajectory to the motion logic.
if you look at EMC2_Code_Notes fig 3.1, you'll see the low level structure for EMC2
If anything is going to cause a discontinuity, then you have to prepare the whole system to accomodate it.
during homing, the switch in the middle of that diagram is in the "free mode" position
Yes, got that fig on my screen.
free mode is used for jogs, homing, etc
coord mode is used for coordinated motion, like MDI and AUTO
the box labeled free mode traj planner is a simple single axis trapezoid planner
Ahh, yes, now I see why the two modes.
set free_pos_cmd, and it goes there, at free_vel_lim
homing is a state machine that simply sets those params to move the axis
and when it finds the home position, it sets "motor_offset" so that pos_fb becomes what it should be
Well, the state machine was in EMC before, just that it was in tiny pieces all over the place!
So, motor offset is a velocity offset or a position offset?
now it is in one place, and clearly designed as a state machine, with #defined state names that actually mean something
position - everything in that disgram is position, except the output from the d/dT block in the center
OK, so the PID is down BELOW HAL, now. Yes, I guess I knew that's how we had figured to break it up.
the assumption is that too the right is a PID block, or _something_ that can move a motor to a commanded position
OK, so if this jump in position is done in the right sequence, the
to the left is the kinematics transforms, and further to the left is the coordinated mode trajectory planner
(oops, sorry) system never actually gets a jump in the loop.
* alex_joni is still following...
as it is now, motor_pos_fb (from the right side) never jumps
motor_offset does, when you get to the home position
what if both jump?
so pos_fb (leaving to the left) jumps, but that just means the display jumps (to zero, probably)
motor_offset and pos_fb
Well, maybe this is the way it should be.
if pos_fb jumps, it has problems
(which means you can't have the driver resetting itself)
hmm.. the sum (pos_fb) would still be the same
Well, it will jump if we reset the pos counter.
pos_fb doesn't need to be stable, in fact it _should_ jump in most cases - it will jump from the original unknown position to the correct home position
Then the motor_offset would be set to zero at the same time?
so.. during free mode there is no feedback to the traj planer?
there is feedback
in fact "pos_fb" is what drives the display
let's take only homing for now
right - the display works during homing too
I've done testing with simulated home and limit switches
the display counts up as the motor moves toward home
I know.. but it's not very important what's on the display before homing
And, it is fine that the display sees a discontiuity when home is reached.
let's back up a step
in free mode? or in teleop mode?
the existing EMC2 homing design, and all the rest of the EMC2 motion controller, expects motor_pos_fb to _NEVER_ jump
the drawing is missing some things - like HAL pins on the right side for the home and limit switches, and the index pulse
Well, that is the most general solution, since there could someday be an interface that CAN'T load or reset the count on the home pos. But, that could be fixed is SW, too, I guess.
it is general, and kind of cleaner too... there is only one hitch
Well, only if sensing these events is NEEDED in this block.
OK, what's the hitch?
the existing design polls the home switch or index pulse once per servo cycle
if you are running at less than one count per servo cycle, homing is accurate
Ohh, high speed homing! Yup.
you got it!
the only way to do high speed homing is to let the driver handle it - and then you have jumps in motor-pos-fb, and things get messy
There'a guy in the Netherlands that has some INSANE encoder on his machine.
Mhz count rates ;-)
the new homing algorithm does have different homing speeds for the initial search for home and the final latching
so you can search fast, then back off, and approach slowly for accuracy
but suppose that it is 1/2 turn of the screw from home switch to index pulse,
you have a 50000 count encoder
and a 1mS servo rate
at one count per servo cycle, it will take you 25 seconds to go from home switch to index pulse
with more mainstream 500 count encoders, it's only 0.25 seconds, not an issue
If you have a 50000 count encoder, your update rate should be faster.
Yup, it is more of a problem than I thought. My Bridgeport can easily go over 1 count/servo cycle.
it's not that you can go over
it's whether you need to go over
I have a 2500 count encoder -> 10000 counts in the LS
the low speed is only required for the final phase of homing
should only be 1/2 turn of the shaft
Well, the old EMC homing cycle is not too good, either. It does
so for alex, the final approach to the index pulse might take 5 seconds
(oops) a violent reverse at home speed to the index, then a rather violent halt at home.
the previous phases could happen at full rapid speed, if he wants - it just needs to be able to stop after hitting the switch, before it crashes
new one: move toward home at user configured speed, max_accel stop when hitting the switch
Well, you need to have a reasonable deceleration, not just turning the velocity to the opposite sign.
pause 100mS (or 50, don't remember)
then backoff at same speed
All of the machines I have looked at (Bridgeport and Hardinge with Fanuc) rely on being able to stop the axis in less than the distance between index pulses even during the initial medium speed home travel.
approach at a second user configured speed (slower I hope)
hit switch, and optionally continue on to index, then stop
fig 3.2, on page 21 of EMC2 code notes, has details
I think a simpler scheme might work, where you approach fast, decelerate, reverse and search for the index pulse. But, maybe what you suggest is the most flexible.
there are actually four versions, you configure the one you want (see the pic)
OK, I see it now!
you are describing the third one
I have always communicated better with drawings - IRC is a real handicap for me
so the real issue here is: do we keep the existing scheme, where motor_pos_fb never jumps and the homing logic is entirely contained in the joint controller (fig 3.1) or do we move part of the homing process into the driver by allowing the driver to reset its counter
OK, well, then the home sequence seems to be in hand. So, I need to know what features to code into the driver.
I guess we have to move part of it into the driver, to accomodate the higher-speed homing.
(we'll also have to be able to reset in the driver to do threading - spindle sync is _not_ something you can slow down for
Don't forget the tandem XX axis setup on gantries.
There will be a HAL pin for "home detected", and we expect the position to jump to very close to zero in the very next servo cycle after home detected goes true.
but before we can decide exactly how the driver will do it's thing, we need to figure out how the motion controller is gonna deal with the jumps
with higher speed homing you mean: during moving if the index pulse is encountered the count gets reset, so the joint controller will eventually stop the movement, and be homed already ?
its not that simple
Yup, tandem axes are a big problem, that is a bear with the old EMC.
tandem axis may well be handled by a revised version of fig 3.1
I know in detail it's much more complicated, I just wanted to get a big picture
There was already some discussion a week or two ago on IRC.
I've given serious thought to makeing fig 3.1 a HAL block, so you could swap in a XX one or the standard one
but Paul would probably shoot me
I like it. 8-)
let's ignore XX for now...
It may not be necessary. A lower level HAL block could handle what fig 3.1 needs to see, and also split the motor_pos_command for the two axes.
that was the original plan, and it might still work
* alex_joni is back in 5 mins
depends on the interaction between fig 3.1 and whatever is to the right of it
Oh, of course, this would preclude seeing BOTH encoders from the tandem axis on the screen. (Only needed for diag mode, anyway.)
right - the tandem axis would appear as a single axis to EMC, only in the HAL would you be able to see the two different ones
* jmkasunich needs a couple minutes too
When the tandem axis is homed, the two encoders are very nearly the same all the time. The PID is to the right anyway. So, if you do a particular offset for the before/after homing modes, then tandem splitter module could do the same for the 2nd motor/encoder.
Jon - What do you want to do with your drivers under 2.6 kernel ?
* jmkasunich returns, refreshed....
2.6? For the next BDI? What is involved? Are we talking for the old EMC or EMC2?
EMC, (emc2 is now where near being ready or BDI)
OK, what is needed? I believe I have everything beat into shape so that it compiles and runs OK when put on the BDI-Live! rc46 distro.
If there s a source file used to build two (or more) object files...
it is doomed to building one or the other, NOT both.
So no more #ifdef foo
Ugh! I use common c code to build a number of different drivers
* alex_joni returns, refreshed.... (:-))
Can mix #ifdefs for the user space stuff...
for 4 and 8-axis versions of 3 different products.
can you do something like this:
So, I have to remove ALL #ifdef?
make driver1.o, driver2,o
make driver1.o, driver2.o
If the #ifdefs are to separate usr & kernel code, it will work
so to be more precise, you can't make two or more kernel modules from one source file?
but #ifdef STEPPER #else SERVO
One source file in, one object file out - A module can be built from a multitude of object files.
oh, then it isn't that bad
Well, this is going to cause a complete rewrite, from the ground up. I suppose I could just break the commonality, and expand everything to the max. That would generally mean about 12 different drivers to support the device combinations I currently have made work!
The #ifdefs are in effect handed to the Makefiles
jon - you just need to put the common code in a "library"
jon - Do you need a 4 axis AND an 8 axis variant, or will a single 8 axis module work for both ?
jon.. look at hal_stg for a bit
you can define the number of axes handled at insmod time
insmod hal_stg num_chan=4
No, it is imperative that the driver never try to talk to a board that doesn't exist, after the initial scan. It takes 10 us to timeout for EVERY transfer that is not acknowleged. It will lock up many slower PC's if you let a timeout happen.
* jmkasunich is on the phone
you can try at insmod time to test if the specified axes really exist
the init_module code could do the talking - one attempt only
before the RT stuff is started
hmmm.. it's been a while ;)
it has... Hard to find these days. Hello all!
erm.... find time that is...
To make the code as efficient as possible, with an absolute minimum of if's, I did it ALL by #ifdef and conditional compiles. I did make one version that can adapt to an extra DAC for spindle speed control, and disable that function if the board was not there.
OK, so If we ignore the 4 & 8 axis #ifdefs for the moment
Yup, making the modules more flexible and sensing the config is a good idea. The cost of a few ifs is a lot less now.
how much else is #ifdefed ?
zwisk: how much time do you have now?
great question... probably an hour or so....
Ohhhhh, man, just count em! Lots! But, every one of these modules (for encoder, I/O and velocity command) has 4 and 8 axis ifdefs, and most have ifdefs for the particular version of the device (PPMC, USC or UPC).
Jon: when I wrote the first part I did it per axis basis
ppmc_encoder has 12 #ifdefs (not all for my purposes, some of it is for user-mode test versions.)
I know it's not the best thing (speed-wise)
because 2-axes could be addressed at once
but like this it's more generic
can you use the preprocessor to generate the many files before the makefile builds them into objects?
and the code doesn't really care if you have 4 or 6 or 8 axes
There are performance reasons why it is done all at once. It takes one bus transaction to set the address. Then you can read 12 bytes (4 axes x 3 bytes of position per axis) with 12 CPU instructions. So, that's how I do it.
I agree (performance-wise)
I'm not really sure gcc doesn't do some optimising aswell (break out the for, and do the transactions faster)
but modern machines can probably execute 20-50 instructions while waiting for each parport byte
Yup, using the preprocessor, assuming that the right flavor of ifdef's can be acted upon, might be fine. Or, I could just make it look a lot more like the STG, with one big driver block for all the functions of one board.
looks like ppmc_dio.c is the worst...
Yes, ppmc_dio.c IS the worst, becaus the register configuration is different on two of the products. The encoder is register-identical on all 3.
But, the way the IEEE-1284 works is that the CPU is in a wait state
until the transaction completes. (oops)
Keep hitting that darn enter key at the end of the line.
Anyway, putting the fast CPU in the wait state is pretty gross, but it does allow a handshaked byte transfer to be done very fast (now down to 600 ns or so with a PCI parallel port card or MoBo built-in port.)
600nS = 600 instructions :-(
Yeah, but since it is a RT process, there's not a whole lot else you can really do during that time. I suppose you could have some really horrible threaded code checking the I/O every few instructions, but the checking is slow, since it is outside the CPU, anyway. And, all the branches would kill you, too.
but it points out that the bus transactions are the bottleneck
Nothing you can do about that, except graft the parallel port to the inside of the CPU!
ppmc_dio.c has two, maybe four #ifdefs in total that would need a work-round
I can still do 10 KHz servo updates on a 333 MHz Pentium 2, on 4
you could take some wires from the processor to the stepper
axes, at less than 50% utilization.
OK, Paul, thanks for looking at that. That sounds about right.
Jon - The 4 or 8 axis #ifdefs can be worked round...
even the univ_step #ifdefs have a solution...
I think the short term solution is probably to try to make 4 versions, right now. PPMC 4 and 8 axes (maybe I can do that with one version that checks the config) and a USC and UPC version. That would only be 3!
wots USC & UPC ?
nobody likes my trick with the #include, eh?
ppmc.h also has an ifdef.
universal stepper controler, universal pwm controler
The 3 products I have now are : 1. PPMC - analog servo board set
jmkasunich: Missed the suggesion...
2. USC Universal Stepper COntroller
3. UPC Universal PWM servo controller
very short C files that set the #defines and #include the common stuff
the makefile would make the shorties
so from makes perspective, they are all different files
nah... Use sed & awk to generate the source files on the fly.
how bout make configure figure out the hardware?
and output the source files to make the hardware work?
Fine if you have the hardware hooked up to the build box
Ugh, then the user has to RECOMPILE if he changes the config? I wouldn't wish that on an ENEMY! Sensing the config at start-up time would be much better.
* alex_joni wonders why nobody noticed he was kidding....
* paul_c hits alex_joni with the old trout
8-) too good!!!!
* alex_joni threw the trout to his cat
besides, this is emc1 we're talking about - some folks don't even use configure for it
thought we started talking about HAL...?
but Paul came in with his 2.6 question while I was on the phone
Same rules would apply for 2.6 kernels and emc2
we've been talking about that ever since
No kernel level #ifdefs
the driver for HAL will be completely different anyway, and I expect we'll find a better way to deal with such issues
I need to switch screens for a bit.
* paul_c is away: on another screen
alex, jon... where were we
#ifdefs are going away
greetings from Nanoose Bay BC, Canada... just getting irc setup so hope I dont mess up too badly.
No #ifdefs in the future? Yikes!
greeting neighbor to the north ... Selah. WA
#ifdefs are _NOT_ going away
greetings from Timisoara, RO (far away from Canada)
OK, just in kernel code, then.
03cradek * 10emc2/src/emc/task/emctaskmain.cc:
In the last version Paul applied this patch by hand but put the fix
in the wrong spot. You are in a twisty maze of passages, all alike.
paul is referring to the fact that you can build only one kernel module from any given source file under 2.6 kernels (actually the 2.6 kernel make system)
so you apparently can't do thisL
gcc -DVERSION1 foo.c -o foo1.o
gcc -DVERSION2 foo.c -o foo2.o
OK, so this is a version tracking sort of problem, not the ifdef
but IMO a properly designed HAL driver for Jon's cards will figure out what it has without needing foo1-12.o
anyways.. we can put that stuff on hold, and return to the hal stuff
and the drivers
gcc -DPPMV foo.c -o ppmc.o
gcc -DPPMC foo.c -o ppmc.o
gcc -DUSC foo.c -o usc.o
not really versions per se
disregard the PPMV one, I can't type
Now, how does that apply to a kenel module built from a bunch of c files? Is it the first one that gets "linked" to the module?
damned if I know - I've done nothing with 2.6
OK, doesn't really matter, just wondering what the real interaction is.
IMHO, it is onlyan issue for EMC1, because that code is already written and will require massaging
for EMC2, the code isn't written yet, so as long as there is some planning, it can be made 2.6 compatible from the beginning
Well, it certainly makes a difference in the code I throw together for EMC2, also!
for HAL, I expect you will want three drivers - ppmc, usc, and upc
the insmod code will be responsible for figuring out everything else
Anyway, where did we leave the homing issue?
I'm having a heck of a time remembering - phone call and digressions hurt my brain
* jmkasunich scrolls back
Well, I think we figured out that the encoder routine needs to reset the position to zero when it is at home.
Yes, I know there is more to it.
and the traj planner needs to accept some position changes
the encoder driver needs to be able to reset the it's position feedback to zero when it sees and index pulse AND the motion controller has enabled the index
and as alex said, the motion controller needs to be able to deal with that
Right, only when in the search_for_index mode.
but that functionality will be used for threading too
going back to figure 3.7 in HAL_Introduction.pdf
So, does there need to be a different mode for spindle axes, or can it be the same?
the driver should be the same (I hope)
I'm seeing a big blank space, but no fig 3.7
hmmm that's not good
Yes, same driver, but would it be a different mode sent through the pin, or the same?
should look like: header "3.4 Encoder", then one paragraph, the figure, then header "Installing"
IMO, drivers shouldn't know about things like "modes"
an encoder is an encoder is an encoder, only the higher level code should know that one encoder is on a spindle and another is on a leadscrew
That's where I see fig 3.2
Well, the search_for_home is a "mode", it seems to me.
go to the very first page, what is the date there?
5 sep 2004
only EMC knows about search for home, the driver doesn't
5 oct here
* jmkasunich FTPs the latest to linuxcnc.org
Then, how does it reset the pos counter to zero when the index is seen?
index_enable is set (by emc)
that tells it that is should reset to zero on the next rising edge of index
Hmm, I am loading it from linuxcnc.org, and did a reload to be sure.
just checked the site, the file there is dated oct 5
OK, so index_enable is a "mode", then. I used the wrong term.
it's just a terminology thing - one of my strongest goals with HAL is that drivers should be generic
this is the URL I'm using : http://www.linuxcnc.org/EMC2_Code_Notes.pdf
me too.. still 5th September
there are two docs... the fig 3.7 is in Hal_Introduction.pdf
(sorry I wasn't more clear about that)
fig 3.7 is on page 51 of the Hal_Intro doc
the others we were looking at earlier are in EMC2_Code_Notes
OK, see that fig now.
that is the existing SW based encoder counter
but HW based ones should look similar, on the left side where they connect to the HAL
the right side is where they connect to hardware, and will be completely different
(most everything right of the dashed line will actually be in hardware, there will be no "update_count()" function
don't think most will have a right side
at least not exported to HAL
OK, well, I just need to know what to code, but the index handling can be left mostly for later determination.
if you don't care about indexing, you can just base it on the tiro driver
but indexing is a big issue, one that needs fixed
Yes, it is key to soem of the things that we want to do with EMC2's new capabilities.
the existing driver (fig 3.7) isn't neccessarily what we want - we need to decide what it should really look like - because it will be the template for future hardware based drivers
btw, position-scale is an HAL-parameter (which can be changed during runtime)
I should explain that, in case Jon isn't aware
in all these HAL block diagrams, a box like <position| that penetrates the "wall" is a HAL pin
a box like |position-scale| that is inside the box is a HAL parameter
Would it help with homing speed operations if the encoder module could capture the count instead of reset it upon index?
parameters can be changed at runtime (and are usually set from the ini file
A "parameter" is like a local variable?
yes, except that you can view/modify it using a command line utility
No, Steve, because the encoder module is only run once per servo cycle.
and even capture it with halscope
if the _hardware_ could capture the count, that would be nice
but not all hardware can do that
The hardware in the encoder counter can reset the count (or latch
OK, I was thinking hardware capture....
it, for that matter) in continuous time, or nearly so.
the issue again becomes how does emc use that information
The LS7166 doesn't have a separate register to hold the count at index pulse time, but it could use the latch. But, that is tripped every servo cycle.
allowing a jump in feedback gets really ugly - the more I look at it, the uglier it gets
position feedback goes not only to the joint controller (fig 3.1 in EMC2CodeNotes) but also direct to the PID loop
Yeah, I was afraid of that. There is another option, at least with hardware.
what is that?
If you shut off the loop, you can just run at constant velocity, and dedicate the latch for capturing the index count.
I thought about that... but it implies even more widely scattered knowledge of what EMC is doing... the PID loop also needs to know
All of my devices have the option to run in velocity mode, just by writing the same value to the velocity register during the home.
No, during that, you shut OFF the PID, or just ignore its output, and feed the velocity your own value.
right... so you need a switch, that goes between the PID output and the DAC
I fear I may be fighting a losing battle
Right. And, the axis that has been set to index_enable will ignore the latch_encoder command, and only latch when it gets the index pulse.
one of my main goals was to be able to break a machine control into independent chunks
the motor control chunk would simply be given a position and go there, meanwhile reporting back it's current position
Yes, but these interactions are pretty necessary. It causes some significant restrictions of you can't do it the "best" way.
"if you can't...
that chunk could be PID + DAC + encoder, or PID + freqgen, or stepgen alone, or ...
* alex_joni wonders why we got here...
where did the whole thing start?
cause I knew that the existing method (no feedback jumps) was gonna make people unhappy sooner or later
what if there is no feedback jump?
and to fix that implies revising encoder.c, which will be the template for all other encoders
if there is no feedback jump, it works fine, but you can't do "fast homing", where you are getting more than one encoder count per servo cycle
let's say the encoder handles the offset from the index pulse
maybe a second count?
I don't follow you
ok.. like this:
How does it do that. We are stuck with what is in the LS7166 chip for boards that use that.
in SW ?
check that output has zero-ed
but don't export to hal
export the last value+current output
That doesn't do me or any of the other users of hardware encoder counters any good. (I guess I could add functions to my boards, but I don't want to have to update a bunch of units in the field.)
not HW, only in SW
no Jon, he's talking about things that the driver would do
don't know if it's doable
jmk: did you get what I'm meaning?
I think so, I'm trying to wrap my head around it
OK, but how does the driver do this? It is only sampling the counter every millisecond or whatever.
is there a bit that tells us that the index has happened?
yes.. the driver knows it's in homing mode
I mean a bit from the hardware
there is some info from the LS7166, but I'm positive that not all have that bit
so that's not generic enough
The count suddenly jumps from a larger value to a small value, maybe <|20|
so how do you know you hit the index then?
what Jon said
what if the original position was only off by 1 or two counts
if you see 1000,1010,1020,4,14,24, then you know it reset
So, yes, you now KNOW the distance from index, as that is the count, and there is a bit that tells you index was seen, if that was in doubt. But, you still have to fake the count to the HAL pin to avoid a discontinuity.
but what if you see -18, -8, 4, 14, 24?
the question I was asking is "is there always a bit that tells you index was seen?" (to deal with the doubt)
got your point ...
I think there IS a bit for that, yes. My hardware has it, and I pretty much followed the LS7166.
for the LS's there is...
but for generic... I don't know
let's say somebody builds a board with normal counters...
because of the ambiguity, I would expect that it is neccessary
hmmm... if the hardware counter can be reset on an index pulse, the doesn't mean that it gets reset on _every_ index pulse
there must be a bit that you set to "arm" it, to reset on the next index
Yes, there is the "arming" bit
there is a "mode" for the LS to do that
does the arming bit get automatically cleared once you hit the index?
or do you have to disarm it before the next index comes around?
Umm, probably not! But, the index sensing is EDGE activated, so it responds to the RISING edge, only.
afaik it works only once
right, and one rev later there will be another rising edge
But, yes, you'd need to disable before the NEXT index pulse (next revolution).
you need to set it up again in order to make it work
so right there we have two possibilities for the hardware
* alex_joni takes out the LS pdf
alex_joni: auto-disarm, you need to explicitly arm it before it will reset again
jmk: not sure I'm right
jon: no auto-disarm, if you don't disarm it it will reset every time
doesn't matter who is right - we can't count on either one, because sooner or later there will be hardware that each way
(different drivers for each way, of course)
if there is auto-disarm, the clearing of that bit is the indicator that an index has arrived
if not, there must be a different indicator
so you know it is time to disarm
I don't see this "auto-disarm" in the LS7266 documents. But, could be present in the LS7166. I don't have such a feature.
And, I'm being called to lunch! I'll keep logging.
ok, doesn't matter
but our driver should pick one way (whichever we feel is better), and emulate it for hardware that works the other way
* jmkasunich is torn
jmk: no disarm in LS
I really _like_ the "no jumping feedbacK"
I think disarm should always be done
even if it's no code there
after index has been found of course
there would be 2 things to do
1. disarm the index reset
but "jumping feedback" is probably better
2. let hal know that the index has been tripped
I was thinking about two HAL pins on the left side of figure 3.7
index_enable and index_latched
index_enable input to encoder
rising edge of index_enable arms the latch
falling edge of index enable disarms the latch
rising edge of index input while armed resets counter and sets index_latched
falling edge of index_enable clears index_latched
does that make sense (again, I wish I could draw a picture)
no need for pictures
that makes perfectly sense
I think better with pictures
I imagine a OR-gate
input from index-enable and from index-input
output to counter-reset
maybe NAND is more appropiate
I was thinking more of a 7474 D flipflop
index_input to clock
D tied hi
index_enable to RESET/
index_latched is the Q output
and a rising edge on index_latched resets the counter
Still wondering if having a realtime encoder count and a "latched at last index" count would allow the motion code to chose jumpy or not on index. If there is no hardware latch, the resolution is no worse than if it did not emulate the counter latch.
yeah that too... (that even latches)
SteveStallings: much hardware including the 7166 wouldn't let you do that
.... looking up datasheets....
I think it has _one_ "snapshot" register that can capture the value of the counter
you can decide if you want it to be captured on an index pulse, or simply captured when you are ready to read it, but not both
for several reasons, I think it is better to make the driver reset the output when the index happens... I just have to figure out how to keep the PID from getting flummoxxed by that
jmk: I think I'll leave now...
keep writing to IRC, I'll read tomorrow
running away? ;-)
going to sleep
* jmkasunich ponders
a spindle encoder driver _must_ reset to zero on the index pulse at least once in a while, otherwise it just keeps getting bigger and bigger
how about resetting every-time?
for a spindle? or an axis? or both?
spindle probably would not want to reset during a threading pass, it would reset right before the pass starts
axis would only want to reset during homing
I really like this AXIS thingy ;)
I think all encoder drivers should try to emulate the "index_enable"/"index_latched" 74LS74 logic we just discussed
and the homing logic and joint controller needs to be modified to deal with that
what for drivers (HW) without index_pulse?
then they can't home on an index, they home on switch only
I thought so, but where does that stated?
Right about the reset spindle just before threading pass, that's how I was thinking it should work.
how does the driver know? (it just doesn't get the index_enable?)
based on the stuff in the inifile?
yes - index_enable for the encoder driver would be driven by a pin that leaves the right side of the joint controller (fig 3.1 EMC2CodeNotes)
if the hardware doesn't support index pulses, the driver won't have an index_enable pin, and the joint controller pin won't be connected to anything
there is a parameter "use_index" in the joint controller that decides whether it will be used
sounds about right
but PID needs adjustments..right?
OK... I give up..... no support for capture the count. I'm beginning to seriously doubt if these folks (US Digital) have a clue about realtime. First the rollover glitches now this.
steve: the only thing there is
I STILL don't know if the LS7166 rollover glitches are truly in the LS7166, or in the STG boards. (Although I suspect it IS the LS7166.)
is to connect the index pulse to the reset input of the counter (on the LS7x66)
Jon: can you describe the rollover glitch?
I think that reset can be done INSIDE the chip, by a control reg setting.
but where do you connect the index pulse?
I managed to trap this years ago with the EMC logging/graphing function. We had a problem with the sefvos "clicking" every once in a while.
I had a problem with one of my axes being more sensitive, and causing an amp fault from these clicks.
I found out that it did it a lot worse when the machine was left at its startup position (where the encoder counter was zeroed).
I believe it was a problem with the latch capturing the count before the 24-bit carry ripple had propagated across all bits. This should not happen, but it apparently does.
I think I read about this on some list (or maybe IRC log)
So, you'd get a transition from, say 00000000 00000000 00000000 to, say 00000111 11111111 11111111.
The next sample was always OK, either back to zero, or all 1's.
I see, but there is code inside emc to do more checks on faulty values
So, a software filter that supresses a count value that is impossibly too far from the last reading.
ok.. back to the resetting
resetting the LS7266 can be done in 2 ways (from the index_pulse)
was away for a minute
That software filter that rejects bad sample - that should be in the driver, not in EMC
either connect the index_pulse to /RCNTR (resets the counter on index_pulse)
or connect it to /LCNTR/LOL (load counter on index_pulse)
that can load a non-zero value into the counter?
John, agee the filter should be in the driver. BUT! It needs to know the maximum velocity the system is theoretically capable of!
More complexity and interconnection.
jmk: not loading a non-zero value into the counter, but...
it's actually a little bit more complex for the LS's
there is the 24-bit counter
and there is a 24-bit register
Yes, the LCNTR can load a non-zero value from the preset reg. I have the same function in my boards.
a more elegant solution is for it to keep track of velocity itself (difference between successive samples) and reject anything that represents an impossible change in velocity
Yes, that might also work.
in order to read the value from the LS the counter gets copied to the register
you could say "that just requires you to know max_accel instead of max_vel"
and then it gets read from the pc (because of more accesses needed)
so the value doesn't change during the read (which would imply a tainted read)
right alex, that avoids you reading the LSB and then a count happening before you read the MSB
ok: so for index_pulse there are 3 vars.
1. tie it to RCNTR (then counter gets reseted)
2. tie it to /LCNTR/LOL (configured as /LCNTR)- (then the value from counter gets loaded to the register)
3. tie it to /LCNTR/LOL (configured as /LOL)- (then the value from register gets loaded to the counter)
oh - _to_ the register - a snapshot
which one did the STG people do?
I think it's software changeable (as long as the index_pulse is connected to this pin)
but if index is connected to RCNTR then you can't
STG is totally configurable. You don't "connect" wires on the outside of the chip, you steer the signals with the indec control reg, inside the chip.
ok, so RCNTR and LCNTR/LOL aren't really physical pins?
or are they physical pins, both connected to index_pulse, but configured inside?
guess it doesn't really matter
* alex_joni doesn't know
* paul_c is back
comes down to "how badly will a jump on motor_pos_fb" affect the PID loop
assuming "motor_pos_cmd" jumps the same ammount at the same time
John, I can't find the index control register in the STG manual.
error will remain small, it's only the FF terms that will mess things up
Maybe you need to suppress the FF terms when in index_enable mode.
gets right back to undesired coupling between modules
paul: any luck on the packages?
Testing a new build - Didn't save as much space as I'd hoped..
how bout a DVD-boot disk for BDI ?
You wanna do one ?
hmmm... not different from a CD-one
DVD drives aren't exactly common in machine controller class PCs
so weren't CD-s a few years back ;)
just an increase in the size of the comps.xml
by an order of magnitude
hmmm.. short question
so in a few more years, we'll be ready for DVD based BDI
on the other extreme...
how small could a running image get?
machine control - pushing the trailing edge of technology
how small depends on how much cruft you are willing to do without
like X, for starters ;-)
there are X-distro's in 16 MB
16MB ram, or disk?
[21:54:41] <alex_joni> http://jailbait.sourceforge.net/
Then there are minimal distros on single floppies
even X-ones (I've seen a 2 floppy X-windows one)
If you off load the GUI on to another box, you don't need much space
Use busybox, and you might be able to use a single floppy
busybox with a RT kernel on one floppy would be cool
busybox is the "usual" cmd line stuff, like bash, grep, ls, etc?
well, I think maybe we need to digest the home/index implications and maybe work on it some more later. Meanwhile, I'll keep trying to put together a simple encoder driver.
a minimal shell and core utillities only.
same here - need to think on it
And, I think I'm going to sign off, and try to build some boards.
for a simple driver, look at tiro.c
Right, I have seen it. Thanks.
I need to sleep on it... :-)
Looks like the new build is OK
03Zathras 07BDI build system * 10Babylon Cluster/comps.xml: File changed. New revision:picax.xml
* alex_joni is worn out...
hes gorn ...
* paul_c was going to send him an ISO as an attachment
* robin_sz returns from yet another day of metal bashing
paul_c: the next BDI is it also Knoppix based ??
It is a merging of BDI-2.xx and the Morphix stuff
Using the BDI-2.xx installer with Debian packaging.
in a pervy sort of way
has debian released Sarge as stable yet?
what is the reason for choosing the debain installer ??
The instaler is from Red Hat (originally)
From what I've seen of the Debian installers, they suck.
I've had fair success with them, especially the net based installs
is the new one then also runing without installing, like the Morphix CD's ?
is it possible just to do a normal debain install, add an emc foo to the sources list and then install the 'emc-run' package set over the net?
in theory it should be ... just drops in a new kernael and the other stuff
the realtime stuff is the problem i think
You need a repository with pre-built kernels
presumably you have those for the distor anyway?
and emc packaged up
so its just a question of slapping em up somewhere and running that package lister whatsit?
and is it runnig without installing Paul ???
Imperator_: No, you have to do an install to HD first
robin_sz: this time i have switched on the light all the time during the building process. So this time you can see what it build's
[22:27:11] <Imperator_> http://cimweb.cim.fh-aalen.de/Menue/RapidProto/stereo/camera.html
will probably do a slimmed down Live for testing purposes
also morphix based ?
Yes - Will try to get it down to 50Meg
how many MB did fit on thos small CD's ???
ooh, cute .. look!
its making ...
a grren thing
heh, its got a windscreen wiper!
360nm or so
a doctorplade sweeper :-)
is that removing stuff or laying doen a new layer of goo for the laser to play with?
Ok : The sixty-four-dollar question what is it, if it is ready ????
dunno, the java push stuff stopped after a minute or so in a broken sort of way :(
after lighting you can see that it goes down. then the resin flood over it. then it comes up again. the sweeper has then to remove the resin that is too much
jep you have to reload sometimes
thats Java for you
with mozilla it is much better than with IE
* robin_sz has Netscape 7.2
because mozilla can do server push
that's the same
ach, stopped again after the wiper blade
is that your Java, or soemting pre-built?
hm, with my mozilla it is quiet stable
or try it with IE if you are on Windows
* robin_sz takes it apart to see how it works
heyyyyyyyyyyyyyyyyyyyyyyyyy i have Axis running
after updating Readhat 7.2 to maybe Readhat 20
Imperator_: did you do the java, or is it a commercial product?
cradek: it is working now !!!!!
it is Webcam 32 a comercial software, but not that expensive
looks quite nicely written
it is running good on windowsNT and newer
the Java applet has mainly the problem that it doesen't read the proxi setup if a user is behind a proxi
on Netscape/Mozilla it works with server push that is much better
and you have nearly no problems with firewalls
so, it has its own little webservery thing to run on the server?
seems to use a mime type thats porbably not normally supported
printwriter.write("GET /video/javacampush WEBCAM32/1.0\n");
anyway, thats quite neough Java talk
OK, so what exactly do you have running?
but you a right a P166 is too slow
at about 10x that speed it works great
it will be a little better if you turn off the tool cone
robin_sz: it has his own webserver, and we are running each cam on a own box. We had putted in the past 3 cams on one box but that makes too much problems and we have enough old computers
* robin_sz nods
cradek: how can I do that ?
Imperator_: Janet Street-porter has been voted off 'Im a celebrity, get me out of here'
Imperator_: that is a disaster
Imperator_: I was hoping one of the other contestants was going to murder her in her sleep for being irritating.
I am happy that my TV has burend ayear before
mine went to the tip 5 years ago
but, Id have been happy beyond belief of a nasty death came to janet street-porte, horrible whining bag that she is.
but I haven't bought a new one :-)
abouth the stereolithographie: the good thing is that Father Christmas was here and he brought us a new one. It is already in the lab, on january we install it, maybe also with a webcam
waht was it being made?
at the moment ?
on the webcam
a replika of a skull
is that the sort of thing its normally used for?
no technical prototypes
so the skull is just for fun then?
useless stupid plastic parts
no we have a research project about that
we have also a CT at teh university, with that we are scanning them
mmmm ... magnets
or how it is called
* robin_sz thought it was big magnets and an array of aerials and stuff
but hey, what do I know
or is that NMR?
maybe that is the one with the magnets
is it called here
03Zathras 07BDI build system * 10Babylon Cluster/ks.cfg: File changed. New revision:1.2
looks like I picked up a nice little project to make a 2 axis X Y thing for a local printing company
theres not a huge budget, but, it should be enough and leave some .. profit even :)
are we any closer to cheap servo/encoder cards for EMC? .. I do look occasioanlly but always seems to be 500 quid plus
the vital card is that?
isnt Alex Joni working on some sort of cheap card?
well.... $575 for the 8 axis version.
thats certainly competetive
I#m also working on something like that, but very slowly. Now a other german guy want's to help, maybe that speeds it up a bit
Alex has also something
yeah, we need somehting cheap
but search for a cheap DAC ISA card and use the software counters
Alex is/was working on a PC104 card
not so handy for most people i guess
realy cheap was my siemens card 8 EUR
did you get a driver working?
more or less
i had the chance to get 120 peaces of it but i was to slow
somwbody has bought them
I can buy commercial 4 axis controllers, with a usb connection and all the control and stuff onboard for 600 GBP
you can see emc needs some nice cheap hardware to be attractive to hobbyists
GBP ?? Brit. pound ???
900 EUR !!!!
Imperator_: in the edit menu
industiel quality !!
thats NOT including drives though
not so bad, because for that plug in cards you need some additional hardware like optocopplers ....
yeah, the 900 EUR thing is quite neat, has 32 IO and various other stuff too
cradek: how can i move the view ???
oh 7 axis servo, 32 IO, 12 bit analogue (1 out, 2 in), serial, USB ...
[23:27:04] <robin_sz> http://www.baldor.com/products/motioncontrol/nmesb.asp
* asdfqwega waves
* robin_sz waves back
Now that I've seen the latest screenshots, I simply MUST try AXIS
the downside to thos controlelrs is yo end up spending at least that amount again on an HMI if you need one
but it looks not so bad.
* asdfqwega lurks - cleaning shop
but it depends also on how fast you get it running :-)
www.baldor breaks if you don't dend it a browser ID
why make websites so difficult eh?
just code em up in compliant html and bobs your autnies live-in lover
and keep java out of the equation too.
itr has its uses
like whatshis names camera thing
but generally, its as you say, not needed
esp. for navigation
Imperator_'s camera doesn't work (for me)
what browser are you using ?
Imperator_: pan with the left mouse button, rotate with middle, zoom with right
Imperator_: or, there are preset views on the toolbar
Paul do you also have mozilla ?
asdfqwega: what's stopping you from trying it??
is java enabled ?
Konqueror rartely works with most modern websites, ive really no idea why KDE insist on trying to code their own browser
Imperator_: is it heck
never worked for me
hm, maybe if you say to konqueror it has to say it is a IE
then it loads the java applet
because on mozilla it is runing with server push
does Konqueror have tabbed browsing in its latest incarnation?
our webside makes a difference if it is Netscape/mozilla or IE
on Ie it loads the java applet because it can't do server push, but that fails if you are behind a proxie
ok have to go to bed
ok ... so
you know those 'digimatic' style digital verniers?
HTF do they work then?
is there a little wheel an a quadrature deetector?
the scale has some weirdness under it?
I can vaguely see some sort of 'fingers'
but they seem quite coarse, maybe 0.5mm spacing ...
anyway, theres a nice Mitutoyo 8" one on eBay ...