Advanced Search

Today a question was asked on the forum: why so many gui in linuxcnc?
I always thought that it shouldn't bother anyone because at worst they don't have to use it.
But today I started wondering if this garbage can makes any sense.
Well, I have always been curious what this Qtdragon is and whether it can be useful for something.
Since I always compile linuxcnc from source, I never managed to get this GUI to work.
Recently RuntimeError: module compiled against ABI version 0x1000009 but this version of numpy is 0x2000000...
I can't downgrade numpy to version 1, because I need version 2 for other programs, and besides, apt, together with numpy, wants me to uninstall a dozen or so other packages because they have dependencies.
I downloaded qtdragon from github.com/persei802/QtDragon_hd.
The repository looks fresh, but it's not and it want the old numpy...
Today curiosity got the better of me and I launched Qtdragon with linuxcnc_2.9.10-amd64.hybrid.iso.
Here Qtdragon started up, but my worst suspicions came true.

I simply have the mind of an engineer and I hate "artists" who spoil formally good designs to make them bad but nice...
What's the point of a small gray font on a gray background?
LinuxCNC is not a game that you can run in a dark room and then a dark interface actually makes sense.
LinuxCNC is a machine control that can be dangerous and there is no room for anything "nice".
It is no accident that the e-stop button has a different shape and color than the start button, so as not to look for it and not to confuse it with another one when the machine starts to live its own life...

I know that someone will soon start explaining to me that the authors do it for free and I should be grateful to them.
No, that's not true.
If something works badly or doesn't work at all, there is no reason to be grateful, because why should it?
The rule is simple - if you do something, do it well, and then people will be grateful to you, even if they have to pay for your work...
 

It might be a nice idea, but it's not really working.

(I have sold 4 out of 25)

Aqui estão meus arquivos. O encoder está lendo corretamente e o motor funciona em modo de malha aberta, mas quando habilito o controle em malha fechada, o motor começa a vibrar.

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.