Advanced Search

Looking more carefully at your hal file:

setp joint.0.jog-vel-mode 1

Means that the jog will continue as long as jog count <> 0

(this is normally intended for input devices like joysticks that return to 0 when not pressed)

for position mode jogging with a MPG, you should have:

setp joint.0.jog-vel-mode 0




 

I found it.

Ok, I didn't find the reason but I found a way around it.
It always crashed for me with "libusb: debug [libusb_unref_device] destroy device 3.109"
I ran it in the debugger and saw it stopped with a SIGSEGV.
After spending too much time figuring out how to turn on core dumps, I got a core dump.
Here is the stop point.  

 

The one wonders what ctx_log_handler is
I commented out this line in libusb_unref_device()
 
and then the xhc actually restarted.
Here is the log of that. 

were you able to get it set up and working?

how do i change the pref_edit.py from this one out of the forum with mine becaus when i am just copy paste than occurs an error . regards tom 

The links : NativeCAM-Python3-Debian-12-Installationguide2026-02-20.pdf
: forum.linuxcnc.org/media/kunena/attachments/40714/pref_edit.py

Amazing support Peter, but I really don't understand the expectation of the original post. 

Your Mesa cards are very resonably priced. You have obviously put years of work into designing and updating these cards, and provide outstanding support to us here in the forum.

Someone reverse engineers your work, floods the market with knock-offs, undercuts your livelyhood, and then expects support?

You are a better person than me Peter. In your place, I would be tweaking Mesaflash to brick any knock off which gets connected to it
Cheers,
Mark

something like this:

 

and it will generate the code for all FPGA's and MCU's

the interlinks are RS422 over RJ45 cables (like smart-serial)

Ok, got it, good to know - and I do not know that much about Linuxcnc and lastly, Pnnconf / MESA stuff. All new.

But, all limits working now. I just need to check the probe setup - think that I can do after the limit switch and HalShow stuff initiation.

But, my ESTOP is still beyond me. Saw threads where JT and I believe a few others talked about inserting lines that linked the ESTOP pin to other pins or feedback - tries several but beyond me once again. 

ESTOP - loaded all pins and all ESTOP, Abort, Charge pump references into HalShow, enabled [it's a NC switch] my external ESTOP button and nothing in Halshow changed color. Yes, my external button is wired into the mx3660, and yes it shuts down the motors on push.

I tried to move the ESTOP to different pins that were open and then Halshow - no change. The probe pins work in Halshow so I know that is at least on the right pin and gives feedback - I can figure that out.

So any suggestions on ESTOP? Else I will live with it the way it is. Still have a lot of changes to do with travel and positioning in the ini for axes but that's easy stuff, just takes me a little longer one step at a time.

Thanks.
at the moment, i rewrite the riosub stuff in the dev branch and the riosub plugin will be removed in the next release.

it will be replaced by uartsub+uart/satmcu (i need other names for that plugins, something with 'satellite').

The reason is that you can then edit everything in one configuration and thus always have the overall picture in front of you.

Then you can also use microcontrollers as satellite-board and configure them in the Flow GUI.

You are doing awesome things, I plan to start testing Riosub in the near future, hopefully I can contribute something useful !

I don’t have anything in those files. I’m very new to Linuxcnc so maybe I missed a step somewhere to set those files up? 

Moin,
ich würde gerne die ena+ und ena- Eingänge meiner Leadshine DM856 bei einer Mesa 7i76e beschalten. Wenn ihr euch die Anhänge anseht... nach welcher Schaltung muss das geschehen? Spontan würde ich nach PNP sagen... nur ist das richtig?
 

Wow, wow and wow! Great job. Thank you so much 

I get the same error there too (see image).

Would it be possible to activate debug mode in the configuration? This will generate a more detailed error message, which may be more helpful.

PS: If you would prefer me to write in English, please let me know. I'm happy to do so, as I'm the one with the problem, not you. 

 

Vorher wurde durch die Steuerung ja über die Glasmasstäbe positioniert, da war das Umkehrspiel weniger ein Problem weil die Steuerung das für die Positionierung ausgeglichen hat, wenn man bei den wirkenden Kräften (Gleichlauf-, Gegenlauffräsen) und der Anfahrrichtung aufpasst lässt sich trotz Umkehrspiel relativ genau arbeiten.
Meine Aussage hat sich vorallem auf den Motor Encoder bezogen, der würde die Ungenauikeit ja nicht mitbekommen. Wenn die Anzeige der Heidenhain Steuerung noch geht, kannst du ja damit auch erstmal abschätzen "wie schlimm" es ist und dann immer noch Umbauen auf einlesen der Masstäbe.
Welchen Servoantreib und Umrichter hat du den verbaut? Wenn du da einfach an die Encoder Informationen kommst sollte der Aufwand das zu testen ja nicht allzu groß sein.

Marcos wrote:

To prepare proper adapter templates for your two drives (the Lichuan OL57E-4A and the Stepperonline A6-750EC), I just need a few details from your setup so I can map the HAL pins correctly.

If possible, could you share:
1. Your LCEC configuration
• lcec.conf (or equivalent configuration file)
• The EtherCAT XML/ENI if you have it
• Or a snippet of the HAL where the lcec.* pins for the drives appear
2. PDO mapping
I mainly need to confirm the HAL pins for the standard CiA402 objects:
• 6040 Controlword
• 6041 Statusword
• 6060 Modes of Operation (command)
• 6061 Modes of Operation Display
If available in PDO as well:
• 6064 Position Actual Value
• 607A Target Position
3. Homing
• Which homing method (object 6098) you plan to use
• Whether the homing/limit switches are connected to the drive inputs
• The HAL pin names for those inputs (for example lcec.*.din-*)
4. Quick Stop
• Is Quick Stop (Controlword 0x0002) configured and usable on these drives?
• Or do they require a different shutdown sequence?
5. Anything unusual
• Any known quirks with enable, fault reset, or homing behavior.

 

Later tomorrow I should be able to gather some of the info you requested. I know I will have hal pins, lcec.conf, PDO/SDO, and a terminal log from test driving these servos.

I have not looked at CiA402 homing at all yet, I will take a quick look at the manual to check whether I have a preference which homing method I'd use.

One potential quirk I noticed with the Lichuan OL57E-4A was if I test drive it in velocity mode (I was typing hal commands at the terminal) I then can momentarily disconnect the servo amplifier power, shutting down the servo amplifier and resulting in a flood of ethercat error logs in dmesg, in a second or two the drive recovers and ethercat reconnects, and the motors resume rotating at the velocity I had previously set in lcec.

This is hardly a problem, as we will be running in position control mode. I expect a servo drop-out like that would at least trigger a following error in a standard linuxcnc config. It did not do that here as I was just running simple hal commands in the terminal directly to lcec without using CiA402.