Advanced Search

Hi Tom, with the new cable all four work. I looked for motors but they ask 200 euros, in your opinion are these drives valid or are new Chinese ones better?
I calculate the cost of the motors because the drives didn't cost me anything.

Perhaps an output is marginal because of previous damage

I would verify full 5V swing on all step/dir pins.

Here is a simple script to toggle all stepgen step and direction pins slowly:

 


Download then

chmod +x stepgens.txt

and

./stepgens.txt to run

Note that this needs a relatively recent mesaflash

github.com/LinuxCNC/mesaflash

I'm running version 2.9.3

When I open this link: developer.arm.com/downloads/-/gnu-rm, it says: This page is deprecated. See Arm GNU Toolchain for updated content and latest releases. Arm GNU Toolchain.
If I follow Arm GNU Toolchain, many download options appear. Which one should I download?
The truth is, I have little experience doing this type of installation from scratch, and it seems like what you've written on your Github is for experts. I don't know if there's a way to do all these processes automatically with bash.

Which version of linuxcnc are you using?

i cant tell as am not machining anything, just moving the machine.
with other files this doesnt happen, but the position errors still happens
a lot of times i have drivers out off op state, then back on, i can run the same hardware on standard linuxcnc without any problem

edit:
emcMotionInit: emcTrajInit failed
this message shows in terminal when i start the scurve ethercat config, is this a problem?.
 

C is a bit too simple for my liking.

The nice thing about Java is you can do almost everything with just the JDK, no add-on libraries are needed usually.

Python needs all these dependencies which are installed via pip, and I think it just makes stuff more likely to be incompatible.

Does it actually machine straight lines?

If it does, that's super odd, especially as those straight lines will cause higher jerk than a smooth curve.

i was able to solve it removing
addf cia402.0.read-all servo-thread
addf cia402.1.read-all servo-thread
addf cia402.2.read-all servo-thread
addf cia402.3.read-all servo-thread

now im running the machine but sometimes i have following errors that disable the motors, some arcs are beeng replaced for straigh lines and causing this, im trying to solve it now

i attach a printscreen from the gcode 




 

@lcvette I have LinucCNC 2.9 running on my computer now, installed using this:
linuxcnc.org/docs/stable/html/getting-st...th_preempt_rt_kernel
If I'm understanding the documentation correctly, the above link installs the Debian Bookworm distribution.

To install Probe Basic, do I start at the very beginning of this which seems to install Debian Bookworm.
kcjengr.github.io/probe_basic/stable_quick_start_apt.html

Or start here?
kcjengr.github.io/probe_basic/quick_start.html

@tiagounderground,
Those are EtherCAT errors, probably better to ask in the EtherCAT section of the forum.

I'm trying to run the last update on ethercat drivers but i have this error
HAL: ERROR: function 'cia402.0.read-all' not found
./cia402.hal:34: addf failed
HAL: ERROR: pin 'lcec.0.3.out-01' not found
shutdown.hal:2: unlink failed
24062
24076

am i missing something?

Alright, I found out that though the error looks identical, this time the MESA card is NOT the problem. The other good news is that the problem has become reproducible and the Joint Amplifier Failure now always happens immediately during the (attempted) homing procedure.

I can see during the homing attempt that the joint that has the amplifier error attempts to move - the other joint does not. In other words, I think that the servo with the alarm is the good one, and it goes into alarm because it fails to drag the other servo along.

It is still a puzzle though. By swapping port/cables/motors it seems that the common denominator is a port/cable:

 

The red path marks the one that has amplifier error in the different scenarios that I tested.

What puzzles me is that the common denominator in all failure scenarios are panel ports 2 and 3. However, I have measured the every wire several times with an ohm meter (as shown by the green lines in the image), and they are all fine. Since they are also not moving cables I cannot imagine it is a flapping connectivity issue.

So I am a little clueless as to what else I could do now. It seems every potential source of the problem was excluded.

Maybe EMI could have something to do with it, but... why would that suddenly become a reliably reproducible problem after running years with no issue?
Anyway, I also measured all the grounds on the shields of each cable, and they also seem fine/low impedance. (star configuration off of the panel, no loops)

Any ideas what else I can check?

I've been doing a bunch of machining on my freshly built mill running QTDragonHD and there's one thing that is absolutely throwing me off. I have a ton of experience running a Tormach on Path Pilot so I have established muscle memory for smacking the space bar to pause (feed hold) when proofing new code. QTDragonHD doesn't appear to have any shortcuts mapped to the space bar when a program is running.

Is it possible to remap the space bar to be pause (feed hold) when running programs?

Thanks!

langdons wrote:

Coding is not about speed, it's about the journey.

You can have both, try Assembly !