# The never-ending saga of the Hurco that's "ready to make parts"



## ecdez

I've been chasing gremlins on this machine for two weeks and finally got to cut some metal today only to find a new gremlin.


I have some code to cut a circle 1.339" in diameter (inside cut). Here's the code.

%
N10 G70 G17
N20 G40 G90
N30 S1000
N40 T1 M06
N50 G00 Z0.5
N60 S1000 M03
N70 X1.8954 Y0.4149
N80 Z0.0197
N90 G01 Z-0.06 F4

(All is good until here)

N100 G02 X1.3992 Y1.4519 I-0.2226 J0.5307 F12.0
N110 X1.6702 Y1.5211 I0.2736 J-0.5064
N120 X1.8954 Y0.4149 I0.0026 J-0.5755

(Back to good again)

N130 G00 Z0.5
N140 M05
N150 M02
E




I have two problems with it and both are equally disturbing.

#1 - circle comes out to just over 3.75" in diameter.

#2 - circle has a small (1/2" x 1/2") pac-man mouth in the 2 o-clock position


Machine is a Hurco with Ultimax. Code comes up on the display after being dripped in and it's the same as shown above. Double checked that everything is in inches.  Generated the code twice with the same results.



Anyone have any ideas?


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Check to see if the circle center is in absolute or incremental mode, it looks like it's incremental.   Are you using a CAM program or are you generating this code on the machine.

EDIT:

I loaded your G-code in to my cam program, and yup, it has a PacMan mouth looking feature.  Check your drawing to make sure there are no hidden lines or artifacts hiding.  If you will post the hole center location from 0,0 and tool size, I'll run it through my CAM program and correct your G-code.


----------



## countryguy

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I am still new, but was checking to see if there was a Hurco emulator?    I did find this site for a GCode reference?  Not sure how old it is?  
http://www.stonemachinery.com/support/document-library/g-code-list-hurco-ultimax-max.html

I'll see if my dolphinCAM had this type in it's driver base?  But Jim's usually on the dime here.   Will check for Hurco tomorrow when I'm in the office.  

Good luck!  




ecdez said:


> I've been chasing gremlins on this machine for two weeks and finally got to cut some metal today only to find a new gremlin.
> 
> 
> I have some code to cut a circle 1.339" in diameter (inside cut). Here's the code.
> 
> %
> N10 G70 G17
> N20 G40 G90
> N30 S1000
> N40 T1 M06
> N50 G00 Z0.5
> N60 S1000 M03
> N70 X1.8954 Y0.4149
> N80 Z0.0197
> N90 G01 Z-0.06 F4
> 
> (All is good until here)
> 
> N100 G02 X1.3992 Y1.4519 I-0.2226 J0.5307 F12.0
> N110 X1.6702 Y1.5211 I0.2736 J-0.5064
> N120 X1.8954 Y0.4149 I0.0026 J-0.5755
> 
> (Back to good again)
> 
> N130 G00 Z0.5
> N140 M05
> N150 M02
> E
> 
> 
> 
> 
> I have two problems with it and both are equally disturbing.
> 
> #1 - circle comes out to just over 3.75" in diameter.
> 
> #2 - circle has a small (1/2" x 1/2") pac-man mouth in the 2 o-clock position
> 
> 
> Machine is a Hurco with Ultimax. Code comes up on the display after being dripped in and it's the same as shown above. Double checked that everything is in inches.  Generated the code twice with the same results.
> 
> 
> 
> Anyone have any ideas?


----------



## Marco Bernardini

*Re: Code issue, please help.  This stopped being fun a few days ago.*



ecdez said:


> N100 G02 X1.3992 Y1.4519 I-0.2226 J0.5307 F12.0
> N110 X1.6702 Y1.5211 I0.2736 J-0.5064
> N120 X1.8954 Y0.4149 I0.0026 J-0.5755
> 
> #1 - circle comes out to just over 3.75" in diameter.



The radius of the arc in N100 is *1.863*, thus the diameter is *3.726*.
Try here: http://www.calculatorsoup.com/calculators/geometry-plane/distance-two-points.php inserting your X,Y as (X1,Y1) and your I,J as (X2,Y2).


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Thanks for the responses guys!  

Little more info could have helped I suppose.  I'm using sheet cam on the advice of someone on another forum because it's really simple and does 2.5d without all the bells and whistles and it has a Hurco post.  I actually like CamBam alot but shyed away because I have to write my own post for that.  I really just want to make parts.

In sheet cam the part shows up exactly like it should and even runs through the simulator correctly.  Maybe the problem is in the post?






JimDawson said:


> Check to see if the circle center is in absolute or incremental mode, it looks like it's incremental.   Are you using a CAM program or are you generating this code on the machine.
> 
> EDIT:
> 
> I loaded your G-code in to my cam program, and yup, it has a PacMan mouth looking feature.  Check your drawing to make sure there are no hidden lines or artifacts hiding.  If you will post the hole center location from 0,0 and tool size, I'll run it through my CAM program and correct your G-code.




I appreciate the offer but I have about 20 files I need to generate so I need to figure this out on what I have so I can crank some stuff out.




countryguy said:


> I am still new, but was checking to see if there was a Hurco emulator?    I did find this site for a GCode reference?  Not sure how old it is?
> http://www.stonemachinery.com/support/document-library/g-code-list-hurco-ultimax-max.html
> 
> I'll see if my dolphinCAM had this type in it's driver base?  But Jim's usually on the dime here.   Will check for Hurco tomorrow when I'm in the office.
> 
> Good luck!



Thanks for the link.  I have the original manual for the machine but I'll compare the info in the link to make sure it all lines up.  The code portion of the manual was supplemental so I have no idea if it was original to the machine.




Marco Bernardini said:


> The radius of the arc in N100 is *1.863*, thus the diameter is *3.726*.
> Try here: http://www.calculatorsoup.com/calculators/geometry-plane/distance-two-points.php inserting your X,Y as (X1,Y1) and your I,J as (X2,Y2).



Thanks for that link too, I was looking for something like that.


I'll try a different post in sheet cam and see what happens.  I have a small machine that's running mach3 so I can possibly narrow the problem down to the post processor.


I downloaded the trial of BobCad and of course they contacted me to get me to buy the program.  Unfortunately the trial version does not allow certain processes so I can't even see if their Hurco post will work correctly either.  I have an email where their representative "guarantees" me it will work but once you spend the money what incentive do they have to make good on an email guarantee?  Their site also has instructions on how to adjust you post should you need to but if I'm going to adjust a post why not just stick with CamBam and figure it out.  

It's all really kind of frustrating but I am one step closer and happy to hear the problem is in the code and not some issue with the machine.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*



ecdez said:


> Thanks for the responses guys!
> 
> Little more info could have helped I suppose.  I'm using sheet cam on the advice of someone on another forum because it's really simple and does 2.5d without all the bells and whistles and it has a Hurco post.  I actually like CamBam alot but shyed away because I have to write my own post for that.  I really just want to make parts.
> 
> In sheet cam the part shows up exactly like it should and even runs through the simulator correctly.  Maybe the problem is in the post?



I think you are correct, I suggest the problem is in the sheet cam post.  I opened the g-code in CamBam and it is not a circle, and has a major dia of about 3.375.

Modifying a post processor is pretty easy in CamBam.  The Hurco post looks a lot like Fanuc.


----------



## Marco Bernardini

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I'm writing (just now!) a small "G-code to display" online converter based on this: https://github.com/fros1y/GView
The original creates a bunch of standalone files, while I'm trying to make a single online almost fancy image (yes, I'm lazy… as every hacker :biggrin.
I think it's useful to test a few lines of G-code to see if the geometry is correct, before to deal with other more arcane codes.
If it works I'll donate it to the forum…


----------



## sinebar

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Arc center vectors I and J are almost always measured as incremental distances from the start point of each arc to its center, so line 70 is the start point of the first arc. The X,Y coordinates in line 100 are the end point of the first arc and the start point for the second arc in line 110. Likewise, line 110 is the end of the second arc and the start of the third arc. Line 120 completes the circle. 
I drew this out in AutoCAD with incremental center distances and it does trace a circle 1.1515" in diameter. Assuming the use of a 3/16" end mill, it would cut a 1.339" circle. The OP didn't mention cutter diameter or G42 offset.

If the control system requires absolute coordinates, they would be somewhere around I1.6728, J0.9457.

I am curious as to why the circle was divided into three arcs. I know that some older controls don't allow circular interpolation in more than one quadrant per block, so if that were the case there should be at least four blocks of code to cut each quadrant of a full circle. In the case of this program, there are only three blocks with arc angles of approximately 174
, 28 and 158 degrees.

Another option, if the control system allows, would be to program a full circle something like this:

N10 G70 G17
N20 G40 G90
N30 S1000
N40 T1 M06
N50 G00 Z0.5
N60 S1000 M03
N70 X1.8954 Y0.4149    (START POINT)
N80 Z0.0197
N90 G01 Z-0.06 F4
N100 G02 X1.8954 Y0.4149 I-0.2226 J0.5307 F12.0    (FULL CIRCLE with incremental I and J arc center coordinates)
N130 G00 Z0.5
N140 M05
N150 M02
E

A proper program to cut an internal circle should start near the center of the circle and move radially outward and arc into and out of the the circular path. This makes a smoother blend at the start and end points of the cut.


I forgot to mention that I am only familiar with HAAS and LinuxCNC controls so I don't know anything about Hurco.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*



JimDawson said:


> Modifying a post processor is pretty easy in CamBam.  The Hurco post looks a lot like Fanuc.



It looked pretty easy, I just didn't want to have to do it.  Since I really like CamBam it may be worth the effort.  I've heard the Hurco is pretty similar to Fanuc.







sinebar said:


> I am curious as to why the circle was divided into three arcs. I know that some older controls don't allow circular interpolation in more than one quadrant per block, so if that were the case there should be at least four blocks of code to cut each quadrant of a full circle. In the case of this program, there are only three blocks with arc angles of approximately 178, 28 and 158 degrees.
> 
> Another option, if the control system allows, would to program a full circle something like this:
> 
> N10 G70 G17
> N20 G40 G90
> N30 S1000
> N40 T1 M06
> N50 G00 Z0.5
> N60 S1000 M03
> N70 X1.8954 Y0.4149    (START POINT)
> N80 Z0.0197
> N90 G01 Z-0.06 F4
> N100 G02 X1.8954 Y0.4149 I-0.2226 J0.5307 F12.0    (FULL CIRCLE with incremental I and J arc center coordinates)
> N130 G00 Z0.5
> N140 M05
> N150 M02
> E
> 
> A proper program to cut an internal circle should start near the center of the circle and move radially outward and arc into and out of the the circular path. This makes a smoother blend at the start and end points of the cut.
> 
> 
> I forgot to mention that I am only familiar with HAAS and LinuxCNC controls so I don't know anything about Hurco.




Not sure why the three arcs either both both CamBam and SheetCam do it and have done it for both the Hurco and Mach3.  Never had a problem with this on the small machine but Mach3 was a supplied post in CamBam.  I'm just trying to sort out the Hurco.  According to the manual Hurco can be programmed from the controller for a full circle and I think it had some code displayed with it so I believe it should be possible with one line of code it's just that I'd rather use a Cam program and drip than program the part into Ultimax.

There is an Option on CamBam to blend the start and end with a lead in and out but this section of the code is for the rough cut so that is not displayed.  I do use it on the finish pass.

- - - Updated - - -

Sorry, forgot to mention I was using a .25" cutter but the program was wrote for a .1875" cutter.  It wasn't until I ran the test that I realized I didn't have a 3/16" holder so I figured for a test I could wing it with the 1/4".


----------



## SEK_22Hornet

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I had to spend some time working on a BobCAD post for a router we have a while back and remember seeing something in there that affected how it output circles and arcs - I don't recall exactly what it was or how it worked, since that wasn't an area I was having trouble with, but just remember seeing it. Point being, there may be a setting in other software that is causing it to output arc segments rather than a full circle.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

This may help to get you started, copy the following text into notepad and save into the CamBam system folder as Hurco.cbpp  (C:\Documents and Settings\All Users\Application Data\CamBam plus 0.9.8\post) or where ever yours is at  This should be a good starting point.



<?xml version="1.0" encoding="utf-8"?>
<PostProcessor xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Version="0.9.8.0">
  <Notes>Hurco KM3P Post</Notes>
  <PostFile>{$comment} Made using CamBam - http://www.cambam.co.uk {$endcomment}
{$header}
{$mops}
{$footer}
</PostFile>
  <Header>{$comment} {$cbfile.name} {$date} {$endcomment}
{$tooltable}
{$cbfile.header}
%
{$units}
{$distancemode} 
{$cuttercomp(off)}
{$toolchange(first)}
{$clearance}</Header>
  <Footer>{$clearance}
{$spindle(off)}
{$endrewind}
{$cbfile.footer}
</Footer>
  <ToolChange>{$clearance}
{$comment} T{$tool.index} : {$tool.diameter} {$endcomment}
T{$tool.index} M6</ToolChange>
  <MOP>{$comment} {$mop.name} {$endcomment}
{$toolchange}
{$velocitymode} {$workplane}
{$mop.header}
{$spindle} {$s}
{$blocks}
{$mop.footer}
  </MOP>
  <CannedCycleStart />
  <UnitsMM />
  <UnitsInches />
  <VelocityModeConstantVelocity />
  <Rapid>{$g0} {$_x} {$_y} {$_z} {$_a} {$_b} {$_c} {$_f} </Rapid>
  <FeedMove>{$g1} {$_x} {$_y} {$_z} {$_a} {$_b} {$_c} {$_f} </FeedMove>
  <ArcCW>{$g2} {$_x} {$_y} {$_z} {$i} {$j} {$k} {$_f}</ArcCW>
  <ArcCCW>{$g3} {$_x} {$_y} {$_z} {$i} {$j} {$k} {$_f}</ArcCCW>
  <UpperCase>true</UpperCase>
  <MinimumArcLength>0.0001</MinimumArcLength>
  <MaximumArcRadius>10000</MaximumArcRadius>
  <ArcCenterMode>Absolute</ArcCenterMode>
  <ArcOutput>ConvertToLines</ArcOutput>
  <ArcToLinesTolerance>0.001</ArcToLinesTolerance>
  <AddLineNumbers>true</AddLineNumbers>
  <LineNumberStart>10</LineNumberStart>
  <LineNumberIncrement>10</LineNumberIncrement>
</PostProcessor>


----------



## sinebar

*Re: Code issue, please help.  This stopped being fun a few days ago.*

The attached page is from a Hurco programming manual. I think the last two paragraphs might clear up your problem.





I think your controller is in BNC mode, but your post processor output is ISNC. In that case you'll need to use absolute coordinates for I and J. Or, change the mode of your post processor to BNC.
Does that sound right?


----------



## wnec65

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I took the liberty of loading your program into my Mach3 software And it seemed to run fine.  With no tool offset I got a dia. of 1.151 which with a 3/16 end mill would give you a dia. of approx.  1.339.  don't know if this was helpful.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

*FINALLY!!*

I just came in from outside and I owe you guys some drinks!  Not sure what change did the trick but the cut is exactly to size and no more pac-man.  I'll try to run the full part soon and make sure there's no other issues.

Jim, thanks for you effort with the post.  I just couldn't get it to load in the way you recommended so I entered most of it in line by line.  If you have CamBam then you're familiar with what I'm talking about; turns out it's pretty easy to modify.  I had to eliminate some of the comment stuff as the Ultimax doesn't care for them very much but everything else seems to have worked.


sinebar, I did change it to absolute so that may have played a part too.


wnec65, that was helpful to confirm one of my findings.  The coordinates work fine for me in Mach3 too.  Helped me to eliminate my vector file as the culprit.



As a side note.  I posted this thread on another forum that is exclusive to CNC machines on the same day as the post here and only got 1 response.  You guys jumped right in and helped a guy out and I really do appreciate it.  Living up to the tagline "The Friendly Machinist Forum"


----------



## Marco Bernardini

*Re: Code issue, please help.  This stopped being fun a few days ago.*



ecdez said:


> Not sure what change did the trick but the cut is exactly to size and no more pac-man.



Uhm… I just called your CNC machine and told her: «In the next 5 minutes on that table there must be a precise piece… or your gears. Up to you to choose.»

:roflmao:


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*



Marco Bernardini said:


> Uhm… I just called your CNC machine and told her: «In the next 5 minutes on that table there must be a precise piece… or your gears. Up to you to choose.»





So you made her an offer she couldn't refuse.





Appreciete the phone call :lmao:


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Looks like I celebrated a little too early.  I ran the code that night and it came out perfect.  Just came in from trying to run a different program and my part has some weird cuts.  I reverted back to the file that worked to check myself and now it doesn't cut right but I can't remember if I saved over it or not.  In my frustration I made a simple file to cut a circle (again) to check everything and weird cut again.  The problem is no where near the problem I had previously but definitely there.


Just when I was getting over my regret of buying this thing I'm back to square one.  I checked the post I altered and everything seems to be in order.



Now on to my request.  Below is the code I generated for the test circle.  Can someone run the coordinates and see if they get anything besides a perfect circle?  I got nubs (don't know the proper term) at the 12 and 6 o'clock position.  The part I was trying to cut has multiple arcs in it and it appears they all have something screwy going on.  I'm thinking it's the post but it worked a few days ago' why not now?  At first I thought I closed it without saving but I went through line by line and everything matches my notes.  I need to narrow down my search for the problem.  If the code, or coordinates generated by the code, is problematic for someone else then I know where to start.


%
N10 G70 G17 G40 G90
N20 T1 M6
N30 G0 Z0.125
N40 S2500 M3
N50 G0 X0.5707 Y1.6711
N60 G0 Z0.0625

----- coordinates for circle cut are here -----
N70 G1 Z-0.06 F6.0
N80 G2 X1.9965 Y1.9547 I1.3118 J1.6711 F17.0
N90 G2 X1.5954 Y0.9864 I1.3118 J1.6711
N100 G2 X0.5707 Y1.6711 I1.3118 J1.6711
--------------------------------------------

N110 G0 Z0.125
N120 M5
N130 M02
E





I'm ready to do one of these :whiteflag: and part the machine out.  Not really, but I am frustrated.  It was a toss up between this machine and a Tormach.  I've been thinking for days that I made the wrong choice.  Nice heavy duty small industrial machine but 30 years old and zero support other than the forums.  There's something to be said about setting up a new machine and your cutting parts in a few hours.  I've been trouble shooting for two weeks.

Sorry for the vent.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I loaded your code into CamBam and it looked a little strange until I generated the tool path, then it became a circle.  This time the code looks good, the last code was a series of arcs but with different centers.

I am beginning to wonder if the is something wrong in the controller, maybe a noisy comm signal or something.  Can you load the full program into the controller and edit it, or at least look at it?


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

The screen on the right is burnt out so I can't see the graphic but I'm not even sure that was possible for drip feeding anyway.  It might have been only for programming on the controller.

The left screen works fine and that's the one that displays the code for the controller.  I believe I can edit it too.  What should I be looking for?


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I would just look for any differences between the original code and what is displayed on the screen.  It may be the same, so it in that case, no problem.

I would also try to manually enter the code into the controller and see if you get the same result.

I am asking these questions to try to isolate where the problem is being generated, in other words, is it the controller or the code?  In this case the code looks fine, but does it need to be tweaked to run on this controller?

EDIT:

If your controller has a ''conversational input'' function, see if you get the same odd hole shape when the code is generated that way.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I'll give that a try when I get home.  I think the thing that bothers me most is that it worked great once and not since then.  I can't remember what I've changed, if anything.  I checked everything but can't find any differences.

What it looks like to my untrained eye is that the arc is being broken into segments (that can be confirmed by looking at the code) and the segments do not start where the previous one ended.  Let's say one arc completes at the 12 o'clock position and another one starts at the same position.  It looks like the Y position shifts a few thousandths between the start and end points.  Same thing with the 6 o'clock position.  If I had a way to confirm the coordinates of the code I could verify weather my shifting occurs at the segment joints or not.

Now that I think about it, I had the same issue on my small machine running Mach3 but I just assumed the problem was a sloppy thrust bearing on the Y axis.  It never made sense to me as the square corners always lined up but the circles/arcs had the problem.  The problem was not as pronounced as it is on the Hurco, but there none the less.

I thought I might have a problem with my vector art so I went into CamBam and just made a circle and tried it.  Same problem.

Wierd.  I'm not sure what to think now.  Two different posts, two different machines and the same problem (different degrees of severity).  Wonder if it's CamBam itself?


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

N10 G70 G17 G40 G90
N20 T1 M6
N30 G0 Z0.125
N40 S2500 M3
N50 G0 X0.5707 Y1.6711
N60 G0 Z0.0625


N50 G0 X0.5707 Y1.6711  Start point of the circle
N60 G0 Z0.0625

----- coordinates for circle cut are here -----
N70 G1 Z-0.06 F6.0
N80 G2 X1.9965 Y1.9547 I1.3118 J1.6711 F17.0     X & Y are the endpoint of the first arc
N90 G2 X1.5954 Y0.9864 I1.3118 J1.6711    X & Y are the endpoint of the second arc
N100 G2 X0.5707 Y1.6711 I1.3118 J1.6711    X & Y are the endpoint of the third arc, and are exactly the same as the start point.

So this code should work just fine.  G90 says it's in Absolute mode.  That should be correct, but in looking at the Hurco code I could find, it may not use a G90 code.

You might try the following line of code in place of the 3 arc segments in the above code.  I don't know it it will work or not, but worth a try.  This should cut the entire circle rather than arc segments.
N80 G2 X0.5707 Y1.6711 I1.3118 J1.6711 F17.0 


What happened to my machine, was the encoders got flakey and it would not cut a correct circle and it would lose position on straight X and Y moves.  I just built a new controller for mine, and used mag scales for the input.  Ended that problem.

Good luck.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Forgive my Ignorance, but the code you've supplied looks like it's the same as my line 80 with the exception of the x and y coordinates being replaced by the x and y from line 50.  Is that the way to make it do a 360º?  If so, and it works, that's easy enough.  A pain to do it that way but better than not doing it at all.

The NC manual that came with the book has a G 75 code for "Multiquadrant circular interpolation" and specifically says it's for generating an arc in 1 line of code up to 360º.  I'll have to replace the G2 with a G75 but OK, whatever, no big deal.

The manual also references G90 as being correct for absolute.

I did a pen plot on graph paper and the arc points are roughly at 2, 5 and 9 o'clock.  That screws up my earlier theory about different start and stop points.



Eventually I'd like to make some parts on this thing.


Oh yea, thanks again for your help.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*



ecdez said:


> Forgive my Ignorance, *but the code you've supplied looks like it's the same as my line 80 with the exception of the x and y coordinates being replaced by the x and y from line 50.*  Is that the way to make it do a 360º?  If so, and it works, that's easy enough.  A pain to do it that way but better than not doing it at all.
> 
> The NC manual that came with the book has a G 75 code for "Multiquadrant circular interpolation" and specifically says it's for generating an arc in 1 line of code up to 360º.  I'll have to replace the G2 with a G75 but OK, whatever, no big deal.
> 
> The manual also references G90 as being correct for absolute.



That is true, I'm not sure that will actually work, your controller may just see the end point and decide it is done.  On my old Anilam, it would work.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

As I went out to the shop this morning something told me to check the belt to see if it was loose or worn.  Take the cover off and belt looks good.  I figured while the belt cover was off I might as well see what I can see.  Check out the video below.


https://www.youtube.com/watch?v=EtId1WdyK0g&feature=youtu.be

In the video you will see that when I change directions on the Y axis, the motor makes a partial revolution in the reverse direction and then goes correctly.  After you let off the feed, the motor continues to walk for a partial revolution. :nuts:  OK, this is good to know, but what is causing it?

There is a sensor on the x and y axis that detects the limit of the table travel.  I took the housing off to see if there was any interference.  Same thing happens.  Unit looks to operate via magnets so I put a small piece of metal in front of each sensor and they appear to work as the metal sets off the sensor and the axis walks slowly off the sensor.  I was thinking about disconnecting the sensors to see if they are the source of the drift but was unsure of the result of running it with these disconnected.  Any ideas if this will cause a problem?


While I was at it I decided to run the program that we've been beating around here for the last few days and see what I could see.  I ran it at a feedrate of 1 so I could keep an eye on the y position while it was running.  Movement got to the position where it changed directions and sure enough the y jumped .01-.015 or so.  It appears as though the controller picks up on this position change and corrects it but by then the damage is done.  If nothing else, this tells us the machine is reading the travel correctly and correcting but why does it allow the y axis to wonder?

Anyone run into something like this or know where to go from here?


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

This is starting to sound like a zero-offset problem, at the drive level.  The clue is that the end-of-travel limit should shut off the motor, but the motor continues to drift.  Apparently on end-of-travel limit, the drives are not disabled by the controller, but rather the command signal is set to zero by the controller.

If there is a backlash compensation parameter in the controller, try setting that to zero and look at the result.


I am going to go out on a limb here and assume that your mill has DC Servo motors that are driven by a +/- 10 V command signal from the controller.  The drive has some provision for adjusting the zero-offset.  On many of the older drives this is accomplished by adjusting a pot on the drive board, on the newer drives this is normally done via a parameter in the setup.  The motor should not turn when the command signal is at zero.  If it does, then the zero-offset needs to be adjusted.


If you have some electrical documentation for your machine it would be helpful, Fenner drives were popular when your machine was made, and documentation is available for them and I may have that in my archives.


Where are the encoders your system, and how much backlash do you have in the leadscrews?  Is the table ‘’sticky’’?  It might be useful to shut all power down, put a dial indicator on the table, and rotate the leadscrew by hand and try to get a reading on the backlash.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Let me clarify to be sure we are on the same page.  When the table hits the limit switch, it stops.  I have to do a process when I start the machine and one item is to calibrate the axes (all 3). When the table hits the limit switches the movement stops and the table backs off a partial revolution.  This happens on all axes.  I could not get to the X axis motor cover this morning before I had to be at work but I did check the Z and it does not walk.  I checked the X axis and it did not feel like it was walking but I forgot to check the readout to see if it was or not.  The X axis did not appear to jump while running the test program.  At this point, I believe the trouble lies in the Y axis only.  I took the limit switch assembly off to see if it was gummed up or shorting out somehow but visually it is fine.  I wasn't sure how it worked so my experiment with the piece of metal was simply to check to see if it was magnetic or not.

I'll have to check into the backlash compensation in the controller.

The motor does not turn all by itself.  Only after having pushed the feed button does it continue to drift (excluding the jumping while running the program) almost like the button is sticky.  That would not explain the backward turn before correcting though.

I have a set of electrical schematics that came in the manual but I have limited electrical knowhow.

Encoder is right on the ballscrew; took the picture below before work this morning just in case.  The picture is of the Z axis.  Parts list calls it a "Litton" encoder.  Not sure of the backlash, I'll have to check that.  Table is neither sticky or sloppy.

The limit switch on the Z axis is different from the ones on the X and Y so don't let that picture confuse you.






Do you think there would be an issue with running the machine with the Y limit switches disconnected just to eliminate them as a source of trouble?  After the initial calibration I mean.  I'd have to disconnect after I ran through the startup process.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*



ecdez said:


> Let me clarify to be sure we are on the same page. When the table hits the limit switch, it stops.
> 
> 
> When the table hits the limit switches the movement stops and the table backs off a partial revolution. This happens on all axes. *I suspect this is designed in to the system.*
> 
> 
> At this point, I believe the trouble lies in the Y axis only.
> 
> 
> I'll have to check into the backlash compensation in the controller.
> 
> 
> The motor does not turn all by itself. Only after having pushed the feed button does it continue to drift (excluding the jumping while running the program) almost like the button is sticky. That would not explain the backward turn before correcting though.
> 
> 
> I have a set of electrical schematics that came in the manual but I have limited electrical knowhow.
> 
> 
> Not sure of the backlash, I'll have to check that. Table is neither sticky or sloppy.




I don't think there is a limit switch problem.  The key statement you make above is:  _''That would not explain the backward turn before correcting though.''_  You are correct.


What would explain this is the zero offset on the y axis.  I will try to explain what I think is happening, I hope it makes sense.


I am going to use the terms Forward and Reverse here just to define a change of direction for ease of explanation, and also when I say ‘’More Voltage’’ this means a greater deviation from 0 volts, up to a maximum deviation of + or – 10 Volts.  The greater the deviation from 0 the higher the torque the motor produces.  Let’s assume that Forward = + deviation and Reverse = - deviation.


When the controller is outputting 0 volts, the motor should not move if the zero offset is adjusted correctly.  When the encoder has reached the commanded position the controller should be outputting 0 volts.  The controller does this by reading the encoder position and comparing the actual position to the commanded position.   The controller will apply enough voltage to move to and/or hold the commanded position.  If you were to grab hold of the motor shaft and attempt to turn it, the controller would send more voltage to correct the position.


I think there is a battle going on between the controller and the drive.  Let's start with the case shown in your video where the motor turns Reverse before moving Forward.  The motor is being held in position by the controller.  If the zero offset is not correct, then the controller has to provide More Voltage to keep the motor in position.


Now you command the motor Forward, the controller starts changing the voltage to the Forward direction, but the drive is still telling the motor to run in reverse.  Due to the acceleration ramp, it takes a while for the controller to catch up to the error and apply More Voltage to the drive, when it does catch up, then the motor runs Forward.


This is a bit hard for me to put into words, so I hope it makes some sense.  If you have trouble understanding what I said, I'll try to explain it better.


The best way to set the zero offset, is to put a good voltmeter across the command signal terminals and adjust the zero offset until the controller outputs 0 volts when the motor is in it’s commanded position.  I say good voltmeter because a few mili-volts can make the difference.  You need to be able to read the voltmeter to at least 2 decimal places and preferably 3 decimal places.  There is probably a dead-band of +/- 25 mili-volts (0.025 volts) or so that is equivalent to 0 volts


_''Do you think there would be an issue with running the machine with the Y limit switches disconnected just to eliminate them as a source of trouble? After the initial calibration I mean. I'd have to disconnect after I ran through the startup process.''_

I try never to run a fixed travel machine with the limits disconnected.  If you lose control of the motors, things can get ugly in a hurry.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Thanks for the explanation.  I think I got the concept and it all seems to make sense.  Now the question of how to check and adjust.

I've attached what I believe is the correct diagram for the task you are explaining.  If not, I've got the manual.  Which pins should I be checking for voltage on?  I've got a fluke meter and I think it's 3 digit so I should be good there.





Here's a picture of one of the drive boards I found online.  I had a picture but it wasn't this good.  Unless I'm missing it I don't see a pot.




I've looked briefly through the manual for instructions on adjusting the 0 offset using the controller but I'm at work so I'm doing this between waves of work.  I have yet to see anything but I'll keep digging as time permits until I get home.


I agree with you about running the machine without the limit switches.  I wasn't thinking clearly, just desperate to find a solution.






Not to fawn over you but you have no idea how much I appreciate you spending your time helping me (a total stranger) with this problem.  I'm serious about those drinks!


----------



## pdentrem

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Would the two "blue squares with orange paint" near the white label on the bottom left, be the pots? They look like a pot to me.
Pierre


----------



## John Hasler

*Re: Code issue, please help.  This stopped being fun a few days ago.*



pdentrem said:


> Would the two "blue squares with orange paint" near the white label on the bottom left, be the pots? They look like a pot to me.
> Pierre



Yes.  The orange paint is glue intended to hold them as they were set at the factory.  Those ones are probably not intended for field adjustment.  There are also six pots on the top edge of the board.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Not at all what I had pictured when pots were mentioned.  I was thinking something like this :lmao:









The two small ones are near impossible to reach once they are installed on in the assembly.  The six on the end would be easier but which one?


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Your Fluke meter is good.

Set your meter on DC volts and put one probe each in the brown? and orange? wires (J2, Terminals 8 & 9?) coming off the amp to be tested.


Start the servos and jog the axis to be tested at 1/10th rapid, the voltage should read about 0.65v and -0.65v, adjust the BAL pot ( that would be the little blue guys at the top of the board) until they do read the same, but with opposite sign, in both directions.  When the motor has reached the commanded position, the voltage should be very near 0.

Write a program that moves the table 2 inches, when it stops, the voltage should be near 0, and the DRO should read 2.0000, if not then tweak the BAL and move again.  This should bring your machine back to useful again.

If this doesn't resolve the problem, then maybe you will have to do a full tuneup on the drive.  Not a huge deal, but a little more work.

I'm semi-retired so I get to ''work'' on the stuff I want to work on.  And I'm avoiding going out into the shop to work on a project that I really don't want to do.  So helping you with this problem gives me an excuse to do something useful while avoiding the less desirable job.  We are helping each other out.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I might actually be able to do this.  The contents of the component cabinet are imposing but I'm reasonably intelligent, I should be able to handle this.  Turns out the 6 pots are labeled and I found more wiring diagrams that I believe are more specific to what I need to check.  That should get me the terminal numbers (or wire colors) I need to put the meter on.  I'm tied up tonight but I'll get out there in the morning and take some pictures and post them up the the diagrams and we can get me pointed in the right direction.

Thanks again!


----------



## pdentrem

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I missed those multi turn pots at the top! Since I was on my 30 minute lunch, I claim that I was too hungry to notice!
Pierre


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

This should be more helpful.

Here is what I believe to be the correct wiring diagram.




and the corresponding wires in the cabinet (hopefully, although the color coding appears to be off)





And here are the pots with their labels.




Which terminals should I be monitoring for voltage; 15 and 16 seem to be the obvious choice but ?
Which pot is the correct one to adjust?  I certainly don't want to go in there turning the wrong knobs.





As an aside.  I was looking over the initial piece of material I was working with when we were chasing the coding issue at the beginning of the thread.  Although the circles were oversize and had the pac-man mouth, none of them had the offset in the 6 and 12 o'clock position.  Not even a hint of it.  The final piece I cut was perfect, correct size and no weirdness in the circle.  If the voltage is out of adjustment what caused it over the span of a single day?  I understand that when things happen, they happen but is there something I could have done to cause this?  I havn't been playing around in the cabinet as I was intimidated by the contents.  Better to be left alone as long as it works.  It did work fine until suddenly one day.

This whole process has been one of a new problem cropping up just as soon as I fix a previous problem.  All I want to do is make parts.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

The pictures are very helpful.

The DAC (*D*igital to *A*nalog *C*onverter) and DAC Return, terminals RTB1 19, 20, Orange, and Brown wires are the ones you want to probe.

The pot you want to adjust is BAL

Start the servos and jog the axis to be tested at 1/10th rapid, the voltage should read about 0.65v and -0.65v, adjust the BAL pot until they read the same, but with opposite sign, in both directions. When the motor has reached the commanded position, the voltage should be very near 0.

Write a program that moves the table 2 inches, when it stops, the voltage should be near 0, and the DRO should read 2.0000, if not then tweak the BAL and move again. This should bring your machine back to useful again.

I think you actually had two problems, one with the code, and one with the machine.  The pacman shape may have masked the y-axis problem.  

You will be making chips in no time.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Okey Dokey

Turned her up as fast as she would go and got full rapid at 93.7.  I believe it's higher but that's the top speed in manual mode so I adjusted it to 1/10 of that at 9.3.  When I first started I was getting a voltage of .185 in one direction and .175 in another, a full .010 difference.  I adjusted the pot about 1/8 turn and got it mostly balanced out.  Check out the results in the video which will show more than I can explain.

https://www.youtube.com/watch?v=hgt03ykPvP8&feature=youtu.be


After a few seconds the voltage balances out to .183 in both directions.  The wandering appears to be gone but the slight backwards rotation is still present, see 0:42 and 0:49 in the video.  It appears to be reduced from maybe 5º to about 1-2º so it is an improvement.

Most of the stuff I need to cut in in the 30ipm or less range so I figured I'd try it at 30 and see what I got.  The voltage appears to balance out in a similar manner to the video above just at a higher voltage and that makes sense.  At this higher feed the wandering is back although it does seem to be lessened.

Also, if you look in the range of 0:33 on the video you can see a slight forward jump in rotation as the axis is stopping.  Not sure if this is a new development or just something that was overlooked with the other problems.


Time was not on my side this morning so I didn't get a chance to run the program that was suggested to move the axis and check the measurement but I'm not convinced that would affect the wondering or back-turn although I am admittedly not even a novice at this stuff.

Where should I go from here?


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I think you are on the right track.  You may have to tweak the BAL pot a bit to get rid of the little backward movement.  I only watched the video a couple of times so I didn't see everything.  I'll study it a bit more later, and read the manual again.  I would like to see what happens when the table is moving under program control, when you get time that would be helpful.

I'll update this post later, stay tuned.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I was thinking I need to run it a 30 since that's basically where I live and make sure the voltage is balanced there.  I might experiment with that later today and see what I get.

I believe the max rapid for the machine is the the 270 range so 30 would be closer to 10% than the 9.3 I was using.  I'll dig through the manual I have with me and see if I can find what the machine rapid actually is.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

OK, max rapid is 250 so I set it at 25 and checked the voltage.  Got it pretty much equal in both directions at .510 volts ±.002.  Ran my favorite test circle and still have the 6 and 12 o'clock offset although it is decreasing in severity.



I did notice a slight thud when the Y axis changed directions that the X does not have.  I didn't get a chance to write the code for the 2" movement yet to check the accuracy of the movement but now I'm wondering if I also have a backlash problem.  I didn't see any thrust bearings on the body of the mill but I'm also not sure exactly what I'm looking at.  My small CNC has thrust bearing on the handwheel side of the ballscrew that can be tightened.  Are the large CNC's made the same way?  That pulley appears to on there pretty good and I don't want to break it just for some exploration.

Anyone have experience with this?


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

With the power off, put a dial indicator on the table and rotate the motor/ballscrew by hand and check the backlash.  If the ballscrew turns a bit before the dial indicator moves, then it time to start looking at the mechanical parts.  You can check the end play in the ballscrew by putting an indicator on the end of the ballscrew and rotate back and forth.  There should be zero end play.

The end play should be set by the nut holding the pulley, but your mill may use another method of adjusting the end play.

If the end play is OK, then the problem is in the ballnut and it will have to be adjusted.

I think your machine is put together like this:  (The handwheel is replaced by the pulley, but should be pretty much the same design)


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Through a rudimentary arrangement of a square, protractor and a sticky note I've discovered that there is some endplay and it is resulting in approximately 5º of rotation of the pulley before the indicator moves.  While 5º does not sound like a lot, I'm sure it can make a difference.

I got the pulley off and took a picture of what was under it.




if you zoom in on the nut you can actually see that it has something below it that appears to be a lock washer like the picture below.  I did not take anyhting apart as I would like to get input first.





If you look from the side you can see a space between the mill body and the black item that looks like it can be tightened.





Here's a better shot of the Z axis that shows this better.






Any guesses as to where the adjustment for tightening should be?  I'm guessing the nut with the spanner wrench holes but I don't want to screw anything up.


Thanks,
Corey


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I would say that 5* rotation is huge in a CNC, that's probably about 0.003 or so, couple that with some backlash in the ballscrew and it may be quite a bit more.

The black ring locks the OD of the bearings into place, in other words, it captures the bearings in the bore of the housing.  This should be pretty snug.  The nut with the lock washer is what sets the pre-load on the bearings.  This should be adjusted to just over finger tight, plus an additional amount to align the next tab with the notch in the nut.  The ball screw still should turn freely, but should have a light resistance due to the bearing pre-load.  There are probably torque specs on all of this, but I just use my experience and feel.

Once you adjusted the pre-load, then check for backlash in the ballscrew.  Put an indicator on the table, and rotate the ballscrew.  If it is correct, any movement in the ballscrew will cause the table to move.  If this is not the case, then you will have to adjust the pre-load on the ballscrew nut.

You may be able to reach up under the knee to do this, if not, it may require that you remove the bearing housing, the part labeled HK 2020 1, and go in from there.  Look at the drawing in my last post.  The ballnut should have a slotted mount, that when you rotate a bit will pre-load the ballnut.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I adjusted the end nut which barely moved and no noticeable difference so I watched the screw as I rocked the pulley back and forth and looks like all the play is in the ball screw.  Unfortunately, my ballscrew does not have the slots as shown in the picture referenced above but rather looks like so...








I guess I'll be pulling it out to check the condition and to see if there's any way to adjust it but my initial google research says there isn't.  I don't really want to rebuild a ballscrew but it's leaning that way.

Any thoughts?


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I wish I had a easy answer for you, but I'm afraid that I agree with google in this case.  I don't see any way to adjust that ballnut.  Normally an adjustable ballnut system consists of two nuts that are tightened against each other to pre-load the system, in this case, it looks like a single nut.

Do a google search for    rebuild ball screws  There are a number of companies that do this.  I don't think this can be done in the home shop.  I have no idea what the cost might be.  I would balance the cost of having a rebuild done vs. buying ballscrew off of fleabay and modify it to fit.

I had a similar problem with my mill, but I solved it by putting 1 micron magnetic scales on the table rather than rely on the encoders for positioning.  I am looking at the actual table position, doing it this way takes all of the ballscrew variables out of the equation.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

The amount of slop equates to just about .004" and the ball screw appears to be the only culprit left.  It appears as though I have some decisions to make.


There are a few ball screw rebuilders that are recommended on a few forums and I'll get some pricing from them before I do anything stupid.  From my research it appears that the balls are the first to go (wear), the nut next and the screw last.  Seems to make sense.  If that rebuild is too expensive I might try to rebuild it myself.  What have I got to loose if I'm gonna end up replacing it anyway?  I know the slop dimension and once it's apart I'll know the dimension of the balls in the nut.  I can do some math and figure out what the ball dimension should be and give it a shot.  This is contingent of course on a visual inspection of the screw showing no signs of damage.  The video below gives a brief overview of the process and I read where a few guys have done it successfully but it was not easy.  Almost nothing in my garage is easy so nothing new there.

https://www.youtube.com/watch?v=dGp56l0bsdA 


My preference will be to let someone else do it but I need to have a backup plan.

One more thing I'll do is check to make sure all the attachment bolts are tight before I take it apart.  A loose bolt here or there could result in a bunk reading.  It's a little hard to get to but I'll need to take it apart to get it out so I might as well check the tightness before I take a bolt out.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I have reloaded a few ball nuts, a rather tedious job but not difficult. One time I had to do it on a vertical ballscrew, with two opposed nuts, in place on the machine.  That was a bit more challenging.

I suspect that there will be a bit more tuning needed on your servo also, but that will be for another day.

Best of luck.  Please let us know how it works out.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I figured I wasn't done with the servo but I think I need to eliminate the slop to get accurate readings for everything else.  You're right, another day for that.


----------



## countryguy

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Opps..  Sorry gang.  I did not travel to the end of the chain here... disregard....  But man... This is a wicked one for sure! 
Jeff. 

The pots (adjustable potentiometers or variable resistors) are indeed the blue squars w/ orng loctite type material.    there are also several on the top of the picture.   If I recall the old day's those we called "10" turn pots since they offered better resolution to a fixed signal point.     I see BAL  SIG  AUX TAC etc... on them.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Yet another chapter in the CNC mill that is "ready to make parts", or so the ad claimed.


So I start taking parts off to get the ball screw out and about halfway through I decide to check something.  I have the nut unbolted from the housing but the screw is still installed and as I was moving it I noticed how smoothly it moved.   I didn't hear the clunking I heard when the table moved.  Put an indicator on it and nothing, no play.   I'm thinking maybe the play is only noticeable when it's moving a heavy table so I grab hold of it as best I can and try to rock it back and forth... nothing.  What gives?  So I have a brainstorm and bolt it back up.  Now I take the indicator and put it on the end of the shaft that's sticking out of the front of the machine. Guess what the measurement is............ .004".  That's right, the exact amount of slop I had in the table.  I had checked the end nut and thought I had it tight enough but apparently not.  Gave it a few light taps until I got to the next tang on the lock washer and took another measurement.  I'm getting somewhere 1/8º and 1/4º turn in the pulley (it's really hard to measure that small) but more importantly my indicator, which is .0005", got barely a wiggle.

Looks like it's not the ball screw after all but my instead it's my inability to remember to check the simple things first.  Still good news though.  I'll get it all back together soon and make another test cut.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Good catch.  You'll be up and running in no time.  Pretty sure this is going to make a huge difference.


----------



## countryguy

*Interested in the 1micron comment?  , please help.  This stopped being fun a few days ago.*

Jim,  this sounded interesting.  Not to hijack this, but have you posted about this magnetic scale system you setup?   Sounds interesting?  

"micron magnetic scales on the table rather than rely on the encoders for positioning. I am looking at the actual table position, "


----------



## JimDawson

*Re: Interested in the 1micron comment?  , please help.  This stopped being fun a few days ago.*



countryguy said:


> Jim,  this sounded interesting.  Not to hijack this, but have you posted about this magnetic scale system you setup?   Sounds interesting?
> 
> "micron magnetic scales on the table rather than rely on the encoders for positioning. I am looking at the actual table position, "




The best write up I've done is here  http://www.dawsoncontrols.com/millupgrade.html

I'll be happy to answer any questions you have.  Maybe start another thread for that.


----------



## countryguy

*Re: Interested in the 1micron comment?  , please help.  This stopped being fun a few days ago.*

That is a very neat write up Sir.  I always pick up a ton of brain cell material reading your stuff.   Thanks for always taking so much time w/ us!  Really appreciated.  

Now, Here's something you don't read everyday:   from your link  :  " my WD-40 / kerosene mix (my preferred coolant for aluminum machining), "  ;-)   Wowza!    You are a steely eyed missle man! 





JimDawson said:


> The best write up I've done is here  http://www.dawsoncontrols.com/millupgrade.html
> 
> I'll be happy to answer any questions you have.  Maybe start another thread for that.


----------



## JimDawson

*Re: Interested in the 1micron comment?  , please help.  This stopped being fun a few days ago.*



countryguy said:


> That is a very neat write up Sir.  I always pick up a ton of brain cell material reading your stuff.   Thanks for always taking so much time w/ us!  Really appreciated.
> 
> Now, Here's something you don't read everyday:   from your link  :  " my WD-40 / kerosene mix (my preferred coolant for aluminum machining), "  ;-)   Wowza!    You are a steely eyed missle man!



Thank you for the kind words.  It's my pleasure.  This gives me something semi-useful to do when I don't feel like actually working.  Maybe I can pass on some of the experience that I have gained in my 50 or so years of doing fun stuff.  Being about half crazy helps too.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I've gotten everything back together and hoped to have some good news, but alas I do not.  One good thing i guess is the thud is gone.  We can rule that out as having any effect on matters.



Here's a couple new videos of the issue I'm having as it stands today.



Still walks a bit but now I have a jump included.  See the area around 0:08 - 0:11 of the video below.

https://www.youtube.com/watch?v=nHVVEaRYM_4&feature=youtu.be

Interesting thing is it does not appear to walk while traveling "in" only "out".  Not sure what to make of that.  The jumping is intermittent too.  Sometimes it doesn't happen but usually it does.




Here is a video of me cutting a circle.  I slowed he feed down in the trouble spot to make it easier to see.  When it get's to the bottom of the circle (0:30), it jumps just like the video above.

https://www.youtube.com/watch?v=_9iLqSq0FdQ&feature=youtu.be


The readout seems to keep track of this in both instances and appears to try and compensate.  In a previous exercise I got the voltages mostly balanced for in and out as we suspected this may be a culprit.  So if it's not the voltage and not free play in the screw, what's next to check?


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

This is becoming more interesting.  There is one mechanical problem that I can think of, and that is a floating gib.  If it is sticking in one spot then the motor torque has to increase to overcome the stick, this can cause the motor to overshoot the position and then try to correct.  In watching the videos, the motion seems to indicate something like this, but it could have other causes also.

At least, you know the ballscrew is pretty accurate now.

The other external possibility is that the encoder is flaky and is outputting a ''fuzzy'' signal.  This is a somewhat common problem.  The only way to check this is with a dual channel oscilloscope.  The output from the encoder consists of two square wave signals that are out of phase by 180 degrees.  These signals should be well formed and crisp.  This gives the controller the direction and position data.  When these signals are ''fuzzy'' it confuses the controller.

It is possible that there is a intermittently bad connection in the encoder cable, maybe a broken wire that makes contact most of the time.

You might switch the X and Y cards in the computer to see if the problem moves with the card.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I'll check the gib first since it's the easiest.

When you say switch the cards, you are referring to the card with the pot on it I adjusted correct?


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Yes, physically switch the cards in the controller cabinet.  The adjustments are probably not exactly correct but should be close enough for testing.  Just stay close to the E-Stop button when you power up, and during testing.  I don't think the motor will run away, but you never know.


----------



## Thomas Paine

*Re: Code issue, please help.  This stopped being fun a few days ago.*

he's right, if the cards are the same for x y and z, swap the cards and see if the problem moves axes with the card swap.


----------



## Thomas Paine

*Re: Code issue, please help.  This stopped being fun a few days ago.*

remember, the only reason the motor will move like that is if it 'thinks' the motor is out of position.   Encoder or encoder feedback problem?  Check the brushes and commutator of the encoder if it's of that type.

Is the encoder on the ballscrew, or on the motor?  

Can you verify the 'following error' via the control?  See if it's bouncing.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Pulled the gib out and checked it and all seems well.  I didn't expect to find a problem there because I can move the table (by hand) through the complete range with no real effort and no noticeable change in feel.  Good to eliminate it as a culprit though.

Not sure why I did this but I pulled the motor out to check the encoder.  Connections seem fine.  I put an ohm meter on each connection and wiggled the wires and got no interruption.  If there is a short, it's not in there.  I'll check the main wires to the cabinet before I button it all back up.  I realize I should have just switched the cards first but this was knawing at me for some reason.

When the machine jumps position, the readout on the screen follows it so I don't believe there's a problem with the encoder.  It seems to be tracking just fine.

Anyway, here's a shot of the encoder since I had it apart.  Not much info for these machine on the interwebs so I figured why not.  It's a Datametrics S-9992b.








On the first page of this thread I posted this picture and said it was the encoder.  Obviously I was wrong.  Anyone know what this is?  It's on the Z axis.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Since you have the motor out anyway, pull the encoder off of the motor and rotate the shaft by hand.  If it feels rough at any spot, then that may be the problem.  Sometimes the bearing gets sticky and will cause what you are seeing.

In some encoders, the actual encoder is mounted on a spring plate inside the housing and if the bearings are sticky, it will bounce in certain spots.  On some of the machines that I used to work on, just a small ''tick'' noise as the encoder is rotated was enough to fowl up the whole system.  You had to have the encoder right up against you ear to hear this.

It seems that the Datametrics encoders are not available, it would be easy to replace the them with another brand, and the good news is that they are reasonably inexpensive.  If it comes to the point of replacing encoders I'll be happy to recommend something if you like.  All of the needed information should be on the data plate on the encoder.

I suspect the z-axis picture of what you thought was the encoder, is actually a lubrication tube, protected by a flex conduit.

By the time you get done with this, you are going to be a CNC trouble shooting expert.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*



JimDawson said:


> By the time you get done with this, you are going to be a CNC trouble shooting expert.



:lmao:


Not exactly my goal but I suspect so.




I'll pull that off tonight and check it out.  I'll also check the coupling to be sure there's no defect in it either.



I was trolling the interwebs earlier and stumbled across an old thread and someone was having a problem with one of their axis; not the same problem, but a problem none the less.  It was pointed out to them that the cables from the cabinet to the servos have the same plugs and can be interchanged to see if the problem is inside the cabinet or outside.  I suspect this could also help determine if the problem is in the cable too.  If I switch the cables and the problem moves with the cable then I can switch the boards to see if the problem follows the board.  This should narrow it down a bit further.  I was wondering how I was going to tell if the cable had issues without actually probing each pin and a corresponding connection in the cabinet.

This is way more fun than you guys can imagine :nuts:.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

One more thing.  When I pulled the cover off the wire housing on the side off the motor (where the plug goes) it was about 1/2 full of oil.  The motor and encoder was completely dry and I pulled out the brushes and they were all dry but apparently oil seeped into the plug housing.  Could this have an adverse affect?  How should I get that oil all dried out to put it back together?


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

The best way to clean the oil out is using 1,1,1triclorethane, but I don't think you can't buy that any more.  So, find some electrical contact cleaner in a spray can, probably from your local industrial or electrical supply, or maybe an auto parts store, a NAPA store might be the best bet here.  The good news is that you live in a heavy industrial area, so it should be pretty easy to find.  If you can find a store that carries CRC products, they will have just what you need.

As long as the oil is not in to the works, it is probably not causing a problem.


----------



## Thomas Paine

*Re: Code issue, please help.  This stopped being fun a few days ago.*

swap the boards.  swap x and y, and see if the problem moves to x.  it's very easy, common troubleshooting method.  Also, check the board backs for hot spots (darkening), blown resistors or whatnot, and clean the board and drive contacts and terminals and make sure there is no corrosion.  

but swap the boards, this will tell you if the y card is bad or needs adjustment.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

While I had the Y motor out I decided to check it out.  I cleaned the contacts, pulled the brushes, checked and wiped them off and grounded the shielded cable inside the motor (approx 6" of cable)  put it all back together and checked it.

Same problem.




Just swapped the boards and the problem is still on the Y axis.




What next?


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I would say you have eliminated everything but the encoder.  Without a scope, I would swap encoders and see if the problem follows the encoder.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I actually thought of that when I had the motor out but the encoder on the X axis was different with a different mounting method.  Wasn't sure what I was setting myself up for.  I guess I should have bit the bullet.  Maybe I'll check the Z axis one and see if it's the same.

Any chance un-grounded shielded cable from the box to the motor would cause this?


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*



ecdez said:


> Any chance un-grounded shielded cable from the box to the motor would cause this?



Not likely, but nothing is impossible.  You do want only one end of the shielded cable grounded, never ground both ends, it can cause ground loops and induce electrical noise into the encoder circuit.

I don't remember if you tried it with the drive belt off, but you might give that a shot and see what happens.  The only problem with this is that without moving the table the mass of the system is greatly reduced and therefore the motor won't react the same.

I am rapidly running out of ideas for field testing.  The encoder needs to be checked out, and I'm not sure how to do that without a scope.  You might be able to find a local motor shop that can check it.  I would send the motor along also and let them check it.  You might try these guys, their web site says they work on servo drives:

Peninsula Electric Motor, Inc.
Tel (757) 873-1273 - Fax (757) 873-3033
742 Bluecrab Road, Newport News, VA 23606
http://www.peninsulaelectricmotor.com/index.html

I am not ready to say that you have eliminated all of the possible failure modes, but you have to be getting close.  The mechanicals have been pretty much eliminated as a possible source, the problem seems to stay with the y-axis even when swapping boards, so that leaves the motor, encoder, and the cables.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I was halfway through changing the encoders when I got called in for dinner.  I'm headed back out now so I should know something soon.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Okey Dokey.  Swapped out the encoder and no change.


Swapped the wires at the box (left them where they were on the motor) and now the problem is on the X axis.  Since I swapped the boards and there was no change the only thing between the boards and the motor is the wiring.  Other than grounding the shield on one end, anything else I should do while I'm at it?


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*



ecdez said:


> Okey Dokey.  Swapped out the encoder and no change.
> 
> 
> *Swapped the wires at the box (left them where they were on the motor) and now the problem is on the X axis.*  Since I swapped the boards and there was no change the only thing between the boards and the motor is the wiring.  Other than grounding the shield on one end, anything else I should do while I'm at it?



If I understand correctly, you connected the wires from the X motor and encoder to the Y board and the problem moved to the X motor.  I am also assuming that the motors and encoders are mated in their original location.  Is this correct?


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Not sure if I understand your question but I'll try to be clear on what I did.

Swapped out the boards; x and y - problem stayed on y (boards are still like this as I have not switched them back yet)
Swapped out encoders; y and z - problem stayed on y
Swapped connection at the cabinet; x and y (x axis follows y command on control and y axis follows x command) - problem moved to x



I'm over reaching my experience here but here's my theory based on your feedback and what I've seen.

Since the problem switched axis I think it's logical to rule out motor or encoder.
Since the problem did not switch axis when I swapped cards I think we can rule out the cards as the culprit.
Since the problem moved with the cable that seems the logical place to look next.



I simply could leave it alone and went back outside to check the cable.  Turns out the cable is not shielded.  I decided to take the cable completely off and check for shorts but something was itching at me to pull the cable wrap back and have a look inside.  The end that was connected to the box was stuffed full of tiny splinter like shards of aluminum.  Is it possible that some voltage is bridging the gap between terminals by means of the aluminum and the motor and encoder are constantly fighting to keep each other in line?  I plan to clean it out tomorrow and give it another test run.  Like you said we're running out of options.  This seems to make sense but it may be my desperation talking.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

OK, now I understand what you did.  You swapped the connections where they enter the cabinet.  Sometimes you just have to draw a picture for me.

Your intuition and logic are perfect, I think you are correct.  The ability to logically proceed through a troubleshooting process is a great skill to have.

The aluminum shards are very likely the problem if there is any way that they can bridge any connection.  If there is a small short it could cause all kinds of strange problems.  The real question is how did they get into a sealed box?


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*



JimDawson said:


> The aluminum shards are very likely the problem if there is any way that they can bridge any connection.  If there is a small short it could cause all kinds of strange problems.  The real question is how did they get into a sealed box?




I was wondering that myself.  I will still clean them out but unfortunately, I don't think that's the problem.  I woke up this morning thinking about it and realized that I swapped the wires at the cabinet plugs.  This would be similar to swapping lamps in a wall outlet.  If the problem changes lamps when you switch outlets, it's not the lamp (or the wire to the lamp) but rather the outlet.  If the problem would have followed the lamp then the lamp or cable could be the culprit.  Good news is I'm closing in on it.  I need to check the cables between the card and the socket in the cabinet.  Problem seems to be in there somewhere.  Those are shielded cables but I suspect the problem is less sinister.  Maybe a frayed cable, loose connection or something coming loose.  Not sure, but I'll be checking it out later tonight.  I finally feel like it may be solvable if I can just locate it.


----------



## Rbeckett

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Great job chasing down a ghost.  I would have lost my mind and given up on it by now.  But you have soldiered on and it looks like you finally have it figured out maybe!!!!  Good luck and hope that solves you issues.

Bob


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

You guys won't believe this!!

Looks like the problem is fixed.  Not sure what did the trick but I don't even care.  Here's what I did;

1. Cleaned out the cable that was packed with shards
2. Pulled out every card and inspected it for damage (found none) - in the process of pulling the cards I had to unplug every ribbon and plug (possibly fixing a weak connection in the process)
3. Cut at least a dozen cable ties that looked overly tight
4. I also found and removed a screw tip that had fallen into the bottom of the cabinet on top of one of the main cards.  The card had a coating and didn't look like it was making any electrical contact but I don't know if the tip was magnetized or not.  I couldn't detect any but I might have been minute.





Now for the part you won't believe.
The USB port on the drip feeder stopped working and I'm back to a code issue anic:.  The code issue is in Cam Bam though so not really a machine issue.  All arcs are generated with 0.0 as the value for I and J.  Works for Mach but not for my Hurco post.  I don't think I changed anything but who knows, I'll sort it out.



The final verdict is in...... I should have just bought the Tormach :thinking:.   Regardless, it's done now so no use over thinking it.  I am starting to think I will be chasing problems with 30 years electronics for rest of eternity and am starting to think about a retrofit.  Not really the path I wanted but I'm here now. There's a few threads on other websites where guys have done it successfully using the stock motors [which would reduce the cost], Gecko drivers, a breakout board and a stripped out old computer.  I'm not ready to throw the towel in yet but I'm not far from it.

Thanks to everyone for their help so far and especially Jim for sticking with me so try and sort this out.


I'm gonna leave it alone for a few days to clear my head.  Not really good to work on it or make decisions when I'm frustrated.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Well, I'm happy to hear that the electronics seem to be working.  This has obviously very frustrating for you, but I actually enjoy troubleshooting these kinds of problems.  It's part of what I do for a living, and normally over the phone or via email.

As far as the drip feeder goes, is there no way to dump the entire program to memory and run it that way?  Also, check your comm port settings on both ends, it could be as simple as a changed comm parameter.  I assume that you are using a USB to RS232 adapter.  I've had pretty good luck with those.

Try changing CamBam to Absolute Arc Center mode, right now it sounds like you are Incremental mode.  CamBam does some strange stuff with arcs, I think to accommodate some of the older controllers that could not digest a full circle.  I'll be happy to look over your .cb file if you like.

I also got tired of chasing electrical problems with my 30 year old controller, that's the reason I updated mine.  The good news is that I already had the program written for another machine, and I had the hardware on the shelf so it only took me about a day and a half to get mine up and running again when it went down right in the middle of a big job.  If you're interested in seeing that process, take a look at my mill upgrade webpage  http://www.dawsoncontrols.com/millupgrade.html  BTW, I'm not trying to sell anything here, I will give my CNC controller software for free to anyone that can make use of it in their home shop.

There are several different options for updating, I'll be happy to offer my opinions if asked.:lmao:

Keep us posted on the progress.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I think I got the CamBam figured out, operator error.


My compressor went out so no more progress until I get that fixed as it won't run without air.


I an interesting turn of events, the guy (from the business) I got the machine from called today to ask how things were going.  I told him the whole sorted tale of my problems and he was completely taken aback.  He explained how they had the machine for years and serviced it for years before they bought it and the biggest issue they had was an encoder went out.  Must have been the X axis as it was the only one that was different.  The business they operate is a machine automation business and they also manufactured the drip feeder.  I saw one on every machine in their shop.  He said he would ask his techs what could cause the y axis wandering and back-turning.  He also said to take the drip feeder off and bring it in and they'd check it out.  It work's just not the USB port.  While I was talking to him I remembered that when I went to take one of the cards out, my drill tip stuck in the screw and came out of the holder in the drill.  I was wondering if maybe someone at some point in the past was putting a card in, drill tip stuck and they didn't notice it and when I was jostling it around to get it in my shop I knocked it loose and it fell onto the bottom card where I found it.   Guess it doesn't really matter at this point.


I'll get the air compressor fixed this weekend and run some tests to confirm my belief that all is well.   Even if it is, I need to start compiling my backup plan for a retrofit.   Eventually these old electronics will fail and I want to be ready.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Man, what a run of bad luck.  I'll be looking froward to seeing lots of chips made.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*



JimDawson said:


> I'll be looking froward to seeing lots of chips made.



Me too man, me too.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Ran a test circle yesterday (1"d through 1/2" alum) and looks like it's working fine although I have to admit I'm cautiously optimistic.  Maybe I can crank out some parts before the next problem flares up.  Hopefully I can make a few bucks off it before I have to sink any more money into it.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Happy the hear it's working.  I hope it stays that way.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Small update.  Machine started wandering very slightly today.  First thing I did was get bummed out.  After that, I set to figuring it out.

Check all oil levels and makes sure all connection are tight.  In the course of checking the oils I discovered I had the wrong oil in the auto lube.  I had medium light when it should have been #2.  Syphoned all the oil out, put new in and turned it on.  Problem is still there.  Let it idle for about an hour and the problem is now gone (tentatively).  Machine lubes itself for 15 minutes every hour. 

Here's my theory, and this is more for someone who stumbles on this in the future with a similar problem.  Y axis is carrying more weight than the other 2 so if the oil is the wrong weight it would manifest a problem there first with the movement dragging and fighting itself.  Only difference between today and yesterday is the addition of a 100# vise.  Might have been just enough weight to cause a problem with the thinner oil. After and hour if idling (15 minutes of lubing) the thinner oil is out of the system and the correct stuff is in.  If the problem is back tomorrow then I know my theory is crap.  I'll update if it is.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

That might do it.  My oiler pumps one shot about every 5 minutes, I have it set to max output.  I use 85-w90 differential gear lube in mine.  The oiler holds about a quart or so and will empty it's self in about 24 hours.  I have it wired to the e-stop circuit, so anytime that input is high, the oiler is running.  Sometimes I forget to hit the E-stop when I'm done for the day, and and wind up with a puddle in the base.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Yep, theory was crap.  Issue has gotten progressively worse until now I can't get the machine to do anything but shimmy the table a little.  I think the encoder might be shot as when the table is trying to move when I calibrate the axis the reading on the screen doesn't change.  They do on the Z axis but not the X (which is next in line for calibrating).  New theory is table is trying to move but the encoder is not giving any feedback so it just shakes back and forth .  My theories havn't exactly been working for me lately.


I got to use the machine for about two weeks and am happy with it when it works.  It's plenty sturdy and accurate but I believe I'll be chasing electrical problems until I do something about it.  Looks like I might have sold myself on an upgrade.  Hate to do it but if I had started a month ago I'd already be done.  I'm gonna play with it a little more but I can see a conversion on my horizon.  I better start doing my research.

I might start with the encoders and see what that get's me since I'd most likely do those anyway on a conversion.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

One thing after another.  I see a conversion in you future also.  The encoder is also my best guess at this point, try Automation Direct for encoders.  Reasonably priced and a lot of options.

There are quite a few options for upgrade systems, I would pick a system that can use your existing motors, drives, and encoders.  That will save a lot of expense.  If your budget is large enough, then going with a full AC servo system would be the ideal choice.  I was able to use the existing motors in my upgrade, so the cost was not astronomical.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

Existing motors is a must.

I think I'd like to convert to linear scales if I'm going to go through all the trouble.

From what little research I've done it looks like a PMDX-126 breakout board and Gecko G320 drivers are compatible, inexpensive and easy to come by.  Parts I havn't figured out yet is getting the 90v power for the motors and spindle motor control.  Spindle motor might be as simple as a VFD but it does have a speed control knob to either eliminate or deal with.

Every picture I've seen there is a large capacitor in the box with the electronics.  What is that for?




Life was looking good! anyway, it will again, just have to get past this hurdle. In the two weeks I had to make parts I actually did a few samples and sold a couple hundred $$ worth of stuff.  The day it broke I had requests for $100 worth of more work that was about 1/2 hours work and material I had on hand.  Came to my day job today and there is a small job that I could have produced that's worth a couple hundred $$ that they're going to buy from someone else.  I have to get this going again.


----------



## JimDawson

*Re: Code issue, please help.  This stopped being fun a few days ago.*

_I think I'd like to convert to linear scales if I'm going to go through all the trouble._
Linear scales is the only way to go in my opinion.  Magnetic scales are an option to look at.

_From what little research I've done it looks like a PMDX-126 breakout board and Gecko G320 drivers are compatible, inexpensive and easy to come by._
That looks like it might be a good option.

_Parts I haven't figured out yet is getting the 90v power for the motors and spindle motor control._
The Gecko drives use a 80V supply, I'm sure that Gecko sells one.  Also easy to build out of a control transformer, 4 diodes, and a couple of filter capacitors.  I'll be happy to supply a schematic.    I am using an off-the-shelf 70V supply on my system, because my Z-axis stepper drive would not take the original 100V DC servo drive power.  I found that my x and y motor voltage only went to about 45 volts on a 200 IPM rapid move, so they run just fine on 70V.  You probably have a 100V supply in your existing system also.

_Spindle motor might be as simple as a VFD but it does have a speed control knob to either eliminate or deal with._
A VFD is the way I would go.  I suspect that there is a VFD control port on the PMDX-126.

_Every picture I've seen there is a large capacitor in the box with the electronics.  What is that for?_
I'm pretty sure that would be the filter capacitor for the 90V (80V?) power supply.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I meant magnetic scales.  Glass ones are a little too pricey for me.

I'll take that schematic if you don't mind.  I'll PM you my email.

In the few tests I've run I never got any voltage above 40 but from the manual it appears that more voltage is supplied (some how) when the machine feels it is necessary.  I tend to baby my stuff a little so the difference between 70 and 80 volts will probably never happen.


If you're up for it, I'll definitely be picking your brain when the time comes.


----------



## ecdez

*Re: Code issue, please help.  This stopped being fun a few days ago.*

I posted in another thread about an oscilloscope but figured I'd put it here too so it's all together.



Finally got all the encoders off and ran some basic tests.

Basically just checked the voltage coming out of each lead as I turned the shaft very slowly. Used a small 12v power supply.

Z aixs - known good
A - fluctuates between 14v and 0
B - fluctuates between 14v and 0
Z - fluctuates between 115mV and 0

Y aixs
A - fluctuates between 13.25v znd 12.5v
B - fluctuates between 12.5v and 13v
Z - fluctuates between 10.3v and 10.35v

Xaixs
A - fluctuates between 14v and 0
B - fluctuates between 14v and 0
Z - only get a reading of 10mV - no fluctuation


I know this is not as accurate a test as an oscilloscope would offer but I know now there is a different reading between the known good one and the others. There's definitely something fishy there. I have found a scope locally that I told I could borrow so I'm gonna make him up on that.



Is there any way to change the title of the thread to something more appropriate to what it has morphed into?


----------



## JimDawson

I can change the title, what would you like?

I can also merge the scope thread and this one if you like


----------



## ecdez

No need to merge, I'm done with the other one.

Title should be something fun and accurate.  How about - The never-ending saga of the Hurco that's "ready to make parts"

That should cover it.  THANKS!


----------



## JimDawson

ok, changed


----------



## ecdez

Thanks!


----------



## ecdez

Hey Jim, I checked into the link you emailed me for the rotary encoder but they are out of stock.  When you get a chance, can you check the following units that I found and see if you spot any glaring deficiencies in performance compared to the one I had.  I'm such a novice at this I can't even tell the difference between them except the shaft diameter.

Thanks a bunch.


http://www.automationdirect.com/adc...haft_Line_Driver_(TRD-MX_Series)/TRD-MX1000VDhttp://www.automationdirect.com/adc...ft__Line_Driver_(TRD-SH_Series)/TRD-SH1000-VDhttp://www.automationdirect.com/adc...ft_Line_Driver_(TRDA-2E_Series)/TRDA-2E1000VDhttp://www.automationdirect.com/adc...Line_Driver_(TRDA-20_Series)/TRDA-20R1N1000VDhttp://www.automationdirect.com/adc...Shaft_Line_Driver_(TRD-S_Series)/TRD-S1000-VD


----------



## JimDawson

The only difference in those is the shaft size.  I may have generated some confusion by kind of randomly picking an encoder as an example.

Just to help understand the part numbering system

TRD A-2E 1000 VD

TRD  = Light Duty Incremental Encoder

A = SAE Dimensioned

2E = 1/4 inch shaft

1000 = PPR

VD = Line Driver Output  (A, B, Z, 5 volt)


TRD A-2E 1000 *BD*

TRD  = Light Duty Incremental Encoder

A = SAE Dimensioned

2E = 1/4 inch shaft

1000 = PPR

*BD* = Open Collector Output  (A, -A, B, -B, Z, -Z,  12 - 24 volt)

You were testing your encoder at 12 volts, so I assume the you require a 12 volt encoder, therefore, the BD suffix would be correct.  Since you have no connection for the -A, -B, -Z, you would simply not connect those wires.

I would try to match the physical dimensions of the existing encoders, then match the PPR, then the voltage.

Here is a link to the PDF overview of all of the encoders, including drawings.   http://www.automationdirect.com/static/specs/encoderld.pdf

I'll be around if you need a bit more help.


----------



## ecdez

That is helpful.  The encoder on the x axis is a replacement unit and is capable of 5v - 24v.  The other encoders are original and are labeled as 5v (even though I checked them at 12v).

The replacement one is rated at 1000 PPR but I have no idea what the originals were.  Since the replacement one worked fine I figured I'd just go with it.


The replacement one has the following part number 260-N-T-10-S-1000-R-HV-1-S-SF-1-N which can be decoded on this page (http://www.encoder.com/literature/datasheet-260.pdf) - Pay no attention to the shaft size and through hole as I believe I'll be putting it back on a mount like the others.



Since I have 1/4" shafts coming out of the motors, looks like this one is the winner. http://www.automationdirect.com/adc...ft_Line_Driver_(TRDA-2E_Series)/TRDA-2E1000VD

Of course, if I'm way off base I can accept that.


----------



## JimDawson

Ding, Ding, Ding, I think we have a winner:winner:

You might want to confirm the encoder operating voltage on the machine.  Based on the original encoders, I would guess it is 5 volts.  You don't want to feed a 5 volt only encoder with 12 volts, it lets the magic smoke out.)


----------



## ecdez

I got the encoder replaced a few weeks ago and now I keep getting servo errors.  Quirky thing is it's different every time I fire it up.  Sometimes it's the Z, sometimes X and sometimes Y.

Sigh.

I hate to accept defeat but I think the 30 year old electronics are giving up the ghost.  Bummer, it cut beautifully when it was working.  Oh well, I guess it's time to start researching the upgrade.  Once it's done I'll probably kick myself for not doing it sooner.


----------



## pdentrem

I cannot remember but did you do a visual check of the caps? They dry out over time. Look for stains that the oil leak would of left behind and swollen rubber plugs pushing out the bottoms or tops that are round instead of flat. 

As you are chasing ghosts in the machine, bad caps can cause very similar issues, due to varing voltages and power spikes that they were supposed to remove.


----------



## countryguy

Sorry to hear of the woes...  I did enjoy following this long series and hearing of hopeful success!  But I am also in the same boat so maybe I can share somethings I've found out for conversions myself.    Wowza... Again, Hope you can make this thing go.    Just some comments from my end.    

Stepper (closed loop micro step or plain ol' open stepper) -vs- closed loop true Servo.    Jim has some good notes on some aspects in a recent thread or two.  I also posted a few links and vids.  Which do you think ya want to go with?   There are a lot of YouTube vids on closed stepper setups.
Capacitors do go dry! especially the 85'C rated ones.  We put in 105 C rated caps in closed case supply situations often.  A ESR type meter will very swiftly tell you if good or bad.  You can google for alternative ways w/o an ESR meter. There are many!   Amazon has a cap checker for $13 also.
For a DC supply put the meter on AC and check the readings.  Bad supply's can put AC ripple on the DC.   You can pick this up with that Oscope as you were thinking about getting one.  But the regular ol AC volt meter will pick that up as well. usually set to a millV level and go up from there.  I remember that Oscope post of yours.  I put a few posts on there too for some import brand digi scopes if I recall?  Or the same brand I know of was already posted. for $250 - $400... Very reasonable!
On a Servo CNC type conversion I'm sold on the AjaxCNC kits from the Company that does Centroid.  you can run w/ Mach3 and/or Centroid.  Since I want my Son to also learn Industry based controls, I'm leaning to the Centroid AjaxCNC kit as soon as this week!

I hope you can sort it all out!  Keep us posted!   Need to get that Mill going!


----------



## countryguy

I wanted to also put a few dollar metrics to this tale of 'the upgrade patch'.  

The Servo kit I note below with the Encoders, cables, and DC AIO (All in One) kit is near $4K.  I've run this upgrade everywhich way.  I cannot get around the cost best deal bundle deal of $4239 and you get the control pendant too.  (see link: http://www.ajaxcnc.com/ajax-cnc-centroid-mill-kits/)  and that is no motors what's so ever!  The kit is well known and I've found their support to be really really good.

On the Closed Loop stepper for example:  is a mere $1200 and that's motors and all!  (http://www.automationtechnologiesin...op-stepper-motors-3-axis-cnc-kit-110vac220vac) (on sale too)....   I honestly do not know how the feedback and closed loop on a possible stepper stall works with MAch 3 or 4?  Or if there are plug INs?  Or do you have a LinuxCNC setup ?

Just a few comments back as I pondered this today myself on the $$ hit that a Servo setup will take. 




countryguy said:


> Sorry to hear of the woes...  I did enjoy following this long series and hearing of hopeful success!  But I am also in the same boat so maybe I can share somethings I've found out for conversions myself.    Wowza... Again, Hope you can make this thing go.    Just some comments from my end.
> 
> Stepper (closed loop micro step or plain ol' open stepper) -vs- closed loop true Servo.    Jim has some good notes on some aspects in a recent thread or two.  I also posted a few links and vids.  Which do you think ya want to go with?   There are a lot of YouTube vids on closed stepper setups.
> Capacitors do go dry! especially the 85'C rated ones.  We put in 105 C rated caps in closed case supply situations often.  A ESR type meter will very swiftly tell you if good or bad.  You can google for alternative ways w/o an ESR meter. There are many!   Amazon has a cap checker for $13 also.
> For a DC supply put the meter on AC and check the readings.  Bad supply's can put AC ripple on the DC.   You can pick this up with that Oscope as you were thinking about getting one.  But the regular ol AC volt meter will pick that up as well. usually set to a millV level and go up from there.  I remember that Oscope post of yours.  I put a few posts on there too for some import brand digi scopes if I recall?  Or the same brand I know of was already posted. for $250 - $400... Very reasonable!
> On a Servo CNC type conversion I'm sold on the AjaxCNC kits from the Company that does Centroid.  you can run w/ Mach3 and/or Centroid.  Since I want my Son to also learn Industry based controls, I'm leaning to the Centroid AjaxCNC kit as soon as this week!
> 
> I hope you can sort it all out!  Keep us posted!   Need to get that Mill going!


----------



## JimDawson

countryguy said:


> ........I honestly do not know how the feedback and closed loop on a possible stepper stall works with MAch 3 or 4?  Or if there are plug INs?  Or do you have a LinuxCNC setup ?



That is a really good question.  I'm going to take a guess here and say that the steps from Mach3/4 are buffered in the motor processor.  So it would depend on how big the buffer is.  If the stepper really stalled, then it's time to shut down and start over anyway.  If it's just a momentary glitch, then maybe the buffer will handle it and Mach3/4 will just be a few steps ahead of the motor(s) but I could see where this might fowl thing up unless the motor speeds up to catch up.  The motor may realize that it's behind where it should be and try to compensate, a normal servo system does this.


----------

