Retrofitting a 1986 Maho 400E

Got everything rewired to the 7i77 and changed the pin names, everything works like it's supposed to! Now I'll finally get to servo tuning. Watched a very nice tutorial in German on the subject by the Youtuber you recommended, and even though I understood only some of the words he said, the process was laid out very well in an easy-to-understand way. Don't remember his name but that guy makes awesome tutorials.

Talla83. He is also active on the CNCEcke.de forum. Very bright young engineer, who's videos also helped me a lot.

I hope you get that machine back up and running today. It has been discussed before, but it is probably easiest to implement two (or three) complently separate LinuxCNC configurations, as separate machines. One the HF spindle set up, one for the MAHO vertical spindle with the gerarbox.comp, and maybe a third for the horizontal spindle. SInce switching from one spindle to another is a significant job, restarting LinuxCNC is not a singificant burden. Not worth learning the HALfui necessary to make a single super clever HAL/INI which can switch on the fly.

Congrats for the PhD. Expanding the boundaries of science is an impressive acheivement.
Mark

I made some test cuts in plastic to see if there's anything visibly wrong with the cutting. Don't really know what I'm supposed to shoot for with all this servo tuning.

John suggests to start with setting P, but I find there's a range of values in which P doesn't cause any noticeable problems. In fact, the machine looks okay with Mark's values, even if it sounds a bit different.

The big difference is that the interpolator (I think?) takes control of the acceleration and braking vs the Philips where you set an X or Y and the machine didn't really show a very visible signs of speeding up or slowing down before it reached the programmed end point.

Is there a good way to measure the actual acceleration available on the motors to really nail this value down and set it to get the best results? I cranked it up at random for the X axis and it does have an effect on the cutting vs the Y. In plastic, if you don't move fast enough, the chips don't evacuate properly. The Y from a dead stop had a speed up period which showed in the cutting, while the X with its higher acceleration didn't show the same behaviour.

Maybe measuring the ramp in halscope to see how long it takes to achieve the set speed? What did you guys do to set it up on existing drives?

I'm not getting any following errors on any axis without doing anything to Mark's values btw.

The communication signal between indramat and mesa (-10.. to +10volt) is a speed signal.
In theory only a value of ff1 should be enough to for the system to do its job, P and ff2 can help to reduce imperfections of the system.
So if marks values are perfect for his system because you are using the same scales the main tuning parameter (ff1) should be very close (in theory)
The P and ff2 witch is there to correct things it should have different optimum value
The MAX_ACCELERATION in the ini files should be different because the machines have different motor and different weight (inertia) in the axis, if this value is beyond machine capabilities then the result will be a lot of ferror (and a lot of frustration) in the beginning and at the end of motion.
I am not a tuning expert (not even close), so plz correct me if I am wrong
John

Thanks John, that's one method of finding optimal acceleration values for each axis then: measure ferror for different settings and find the best ones.

I was thinking there was another way also because the calibration menu of the machine doesn't allow you to change acceleration values, and it's necessary to close LinuxCNC, change parameters in the ini and restart the controller and halscope.

It's stuff like this when actually knowing the theory of what's happening and understanding the underlying physics would take the process to another level.

On a related note, if anyone of the fine people helping out in this thread ever goes to Poland for some reason (especially Mark!), the drinks are on me

Mark, did you leave the default base period of 1000000 for any particular reason? I know that it's not very important if you don't do software step generation. My latency test gave me a jitter of 22405 on the Intel i3 processor. Shouldn't the machine know that value even if it's a servo system?

EDIT: nevermind, the documentation says not to change the servo period.

I set it up the axis motion with the original Y Axis EXE, which would start drifting after a few minutes, but hadn't identified that at the time. I set the current acceleration as I had a few E-Stops for following errors at higher accelerations.The following errors and acceleration set in my ini could have been compounded by the drift problems, so I really need to revisit the tuning/performance values now that the encoder feedback is robust.

If you ramp acceleration slowly, then the drives keep the axis extremely close to the desired position (minimal FError). If you want to do high acceleration with a low power, high inertia or "soft" system, you have to accept greater position errors during accel/decel. Setting narrow Ferror limits the allowable acceleration on a weak soft machine. If you have an extremely stiff drive train, low inertia and high power, you can keep that Ferror small even with high acceleration rates (modern VMC's). I have no real clue of what Ferror values or acceleration rates are considered acceptable/normal for a machine in this class, so it is possible that I unecessarily limited performance through a poor choice of those parameters. I was sort of disappointed by the MAHO's performance in that regard, but have never used a Phillips 432, or seen a Maho run under such control.

You mentioned that the acceleration under the Philliips seemed nearly instant.That would make sense given that the indramat motor/drives and large diameter ballscrews should be a reasonably stiff and powerful combination, engineered to match the MAHO's inertia. LinuxCNC must be able to match whatever performance the Phillips had, as that is limited by inertia, stiffness and motor power, which haven't changed. I would appreciate if you could try and set up the motion performance to match what you are used to from the Phillips, and share your INI values.

I haven't made it to Poland yet, closest I have been so far was Usedom and Ostrava. If I get up to there I'll let you know.
Mark

Thanks for the detailed reply. I am currently PID tuning to get better performance. Your parameters made the machine extremely sluggish in comparison to my previous experience.

As an example: I've been cutting acrylic at the allowable Philips max feed of 1500. The changes in direction were rather abrupt (no lookahead), but never did I get the impression that the machine couldn't accelerate fast enough. You'd start seeing some kind of lag at G0 (3000/2500/2500 mm/min X/Y/Z), but if I could have tried cutting at those feeds (spindle speed permitting), I'd do so for sure. I just didn't see the limit in that area, I thought the speed issues were more related to the gear reduction and low initial motor speed, not acceleration.

Then again, the machine was originally tuned by guys who did only that all day for many years. I think they squeezed those drives for all they could (reasonably).

What Linux does that's annoying in comparison is arbitrarily (or more likely based on the parameters in the ini) creates a velocity ramp on rapid moves. You get a very pronounced speed up/slow down effect which wasn't present on the Philips at all.

I guess it's all related to the trajectory planner somehow but in that case it's our job when tuning to get it to work as best as we can. In all fairness though, once you have the machine up and running, this tuning process is about as fun as sanding wood with very fine grit sandpaper.

EDIT: within the given limitations, the drives should feel very responsive. When I used to control the machine with the original pendant in step mode, 1mm felt really fast and abrupt. The frustration was more down to rapids across the work envelope (600mm travel in X for example is when you see that 3m/min is slow).

What Linux does that's annoying in comparison is arbitrarily (or more likely based on the parameters in the ini) creates a velocity ramp on rapid moves. You get a very pronounced speed up/slow down effect which wasn't present on the Philips at all.

I guess it's all related to the trajectory planner somehow but in that case it's our job when tuning to get it to work as best as we can.

That is good to know, as that ramp is directly driven by the acceleration value set in the INI. There is nothing inherent to LinuxCNC limiting that performance. The trajectory planner helps to keep velocity high by avoid using the machines accel/decel where you don't need to slow down if the next line of code is in a similar direction. I didn't touch the Indramat's settings. I figured anything I could do would only screw up what MAHO did well. The Indramat knows nothing more than it's commanded velocity. If the Phillips had a much larger value for acceleration, and thus much steeper ramping it could mean:
A/ My tuning sucks, and a little sanding with that fine sandpaper will return the Maho it its former glory.
B/ The Maho engineers accepted significantly greater following errors, and we should too. They know way more about this stuff than we ever will.


My bet is on option A.