On 4/7/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Send Emc-users mailing list submissions to
> emc-users@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/emc-users
> or, via email, send a message with subject or body 'help' to
> [EMAIL PROTECTED]
>
> You can reach the person managing the list at
> [EMAIL PROTECTED]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Emc-users digest..."
>
>
> Today's Topics:
>
> 1. Re: M5i20 configuration (John Kasunich)
> 2. Re: homing (Stuart Stevenson)
> 3. Re: homing (John Kasunich)
> 4. Re: homing (Jon Elson)
> 5. Re: homing (John Kasunich)
> 6. Re: homing (John Kasunich)
> 7. Re: Hardware Feedrate Override Control (Kasparov, Aram)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 06 Apr 2007 14:02:38 -0400
> From: John Kasunich <[EMAIL PROTECTED]>
> Subject: Re: [Emc-users] M5i20 configuration
> To: "Enhanced Machine Controller (EMC)"
> <emc-users@lists.sourceforge.net>
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>
> Here is a wiki page where I started to write down step-by-step the
> process I would use for setting up a servo system.
>
> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Tuning_EMC2/HAL_PID_Loops
>
> I strongly suggest that you UNDERSTAND and follow at least the first
> four steps.
>
> Someday I should finish that page... but on the other hand it could
> be dangerous. I strongly believe that when working with a servo system,
> you should understand exactly what you are doing and why. Simply
> following a step-by-step recipe is NOT good if you don't really know
> what you are doing. That leads to crashed machines or worse. The key
> to success is understanding how the thing is supposed to work, so when
> some step doesn't give the expected results you say "hmm, that doesn't
> seem right, better look into it" instead of just moving on to the next step.
>
> Regards,
>
> John Kasunich
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 6 Apr 2007 13:12:59 -0500
> From: "Stuart Stevenson" <[EMAIL PROTECTED]>
> Subject: Re: [Emc-users] homing
> To: Emc-users@lists.sourceforge.net
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Gentlemen,
> I am using a ppmc encoder board.
>
> The parameters in my ini file look like this
> HOME = 0
> HOME_OFFSET = 0.0
> HOME_SEARCH_VEL = 0.4
> HOME_LATCH_VEL = -0.01
> HOME_USE_INDEX = YES
> HOME_IGNORE_LIMITS = NO
>
> I am using the third sketch from the html page you referenced.
>
> I can allow the axis to move to the home switch or I can actuate
> the switch by hand with the axis away from the switch. I get the same
> results either way it just does it in different spots in the travel of
> the ball screw.
> When I start the machine the axis postions are zero. When I home
> an axis the machine moves in the positive direction until the switch
> is activated. When the switch is acitvated the axis reverses direction
> and moves very slowly until it reaches the index pulse. The machine
> then moves to the startup position. The control does not set the axis
> position to zero when it sees the index pulse therefore it uses the
> current axis zero position and moves to it. It does turn the axis
> home signal on.
> It has homed correctly on an axis. I then moved the axis and
> restarted the machine and the home cycle did not finish correct. I
> changed no parameters between the home cycles.
>
> dmesg gives no error reports. I looked at it prior to the homing
> cycle and after the homing cycle. There are no messages generated by
> the homing cycle. The last line in the dmesg report was for a thread
> created. If I home the machine a second time I get as follows in the
> dmesg report
>
> ERROR: end of move in home state 5
>
> thanks
> Stuart
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 06 Apr 2007 15:14:18 -0400
> From: John Kasunich <[EMAIL PROTECTED]>
> Subject: Re: [Emc-users] homing
> To: "Enhanced Machine Controller (EMC)"
> <emc-users@lists.sourceforge.net>
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Stuart Stevenson wrote:
> > Gentlemen,
> > I am using a ppmc encoder board.
> >
> > The parameters in my ini file look like this
> > HOME = 0
> > HOME_OFFSET = 0.0
> > HOME_SEARCH_VEL = 0.4
> > HOME_LATCH_VEL = -0.01
> > HOME_USE_INDEX = YES
> > HOME_IGNORE_LIMITS = NO
>
> OK. This means the home switch is near the positive end of travel, and
> you want "machine coordinate 0.000" to be the located at the index pulse
> just below the switch. Now I understand what you are trying to do.
>
> I wonder if that is actually what you want though. With the switch at
> the positive end of travel, and HOME_OFFSET set to zero, the positive
> end of the table will be zero, and coordinates for the rest of the table
> will be negative numbers. That doesn't matter as far as homing goes,
> just seems kind of odd.
The final (as in released to production) configuration will probably
be different than the testing configuration. The Z axis will surely be
homed at the top limit of travel. I want all Z work piece offsets to
be the same sign. Sign reversal of the offset in the work piece offset
on the X and Y axes is not usually as dangerous as the Z axis. If
someone reverses the sign on the Z axis and the Z axis plunges down
farther than expected the results are never good. If the X (and/or Y)
workpiece offset is near the machine home (eg X- .01) then a sign
reversal to X.01 will result in a scrap part and may be difficult to
find. I believe all axis machine home positions should be at or very
near the end of travel.
>
> > I am using the third sketch from the html page you referenced.
>
> Yes, although without the final move... in fact, there might be a VERY
> short final move in the positive direction, because even moving slowly
> the machine will overshoot the index pulse by a tiny bit. Even if its
> only 0.001" or so - it will (should) move back to exactly 0.0000.
>
> > I can allow the axis to move to the home switch or I can actuate
> > the switch by hand with the axis away from the switch. I get the same
> > results either way it just does it in different spots in the travel of
> > the ball screw.
> > When I start the machine the axis postions are zero. When I home
> > an axis the machine moves in the positive direction until the switch
> > is activated. When the switch is acitvated the axis reverses direction
> > and moves very slowly until it reaches the index pulse.
>
> So far so good.
>
> > The machine
> > then moves to the startup position. The control does not set the axis
> > position to zero when it sees the index pulse therefore it uses the
> > current axis zero position and moves to it. It does turn the axis
> > home signal on.
>
> Something screwy there. You may have found a bug, or something may be
> misconfigured. I don't have a servo machine here, but I might be able
> to set up a "machine" using a simulated encoder. Jon Elson (the PPMC
> guy) probably has more experience homing to index pulses than I do.
> I did just review the homing code rather carefully, and I can't see
> anything wrong. However, if the ppmc driver isn't resetting its output
> to zero when it sees the index pulse, that might cause the symptoms you
> are seeing.
>
> You might want to use halscope to look at the index enable signal and
> the position feedback from the encoder to EMC. Trigger the scope on the
> falling edge of index enable, and verify that position either is or
> becomes zero at that moment. If it doesn't, its probably a driver bug.
>
> > It has homed correctly on an axis.
>
> Huh? You just said it didn't set the position to zero and moved back to
> the old zero point instead. That is NOT "homed correctly"!
>
> This is yet another case of not speaking precisely. The way I read
> this, you described the homing process (quite clearly, thank you), and
> then went on to say "at the end of the process I described in the
> preceding paragraph, the machine has homed correctly." But the process
> you described in the preceding paragraph is not correct!
>
> Of course, maybe what you meant is "There have been a few OTHER TIMES
> when it didn't do what I just described, but instead homed correctly."
This sentence describes it correctly. During the last week I have
homed the machine many times. Three times the home cycle worked in the
manner I believe is correct. Two times the Z axis homed at the index
pulse and one time the Y axis homed at the index pulse. Each time the
remaining axes homed incorrect (at the zero position of the machine
start up position).
>
> There is a HUGE difference between those two statements, and I have no
> way of knowing which one is accurate. If we were talking face to face,
> I could easily ask you to clarify. On a mailing list, it takes forever
> to get things straight. SPEAK PRECISELY! Every time we have to go back
> and forth clarifying things it wastes hours (or a day). I assume you
> want to get this machine running before we both get old.
>
> > I then moved the axis and
> > restarted the machine and the home cycle did not finish correct. I
> > changed no parameters between the home cycles.
>
> I have no idea what, if any, conclusions I can draw from that, because I
> don't know whether it was truly homed correctly before you moved it.
>
> > dmesg gives no error reports.
>
> ...for the first homing cycle.
>
> > I looked at it prior to the homing
> > cycle and after the homing cycle. There are no messages generated by
> > the homing cycle. The last line in the dmesg report was for a thread
> > created. If I home the machine a second time I get as follows in the
> > dmesg report
> >
> > ERROR: end of move in home state 5
>
> State 5 is "INITIAL_SEARCH_WAIT". That state means it is moving at
> SEARCH_VEL and waiting to hit the switch. The message means it got to
> the end of the commanded move without hitting the switch. How far does
> it move before it stops with this message? It should move twice the
> distance between the soft limits before it stops - if your soft limits
> are set right that means it should hit a limit (or hard stop) first.
> Make sure your soft limit settings make sense - if your table as 30" of
> travel, the soft limit settings in the ini file should be close to that
> distance apart. For example, -14.9 and +14.9, or -29.8 and +0.1. The
> latter example makes more sense in your situation, since you are using
> zero as the switch location, which is probably near the positive end of
> travel.
It is impossible to set the soft limits correct until the machine is
homed. I set the soft limits very small so after homing I could move
the machine to the soft limits without hitting the end of travel. In
my mind this would tell me if the machine homed. This would explain
the error as my Z axis soft limits were set at -1.0 and 1.0. I was
using a button connected to the home switch feed back to I could
trigger the home sequence whenever I wanted. When I had the latch
velocity higher the machine would sometimes act as if it didn't see
the index pulse. The machine would move at the search velocity,
reverse direction when I pushed the button and then move at the latch
velocity until it reached the end of travel. This didn't happen every
time I initiated the home sequence. I thought that since I was pushing
the home switch button at arbitrary positions the index pulse was
probably too close to the button push position and didn't have time to
pick it up properly. Since I set the latch velocity lower the machine
has acted as if it has seen the index pulse properly. The result of
the rest of the homing cycle remain unchanged. The axes (usually) move
to the zero of the machine start up position.
With the latch velocity set as low as I have it is it possible the
home sequence times out before the index pulse is found? The axes move
very slow (several seconds to find the index pulse).
These symptoms suggest to me the hardware feedback (the switches
and ppmc boards) is working correct. Since the machine will sometimes
act correct I believe the software is correct. It seems my
configuration is incorrect but I fail to see where.
>
> By the way, if you (or anyone) wants to understand the homing states,
> they are listed in
> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/motion/motion.h?rev=1.76
> about half way down. Search for "HOME_IDLE". The code which actually
> does the homing is at:
> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/motion/control.c?rev=1.107
> also about half way down. Search for the second instance of "homing
> state machine". Even if you don't understand C code, there is a comment
> block at the beginning of each state that says what is happening in that
> state. There is a HAL parameter for each axis, "axis.N.home-state",
> that shows the current state value - it can be observed using halmeter
> or halscope to see where in the homing sequence you are.
I will look at these pages. I am going to play with the latching velocity.
I have tried the homing sequence in the binary version installed
with the script, with the current version compiled (run-in-place) and
with the head version (run-in-place). All exhibit the same.
I read and reread my spelling and logic. I (hopefully) will learn
to express myself clearly to others. Every time, it looks very clear
to me but I have the (dis)advantage of knowing how to interpret what I
have written.
I too am frustrated by the time delay of troubleshooting in this
manner BUT this is not my only job. I, as you, have other things to do
that occupy my time. I, we, will get there. I am happy to be making
consistant progress.
Thanks for you patience, help and insight.
Stuart
>
> Regards,
>
> John Kasunich
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 06 Apr 2007 20:42:24 -0500
> From: Jon Elson <[EMAIL PROTECTED]>
> Subject: Re: [Emc-users] homing
> To: "Enhanced Machine Controller (EMC)"
> <emc-users@lists.sourceforge.net>
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> John Kasunich wrote:
> > Something screwy there. You may have found a bug, or something may be
> > misconfigured. I don't have a servo machine here, but I might be able
> > to set up a "machine" using a simulated encoder. Jon Elson (the PPMC
> > guy) probably has more experience homing to index pulses than I do.
> > I did just review the homing code rather carefully, and I can't see
> > anything wrong. However, if the ppmc driver isn't resetting its output
> > to zero when it sees the index pulse, that might cause the symptoms you
> > are seeing.
> >
> > You might want to use halscope to look at the index enable signal and
> > the position feedback from the encoder to EMC. Trigger the scope on the
> > falling edge of index enable, and verify that position either is or
> > becomes zero at that moment. If it doesn't, its probably a driver bug.
> >
> I got all this debugged around Jan 8, 2007. I have sent Stuart
> a set of updated EPROMS for his encoder boards.
>
> At the end of the debugging process, I observed some behavior
> that may have been the same as Stuart is describing. But, I was
> a lot faster to hit e-stop, so I did not wait to see whether EMC
> was going to stop somewhere within the machine's travel limits
> or not. The final problem turned out to be the polarity of the
> home switches was backwards. This was evidenced by the machine
> moving in a direction opposite to the sign of HOME_SEARCH_VEL.
> Well, instead of understanding why it moved the wrong way, I
> just swapped the sign of that parameter. It seemed to home kind
> of like I expected, but would occasionally (like 50% of the
> time) take off at a fast clip. Reversing the sensing of the
> switch's polarity fixed the problem, and made the home approach
> consistent with the HOME_SEARCH_VEL parameter.
>
> I have homed a number of times since then, and it has never
> taken off rapidly since.
>
> Does anyone know if there have been any changes to any code that
> might affect the homing process since 1/8/07? I don't believe
> my Bridgeport computer has been updated since then, and it is
> the only one with home switches or encoder index signals.
>
> Jon
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 06 Apr 2007 22:12:08 -0400
> From: John Kasunich <[EMAIL PROTECTED]>
> Subject: Re: [Emc-users] homing
> To: "Enhanced Machine Controller (EMC)"
> <emc-users@lists.sourceforge.net>
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Jon Elson wrote:
> > John Kasunich wrote:
> >>
> >> You might want to use halscope to look at the index enable signal and
> >> the position feedback from the encoder to EMC. Trigger the scope on the
> >> falling edge of index enable, and verify that position either is or
> >> becomes zero at that moment. If it doesn't, its probably a driver bug.
> >>
> > I got all this debugged around Jan 8, 2007. I have sent Stuart
> > a set of updated EPROMS for his encoder boards.
> >
> > At the end of the debugging process, I observed some behavior
> > that may have been the same as Stuart is describing. But, I was
> > a lot faster to hit e-stop, so I did not wait to see whether EMC
> > was going to stop somewhere within the machine's travel limits
> > or not. The final problem turned out to be the polarity of the
> > home switches was backwards. This was evidenced by the machine
> > moving in a direction opposite to the sign of HOME_SEARCH_VEL.
>
> Stuart has posted his ini params, SEARCH_VEL is position. He has also
> stated that his machine moves in the positive direction when he tells it
> to home. So it would seem that he has his switches right.
>
> > Well, instead of understanding why it moved the wrong way, I
> > just swapped the sign of that parameter. It seemed to home kind
> > of like I expected, but would occasionally (like 50% of the
> > time) take off at a fast clip. Reversing the sensing of the
> > switch's polarity fixed the problem, and made the home approach
> > consistent with the HOME_SEARCH_VEL parameter.
> >
> > I have homed a number of times since then, and it has never
> > taken off rapidly since.
> >
> > Does anyone know if there have been any changes to any code that
> > might affect the homing process since 1/8/07? I don't believe
> > my Bridgeport computer has been updated since then, and it is
> > the only one with home switches or encoder index signals.
>
> The homing code is in src/emc/motion/control.c. I certainly hope that
> you as a board member have seen and know how to use the CVS browser at
> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/
>
> IMO, the revision graphs are the greatest thing since sliced bread:
> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/motion/control.c?graph=1
>
> You can see when the 2.1 branch was made, and when every change was
> made. along with part of the commit message. Click on a box and you see
> that version of the file. Click on the link between two boxes and you
> see the diff between those two versions.
>
> You can also see any version of any file completely annotated to show
> which lines of code were changed at what revision:
> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/emc/motion/control.c?annotate=1.107
> The main homing state machine runs from line 1282 to 1736. The most
> recent change in that range is line 1735, but that was just a comment
> change. The next most recent is line 1724, which _would_ affect index
> homing. Clicking on the "1.85" link there tells me that change was made
> on January 3.
>
> Regards,
>
> John Kasunich
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 06 Apr 2007 22:14:20 -0400
> From: John Kasunich <[EMAIL PROTECTED]>
> Subject: Re: [Emc-users] homing
> To: "Enhanced Machine Controller (EMC)"
> <emc-users@lists.sourceforge.net>
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> John Kasunich wrote:
> > Jon Elson wrote:
> >> This was evidenced by the machine
> >> moving in a direction opposite to the sign of HOME_SEARCH_VEL.
> >
> > Stuart has posted his ini params, SEARCH_VEL is position.
>
> POSITIVE, not position.... dammit, I proofread before I hit send and I
> still find mistakes when I get the message back a minute later.
>
> Regards,
>
> John Kasunich
>
>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 6 Apr 2007 23:23:13 -0700
> From: "Kasparov, Aram" <[EMAIL PROTECTED]>
> Subject: Re: [Emc-users] Hardware Feedrate Override Control
> To: "Enhanced Machine Controller \(EMC\)"
> <emc-users@lists.sourceforge.net>
> Message-ID:
> <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello Anders.
>
>
>
> I have questions about 6 position rotary switch and 4 position rotary switch.
>
> Are they all one-pole type of switches or they need to be multi poles?
>
> About 4 Pushbuttons switches, are they all momentary type switches (normally
> open)?
>
> How many this electronics devises " I first decode the differential signals
> to single-ended ones using a DS3486
> <http://www.national.com/pf/DS/DS3486.html> ." do I need?
>
> How many this type do I need "6-pos switch is encoded with an SN74HC148
> <http://www.alldatasheet.com/datasheet-pdf/pdf/27887/TI/SN74HC148.html> into
> a 3-bit value." do I need?
>
> Can you also send some diagram of soldering/connecting DS3486 and SN74HC148
> into the circuit?
>
> Thank you,
>
> Aram K.
>
>
>
>
> ________________________________
>
> From: [EMAIL PROTECTED] on behalf of Anders Wallin
> Sent: Sat 2/24/2007 8:38 AM
> To: Enhanced Machine Controller (EMC)
> Subject: Re: [Emc-users] Hardware Feedrate Override Control
>
>
>
> > Dear All,
> > I have the current EMC2 2.1.0. and a Mesa 5i20 board. How
> > can I implement a
> > hardware FRO control? And while I'm asking questions, can I use the 4th
> > encoder inputs
> > for a Handwheel or MPG?
>
> Hi David,
>
> I documented some of my jogwheel hardware and HAL code on my blog
> http://www.anderswallin.net/2006/11/jogging-emc2/
>
> adjusting feed override requires halui, but it's quite easy to do.
>
> If you have the 5i20 with the 'old' firmware then the secondary hardware
> encoders are broken (pinouts overlap), but with an MPG there's really no
> reason to use a hardware encoder counter, the HAL software encoder
> counter works just fine.
>
> Anders
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: not available
> Type: application/ms-tnef
> Size: 6471 bytes
> Desc: not available
>
> ------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> ------------------------------
>
> _______________________________________________
> Emc-users mailing list
> Emc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>
>
> End of Emc-users Digest, Vol 12, Issue 7
> ****************************************
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users
