Advanced Search

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!

Non-existant user wrote:

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

You can have both, try Assembly !

rodw wrote:

We have lost the ability to laugh at ourselves.

True.
Still, i am hell bent on retaining that ability.

I'm trying to install probing on LinuxCNC 2.9 using the Axis GUI.  The tab appears, with icons, when I run linuxcnc.  When I click any buttons, I get errors that certain pins are not defined (ps_probe and such).  These pins, I gather, are dynamically created by probe_screen.py. 

I'm not sure where in the sequence it is executed but it appears in the [DISPLAY] section in the EMBED_TAB_COMMAND variable (with -u) and the postgui.hal file.  In that HAL file, the current problem is that "loadusr -W psng/python/probe_screen.pl" causes linuxcnc to shutdown before the main GUI screen appears.  The debug info says that probe_screen.py did not return.  If I remove -W, the GUI launches and everything is fine until I try to interact with the items on the PSNG tab.

There are so many oddities in this install.  For example, in probe_screen.py there are many calls to _("some string") which is an adaptation for other languages.  Why it is used when gettext is not imported, I have no idea.  I made a pass-through function that returns the string:  def _(message):  return message. I feel uneasy about making changes like this.

I'm an experienced linux user, programmer, and electrical engineer but this is kicking my ass.  Has anyone else had problems like this?  Should I be starting with a different version or fork?  Is there some other way to get probing macros?

 

I did it a bit differently.

I wish I had thought of that earlier.

I added this function to the custom handler qtdragon file in the machine directory and now it works.

Non-existant user wrote:

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

Its really about progrmming  defensively so you can enjoy the journey.

Is dist-upgrade ever a good idea?

WHen I first started, it was never a good idea and we were warned not to do it. I might add after compiling the preempt_rt from source nobody wanted to run the risk of breaking things. Now we have made it all too easy and people keep wanting the latest and greatest which is not necessary on a CNC machine. But on a office desktop keep it updated.