Advanced Search

Hi Rodw,
have the EtherCAT keys expired?

BSAT wrote:

At this point I gotta think its a limitation/configuration of the servos that I dont readily have access too. By accident as much as I have messed with, it should have made a difference one way or the other. But it seems to be the same no matter what.
 

If:

• the machine is ok mechanically
• the autotune is sorted
• you have the appropriate servo settings from Tormach
• The G-code is 'clean' (no faceting in the code)
• Your M64 Pnnn is set appropriately, and
• Other Tormach owners report the same issue

Then it seems like the only thing left to do is modify the OEM steps-per-unit and see if that changes things.

You have the 'enhanced' version of the servo - that is, it's capable of higher input resolution than the 'normal' version (p/n ends in -RLN).  The ELN is capable of up to 6400 steps per rev, while the RLN is only capable of 800ppr.

The Tormach 1100MX configuration appears to use SCALE = 10000.0 in the INI file.  (tormach_mill_base.ini)
Tormach_mill_clearpath_ecm1.hal:
Assuming a 5TPI ballscrew, it looks like the Clearpaths are set to ~2000 pulses per rev.  You can verify this in Clearpath MSP software.

If that's the case, you can set the Clearpaths to 6400ppr input resolution, and edit the INI file to account for this increased resolution.

You may need to edit the INI file further to account for the decreased time between pulses:
I don't know what the hardware is that's driving the 1100MX, but if it's a Mesa board it will have zero problems outputtting a signal at that resolution & max speed.

If you get issues you can turn down the Clearpath resolution a bit, re-adjust INI file, and try again.

All of the above is free, easily reversible,and safe to test.  A simple, short jog after startup will indicate if 1" jog looks like about 1".  If everything appears to be OK, you can fine-tune the INI scale value if you find that the distance commanded isn't exactly the distance traveled.

Test short-ish moves at full rapid speed once you have the scale calibrated.  Do it with the spindle running as well to see if any electrical noise is affecting the increase pulse frequency.

Then test the cutting performance again.  WIth a 3x increase in servo resolution (a 3x decrease in distance per input pulse) the servo should both move and sound smoother.

If there is still no change in surface finish, and there are no mechanical deficiencies, then the problem may simply be the 1100MX isn't rigid enough or Tormach has changed/edited something inside the trajectory planner that causes this faceting.

Nice, thanks for sharing.

It's not really intended but is a known limitation of the planners, original linuxcnc planner as well.

This is part of the reason why I shifted focus on rebuilding the tp base. Which I am ready to share the first draft of, mind that it is still very much work in progress, although quite promising so far on my own testing.

github.com/grandixximo/linuxcnc/tree/tpnext-ma

set in your ini in addition to the jerk limits.

[TRAJ]
TPMOD = tpnextmod
PLANNER_TYPE = 1

This is the different approach which I mentioned in my previous post, based on my multi-axis branch, plus a new base for the tp, path based rather than segment based.

Thank you all for the continued testing and support, I do keep an eye here even if I don't always reply

Mine works

A new class for 3D stock has been added to `primitives.py`. It is suitable for XYZ machines but will not work with a rotary axis.
The sampling frequency is independent of the Vismach refresh rate (currently set to 50ms).
It automatically retrieves tool geometry from Vismach.

The toolpath handling in `qt_vismach.py` has been heavily optimized. It can now manage a much longer toolpath history without placing an excessive load on the CPU—effectively handling unlimited paths for typical use cases.
A small menu for selecting certain settings has also been added, with room for further options. It places almost no load on the CPU when the machine is idle.

I also created a test machine to verify the new stock functionality; although creating the solid is nearly identical to the existing methods, just one extra line of code is required. This machine does not define specific dimensions or positioning; it exists solely for testing the stock.

You want to attach those two files here? Or you could also open an issue on my github repo and attach them there:
github.com/Sigma1912/LinuxCNC_Demo_Configs/issues

Hello, does the N4D3E16 test work correctly? I'd also like to order one to try it out.

Hello,

The issue I was having with the checkout page was resolved by the webmaster.

Regards,
Brennen

And actually if you thing about it Flex GUI "is" a plugin for LinuxCNC.

You install Flex GUI using your favorite method apt, gdebi or command line and set the DISPLAY = flexgui it can't get much simpler than that.

JT

So to get back on the subject of Flex GUI it is the only GUI that is very flexible and requires no programming to create the exact GUI "you" want without knowing anything about programming. If you just have one axis that's not a problem, Flex GUI can be as simple or as complex as you want. No other GUI is easy to change the look and feel and function for a non programmer.

JT

There should be halui pins to do want you want to do. The halui docs say " halui is used to build a User Interface using hardware knobs and switches."
But over time I have found some guis use these pins which stops you from using them. guis don't have hardware knobs and switches so they should respect the boundaries of the original LinuxCNC design intent. I don't know if your GUI is using these pins or not.

I was looking into this as well. I have a 7i73 board to use in the control panel, and google AI was pretty helpful in getting me pointed in the right direction. I have not completed the project though.

by the way, i was looking at using encoders rather than pots. because there could be a disconnect between the pot position and what QTdragon is expecting it to be when the machine restarts.

Is the noise on the analog wiring side or the encoder side?
Are the original analog cables in use? If yes, those will have an analog ground and a general machine ground, should not be wired together, although i had a single case when it was a must.

BSAT wrote:

It doesnt change with feeds or speed changes or end mill changes. Its always there.

Does the rastering change with those changes?
Might want to try with a single or dual flute on some aluminium with the same high spindle speed and different feed rates to see if the distance changes, in general, if it does change would point to servo/tuning issues, if it does not would mean mechanical issue.
Would be nice to also do same feed rate, but vary the spindle speed.
Thinking of it, at what spindle speed are you cutting and what mill? I might have missed that.