1.2032 does not update firmware

[cncdrive]

Hi Derek,

Thanks. I just got to the end of the debugging and I found what the problem is.
The issue is that the spindle is not reversed by the software at the end of the rigid tapping cycles.
And I remembered incorrectly, I thought it does.
So, the issue is that when the first G33.1 cycle finishes the spindle remains in M4 when it should change to M3 to start the new cycle, but it does not, so it is just sitting and waiting for the spindle to start the rotation to the correct direction.
You could verify this with looking at the M3 and M4 spindle buttons and you should see that the M4 is still active when the first Q cycle ends,
and if you press the M3 button manually on the screen and so the spindle changes the direction then the next cycle will start...

Unfortunately I did not have an encoder at hands when I added the Q parameter and I thought adding it is easy enough that I will not make an error so I only tested this with debugging console messages and with replacing the tapping API calls with linear movements temporarily, so I did not explore this issue.

I will correct it soon, will add the spindle direction changes at the end of the cycles.

[Derek]

All you said is correct except pushing the M3 button does nothing but turn the spindle off. No matter though as it sounds like you found the problem.

I have a new job coming in that this would be perfect for so hopefully you can get it fixed soon.

Thanks
Derek

[cncdrive]

Hi Derek,

OK, thanks. I'm working on it.
It is not as simple as I first thought, there are several pitfalls which I did not think about, because I thought the G33.1/2 switches the spindle back at the end of the cycle and then things were simpler, but hopefully finishing soon and can start testing...

[spumco]

because I thought the G33.1/2 switches the spindle back at the end of the cycle and then things were simpler,

I think this is the problem I've been having with the Fusion 360 post processor. Autodesk seem to have fixed it, however, as the new post outputs an M5 after the G33 line, then the move to next hole, then an M3, then the next G33.1/.2

They finally got the hint that G33 isn't modal in the last revision.

-S

[cncdrive]

Hi Derek,

I fixed the new Q parameter issue for the rigid tapping and attaching a test UCCNC exe file here.
Just unzip the file and replace the UCCNC.exe with this one.
This exe works only with the latest 1.2032 UCCNC test release!

And please let me know how it works when you will have some time to test it.

[Derek]

That fixed it. I didn't tap anything yet though. I have something setup in the mill right now but I'll have it done in a couple of hours. I'll run a test after that with an actual tap.

[cncdrive]

Hi Derek,

OK, thanks. Good to hear the Q parameter seems to be working OK now.
This time we've tested it with an encoder.

If you will have a change to test it on your machine then please give me feedback about how it worked.

[Derek]

I was super busy but I did use it on 8 holes on a paying job no less! It worked just like it should. Did one set with a .125" peck and one with a .25" peck.

Now if you could have it measure the Z axis over travel on the second to last peck and apply that to the last peck you could really do some accurate depth control.
So if the total depth is -1.0" and the second to last peck was commanded to -.875" but it actually went to .900" then it would subtract .025" from the final depth.

I basically do this already. on a part where I need to hit a depth I film the Z axis DRO in slow motion. I look at it's final depth on the video and subtract that amount from the Z depth in the code. I can get it really close this way. On my Bridgeport it runs right around .050" for smaller taps. I run the same spindle RPM on most all tapping for simplicity.

Thanks for making the peck cycle happen. I will use it a lot. Having a machine that (semi) rigid taps has made things so much easier. especially when I'm prototyping something.

Derek

[cncdrive]

Hi Derek,

Thank you for the feedback about your test, it sounds good.

I understand what you saying about recalculating the depth based on the previous cycles overrun and then adjust at least the last pass depth.
However I have one concerns about implementing this:

Do you think the overrun is the same as you go deeper and deeper with the passes?
My fear is that the deeper the tool goes the less the overrun will be, so if the overrun is based on the previous overruns then the final depth may not be reached if the previous overrun or overruns avarage is deducted and if the last overrun is shorter because there is then more friction. Ofcourse we could use a simple multiplication or something like that, but then the function could become confusing to understand for the avarage user.

And currently the API does not report the overrun back to the software side, simply because this information was not needed so far,
so if we want to implement this then we will have to pass this info back to the PC side which requires some extra work.
Can be done, but not as simple as adding the Q parameter.
Or we could just wait for the pass to completely end for the motion controller to resyncronise the coordinates, but that would slow down the process a bit,
so passing this info back as a separate event would be much better I think, but as mentioned that needs an extra API function.

So, what do you think about the mentioned concern I have?

[Derek]

Hi Balazs
That's why I suggested you pic up the data from the second to last pass. With a low horsepower spindle the overrun will be less since the tap will act as a brake. With a high HP machine it's more a function of VFD braking ability.

How does peck work if the Q number is not an even division of the hole depth? Does it correct on the last pass or spread it out over the number of passes.

Bottom line is I would rather have it correct shallow than do nothing and overrun.