Adding capabilities to my ELS system

[WobblyHand]

Reading about sources of error in a G32 threading cycle, it says the lead screw rate has to be locked to the spindle and constantly synchronized (whatever that means) and the start of the cycle requires a known start angle and known Z. To the best of my knowledge, I do those things. I use the encoder for angle sync, and I can stop the carriage on Z to within 5um. I am using a 1um DRO for Z. Timing belt is relatively tight. Of course there's backlash, but this is a primarily "going in one direction" system.

Not sure what "constantly synchronized" means. My system moves Z (the lead screw) according to the spindle angle. It doesn't care about velocity of the spindle, only the position. The stepper is incremented effectively N steps for every D encoder counts. It works great for normal threading. I've used it for 3 years now, it cuts beautiful threads for any pitch or TPI.

Perhaps somewhere, I inadvertently have introduced some delay variation in my processing time, so that they are substantially different each thread pass. Nuts if I can find it (so far).

 

[homebrewed]

How are you addressing backlash in the LS? Could that play a role w/regard to your problem? Are you reversing the motor or gears to back the cutter out for the next pass?

 

[WobblyHand]

How are you addressing backlash in the LS? Could that play a role w/regard to your problem? Are you reversing the motor or gears to back the cutter out for the next pass?

Same as when manually threading, cutter is manually backed out then half nuts opened, then move carriage to start point. Move in cutter. Press start, engage lead screw. Carriage moves towards work piece then stops at a known point. When the spindle angle is correct carriage starts moving again to make the thread cut. All motor motion is towards the chuck (for RH motion). All backlash should be taken up, same mechanical motion as manual threading, save for stopping the lead screw.

 

[ivel03]

Is it the same function as manually threading or did you extend it to read from the DRO/linear encoder to know where the carriage is?

Would it make sense to create an intermediate version of this where you never unlock the half nuts and it would work like this:

Assuming threading towards chuck:

• Set the right stop limit at the end of part but not interfering with tail stock, etc
  • This could be hard coded in for proof of concept
• Set left stop limit in the thread gutter
  • This could be hard coded in for proof of concept
• Button to start cycle that moved the threading tool from L Stop to R Stop while chuck is spinning
• You would then feed the tool in on each pass
• You could add acceleration with ramp up/down on the return pass to make the cycle time faster
• You would need to overshoot the R Stop a bit and come back to account for backlash but that shouldn't be a big deal

The advantage i see is that you are mechanically locking the spindle to the carriage. If i understand what you're trying to do (i'm certain i don't at the level you're doing it at) you're keeping track of spindle angle with the Omron encoder and we know where the stepper is at any point because of the amount of pulses,etc since start. The part i don't get is unless you engage the lead screw on the same number every time (or you're using the DRO to get position) how does it stay in sync? I'm sure you've covered it in the past 30+ pages but i'm more or less trying to get you to rubber duck your code!

 

[WobblyHand]

I know the spindle angle due to the rotary encoder. I know the carriage position because I use the Z DRO. I was using stepper counts and stepper angle, but it's unmanageable and not relevant, since the lead screw is not guaranteed to be engaged. As far as I know, commercial CNC uses sensors to close the loop, not steps. So I use sensors.

Sync should be achieved since I stop at a known position (due to closing the Z position loop using the DRO) and I know when I am at the correct spindle angle by reading the encoder. If I can do both consistently I should have consistent sync. That's my hypothesis. Maybe it's wrong, but I can't find anything in the literature to refute it. Maybe it's poor execution, can't rule that out.

I don't have a means to keep the half nuts engaged, since I can't control my spindle controller, nor do I have an X axis controller. I don't want full CNC either. The HW was not designed for full CNC. CNC operation is out of scope for my project. However, executing my second paragraph is within the scope of the HW and the overall design of the project. At the moment, I have to conclude that there's some coding flaws that inject a random delay into the sync process. Finding those flaws will take some time. Fixing the flaws may or may not be possible in this system. It's hard to evaluate without a root cause.

If I can swing it, I will try to integrate in the HW encoder to check for slipped counts. If I detect any, that's a clue and source of error. I know I can do that for the spindle, not sure if I can do that for Z. Hopefully I used the correct pins on my PCB. If the count slips a lot, that's the smoking gun. If one count, that doesn't account for the errors I am seeing.

 

[WobblyHand]

Is it the same function as manually threading or did you extend it to read from the DRO/linear encoder to know where the carriage is?

Would it make sense to create an intermediate version of this where you never unlock the half nuts and it would work like this:

Assuming threading towards chuck:

• Set the right stop limit at the end of part but not interfering with tail stock, etc
  • This could be hard coded in for proof of concept
• Set left stop limit in the thread gutter
  • This could be hard coded in for proof of concept
• Button to start cycle that moved the threading tool from L Stop to R Stop while chuck is spinning
• You would then feed the tool in on each pass
• You could add acceleration with ramp up/down on the return pass to make the cycle time faster
• You would need to overshoot the R Stop a bit and come back to account for backlash but that shouldn't be a big deal

The advantage i see is that you are mechanically locking the spindle to the carriage. If i understand what you're trying to do (i'm certain i don't at the level you're doing it at) you're keeping track of spindle angle with the Omron encoder and we know where the stepper is at any point because of the amount of pulses,etc since start. The part i don't get is unless you engage the lead screw on the same number every time (or you're using the DRO to get position) how does it stay in sync? I'm sure you've covered it in the past 30+ pages but i'm more or less trying to get you to rubber duck your code!

Making the intermediate version as suggested would be a major rewrite. And there's no HW to turn off the spindle, nor retract the cutter at the right time, nor a way to avoid a lathe crash. Short answer, yes, I use the linear encoder to know where the carriage is.

 

[WobblyHand]

So I'm entertaining the thought of using the HW encoder as a safety (and performance) check on the count. My spindle encoder is wired to 0 and 1, which is QuadEncoder compatible. Unfortunately, my Z DRO is not wired to allowed QuadEncoder pins. However, my X DRO is wired to allowed QuadEncoder pins. The X axis rarely moves, and is NOT in the control loop at this time. In SW I can swap the pins. Then all I have to do is swap the cables. Then Z will be wired to the ports that allow HW encoding. The idea is to check (in the main loop) to see if spindleSWcount = spindleHWcount, and Z_SWcount = Z_HWcount for any count slippage. Z will never overrun in real life. Spindle could, but won't in several hour long runs. Should be fine for testing I think. That's if things go smoothly...

I have doubts that this is the main issue, but I have to rule it out.

 

[ivel03]

Making the intermediate version as suggested would be a major rewrite. And there's no HW to turn off the spindle, nor retract the cutter at the right time, nor a way to avoid a lathe crash. Short answer, yes, I use the linear encoder to know where the carriage is.

Right that makes sense. I couldn't figure out how you could keep them in sync without using the linear encoder. I was not suggesting turning off the spindle at all. Leave it running the entire time, when it reaches the LStop you're in the thread gutter, then you retract the tool, click a button and the carriage goes to RStop. Then you advance the tool in and click a button and it goes to LStop. Rinse and repeat.

This isn't CNC, you're still controlling the X axis yourself. The above example might be easier on the Teensy b/c you're only keeping tracking of the rotary encoder and the steps needed to feed to the stop left or right. I'm sure this is oversimplified. I can't imagine the hardware can't keep track of 2 encoders and the steps it sent at the same time but maybe it's not doing it fast enough in real time?

Seeing a few youtube videos and reading up on thread to stop with other ELS systems it appears that none of them are doing what you are trying to do with regards to disengaging the lead screw. If i had to guess they are tracking carriage location with steps +/- origin.

I appreciate that it would be a major rewrite to implement what i described above but i was spitballing ideas more than anything else. I wish i was more helpful to you for this process.

 

[ivel03]

Same as when manually threading, cutter is manually backed out then half nuts opened, then move carriage to start point. Move in cutter. Press start, engage lead screw. ......
All backlash should be taken up, same mechanical motion as manual threading, save for stopping the lead screw.

Would it prove anything useful if you treated it like a typical lathe and always engaged the lead screw on the same number on the thread dial? That's how you sync up on a typical manual lathe assuming TPI and inch lead screw. Maybe you've tried this already.

 

[WobblyHand]

Right that makes sense. I couldn't figure out how you could keep them in sync without using the linear encoder. I was not suggesting turning off the spindle at all. Leave it running the entire time, when it reaches the LStop you're in the thread gutter, then you retract the tool, click a button and the carriage goes to RStop. Then you advance the tool in and click a button and it goes to LStop. Rinse and repeat.

This isn't CNC, you're still controlling the X axis yourself. The above example might be easier on the Teensy b/c you're only keeping tracking of the rotary encoder and the steps needed to feed to the stop left or right. I'm sure this is oversimplified. I can't imagine the hardware can't keep track of 2 encoders and the steps it sent at the same time but maybe it's not doing it fast enough in real time?

Seeing a few youtube videos and reading up on thread to stop with other ELS systems it appears that none of them are doing what you are trying to do with regards to disengaging the lead screw. If i had to guess they are tracking carriage location with steps +/- origin.

I appreciate that it would be a major rewrite to implement what i described above but i was spitballing ideas more than anything else. I wish i was more helpful to you for this process.

Appreciate the suggestions, as I'm floundering at this point. The Teensy is not controlling the spindle motor in any way. If I had better access to the VFD, I may have tried that approach. So shutting down the spindle and reversing are external to the ELS. If I have to do all of what you describe, I am effectively at what I do now with metric threads and attempting to stop the spindle while in the gutter. Honestly, I find it nerve wracking, except at the very lowest speeds. I expect my reflexes will deteriorate with time, and even that may not be possible in a few years. So I'm trying to achieve something different, and hopefully better.

You are absolutely correct that the youtube videos aren't doing what I am attempting. I'm trying to avoid the crazy dance of manual sync and motor stoppage, that is what is normally done. I believe this carriage and angle syncing is very possible to do, with the HW that is currently in the system. It's possible that my SW control scheme is not making the decision at the appropriate time. That is an ongoing investigation. I suspect when I uncover the root cause I'll be giving myself a dope slap... It's either so obvious that I'm totally overlooking it, or so obscure that it will be hard to find.