Advanced Search

Your answer is a technical explanation of why this is the case. However, I look at it from a user perspective. I take it that there is unnecessary information in manual and MDI mode. I understand that removing this is extra work, but it is not unsolvable.

zz912 wrote:

Is there any reason why "G-code properties" is also displayed in manual and mdi mode?

It is there in manual mode as well, because it is part of a box that is displayed in all modes, so this is also displayed in all modes.

At long last, here it is:

Hello dear EC500 users,

same as Thayloreing , I had a quite frustrating time trying to flash my EC500 over the last months. And there still is no success. So I am considering quitting the whole thing but I want to give it a last try by registering to this forum.

The problem is to get the firmware into the flash... and I did not find any solution that is working for me. I even can not reproduce the video from scotta with the reprogrammed STLink/V2 stick.

I tried:

• Modified STLink/V2
• DAP Link probe from Aliexpress
• JLink Edu mini

on

• pyOCD
• MCUExpressoIDE
• On Windows and Linux

I was not able to use the modified ST-link/V2 stick (as in the video from scotta) as a mass storage device under Windows for drag and drop usage. It simply does not show up in Explorer. I checked this with 3 different computers.

The DAP Link Probe is being detected under Linux and is attached to /dev/ttyACMx, but flashing with pyOCD leads only to the prompt: no ACK.

Using both probes under MCUExpressoIDE under Linux is useless, because they are not detected at all. JLink shows up, can be selected but stops programming by stating: can't stop CPU.

The EC500 seems to be a quite nice piece of hardware and I would like to use it in my projects.

Is there a working solution to flash this board available anywhere? I was not able to find any reliable solution what so ever.
Further on: Is the programming interface on the EC500 even usable? And what pins has to be used? There are:

• VCC
• GND
• SCK
• SWO
• Boot_MO
• Pro_B

Is this a sufficient pinout for a  working interface for SWD? SWO is for CPU output, not for data input. And what are Boot_MO and Pro_B good for?

I hope for any help on that topic. Programming a MCU should not be that complicated...

Cheers Julius

Hi, I have finished the lathe with ethercat drivers. I'm posting my configuration. I am using a revolver head with asynchronous motor with carousel control. mesa reads the encoder and buttons. the machine is cast in steel.

youtube.com/shorts/veTGtAU7UrY
youtube.com/shorts/fbEU6qiVqMk
disk.yandex.ru/d/rNy3ErpcVfzkxw

Deleted.

Deleted.

I am currently working on a machine with two X axes 1500x3000mm, what should I do so that with the incremental encoder it can align the bridge if it moves a little in reset mode.
mesa 7i95t
Greetings

  Good afternoon, I think I managed to do what you asked me, but without results, still with the same error. Could it be my pyocd installation? I've tried with other versions of Debian, but always the same problem.

Best thing to do is think of an RPi running Linuxcnc as the ECU in an early 2000's car or bike, as long as it works there's no real need to upgrade.
I'd like to be able to count the amount of times I upgraded the ECU on my 1999 Toyota Echo on one hand, but I have all the fingers on each hand

On a normal daily driver or even server kernel upgrades are fine.
The issue in this instance is that the kernel used in the image is particular to the RPi and is custom built.
From playing around with various Arm devices the boards aren't as "generic" as the PC platform. Each Arm processor or SOC has it's own quirks as such. The device tree is a way to let the Linux kernel know which devices are available, device tree overlays are used to further customise the setup.
Then there are custom patches that are used to further "tune" a particular board.
I have 3 main machines at home running Linux, one desktop and laptop running Mint and a server running Ubuntu, kernel upgrades are not an issue on any of these 3.
Obviously I have an RPi5 & 4 for testing Linuxcnc images, so these don't see kernel upgrades unless testing new images.
The Orangepi PC that running my hacked together reflow oven doesn't get upgrades, it works and is left alone, but it does have a custom device tree has I needed some status LEDs and an off button on the front panel from the GPIO header. Now if I was to upgrade this kernel I would also have to rebuild the device tree file to suit.
Whilst the Arm platform is good, it's come along way in 20 years, it's not as generic as the PC platform, it's kinda like pre PC days.......but without the OS software issues.

Try been in the directory where the file is located. Before you run pyocd. Are you able to ping the board. 10.10.10.10 ??

Aaah I see; thoughtless mistake then. Kernel 6.1.0-35-arm64 was the linuxcnc one, which apt erroneously removed in favor of 6.12.11-1 and 6.12.12+bpo-rt-arm64, since those (recently) emerged as the logical successor. Note to future self: do NOT accidentally do dist-upgrade on LinuxCNC!

I was hopeful though, that the original version could be reinstalled without having to redo the whole install. This is because when removed, apt did note that it could not remove the 6.1.0 folders as they had custom files in them. But alas, I accidentally removed linux-image-bcm2712-rpi since that was now linked to the 6.12.12 kernel. That package has no installation candidate, so I'm borked. Reinstalling...

Thanks! That first paragraph was gold. My understanding of how the whole thing works just went *way* up!

Deleted.