Advanced Search

Nice, thanks for sharing.

Just for the record:
The whole direct push rights discussion doesn't interest me in the least.
What interests me is when people directly push changes that break a pull request that has been pending for 3 weeks. That in itself would only have been a mild annoyance but when that person then comes out completely disregarding the fact that he has just driven over somebody else's work and claims that to be ok because he has done that for the last 23 years to change code he considers his 'own' and that he just doesn't understand what the issue is all about then I find that very, very annoying.
A simple 'Oh sorry I didn't see that at all' would have been all that it takes for me but apparently that is maybe too much to expect.
If you feel disrespected by having an experienced programmer making a single legitimate and constructive comment about the code you are committing to a collaborative project then I consider that to mostly your problem.
And with this I also rest my case.

[edit]
Since Chris has asked for context:
sourceforge.net/p/emc/mailman/message/59393097/

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.

Aciera wrote:

Exactly. The other problem is that there are some people who have their work inside the code base and think that they now 'own' 'their' part of the code and are thus above having it reviewed.

Also I _very_ much hope that LinuxCNC as a project has moved past the stage where somebody can 'just add' a new GUI to the master branch.

I see you're keen on taking things out of context and bending totally unrelated words. No worries. Here's the context for anyone who cares:

sourceforge.net/p/emc/mailman/emc-develo...OOK.COM/#msg59393097

github.com/LinuxCNC/linuxcnc/pull/4580#issuecomment-5833848754

github.com/LinuxCNC/linuxcnc/discussions/4566

I never purported to 'own' anything, nor did I ever call QtPlasmaC 'mine'. I believe quite the opposite in fact, PlasmaC and QtPlasmaC are the product of everyone who contributed to it over the years and there have been many. It's true that I hold the distinct privilege of being called one of the "maintainers" of that portion of the LinuxCNC project. Which is traditionally how GUIs have been handled.

I feel very strongly about the work we've done; I'm proud of it in a way I don't expect you to understand. The complete ignorance and disregard of not only the history but also the literal thousands of hours of coding, painstaking reviews, diffs exchanged, emails, forum posts, spreadsheet bug trackers, passionate debates, ideas, time spent in front of a plasma cutter, etc. is ... disappointing.

Similarly it's what disappoints me about the way Chris was treated.

I apologize JT, you may have your thread back.

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.