Advanced Search

possibly but if you follow the updated how to sticky thread (1st post) , we don't use the igh repo anymore.

Is there a way to prevent the .hal file from being overwritten? If you manually edit the .hal file, everything gets overwritten by pncconf. Is there a setting to ensure that only the parts that were actually modified get overwritten in the .hal file?
Thanks,
Hans

So, is it best to ground the 5V and 24V negatives?

flyingbrick wrote:

... and I measure about 100VAC between 5V- and cabinet earth.Does anyone know what specifically causes CR7 to latch on like this?

The answer to your question is there in your question, 100VAC is way to much interference, so the grounding is non existent if that is happening inside a metal box.
Does the shop have proper grounding and a ground fault interrupter?
Is the machine grounded through the mains cable, properly on both sides?
Is the power supply grounded to machine/control box ground?

Just for safety, and noise I would ground the 5V common.

The Init LED can illuminate for power related issues (check the 5V at the 7I97T)
With power related issues, the Init LED typically blinks.

The other cause of the Init LED being illuminated is because the watchdog
has bitten. This usually indicates either a latency issue with  the host, some
general communication fault or the watchdog timeout set too low in the hal file.

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)

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