John Kasunich wrote:
> Jon Elson wrote:
> 
>>Jon Elson wrote:
>>
>>>>Gentlemen,
>>>>
>>>>>  The screenshots are on imagebin.org under stustev. They are
>>>>>representative of the previously presented scenario of homing
>>>>>attempts. aligned, .030, and .060.
>>
>>I do homing with both velocities in the same direction, and I 
>>might have seen it glitch once, but it might have been a sticky 
>>indicator.  I then changed it so it did the final search for the 
>>index pulse in the opposite direction, and the home position is 
>>set to +0.1, just like Stuart's file, and I got very erratic 
>>home positions. 
> 
> 
> To simplify troubleshooting, make HOME and HOME_OFFSET the same.
> That will tell EMC to go exactly to the index pulse position after
> homing.  Eliminating the post-homing move will make it easier to
> see what is going on.
> 
Will do -  but I think it may work fine that way.
> Then confirm once again that you still have the problem.
> 
> Next, figure out and mark exactly where the index pulses are on your
> machine.  Turn the screw slowly by hand while observing the index
> pulse signal either thru HAL or better yet with a real scope or meter.
> When you get an index pulse, mark the table.  Keep turning and mark it
> again at the next one.  I assume on a Bridgeport that the marks will
> be 0.200 apart, but that might not be true if you have belts or such
> between motor and screw, with something other than a 1:1 ratio.
> 
it is .200" between marks.  I am using a dial indicator to 
detect the exact position.
> Once you have marked the table positions for several index pulses
> in the vicinity of your home switch, try homing and see where it
> stops compared to the marks.
> 
I was seeing it stopping in discrete quanta of .020", ie. 0.000, 
0.020, 0.040" etc.
> 
> I would be shocked and astonished if EMC is doing anything besides
> homing to the position that it reads on the falling edge of 
> "index-enable".  In your shoes, I would attempt to arrange for a
> couple of LEDs, one driven (thru a digital output) from index-enable,
> and another driven directly by the index pulse.  Hold both LEDs close
> to the marks on the table, and home with a very slow latch velocity.
> LATCH_VEL = O.01 would mean 20 seconds to travel 0.200", so it would
> be easy to see if index-enable is switching off between index marks.
> 
I would think HALscope would be better at this.  I did not 
notice anything anomalous while watching the halscope displays 
of encoder-position, encoder-index-enable and index.  The 
picture looked about the same whether it homed to 0 or to one of 
those alternate positions.
> 
> 
> Jeff has already explained that.  Using three arguments for a setp
> command has always been wrong, but HAL used to silently ignore the
> error (and drop the trailing argument).  Now it calls your attention
> to the error so you can fix it.  Note that HAL error messages are
> usually preceded by HAL:<linenumber>, so it's not that hard to trace
> them down.  The ini file substitution means that mistakes might not
> be in the HAL file itself.
> 
Yup, I just never thought about where and how the values came 
from the ini file.  I looked at the ppmc_motion.hal file and 
didn't see anything wrong THERE!
> 
>>Anyway, I can confirm that at least when homing in the plus 
>>direction, and then searching for the index pulse in the - 
>>direction, this error does show up with the late April version 
>>of the driver.  I am hoping that the latest driver will fix this
>>problem.
> 
> 
> WHAT!?  Late April?  Why the hell are you reporting a "bug" when
> you aren't using the latest version of the driver?
> 
Ahh, because the only machine I have here with PPMC hardware is 
my Bridgeport, and I don't keep it totally up to date due to 
possible surprises.  I TRIED to update it before reporting 
anything, but ran into the problem above.
> I rewrote the indexing code BECAUSE IT WAS BUGGY! and committed
> my changes on May 1st.
OK, I don't know exactly what rev Stuart Stevenson is at.
   Those changes were backported to the 2.1
> branch and released as version 2.1.5.  You fixed an index polarity
> issue on May 7, that was backported and released as 2.1.6.  Since
> then you made additional changes in June at the CNC workshop.  Those
> changes were backported, and will be released as part of 2.1.7.
> 
> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/hal_ppmc.c?graph=1
> 
> OF COURSE there are bugs in the April version!
> 
> To be very blunt: reporting a "bug" when you are using an old version
> of the driver is going to get you ignored or flamed.  Users will get
> some slack, but Jon, you should know better, you are the one who made
> the June fixes.  Test the LATEST driver.  If you find problems there,
> report them and I'll try to help.  I don't want to hear about bugs that
> either you or I may have already fixed.
Sorry - it wouldn't have happened if I hadn't hit the problem 
with the setp command.  I got on irc and couldn't raise anybody,
either, although there were a number of member listed as being 
on the channel. Only then did I send a message.
> 
> On a more positive note:  the upcoming 2.1.7 contains indexing fixes
> for the Vital systems Motenc card, the Mesa 5i20, and the PPMC card.
> The motenc was tested at the CNC workshop, and I've tested the 5i20 at
> home.  Let's try to get the PPMC fixed and tested, so that 2.1.7 can be
> the final 2.1 release.  There's nothing more annoying than doing a
> "final" release and then having someone commit a significant bugfix
> a day or two later.
I'm hoping it will be.  I don't believe there are any more 
gremlins in the PPMC driver.  I will try to debug the homing 
with the latest release now and make sure all the possible 
combinations of homing sequences work repeatably.

Jon

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Emc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to