Advanced Search

I am configuring my CNC with a 7i97t, but I don't have that problem. I have a Mean Well 5V 10A power supply with a ground connection for the Mesa and the Raspberry Pi 5; the Mesa needs to be grounded near the RJ45 jack, where it is marked "frame ground."

 I'm having an intermittent issue with a Mesa 7I97T on a Raspberry Pi 5. Occasionally CR7 comes on and stays on until I reset the board.The 7I97T is powered by a Mean Well 5V PSU with no earth connection. The 5V negative is floating, and I measure about 100VAC between 5V- and cabinet earth.Does anyone know what specifically causes CR7 to latch on like this? Is there anything in HAL/HostMot2 I can log to find the cause?Also, should the 5V negative normally be bonded to cabinet earth, or left floating?
Thanks all!

tuxcnc wrote:

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...
 

All valid points, except the "nice" part, see new Mazak controls, they look like form a space ship. Did not use it yet, so no idea how usable it is.

tuxcnc wrote:

I know that someone will soon start explaining to me that the authors do it for free and I should be grateful to them.
 

OK, it is open source so you can modify it to however you like it, see bellow

tuxcnc wrote:

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...
 

"Do it well" for them might not always be well for you or me, and i am fine with it, as i can modify as i see fit, and be thankful i did not have to do the whole thing from 0.
-
Seeing as you are quite good at this, i wonder, would it have taken less time to change the colors instead of this?
I would really like to know, and i do not mean the time it took to make it work for you, i am aware that can be tricky sometimes with versions and stuff, and i had my fair share of numpy issues.
Thank you.

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)

Aciera,
This is really hard for me to say as i was the one who nominated you for becoming a moderator here, but you consistently keep ignoring the fact this is a community of humans, and as such, we (you included) inherently make mistakes and do stuff or express in ways others might or might not like at any given point in time.
I have read everything 4 times by now, i still do not see any reason for taking things out of context and attacking Chris and others, nor did any of the other humans included in those conversations.
-
Again, this is very hard for me as i absolutely admire your ability to help here with your wealth of knowledge and very concise replies to even the most complicated questions, but this?

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.

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