Becksvill wrote:

hey guys

just wondering whats the latest on this.

cheers

andrew

 


Still work in progress

github.com/LinuxCNC/linuxcnc/pull/3807

you can read above, if anyone wants to test what's done so far, they can download the debs from github build artifacts
github.com/LinuxCNC/linuxcnc/actions/runs/22982518117?pr=3807
the above is today's build, scroll to the end of the page for the debs for the different systems, I think I got it to the point where it is in a good enough state for sim testing by the community
To test it set planner type 2, I have included a zip file in this post with my testing settings for planner type 2.
YangYang is refactoring the code, he put planner type 1 on pause because there are certain limitations with TP1 implementation, he cannot reach high speed on short segments.
TP2 will be the general base idea, but much needs to be refactored, the feed override needs to be reworked, kinematics TP and RT servo-thread need to be reworked, there is talk in the github about this, any extra mind is appreciated.
At the moment TP2 generally works, what's still missing from my implementation is spindle sync, I never tested probing or adaptive-feed.
as far as running gcodes and MDI, I believe everything works, but it is far from hardened, it is just me doing testing in a sim, if you put it on your machine, it is at your own risk, play with it in the sim, and let me know how it goes, here, in the gihub PR, or even on my github fork.

They are same

github.com/grandixximo/linuxcnc-ethercat

this just has one small optimization

dc-phased is latency dependent, can you plot in halscope, app-phase, pll-error, and servo thread?

If i get a USB pendant, do i need to have an MPG interface on the controller board? (like the Mesa 7I76EU) or can i just use the USB communications into the LinuxCNC PC? Not sure if i need to connect the pendant to the PC or to the controller.
Any help would be appreciated.

Thanks.

In Europe, try Grotius Machine Tools, the owner is well known on this forum

The Linuxcnc installer uses Bookworm (V12)
The Debian installer is currently Trixie (V1 3)
Trixie has better uefi support at boot

Linuxcnc installer uses Debian's Live Build which is the same as what Debian uses so its odd
so install Debian Trixie and type sudo apt install linuxcnc-uspace linuxcnc-uspace-dev to get v 2.94 (missing a few minor bug fixes)
Install Debian Sid (aka testing) do the same and get v 2.97 (missing one minor bug fix)
Follow this process  on Trixie or Bookworm and then follow the steps in the docs here to get 2.98 (current version)
linuxcnc.org/docs/stable/html/getting-st...th_preempt_rt_kernel

Der verwendete Zeichensatz war UTF-8 und ich hatte auch mehrere Editoren ausprobiert, Überall wurde der Code passend interpretiert. Gedit direkt in Linux hat ihn auch ohne krytische Zeichen richtig angezeigt, nur im maschineneigenen G-Code Fenster kamen dann die wirren Zeichen zum Vorschein.

Ich hab mir anderweitig auch noch Hilfe geholt, und wir haben den Fehler gefunden.
Wie schon richtig vermutet, war ein Sonderzeichen Schuld an der Misere...
Allerdings nicht unsichtbar, sondern offen im Code zu sehen:
'-' ist im Editor klar zu lesen, aber effektiv gibt's da 3 Varianten davon, den Geviertstrich, den Halbgeviertstrich und den Bindestrich. Der letztere ist in der Darstellung ein Minus-Zeichen. Da die AI in den meisten Fällen (außer sie wird direkt aufgefordert ein anderes Format zu nehmen) Textfiles so generiert, dass sie für digitale Druckvorlagen genügen, kommt je nach Zusammenhang im Text, der Geviertstrich, vielleicht auch als 'em-Slash' bekannt, zur Anwendung.
Auf den ersten Blick fällt das nicht auf, aber wenn man ihn dann unmittelbar neben einem Minuszeichen sieht, kann man den Unterschied erkennen.
Ich hab dann meine Schnipsel diesbezüglich geändert und seitdem funktioniert es so wie es sein soll.

Danke für eure Hilfe und Gedanken!

Freddie

CSM enabled does not make any difference for my install when using the LinuxCNC live USB image.

I downloaded the official Debian installer image (not the LinuxCNC specific one) and it ran and installed absolutely fine, didn't even complain about missing firmware, grub installed fine, and it didn't even hiccup once.

From here, I'll follow the normal install instructions for installing the preempt-RT kernel and linuxCNC from packages.

hey guys

just wondering whats the latest on this.

cheers

andrew

Kannst die ngc bitte mal posten?
Ich vermute, dass das mit dem verwendeten Zeichensatz zutun hat (es sollte UTF-8 sein).

Jaja meister,

so mag das sein...
...wenn man aber als Autodidakt von Null anfängt, ist es glaub ich durchaus normal, sich Beispiele zu holen und was liegt heute näher als die KI?

Sich dann aber mit dem Problem auseinanderzusetzen und versuchen den Fehler zu finden ist die logische Schlussfolgerung.

Auf die Spur mit den Sonderzeichen bin ich selber schon gekommen, da der gleiche Code, nur handgeschrieben, funktioniert. Da Du nun da gleiche sagst, werd ich mich in dieser Richtung mal weiterbewegen...

Freddie

There is no timing issue but they are only settable in the hal file (that is they are only set when the driver loads),
it may be that the way the hal file parsing order works means that they must be in the postgui hal file

Thanks for the reply PCW. The issue I'm running into is that it seems the source/sink masks are only "settable" in my postgui HAL file, which runs after the HAL and GUI start up.

If I move the setp commands to set the masks into my main HAL file, either near the top or last, they don't seem to take effect despite "getp" showing them as being set. I can't put the masked pin into the proper mode (sinking in my case).

When I put them in my postgui HAL, or manually set them with setp after linuxcnc startup, it works just fine.

I'm just wondering if there is some timing constraint when it comes to setting these masks that launching the GUI is covering up.

Thanks