Advanced Search

Ok here is the right file for 2.9 version.

As for the other error, set a probe tool number on the probe page - it defaults to black which won't be read correctly.

hold on I did it for the wrong version of linuxcnc... stay tuned

I assume you are using qtdragon_hd:
Ok in your config folder there should be a folder: qtvcp/screens/qtdragon_hd

In that folder add the file included here, name it qtdragon_hd_handler.py
Then run as normal.
If any thing goes wrong just remove or rename the file.

Chris

i believe all non-cnc encoders (OSA/OBA 14,17,18,24) answer on both MR and MD pairs simultaneously. OSA253/104/105 only answer on MD so you need to use 4 wire connection with them.

I've made my own motordrive and used the Mitubishi encoders extensively.
I have tested several motors, from the MR-PQ, MR-MFS, MR_SFS and MR-KP
series. They all seem to use the same protocol and checksum. Some types
use full-duplex communication and others use a single bi-directional
version.

From what I have seen, it is important to poll the motor at a fixed
frequency of 4.5kHz.

My source code is available at:

github.com/mark-v-d/motor_control/blob/h...4400/src/encoder.cpp

The class mitsubishi_PQ_t is the full-duplex version of the protocol,
and mitsubishi_MFS13_t is the half-duplex implementation.

Basically start sending 0x1a at 2.5Mb/s at 4.5kHz and the encoder starts
responding. There is a checksum at the end of the packet.

Great!

Yes, I would be interested to fix it, if you would be so kindly to guide me on how to do it.

Thank you very much Crhis!

I connected a second PC to test wether the PC or the mesa board is dropping the connection. The result is the second PC works well for well over 20 minutes without interruptions or errors. it seems as the disconnected link was caused by the original PC. 

Ok the fix was pretty simple and i have pushed it to 2.9 and master.

i don't know when a new release of 2.9 will be as there was just one done.
it is possible to add a customization to your current system to fix if you are interested or you can edit a file on your system to fix it.

Just completed a successful installation of LinuxCNC version 2.9.8 on a Pi 4 with 4 gig of RAM.

Thanks to forum user "NWE" for recommending the version to download, named below:
2026-01-21-raspios-lcnc-2.9.8-trixie-arm64.zip

After downloading and using balenaEtcher to flash a 256Gig micro SD card, it booted to a Debian 13 Trixie style desktop and opened a "boot wizard".  After creating an account, the wizard recommended loading updates.  There was trouble after that, the login dialog box wouldn't accept any userids/passwords.

After rebooting and choosing NOT to load s/w updates, everything worked fine.  

I'm using LinuxCNC to retrofit a 1990's vintage Intelitek ProLight 3000 CNC lathe.  The original lathe was controlled using proprietary h/w and PC-based s/w.  I acquired a Mesa 7i76EU board as recommended by Mesa Technical Support so the journey is underway.

I see that LinuxCNC has a Mesa board config tool so I'll use that.

Any advice or coaching for me as an absolute LinuxCNC newbie is much appreciated.

 

I try in the while a fresh 2.9.8 installation and the problem persist but it returns an a error window with this messagge:
"Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/qtvcp/widgets/basic_probe.py", line 261, in probe_btn_clicked
self.start_probe(cmd)
~~~~~~~~~~~~~~~~^^^^^
File "/usr/lib/python3/dist-packages/qtvcp/widgets/basic_probe.py", line 183, in start_probe
if int(self.lineEdit_probe_tool.text()) != STATUS.get_current_tool():
~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: '' "

And the attached report once I close the window.

I have used ST-link for EC500 programming (MIMXRT1052 too) but under Linux and with OpenOCD.
I don't know is ST software compatibile with MIMXRT1052 (I suspect not), but there is no reason to try this if OpenOCD works well.

That´s it. Thank you very musch Crhis!!!

I also see that problem is master branch.

So I won´t resolve the problem updating anything, it´not a version issue.

Thank you.   
For a Rtelligent R6L028E I get to the installation stage where I can test for:

ethercat slaves -v      
and
ethercat pdos          
but
ethercat sdos        returns nothing. Is this to be expected or am I doing something wrong ?

Ok I see the probe screen is showing but the tab selected is main.
I also see that problem is master branch. I'll investigate.

ST-LINK (the hardware, at least) actually works fine for programming/debugging other vendors' ARM-M series ICs- used it a lot in the past for Nordic's nRF52 series. I was using OpenOCD, not the ST-LINK SW, though, and have never tried on a Cortex M7.

First thing is to triple-check connections- that you don't have wires plugged in off-by-1 in a connector. Also that everything is actually getting power (and what voltage it's using- 1.8V, 3.3V, etc.). I don't know where you got that pinout, but making sure it's correct wouldn't hurt.

It's been a while, but IIRC some ST-LINK models require you to have a target voltage reference connected- that may well be what the "???" pin is. It may help to probe that pin and figure out what it is and post exactly which ST-LINK you're using- official ST-LINK V2, some knockoff, the ST-LINK built into an STM32-Discovery board, etc. Again, it's been a while, but IIRC some of them have limitations I don't remember off the top of my head- might be they only worked at 3.3V and we were using 1.8V systems? My recollection is that the official ST-LINK V2 (not the isolated model, not the mini model) is the "good" one that works with everything.

You can also try reducing your SWD frequency to see if that helps, but I wouldn't be super optimistic.

Finally, I see in the MIMXRT1052CVL5B datasheet "Support for 5-pin (JTAG) and SWD debug interfaces selected by eFuse". I didn't probe further, but that implies that SWD could actually be disabled.