Advanced Search

Any that you do find will be second-hand. And old.

I would follow PCW's advice and change to a supported FPGA card. The 6i24 is in-stock at Mesa, but would need a PCIe motherboard rather than PCI.
It doesn't look like Mesa have stock of any full-size PCI cards at the moment.
(The 5i24 is the PCI version of the 6i24 but shows as out of stock)

The 6i24 will work with the same daughter cards as the 5i20.

It would be necessary to change "5i20" to "6i24" throughout the HAL file too.

No, there hasn't been a 2.10 release, and that was the development version when my email was sent.

This is the state of the .comp in the 2.9.8 release tag.
github.com/LinuxCNC/linuxcnc/blob/v2.9.8...nts/toggle2nist.comp

(no debounce pins)

So far so good. Next big thing is the wireless jog wheel. 

Okay I changed it and there was no improvement. 

Thank you in advance =) 

ruediger123 wrote:

Hello,
I try to integrate the security plc from Sick Flexi Soft via ethercat but I get the message that bitLen only allows 32 bits.
Are the restrictions limited to Linuxcnc-ethercat or do they also apply to the IGH ethercat-master.
 

 

Did you manage to integrate Sick Flexi Soft Safety controller with IgH Ethercat?
I can set the Sick safety controller in operational mode but can not able to get the data exchange correctly. Probably configuring the pdo incorrectly.

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 !