G0678 CNC Conversion Thread

[martyscncgarage]

I was pretty sure I searched your encoder model number and that's the chart I got.
Bummer it didn't work.
Per our conversation, you are using the factory pigtail on the encoder and simply terminated it to the DB9.

Marty

[Dave_C]

I was pretty sure I searched your encoder model number and that's the chart I got.
Bummer it didn't work.
Per our conversation, you are using the factory pigtail on the encoder and simply terminated it to the DB9.

Marty

Man this is confusing! But yes, I am using the factory pigtail and just adding the DB9.

I made a chart of the like and not alike wires of the wire colors comparing your chart to my documentation. When I wire it according to your colors it actually swaps A for B but it also reverses the A and the /A so I was surprised to see that even worked.

I went back to AD just now and looked at the documentation, it agrees with the paper that came in the encoder box, so where did you find your chart?

Here is the link to what I am looking at: https://cdn.automationdirect.com/static ... oderld.pdf

Go all the way to TECD22 (page)

Dave C.

[Dave_C]

New Encoder!

Failed, failed, failed, failed!

Just like the other two. So obviously the problem is not with the encoder.

Marty, I don't know why we didn't think of this but the label on the encoder has the wire colors and they agree with the documentation that I received with the encoder.

I'm down to chasing ghost now as I've checked and rechecked everything I can think of.

So here is a thought. Since the RPM display waffles between 637 and 641, is that enough to throw the spindle into a sync error?

If so, is there a parameter to allow for a wider margin of error before it aborts the cycle?

I have no idea why the RPM varies but it has done that with all three encoders! I have a remote mounted display for the drive, mounted in the front of the controls panel, and I can see that it does vary 1 RPM or so but the motor is at a 2 to 1 ratio so a 1 rpm variation in the motor RPM would give us half that at the spindle.

So what else is left to look at? I get the fault at the same spot in the cycle, right after the rapid to clearance height (spindle is already at speed at this point)

Don't forget: This is what the error is saying "Error 438 which says "The slaved axis moved too far in the wrong direction during a spindle-slaved move (such as rigid taping). Job is cancelled.""

Wrong Direction? How can that be? The Motor is not reversing and I can't see anything wrong with the spindle decent to clearance so is there a glitch somewhere that is making the Acorn think the spindle moved in the wrong direction? Error 438 says we went too far in the WRONG direction.



Dave C.

[martyscncgarage]

New Encoder!

Failed, failed, failed, failed!

Just like the other two. So obviously the problem is not with the encoder.

Marty, I don't know why we didn't think of this but the label on the encoder has the wire colors and they agree with the documentation that I received with the encoder.

I'm down to chasing ghost now as I've checked and rechecked everything I can think of.

So here is a thought. Since the RPM display waffles between 637 and 641, is that enough to throw the spindle into a sync error?

If so, is there a parameter to allow for a wider margin of error before it aborts the cycle?

I have no idea why the RPM varies but it has done that with all three encoders! I have a remote mounted display for the drive, mounted in the front of the controls panel, and I can see that it does vary 1 RPM or so but the motor is at a 2 to 1 ratio so a 1 rpm variation in the motor RPM would give us half that at the spindle.

So what else is left to look at? I get the fault at the same spot in the cycle, right after the rapid to clearance height (spindle is already at speed at this point)

Don't forget: This is what the error is saying "Error 438 which says "The slaved axis moved too far in the wrong direction during a spindle-slaved move (such as rigid taping). Job is cancelled.""

Wrong Direction? How can that be? The Motor is not reversing and I can't see anything wrong with the spindle decent to clearance so is there a glitch somewhere that is making the Acorn think the spindle moved in the wrong direction? Error 438 says we went too far in the WRONG direction.



Dave C.

My apologies, I went to Automation Direct's website and looked up the encoder, only I didn't look far enough, there were multiple models of encoders on that sheet.

All I can say about the wrong direction is either put the minus sign in front of the encoder value in the wizard or take it away.

I feel your frustration Dave. Top notch conversion and hung on this. I wished I had a different brand encoder to send you to try. I will try and dig around tomorrow.

Marty

[Dave_C]

Marty,

Don't forget: This is what the error is saying "Error 438 which says "The slaved axis moved too far in the wrong direction during a spindle-slaved move (such as rigid taping). Job is cancelled.""

Wrong Direction? How can that be? The Motor is not reversing and I can't see anything wrong with the spindle decent to clearance so is there a glitch somewhere that is making the Acorn think the spindle moved in the wrong direction? Error 438 says we went too far in the WRONG direction.

The encoder is not giving a wrong direction, it gives a positive number when I run forward and a negative number when I reverse. I ask [wrong direction] as the error 438 is telling me the slaved axis moved too far in the [wrong direction].

So if I can figure out why 438 is telling me this, I might be able to figure out the cause.

The RPM numbers do not reverse! They do jitter a bit!

I've attached a new report, I've looked through it for anything that I could find and I can't find anything to even talk about.

So maybe Centroid will tell me what is actually wrong when you get a 438 error. Why does Acorn think the slaved axis moved in the wrong direction?

Dave C.

report_985DAD490575-1006170161_2018-05-17_17-16-40.zip

(179.68 KiB) Downloaded 94 times

[Dave_C]

New Information:

After exhausting just about everything I could think off I tried running the Rigid Tap Routine a few more times.

I missed this before but upon close inspection I can see the spindle "lift" after the rapid to distance. As soon as it tries to lift {wrong direction} then I get the error.

At first I thought I might be programing Intercon wrong so I opened the manual and looked at the example. I had it identical except for the thread pitch!

I then tried a program created in Fusion 360 and it worked the same way. Same error!

But, the new information is that the spindle does try to go up after the "rapid to" distance.

Details: Tool changes at the top of the spindle travel which is 1" above my part zero.

My rapid to depth is .100 (inc)
My clearance height is .100 (inc)
My total depth is .500
Pitch is 20

So this is pretty much right out of the manual as far as settings go.

So why does the spindle try to lift? [thus the 438 error]

Dave C.

[Dave_C]

FIXED IT!

It wasn't the encoder!

It wasn't the wiring!

It wasn't a bad Acorn board!

I figured it out when I got off the encoder issue and started thinking through "why does the spindle try to lift after making the rapid move to the clearance height".

After all, the error was telling me the spindle traveled too far in the wrong direction! And yes, that was the problem.

But what was causing it to do that? Centroid should have picked up on this the first time I sent them a report two months ago when they read it as it said right in the report what the problem was.

NO REFERANCE SET!

I do not use tool length offsets so when I set my Z I did not enter a tool number to set the reference. This morning I reset my part zero's and put the number 1 in the Z tool number.

Rigid taping works just fine now!

I ran it twice!

Dave C.

[martyscncgarage]

FIXED IT!

It wasn't the encoder!

It wasn't the wiring!

It wasn't a bad Acorn board!

I figured it out when I got off the encoder issue and started thinking through "why does the spindle try to lift after making the rapid move to the clearance height".

After all, the error was telling me the spindle traveled too far in the wrong direction! And yes, that was the problem.

But what was causing it to do that? Centroid should have picked up on this the first time I sent them a report two months ago when they read it as it said right in the report what the problem was.

NO REFERANCE SET!

I do not use tool length offsets so when I set my Z I did not enter a tool number to set the reference. This morning I reset my part zero's and put the number 1 in the Z tool number.

Rigid taping works just fine now!

I ran it twice!

Dave C.

Right on Dave!
So when cutting air, it wasn't an issue? Only when you went to cut metal?
Looking forward to seeing the video of it tapping metal.

Now you have a glut of encoders.

Thanks for reporting back what you found. Hopefully it may help others in the future.

Marty

[Dave_C]

Right on Dave!
So when cutting air, it wasn't an issue? Only when you went to cut metal?
Looking forward to seeing the video of it tapping metal.

Actually it failed in both air cuts and metal cuts (PVC in my case) What I am puzzled about is the fact that in ran once in a while like the time I made the video.

I'll get around to making a video once I do some more testing in PVC and making sure this setup is going to be reliable.

I think I am on the right track now!

Dave C.

[rl49]

Hi Dave, I had a hard time getting my head around our t400 lathe years ago, as the verify graphics would not show correct tool path position till I set actual tool references for tool numbers. It took my son to point that out to me. I always run a program in F8 Graph as I've found after a few embarrassing crashes what you see is what you get usually, very humbling. Glad you got it sorted out very nice build by the way.

Regard's, Ron