well it was supposed to be rain today...but warm and sunny
so I may vanish soon...
golf course is calling...
well.. have fun
this is the first weekend off I have had in a month
then take advantage of it
ha I have been...just in the office waiting for it to get to 15c outside
12 now heh
Also answering questions on yahoo and newsgroups
I like to do that when I have time
are there any emc-related newsgroups?
or just machining ones?
Cad_cam_edm_dro is hobby cnc specific and has a lot of emc content
...a yahoo group
thousands of members
I don't mind doing a little free engineering for them....
because every answer is thousands of emails...each with hyperlinks to my site
I think I'm subscribed to cad_cam_edm_dro
I didn't visit it in a while
So I give some free engineering...and get some free advertising
I am getting 7000 hits/mo on my site and a good bit comes from those groups
Grr this new winxp I had to install has java diabled
Does not even seem to have it or the firewall won't allow it
had to get it to test code I wrote for a client that will use it
I did have some problems with SP2 myseld
my imap connection (on local LAN) went berzerk
about 10 seconds before connection
finally tracked it down to the auth port, that was blocked on SP2
I am looking now...I have activex enabled...but java stuff will not run
well.. you gotta have a JAVA-VM
afaik XP doesn't have one by default
they offer their own M$-java-vm
but that one's crappy
I'd suggest you download a JRE from sun
need it to look at sat/radar weather to see why it is not raining all day as predicted
yup just went to the sun site
* Imperator_ is waking up
enjoy the wether les here we have 2�C
here we have around 4�C
hmmm sun cannot install JRE on xp sp2
then.. download opera with java (www.opera.com)
it's way better than IE
I will check that out
some pages don't show right in Opera thou...
but that's a fault of the people who write the pages
they don't go by standards... (rather M$ standards)
* alex_joni is watching UK Champs in York
jre installed...had to do some activex stuff first
like watching paint dry
now got the sat wweather animation...
uh oh...rain is comming
back in a while...
hi alex, I see you have been very active with auto config this week.
last night actually
I did another branch this week
perhaps you should review my comments about packages on the page at http://linuxcnc.org/EMC-description.html
and suggest updates to reflect your work
well... actually right now only make install works
there will be a make rpm
and some deb-packages
but those are not really done
paul started on deb-packages
and Jonathan Starks on some rpm support
is the intention to have packages that will install real time as well as EMC onto a standard Linux system?
SteveStallings: I looked over that page and it looks good to me. We will soon need to add 2.6 to the Linux versions supported.
I don't think so
that's way to hard to do
ray: for emc?
That is what I thought. So what will be the install sequence when one is able to use one of the packages?
Yes. Paul has a new BDI-3xx that is based on the 2.6 kernel.
This install is for EMC2?
I know paul's pretty busy lately with the next release
but it also helps for package creation (binary packages, e.g. rpm)
It is up to Paul, but my preference for 2 would be a BDI inclusion.
that's for sure
That is a ways off.
IMO the autostuff is essentially separate from how it will be finally released into the wild.
the autoconf kinda figures if the system it analyses is ok enough to use emc2 on it
you don't need those tests on a standard BDI
but I don't see how they could harm
I missed the start of this so I may well be way off...
No harm. A lot of help as I see it.
I will be a vendor at Cabin Fever in late January, and our local club will be running a CNC demo area again. I will be happy to distribute BDI releases there. With luck I may be running EMC2 as a demo.
Guru level doesn't need auto, but the rest of us developer/testers will be helped a bunch.
don't know what you mean with guru level?
As will the BDI folk whenever they make a new package for that distro.
John, Paul, Robin, you...
actually autoconf right now provides the ./configure script
which analyses the system and outputs Makefile.inc (with all CFLAGS, RTVER, etc.)
SteveStallings: Need me to ship you a bunch of disks.
so I don't think anyone can use emc2 without it
the HEAD branch of emc2 contains a custom written ./configure script
written by paul
I guess I was thinking of those few who built emc2 from the original make and source.
but that was way to hard to maintain
right now it's pretty simple:
Ray - I would like to distribute the latest thing available at the time. I can copy disks but don't have access to one of the cool label printers.
I've got a couple hundred preprinted.
when / if you're happy with the results ... make install
alex_joni: I don't know much about the specifics but it sounds like this is a big step forward.
rayh: it surely is intended to be... if it's already there... that's a whole different question
looks like an interesting discussion in progress
It started from wanting to update the EMC description on the web site to accurately reflect the status of auto config.
* jmkasunich reads mail
I wish I was online yesterday - seems Paul Fox was having problems that I could have helped with
steve: the autoconf stuff is still in a separate branch... don't think it should go on the page while it is not in the HEAD branch
which brings me to a question I wanted to ask you...
when do you think we should merge it
seems to me we're getting pretty close?
I see it with 2 possibilities
1. get a lot of people to test it, then merge it
2. merge it and fix what comes up, after people start to test it...
but I would really want to hear paul's oppinion about the merging
or 1.5: get a few people to test it, then merge it, and fix what comes up as more test it
well.. a few people did test it
but .. you can count those on your fingers ;)
I will need to build a new EMC2 soon for the show. I will try the new tools. Are there any "instructions"?
I need to do a cvs up and play with it myself
try the new branch I did this week
a branch from a branch?
steve: you really are only supposed to do : ./configure && make && scripts/emc.run
SteveStallings: the autoconf stuff works just like the original: ./configure, make, run
jmk: yes... ain't it twisted? :-)
the difference is that the original hand-generated (and crufty) ./configure has been replaced by an autotools generated one that does a better job
or should ;)
Hey, I don't need any extra help with getting twisted, ample ability on hand already! 8-(
well... it does a lot more tests
any particular reason for another branch? That means either you don't get the benefit of the compile farm, or I have to add the new branch to the farm list
it doesn't change things on ./configure && make
only for make install
I see - we don't do make install on the farm anyway, so I guess it doesn't matter
but I would love some testing from you... e.g. tell me what you think of it
still - if the config stuff is pretty much working, I think I
I'd rather see it get merged, then continue with the install stuff in the original autoconf branch and merge again when that is working
too many branches can get confusing, IMO
right now the autoconf branch has some make install additions in it
some I don't like
1. run-in-place is broken
so I wouldn't want that merged in HEAD
1. strip away all make install stuff
and merge only the autoconf stuff
2. so some more work till the make install is ok
and merge that
but the "more work" is in the new branch, yes?
there's less work there
then what is the new branch for?
I didn't like the way zwisk did it.. I thought it was too complicated
so I did it my way... a lot simpler
have you and zwisk talked about it at all
but I still want to discuss it with him, not to miss anything
we did exchange some e-mails
but he last said he was busy, and I should give it a try, and we'll sync sometime
I like your option 1 (remove make install, then merge)
then work on make install "from scratch"
but I'm really not up to date on where that all stands
that's what I did in the new branch
* jmkasunich needs to read the cvs book again
can you merge from your "branch from a branch" all the way back to the head?
well.. the branch from a branch is actually a separate branch
just like the first one
from the trunk?
they are equal
work can be merged from either one
or from both
I'm just a little concerned about the proliferation of branches - I'd like to hear what paul feels about it
* alex_joni joins the club
in the meantime, it shoulds like I should checkout your new branch
I think paul is more likely to state that the autoconf ./configure is up to replace the hand-crufted one
I agree - regardless of where we stand on the make install, I think the new configure should be merged as soon as possible
Getting it here now. I can test after a bit on 2.20b, live, and knoppix.
ray: either one should work
SteveStallings: Got any clue how many disks you might need for Cabin Fever?
That crowd is just warming up to CNC. Need should be no more than 20. If more ask, I can start making copies. My question is which disk? BDI2.x, RC46, or the new one Paul is working on?
They are printed in Baltimore. I could get some shipped direct.
Hopefully Chris Daniel (aka -thalx) will be running EMC1 and I will be running EMC2.
I'd wait for the new. It promises to be great.
* alex_joni is eager too to get his hands on the new BDI
Are the printed disks blanks that your burn?
jmk: say when you got some time, and nerve to test the new branch
did you talk to Imperator_ about homing ?
Then I could do the burning at the last minute, just tell me how to get some of the disks.
Email me your address again and I'll get some to you.
good morning folks.
alex_joni: nerve - no problem, time - that's tougher
good afternoon jepler
I haven't talked to imperator about homing - I have done zero emc stuff this week except for a couple emails on the list
he's still wondering about a hal module
for a XX machine
he's been talking to les about master-slave joints
SteveStallings: got it.
I was wondering... how is hal connected to emc ?
I need to clone myself
through the /src/emc/hal_intf/ ?
but in hindsight, that probably should have been used
or maybe not
yeah... that clarifies it a bit
I don't like the ext interface - the new emc2 motion controller directly accesses HAL pins
using the ext interface to do it would have just added another layer
well then its more likely that the motion controller can tell a hal_module it needs homing
paul and I have debated it back and forth
through the ext interface --- no way
I need to review how I did homing in the new motion controller
need to define some conventions for the behavior of a HAL encoder interface (whether hardware or software based)
and then modify the motion controller to work with that
sounds like a lot of work
as it stands, when an encoder hits an index pulse, the actual encoder driver does _not_ zero the signal it sends to the HAL, instead the motion controller adds an offset
that is simple and clean, and works well _unless_ you are running at more than one encoder count per servo cycle
yeah.. but a HAL module for a XX axis can do it the same way
right - the XX module would strive to make two physical axes look like one logical one
tell the motion controller it's a single axis
jep, that works well but homing is the problem
im thinking on that the HAL module will make the homing but ..
im not shure if that is a clean implementation
Imperator_: the HAL module needs to home the second axis
while homing the two axis have to move also together. If one hits the home switch it has to do the same procedure like on a single axis. then it has to hit the second home switch. then the axis have to synchronise
I don't think you can do that
but ALWAYS both axis have to do the same movement
you just said it - both axis always have to do the same thing
you can't home one at a time
how can you make sure the two axis's move at the same time if they are not homed?
what if something happened during power-off
and they are not synced anymore?
imagine both were in sync, then you did power off
if they are not homed i can only command both to do the same
and then you turned one screw part of a turn
you won't be able to turn it much because the machine is stiff, and it won't let you
but say you are 1/4 turn out of sync
that can happen
I think it's like this... during homing both have to do the same thing
what's the problem ?
when you home later, you run both axies together, and they remain 1/4 turn out of sync until you get to the end
and if both HOME_SIGNALS come, then it's ok
if only one comes it should be signaled or treated differently
but I don't think you can decide what to do in this case
the XX module must detect that they are not in sync, and it is responsible for syncing them
maybe run the two till the home signal for the second comes
jep, but first you have to hit both switches
then check how far from home it is (from the home on the first)
that doesn't sync them tho - they stay 1/4 turn out of sync
if greater than a certain value- e-stop with message
I think this thinking is incorrect. You are only going to home one of the two.
if not move the first axis on home (because the second one is already)
The second just has to follow that primary axis.
I agree ray, but you have to make sure it's not way off
so the whole thing doesn't get broken
rayh: yes - but what if the second one is offset from the first one (skewed)
in real the home switches are always on different positions
Trying to allign two 2000 encoder index pulses will not work.
rayh: I would disagree on that
The integrator will simply have to mechanically align the two.
Imperator_: here's a thought
the two encoders?
on both axes
not a lot more expensive
i have some, but i want to wite the module also for normal incremental encoders Alex
don't know if you can for all cases
I see abs-encoders the way to eliminate a lot of problems
rayh: you mean the integrator would adjust the machine so it is square (no skew), then manually rotate the encoder wheels until they index, and finally tighten the setscrews?
or use power-off-brakes
that doesn't solve the problem
jmk: I do that on abs-encoders
i think that is all not that problem
I would only use the index from one encoder. The other is irrelevant.
how to you keep the machine square then?
you really need to make sure they are in sync
the question is how to implement that
suppose while it's powered off, someone turns the slave axis by 0.002"
maybe after homing drive the axis for one turn in either direction
Sync is simply matching pulse for pulse between the two motors.
1. a HAL module that does it's own homing procedure
and check for the home-signal from the second axis, and see what diff you have
ray: agreed if the machine can't be moved when switched off
2. add a additional secuence to the existing
Doesn't matter if it is moved.
Imperator_: I'd rather avoid a HAL module that actually knows about homing - keep that in the emc motion module
When restarted it homes on the index from one motor while the other matches the motion.\
rayh: only one part gets moved
so it's not square anymore
No both must move at the same time. That is the nature of the fixed gantry.
right - only one side got moved, it is now 0.002" out of square - if the slave simply matches the master, it will stay out of square by 0.002 forever
i think i have to write the sequence i'm thinking on down somewhere otherwise that discassion lasts forever :-)
it's not fixed
no gantry is infinitely stiff - if it was, you could use only one screw
it's a gantry driven by two motors
Imperator_: I agree it can be adjusted by software, but I would really go with abs-servos (a lot safer)
Gantry axis will self align itself.you cannot force to have skew
Yea... What he said!
that way you can check the skew before moving the gantry
I must respectfully disagree with ray and sivaraj
ok if i add something to the existing homing sequences motion has to know that there are two axis. makes this new problems ???
Skew can be forced and will cause premature wear on bearings.
if the gantry is stiff enough that you "can't" skew it, then why bother driving it from both sides?
* alex_joni agrees with john.
if there is a skew will cause motor to overload
so it cannot move
depends on the amount of skew
a small skew will just damage things sooner or later
if the stiffness is such that 0.002 of skew will overload the motor, then 0.001 of skew will be 50% of overload, and 0.0005 skew might not be noticed until bearings or screw wear out early
* alex_joni leaves for half an hour...
if there is skew it will be there until it has hit both home switches. Then the next step is to remove the skew
yeah but what if the skew that is damages the machine ?
IMO if you try to force both motors to home you will introduce the skew that you are trying to avoid.
I think a abs-servo could have prevented that
check the two encoders... and see what your skew is...
... if the system crashes and there is lots of skew, then the first step is to relax the torque to the ganry can be squared enought to move...
The only way round this is motor amp load balancing.
then it is in sync and the rest is easy because then you only have to give both axis the same command and whach if they are in sync. If they run out of sync the machine goes to estop
most of the CNC's I have seen references only master axis.the slave will just follow it
* alex_joni is back in 30 mins.
no need to reference the slave axis.
don't think so sivaraj
Generalized solution should also take into account systems running stepper motors and NO feedback.
You will get out of banance conditions during accel and decel anyway because it will be nearly impossible to perfectly match the tuning of both systems.
no problem Steve
true - and even if they were perfectly matched, moving the Y from one side to the other will change the inertia on each side - the lighter side will respond faster
using servos or stepper makes no difference
If you insist that both motors must be homed to eliminate skew then make the gantry swivel at both ends.
that is another problem John but i think a small one
Now you can set the squareness of the xy table by rotating one encoder.
Darn this machine design stuff is fun!
Hm ?? Don't understand you rayh
I have build Gantry machine with Heidenhain syatem but they do not reference the slave.Its work is just follow the master
and to a lesser extent, that is true of every gantry - swiveled ends and perfectly rigid ends are two extremes - but since there is no such thing as perfectly rigid, the swivel thing is a usefull thought experiment
The Siemens 840D does it
Imperator_: Don't feel alone. There are not many who do understand me;)
Yes you are correct that many commercial machines have fixed multiple motors and screws.
sivaraj: at the Haidenhain controlers you can decide if the slave only follows or if they will be synchronised after homing
I expect that in many (perhaps most) cases you can ignore the issue that we have been talking about, because there is no realistic way to get a skew in the first place - so as long as the slave tracks the master pulse for pulse, there is no problem
more or less John
but Steve brought up a good point - suppose it is an XXYZ machine, and Y is all the way at one end
during an X rapid, the tool hits something
i think we have to go one step further
one end of X stops right away, then other keeps going a little further
the PID controller has to solve that John
hmmmm.... I guess that's only a problem with steppers, if they have encoders, then other slave would just move back into alignment by itself
but with steppers, if the crash causes one side to loose steps, you have skew
and with steppers you have to take care that the do the stepps in any case
jep that is the problem of the steppers. That's why servos exist
ok i think we have discussed that. Now where can i implement it
Imperator_: The possibility of either slave or dual master would allow for most any kind of mechanical relationship between the motors.
I think that any XX HAL module should have an parameter called "skew" or "offset" or something like that, that is added to the slave command
jep and a few more parameters that is not the problem John
* rayh gotta go. Thanks.
ok if i do homing in motion then emc has to know that there are two axis
and even in free mode they have to move together
how can i do that
why does emc have to know?
because i think otherwise the homing can't work, because it is in EMC, or ???
emc would home the one axis - the other would simply track it.
or do you mean i have to do both writing a HAL module and adding something to the homing code in EMC
if there is no skew before homing, there would be no skew after homing
nope - no change to emc, just the hal module
but i must be able to remove the skew if there is one
and i must be able to home both axis
to mesure the skew
how would you measure the skew?
if i have homed both i know where they are and i know where they should to be
but you can't home them individually - that would (at least temporarily) cause even more skew
i think it is difficult to measure skew with rotor encoder.May be linear scales can help
even at homing they must move together
so if they must move together, how can you possibly home them both?
first i search for the switch of the first one, then of the second one
maybe this is a miscommunication issue: when I say "home an axis", I mean the entire process of moving toward a switch, stopping, perhaps backing up and approaching slower, sensing the switch again, and then possibly continuing until you sense an index pulse
jep i think also on that all John
that has first to be done for the first one, and then for the second one
oh, I think I get it now: you are gonna to two complete homing sequences, first using the switch and index of the first axis, then using the switch and index of the second axis, and moving both motors together
that makes it interesting
that makes it ver, very ugly... because either:
1) emc must "know" it is a dual axis, and home it twice
or 2) the HAL module must "know" that emc is homing
part of the modularity of HAL is that they should not have to "know" these things
there is the parameter homing or how it is named
emc tells HAL to move the axis, hal moves the axis - HAL doesn't know if the moves are part of homing or part of cutting, and emc doesn't know anything about the axis except that it goes where it's told to
jep but there is a parameter or pin (i don't know at the moment) with that the HAL module can know that. But maybe that is not the best way to implement that
JMK - what does the HAL module do now when it encounters a "home" signal during a move?
the homing signals are conected directly to emc the HAL modules don't know them
what he said ;-)
but that needs to be revised at least a little bit to handle index pulses better
(the home switch signal still will go directly to the motion controller)
.. so the current homing routines are not within the HAL code, but rather within EMC2 code
machine tools home, emc2 is a machine tool controler
things like stepgen, encoder, etc, are lower level functions, they don't know about homing
i think there are only two posibilitys: 1: write a HAL module that does homing itself. During homing it tells EMC something to keep it quiet
2: to implement it completly in EMC
the second way i the clean one i think
3) write an XX hal module that recognizes EMC's homing sequence and does whatever special things are needed for dual axis
or maybe 1.5 emc does the homing. After homing it commands the slave axis to move because of eliminating skew. Then it gives a sync signal to the HAL module.
does the current EMC2 homing rely on the final move to be slow enough that EMC2 can stop on exact index pulse by aborting a move command?
both 2 and 1.5 require EMC to know that it is a dual axis
SteveStallings: no - it only requires that it be slow enough that you get 1 encoder count per servo cycle - the servo can overshoot once the index is detected
see chapter 3.4 of http://linuxcnc.org/EMC2_Code_Notes.pdf
Sorry, I have not read the code. So the index snapshots an encoder count?
oops, going to read.....
* alex_joni is back
just got back and read the master/slave discussion
I studied up on it...
the good controls allow slaving to a virtual axis (commanded position) OR a real axis (actual position)
so john you suggest to not change anything on EMC itself. But i think that you agree with me that this would be the cleanest way
which seems to be the way thing are going...
what is the biggest reasoon not to change anything on EMC
03jmkasunich * 10emc2/src/hal/hal.h: fixed some comments so they match the names used in the code
this a link to QA on Gantry axis reference with Galil motion card http://www.galilmc.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic;f=3;t=000141#000000
question: how does emc1 support XXYZ machines
I guess it does not john
I thought it did?
(maybe not well, but I thought it at least makes an attempt?)
I am told no...
which is why I had to use a jackshaft (there were other reasons too)
my reason for not wanting to make the code motion controller "aware" of dual axes is that the motion controller is complicated enough already
ok that is a reason
simplicity is good...
I read that the propagation delay for slaving is about 3 servo cycles....
I just read through the log...
see chapter 3.2 and figure 3.1 in EMC2_Code_Notes.pdf, that drawing can help us communicate I think
so some might need virtual slaving if thir servo update is not fast enough
mainly to John I think
what if we would have a HAL module that does the homing
so it's abstract to emc
this way things could get simlified in the homing procedure
it would be hard to modularize homing
have different modules for different types of homing (with index_pulse, withour, with twin-axis, etc)
communication with the rest of emc
some changes on emc are needed.. agree
but it would simplify things in emc
HAL works well for things that can be modeled as "hardware blocks", with signals connecting them to other parts
Would it be reasonable to put most of the magic into HAL but add one command called "deskew" to be issued by EMC2?
yes... and this is exactly what I am thinking of
right now emc is connected to a hal module
with position command, and response
right - see fig 3.1 in EMC2_Code_Notes.pdf
ok.. now inbetween these to there'll be a homing module
not a bad idea Alex because then it is also possible to check if the counting of the incremental impulses is ok. That can be done every time a axis is driving over the home switch. The professionel controllers are doing that
with 2 signals to emc
and the hal module takes over driving whatever is connected to his pins until it's homed
know what I mean?
results: the GUI would display nothing during homing
well the HAL module can update the position
so the GUI will display it
if the feedback changes but not the command from emc, then emc will trip on ferror
emc will probably need tweaking to not go into e-stop
the ferror could be meters during homing, unless emc is generating the commands
My idea with the "deskew" command is that EMC2 would still be in charge of all homing moves, HAL would "fake" signals so EMC sees only one set, and a "deskew" move would give HAL permission to turn one motor (not two) to allow sync of encoders.
SteveStallings: that's kind of what I was thinking
there are two parts to it, one easy, one hard
easy: provide an offset parameter that moves one motor relative to the other
hard: measure the offset (using index pulses or switches) so you know how to set the parameter
IMHO, the very first measurement of the offset will be made using a precision square and dial indicators
but the easy one would twist the gantry , no?
I was hoping for no parameters, just make sure the deskew move is long enough. HAL would move only one motor until skew was absorbed, then move both until move completes.
if you told it to apply 0.1" of offset, yet
but suppose your dial indicators and precision square tell you there is 0.0013" of skew
you could use that one dinamically
then move one motor by 0.0013" and you are good
there must also be a parameter what is the normal difference between the axis. That difference must be mesured onece with dial indicators or something
let's say you know you have a side that's more heavy
electronic version of my cam and follower on one screw?
les: let's not go there yet ;-) (but yes, that offset could be made a function of X)
right now we're only talking about it at the home position
Imperator_: yes - you measure one time to get the baseline offset
did paul return?
so the trick becomes to measure the current offset, then correct it to make it whatever it should be
It seems complicated in that the system has to stay reasonably synced when shut down and starting up
les: that's why I suggested abs-encoders
Looking at figure 3.2 perhaps we do not need a separate "deskew" command because the move at latch velocity command could be assumed to be a "deskew" move.
_either_ it must stay synced (not move when powered off) _or_ it must be able to measure the skew to correct for it
the first is easy for the software, but very demanding on the hardware
My machine must be kept tightly synced on or off
your machine is synced by the gears
i think the only trick is the implementation of the homing sequence. After homing you can calculate eaily the skew and correct it
but are you saying that the gantry itself is flexible in the skew axis, and depends on the screws to keep the sides synced?
no, I am just saying that even a tiny loss of sync makes huge racking forces that could damage the bearings
so in other words it is very stiff in the skew axis
yes...but not stiff enough to drive with one screw!
but that is not a problem of the controller
but assuming two motors instead of your gearing and jackshaft,
when powered down, it would be hard to get your machine out of sync, for the simple reason that is it quite stiff, correct?
right...unless a motor did something funny
if you turned one motor manually, the gantry would backdrive the other motor
10kN of force there...
the screw is a big gear, you can't backdrive it so easy
but if both motors are at zero amps when you power up the encoders and encoder counter hardware, you can be pretty confident that that skew (and skew loads) are small
30 kN*M of possible racking moment
I hold it to 0.0005" measured
you mean with the jackshaft, and the error correction cam?
sounds almost like two absolute stops in known places that the gantry parked at would be in order
jmk: yes as measured
ok - but we're not talking about your existing system with jackshafts - we're assuming two motors
so if you had two motors, and they were powered down, and somebody came and pushed the gantry such that both motors were backdriven by the ballscrews.....
drive both sides slowly into hard stops, then sync counters?
you're getting ahead of me
besides, index pulses are as good as hard stops (or better)
back to my hypothetical situation:
I come along while your machine is powered off, and I push on one side of the gantry, hard enough to move it, both motors turn
there will probably be some skew (0.0002-5) just because I pushed off center
now you power up your counters, and begin running both motors together, count by count
yes..it backdrives...skew is more
is that skew that I introduced by pushing on the gantry enough to generate damaging forces?
or could you just run both motors together until both hit index pulses and then correct the skew?
would prob be ok on my machine...but in general many would not backdrive...right?
well if they don't backdrive, then there is no prob - neither motor moves, and it's as if you never turned it off
of course if you turn one screw, and the other can't backdrive, then you could possibly put some serious skew into the machine
beginning to think index marks must be mechanically synced during the initial machine setup and calibration
not really mechanically
the sw could remember that index 1 is 236 counts away from index 2 when the machine is square
you would square the machine by moving one motor and checking with squares and indicators, then tell it to remember the offset
then on a later home it would measure the offset between the two index pulses, compare that to the remembered value, and correct if needed
with a gantry machine the user needs some extra care. The controller can't know that a force has brought the gantry axis completly out of sync
ok so in conclusion i try to write a HAL module
I have had couplers slip...but if they don't the calibration need only be done one time
or what is your conclusion John ?
Imperator_: the module should get both home switches, (or both index pulses), and only tell emc that the switch has tripped when _both_ have tripped
at the same time, it measures the difference between when the first one trips and the second one trips
that difference is the current offset, it should be compared to the remembered offset (HAL parameter)
if they are different, the command to the slave axis is adjusted to correct the error
then both switches have to be mechanicaly close together not at both ends of the machine
maybe we need then a new command to allow deskewing
and a new command to tell the GUI the difference
will this work if say a coupler slips on one side due to a crash?
if something slips, you'll have to get out the indicators and square again
because the remembered offset would no longer be valid?
ok i will try to do that
right - just like a single screw machine's home position would change if the coupler slips (I'm assuming you are talking about index pulse based systems - if it was switch based, then a slipped coupler wouldn't matter)
but anyway the idea of Alex to put the homing code in a HAL module has some advantages
even at normal machines
I am just wondering if an automatic offset correction might be a problem with a slipped component
but you got to make sure the overhead to implement it is not too big
prompt if offset has changed?
les: depends on your offser reading
e.g. offset checking
or maybe we put the homing code in a extra file
you would need to have a max_offset
kinda like a offset_ferror
if it's too big you need to e-stop
maybe adjust one PID
yes, have you sean the manual of the siemens controller ??
and the max ferror DIFFERENCE in normal running
assuming a crash while you were running, and the coupler slipped then, the amps would already be trying to drive the machine into a skew condition (and would probably ferror out)
cycling power would make the system forget the old positions, so when it comes back up, the amps would now be happy, and you could move it home
but when you get home, you'll measure an offset that is not what it should be
I agree that maybe you _don't_ want to automatically force it back to the expected value
JMK - sent some ideas by e-mail, too long for one IRC string
there are actually two steps here, that can be implemented independently in the HAL module
* alex_joni sound out that CVS merging is pretty tough
* alex_joni found out that CVS merging is pretty tough
1) only tell EMC that you have hit the switch or index when you have hit _both_, and measure the offset between them, store that value in a HAL param like "measured_offset"
2) apply an offset to the command sent to the slave, derived from another HAL parameter, like "command_offset"
about 1) can't the module try to reduce the offset?
measureing it is always safe, modifying it may not be if something has slipped
or will that automatically be done when emc sets command_offset...
software does not know what is square and what is not
there will be another parameter that tells the module the max offset it corrects automaticaly
actually .... no
I think of it this way:
1. during home the hal module reports measured_offser
(even in other conditions.. let's say everytime it gets index pulses)
emc checks measured_offset against a max. value (after substracting the default value, fixed during set-up)
if it's greater it e-stops
and the user has to decide what to do
so you are proposing that EMC proper _does_ know that this is a dual axis
someone needs to watch the max offset
and remember the default offset (probably from emc.ini)
well the default could be a HAL parameter
this is a major conceptual issue that we need to decide on - should or should not EMC itself be aware of dual axis?
thats the point
if yes, that implies changes througout - all the way from motion controller up to the GUI
are there reasons to treat it differently?
but perhaps it can be handled better that way
if not, then all dual-axis stuff is hidden in the HAL, and there is much less widespread work to be done
i think that dual axis are a very importend thing. Look at the machines all the guys are building that are mostly dual axis configurations
I think it is best that EMC does not know. We do we stop changing EMC as new special drive issues come up? Wasn't this simplification the original purpose of HAL?
but driven by one motor
very important for us yes
but perhaps it doesn't work as well because there's no way for the HAL to tell the user "hey, my offset is too big"
SteveStallings: perhaps dual axis is one of those things that is at a higher level and _should_ be handled within emc
I think to be robust a dual has to monitor that stuff
I don't know - my initial thought were very strongly toward handling it entirely within the HAL, but now....
jmk: what if the hal module sees the offset is too big and stops moving?
other question : is EMC2 still able to drive hexapods ?? Because there are not so many special configurations. One is dual axis and then the hexapods
Could dual XX be treated as a special case of kinematics?
emc2 currently doesn't have the hexapod kins, but so far that is done exactly like emc1, and we should just be able to copy hexapod kins over from emc1
is a hexapod only a change in kinematic or has the homing sequence also to be changed
afaik only kins
you still define all axes
SteveStallings: nope - because kins takes place above the joint controllers - there is no way to force both axes to be homed in sync (or jogged, or any other free mode stuff)
jep dual axis have nothing to do with kins
in a hexapod, all axis can be homed (or jogged) independently, the hexapod kins are to the left of figure 3.1, while the HAL stuff is to the right
So how does an overly constrained mechanical system in a hexapod manage to home the struts?
are you shure John ??
homing in hexapods is "yucky", to use a technical term
staying away from poles...
what happens if all axis of a hexapod are at lowest position is it then possible to move one axis to the home swich that my be on the top position ?
I had an exchange with Fred about it some months back - he basiclly said they used a lot of ad-hoc tricks to do it - automatic homing doesn't really work
so you have not to switch of a hexapod at any position
So back to our special case XX homing...
first and most important question - does EMC know about dual axis or not?
lets list pros and cons
pro: provide the user with custom messages when the offset is too big
con: lot of work but i hope i can do that
pro: clean impementation
con: it will modify emc, make it a lot more complicated
pro: there could be a special version of figure 3.1 that understands dual axis and handles everything
pro: I don't have to spend thousands on mechanical solutions
les: irrelevant - we are talking about _how_ to implement dual axis, not whether to do it
both ways will save you the mechanics
hmmm... you could spend thousands on software solutions... I wouldn't mind ;)
pro: maybe it is easyer for users because handling of all that HAL modules is also not that easy
con: (the big one for me) the changes will ripple up thru emc from the motion controller to the config and the user space stuff, including the GUI
it's starting to sound like makeing EMC aware of dual axis is better, but harder
jep think also so John
simple question: does the user have to know when offset is too big? or an e-stop is enough?
estop with a good message why is best
an unexplained e-stop leads to users asking questions on the list
some descriptive message would be good
well...in that case emc has to be aware
I _HATE_ faults/errors that don't give accurate messages
some changes have to be made to emc
and if those are made... why not go the best way
What about a way for a HAL module to pass a string on errors?
HAL modules can write to the kernel log - that's it
it must fault out on anything from sliped mechanicals to shorted amps, locked computers, anything that would cause damaging racking
how about a NML-aware HAL module?
no, no, a thousand times no!!!
* alex_joni thinks jmk doesn't like NML...
hal is all about simple components, like electronic parts interconnected on a PC board
opamps and 7166 chips don't print error messages
Old thinking, our black boxes are getting smarter.
well.. there are some counter chips that do...
if something doesn't lend itself to that model, then it shouldn't be implemented as a HAL module
just want to make the point:
a HAL based system should be describable by a drawing showing the modules and their interconnections
no extra hidden stuff like NML messages
or other messages
the block diagram _is_ the system
well then.. guess EMC has to decide that the offset is to big, and it has to shout that to the user
right - although HAL modules can write to the kernel log, no existing module does so from the realtime code - only from the init code, in the event of an error
that's more development debug than runtime debug
what we need now is a dual axis version of figure 3.1 from ECM2_Code_Notes
don't expect the user to check /var/log/messages to see why his machine went into e-stop
Forcing all error responses into codes that we have thought of in advance is still a problem. New systems will always require new solutions. String reporting can enhance usefulness.
HAL modules should not generate runtime errors - period
how about a servo as an example of a module?
op-amps don't generate errors - if the input is out of range, they clamp
some servos have serial commands & reporting
and they might say ... motor winding problems
more usefull than error
Agree that EMC must still "poll" for errors, just want more information.
recall that HAL modules are all executing periodically
are you gonna generate the error message 1000 times a second?
... gonna have to think about that...
maybe in that case we need something like syslog im EMC where modules can send messages
I think of HAL as a sampled system, with signals flowing from block to block... if a signal goes out of range (or some other error condition happens), then output of the block does something logical for as long as the condition persists. When the error condition goes away, the output of the block goes back to normal
faults are not latched, and the blocks are unaware of the state of other blocks - all they know is their inputs, all the affect is their outputs
that's not to say that a block can't have a "fault" output and a "fault reset" input, if you truly want to latch some kind of fault, but that should be rare
Could there be a HAL error reporting device that would latch the output of modules that it was connected to, and then the error reporting device could be polled at a much slower rate?
I'm not convinced that HAL modules should have "errors" that need reporting
if you ask freqmod to generate a step rate that is too high, it doesn't generate an error, it just makes the fastest pulses it can
True, EMC should be the thing deciding if it is an error. But I still see a need to get around having to change the EMC code to report every possible signal for the HAL system. I would prefer that EMC be allowed to sense a signal that indicates a fault and then be able to fetch a string from the HAL environment rather than have to code the string into EMC.
i think there are some, for example the encoder counters of professional controllers are reporting that the linear encoder is polluted
detecting impossible motions?
We definitely aren't looking at HAL the same way
Granted, I'm not playing fair. My expectations are probably getting ahead of what is reasonable.
IMHO, if you can't describe the operation of something pretty darn completely using a block diagram (like those in HAL_Introduction.pdf), then it is NOT a good candidate for a HAL module
maybe the things steve wants from HAL could be done in EMC
make EMC modular too.. to some extent
at least error-checking and reporting & such
maybe yes Alex. But the idears of Steve are imortand also
I agree completely that EMC's error reporting could be improved
I think HAL is ok the way it is now...
a HARDWARE abstraction layer
and we could keep it that way
there is a lot. I don't think that we have to do that now, but we have to think what we maybe need in some years. Because that we not make chances that will make things impossible in some years
I also think HAL is a very good thing.
We don't have to kill it by implementing things that don't have to be there
jmk: is the HAL GPL?
ok back to dual axis:
some key parts of it are LGPL, the intent is to allow non-GPL modules to be written and used in a system with GPL modules
how do i have to do it
jmk: very good
Imperator_: two choices: do it in EMC (control.c to be precise) or do it in HAL
to do it in EMC, take fig 3.1 from EMC2_Code_Notes, and draw a new one that supports dual axis
then figure out how to tell the motion controller at insmod time which axis are dual
(so they can export the extra HAL pins)
ok i will check that and i hope to make a precise suggestion next week
and add new fields to the EMC shmem structs (emcmot_Status, etc) to handle things like offset limits, etc
add new NML messages to set those fields
how are you drawing that pictures John
add new GUI code to display important stuff
etc, etc, etc
I used something called EasyCad
where did i find that NML stuff ?
(similar to AutoCad)
don't know anything (much) about NML
to put it simply - I personally _cannot_ implement dual axis the "EMC" way
I could do it in a HAL module, but it would lack some of the features that we have discussed today, like limits on the amount of adjustment
jmk: good news...
If it was done the EMC way, probably 20 files would need to be touched
the HAL way, 1 (probably)
but the HAL way would have some limitations
configure.in and Makefile.inc.in need to be added to trunk, and ./configure needs to be modified
enough work for the winter
so we have to decide what is more important - simplicity or features
that's all that's needed to get autoconf stuff working
so you are describing something of a "manual merge"?
as a machine builder my opinion is that it must have the limits-where ever they come from
no... I just did a manual test to see what needs to be merged
there are more ways of merging
complete merging (whole branch)- don't want that because of other stuff (make install & such)
single merging (only some files9
whatever works, I guess
at this point, I have so little time to work on EMC, I don't know whether I'm coming or going
I just hope we can avoid even more branches to keep track of
I'd like to see older branches either officially abandoned, or merged back into the trunk, and _then_ make new branches for further work
just my personal opinion, as someone who can barely keep up
well right now I see following branches:
auto_configure_0_2 (this one was created by mistake... don't know how to delete it)
these are for EMC2
jmk is dead - I don't even remember what that was
lathefork is active
ioctl is dead, I think
not sure what is in HAL_no_logging
you did say some time ago you'll contact sf guys to remove some unused studd
or is my memory playing tricks on me?
that was unused top level modules (like emc, rcslib, emc2, etc)
I don't think old branches ever really go away, they just sit there
yeah I know... but those are still there
* jmkasunich looks
I used the CVS repository browser on SF
emc, rcslib, emc2, and documents, are the four "active" top level modules
emc_HAL and emc2-auto should have been removed - let me check a few things
strange: Paul requested that they do it over a month ago, and they replied that they did: https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1046949&group_id=1
Alex you are talking about branches what's that exactly ???
don't know anything about that
Imperator_: the whole code is in CVS
if anyone wants to develop something that could be needed when it's done (e.g. 2.6 kernel support)
it is usefull to create a branch
how can i do that ?
a way to develop in a separate dir
because that is maybe good for the dual axis stuff
and when it's done you can merge the changes back to the HEAD (or trunk)
well... you should read the CVS book ;)
oh, the big one
but to keep it simple:
but that has nothing to do with real folders in the CVS
jep say me the command
step 1. tag the branch (cvs tag -b new_branch_name)
step 2. check out the branch (cvs checkout -r new_branch_name) to another dir
step 3. modify the source in the new dir and commit
step 4. merge changes back to main branch (that's more complicated than a single command)
but.. you need to ask around before doing things like this ;)
ok i will do that with the dual axis code
I'd ask paul_c first, or any other board-member
if you are taking the "change EMC", by all means do it in a branch (wouldn't hurt to ask Paul too)
branches can easyly removed if they are bad
with support from SF
but if they are not merged they don't hurt anybody
I'm happy to have some absolute encoders, because they get expensive at ebay
[05:51:09] <Imperator_> http://cgi.ebay.de/ws/eBayISAPI.dll?ViewItem&rd=1&item=3852431815
401 EUR was my price
can get expensive...I design them
don't think 100 EUR/piece is expensive
i have four of them here but the one with the smal profile, i get them for 50 EUR :-)
no you got a great deal
i know they cost over 1000EUR new
how many bits?
that depends on the lenght
they have a resolution of 0,1 microm
what is the smallest distance increment
and they are absolute, with no homing requiered?
you get the serial signals and the incremental analog signals. The analog signals have a increment of 0,02 mm and my Heidenhain card can devide the analog signals by 4096
jmk: I just found out that ViewCVS is from the backup CVS server
yeah, but that should only lag behind a max of 24 hours, not 30 days
hmm 20 bits if 1 meter
floh: are you the one who is fighting with the Siemens card
les: that encoders are vry nice. They have a plastic sheed on it to fix the reading head. So you can move the head only with some force. But if you lay them down on your desk and stamp on the floor you can see the values counting
floh: is it working now
* alex_joni tried a checkout on emc2-auto and it's still there
will get pretty high data rates moving at speed
who was taking care of the IRC-logs on linuxcnc.org ?
you get only the position when you ask the encoder
today I installed EMC2, but I always get an errror: motion.c:173: warning: implicit declaration of function `vsnprintf'. Then I commented out this line in motion.c and now its working on my BDI 2.18. Tomorrow I will see more
hm i had this error also that is a overflow of the driver, but i think that was solved
oh sorry that was an other error floh
vsnprintf should be defined in stdarg.h
or there is a other mode then it sends as fast as it can position information independend of the speed
btw, warning: is not really an error ;)
it was an error, because i couldnt start emc.run (motion.o defect) or so
I see...a far cry from the automotive gray code stuff I did
gray code is cool.. hard to read thou...
alex_joni: re the IRC logs, that was me
need a hand?
they seem to be stuck around 26 sept.
I have logs for each week since then (except today - forgot to start logger)
floh: here it runs fine. I have compiled a fresh cvs copy half an hour before
I do have for the last month
but they need edited (removal of email addys and other confidential info at a minimum - I also removed chitter-chatter that was irrelevant, and misc junk from the IRC servers
but timezone is somehow stupid... ;)
can you send me some logs to filter out?
* Imperator_ is prepaing something to eat
* alex_joni awaits e-mail
do you have an account on LinuxCNC.org?
Imperator_ is now known as Imperator_away
Does alex_joni want an account?
need it to post the IRC logs
floh: here it runs fine. I have compiled a fresh cvs copy half an hour before
good, I'll download the actual cvs version
floh: what version were you using?
I downoaded it 2-3 weeks ago
alex_joni: october logs on the way
03jmkasunich * 10emc2/src/hal/ (hal_lib.c hal_priv.h utils/halcmd.c): added some pointer range checks as recommended by Paul Fox. Thanks Paul.
jmk: I'll modify them
while you're editing, jot down the subjects that were discussed - then you can add them to the brief synopsis in the table
(just FTP linuxcnc.org/EMC_news_history/IRC-logs/index.html, copy the top <tr>....</tr> block, and edit it)
then FTP index.html and the new logs back to linuxcnc.org
and lest I forget - THANK YOU! (I've been feeling very guilty because I've fallen behind)
don't mention it ;)
but I'm still waiting on the logs
hmmmm... that makes two messages that seem to be hung (I posted to the users list a few minutes ago, and that hasn't appeared either)
John, did you get the two e-mail that I sent?
maybe my ISP is being slow... give it some time (maybe an hour) and then mail me if it still isn't there
SteveStallings: yes, got them
incoming mail seems to be OK (I got Paul's recent post to emcusers, and my own commit message)
I'm gonna go away for a while - I have some parts I need to mill for a paying customer
jmk: got the mail
we are blasting away with emc paying work...but not today
Imperator_away is now known as Imperator_
alex_joni: are you next week on that automatisation fair in N�rnberg
jep les :-)
don't think so Martin
are you visiting some fairs in germany ?
if I happen to be in germany at that time ;)
probably I'll go to the welding fair in Essen
I did not go to the chicago imts this year
that is our biggest
if you are here Alex, how are traveling ?
car usually.. why?
woodworking les ?
no machine tools
the big woodworking fair is IWF
hundreds of cnc routers running
with the car you are driving not so far away from me through south germany i think
We represent actually two companies from germany
if you are somewhere around here and if you have time we can drink a beer together
one is in Markdorf (near Friedrichshafen..) that's nearer to you
thanks for the invitation... same way around
Time for me to run.... later....
don't have some projects with people in rumenia at the moment :-(
jmk: still around?
I am in and out while doing laundry....
also fixing that alesis audio amp...it's a bad relay
it actually works quite well as a test servo amp
* alex_joni is tweaking IRC logs
It will put out 13 amps at 110v...not bad for an audio amp
alex_joni: just came back for a minute... what's up?
* jmkasunich goes away again
hmm, thats what, 1500 watt DC?
ok, time to reboot into 'doze :(
jmk_when_back: I was wondering about timestamps (some irc logs have them some don't)
* alex_joni leaves for a while
Ok chiao all
was a good discussion today
anybody still around?
well... guess not...
* alex_joni is going to sleep...
jmk: I added 2004-10-03 to the IRC-logs page. If it's not ok drop me an e-mail...
I'll start on the others too these days
oh.. you're still around
* jmkasunich takes a look
was paul around?
I just got back now - then going back out again
looks good to me
ok.. I'll modify the rest and put those up there too... when I'll get to it ;)
re: timestamps - your call as to whether to keep them or delete them
I hope in a day or two
well... the first file had no timestamps- that's why I asked
(after all it's been a month already)
the previous one had
re: month - that's why I wanna hurry ;)
depends on who's logger captured it, mine doesn't stamp, but I got some of those from paul, and his does timestamps
the webpage should really give people the impression that things are under active development
which is the case
I really appreciate your help on those - when I started them, I didn't realize how my life would get busy
I'm down to one night of emc a week (none this week)
when I find a project that hasn't been updated for a year or so... I consider it twice if it's worth
well... I'm sure everyone gets to a point when we have other stuff to do...
that's why it's better if there are a lot ofpeople in volved
anyways.. if you ever need logs... my logger should be around here
not sure what timezone he thinks he's on ;)
well... I'll go catch some sleep
time to make more brass chips here
paul wasn't around, was he?
never saw him
my client stayed on even while I wasn't here
ok... I'll bug him this week ;)
guess he's kinda tired of me... :-)
* alex_joni plans to merge autoconf stuff to the trunk this week
good to hear that
but I want paul's opinion first
* jmkasunich need to get busy
* asdfqwega opens the doors to let the smoke out
That might sound like something bad happened, but it's actually just the opposite
My new laser is hard at work!
Now I just need some damn ventilation...
(use the laser to make holes in the wall? Hmm...)
Large hammer ?
"When you have a hammer, all the world looks like a nail"...?
Well, I have a LASER :)
Well, dang...it's working great, but I'm freezing my fiddly bits off
Does it cut through brick ?
Well, this is only 10W...it'd take a LONG time
This is really great...This laser is certified 10W...and it's working like it's 3-4 times what I had with the old laser
That's the last time I buy an old laser off of eBay ;)
Burning the midnight oil, paul_c/
nope - ready to pack up and go to bed.
03jmelson * 10emc/src/emcmot/Makefile: add rule for ppmc_pwm.c that had been missing
03jmelson * 10emc/src/emcmot/ppmc_internal.c: remove hardware-specific setup for PCI parallel port to EPP mode
good morning paul
* alex_joni was waiting for paul_C
got 5 mins for me?
can give you 10 ;}
ok.. I'll try to be brief
1. I commited stuff on autoconf_install_0_1 (I'm pretty happy with it)
hope some day you'll have time to check it out...
2. regarding autoconf merging back to trunk
I talked to jmk yesterday who suggested we should do that.
2.1. do you think autoconf is there yet? or does it need more work (if yes, what would that be)
autoconf or autoconf_install ?
2.2. I think I need some advice from you (still haven't read the Red book :( )
simply the configure.in, ./configure and the Makefile.inc.in
no stuff from make install
we should keep that in a branch (or two) for now
corect me if I'm wrong: when merging there are 2 possibilities
poss.1. merge the whole branch (not really ok in this case)
poss.2. merge only some files
3. I'm updating the IRC-Logs page
so if anything's not right there... bug me
just checking autoconf now..
It is failing on GTK here...
do you have GTK?
and why is the gcc test being run twice ?
well... that was zwisk adition
it's pretty a circular dependency
you can check for the kernel_ver by compiling a program
hmmm... you might have a point there
So move the RT CC test up...
I'll do that in a bit
I thought from the way zwisk put it that the Kernelver is needed for checking the compiler used
but it's not
localedir is set wrong