I had another look at the MuellerNick video, and see what you mean. Did you notoice that Nick posted a video last week? He has been absent from the internet for a few years, but the video is a teaser of what looks like a new workshop.

I think Andy's solution with the harmonic drive has got to be the better approach. However, as tempting as it would be to get started on a fourth axis, I am going to be strong and continue to work on my two axis MAHO, hopefully on day fixing the vertical encoder to make it a three axis machine.

Although I was counting on Bob for quality assurance, it turns out he was napping on the job, day dreaming about rotary axis, and failed to notice that I only wired one side of a switch...

So I had to fix that.

Then started mounting the two PEC-16 rotary encoders.

These ones have the push button function which will be set up to reset the feed and jog overrides back to 100% and a set standard respectively. Luckily there were two spare nodes on the 5X5 matrix_keyboard, so I can wire those buttons in there.

This browser does not support PDFs. Please download the PDF to view it: Download
PDF

It is much easier to make an incremental encoder accurate and linear, and quite hard to make a resolver linear. (which is why they are expensive). Typically a resolver (being analogue) will have worse linearity/accuracy but better resolution than an encoder.

Yesterday I wired up the Encoders. I'll recycle the exisiting 21x 0.14mm² cable which connected the Phillips keyboard, and put two connectors on this end. Bad planning on my mark, as I could have done it with a single dSub 25.

I'm on vacation, but a friend who is a programmer is helping with the gearbox control COMP, and needs an explanation if the direction reverse pin of the MAHO's gearbox control so I'll upload it here and link it to the GITHUB for his COMP.

We are trying to understand Dominik's gearbox comp, and create one which is well commented and easier to support. For this Jin has created a
GIT
.

One question which came up. If the G code file has an S90, but the gearbox comp can only set 80 or 100rpm, does Linuxcnc need a feedback that a different speed was set? I am assuming (dangerous), that linuxCNC doesn't care. The S word is encountered, which triggers the gearbox comp, it does its thing, and when it signals it is finished, LinuxCNC goes on to parse any other G or M codes on that line, or moves to the next line, and doesn't check whether the S speed it passed to gearbox comp, is the same as the speed set when it regains control. Or is this incorrect?
Mark

Today I got some time on the MAHO, so I used a surplus cable from the Phillips control panel wiring to pull a Cat 5 and a USB extension cable through the conduit, and then mounted the user control panel for the first time.

When I next pull it back off, I need to hack the top off that mount arm, and weld it back on with the offset pointing forward, as this control panel needs to be further forward than the Phillips was.

Still a fair bit of wiring to do, as I need to reterminate the existing 21x0.14mm² Phillips keyboard cable with a 15 pin and a 9 pin dSub connector on one end and terminate it into the Mesa 7i77 on the other end. There will also have to be some sort of disconnect for the various hard wired switches (E-Stop, E-Stop release) and the 5VDC power to the USB hub.

If anyone is interested, I have been putting everything I learned so far about the MAHO gearbox onto a
GitHub Wiki
Mark

RotarySMP wrote: One question which came up. If the G code file has an S90, but the gearbox comp can only set 80 or 100rpm, does Linuxcnc need a feedback that a different speed was set? I am assuming (dangerous), that linuxCNC doesn't care. The S word is encountered, which triggers the gearbox comp, it does its thing, and when it signals it is finished, LinuxCNC goes on to parse any other G or M codes on that line, or moves to the next line, and doesn't check whether the S speed it passed to gearbox comp, is the same as the speed set when it regains control. Or is this incorrect?
Mark

Also Dominik or John, could please explain the gear motor control pin MOTOR_CENTER_POS and it's usage? If you have a motor energising pin per motor, and a direction reversing pin, then I would assume getting the center position simply a matter of stopping in the right position ones the the correct feedback switches close, so what is this output for? I am missing something here.
Mark

If we need to go to the right position then the motor must turn right no matter what is the current position, if we need to go to the left position than the motor must turn left no mater what is the current position. But if we need to go to the middle position than the current position will determine the direction the motor must turn. This is what the left-middle cam tells to the controller, if the left-middle is on then the motor must turn right, else turn left. The others three cams are for stopping the motor once the position is reached. And the last cam, the one that is not connected to the controller is for slowing down the moto if we need to go the middle position so the motor will not overshoot.

RotarySMP wrote: One question which came up. If the G code file has an S90, but the gearbox comp can only set 80 or 100rpm, does Linuxcnc need a feedback that a different speed was set? I am assuming (dangerous), that linuxCNC doesn't care. The S word is encountered, which triggers the gearbox comp, it does its thing, and when it signals it is finished, LinuxCNC goes on to parse any other G or M codes on that line, or moves to the next line, and doesn't check whether the S speed it passed to gearbox comp, is the same as the speed set when it regains control. Or is this incorrect?
Mark

The controller does not care if you have commanded 90 rpm and the true speed is 100 rpm, it will continue doing its job. I don’t think that 10% off in the spindle rpm is much of a deal, but you can always fine tune the feed rate to match the spindle speed.
John