Advanced Search

Beide Latenzzeiten sind schrecklich.

The first image is running a realtime kernel, but the jitter is larger than is really useful. (0,4 ms in a 0,025ms thread will not work )

The second image shows a system that is not even running a realtime kernel, so the jitter is huge, 10ms or more.

You should try installing the latest realtime kernel and see if things improve after reboot.
sudo apt-cache search linux-image-rt
will give you a list of available realtime kernels. Find the newest listed and then
sudo apt-get install linux-image-rt{rest of the name}

Alternatively you could tre a fresh install from the LinuxCNC ISO image.

www.linuxcnc.org/downloads/

Can you describe how the setup is failing?

One thing that may be wrong is that the "width" seems very large. This is the number of encoder counts each side of the tool slot that is considered properly aligned. Normally it would be at most tens of counts.

The "scale" is meant to be the number of encoder counts between pockets. If your system has 1 servo motor revolution per pocket then your scale is probably correct, but if one servo motor revolution is one carousel revolution then you should divide the encoder full rev counts by the number of pockets.

I am aware that "carousel" has grown to the point that it ought to have a dedicated manual section. (Or maybe there should be a section on toolchangers in general. It's a big subject)

I couldn't attach the SVG files either. But I have attached bitmap reviews so that folk can understand what GraphViz is. 

What's the GUI? It looks specialised.

Hello Chris,
sorry for the late reply,
After Problems with other Software I did a fresh installation a few weeks ago. With all updates the versions are: "QtDragon_hd Version 1.5 on Linuxcnc 2.9.7"
For creating g-codes I use FreeCAD as an APPImage on the same machine, so there is no other software installed on the Computer.

Any one using this card?
pleas help i bought one 
New in linux cnc 

Hallo Leute,

nachdem ich nach ständigen Fehlermeldungen beiden Rechner nun nochmal komplett neu aufgesetzt habe, funktioniert nun alles sauber und ohne Fehlermeldungen, jedoch ist die Latency sehr viel schlechter als vorher.

Da ich von der alten und neuen Installation jeweils ein Image gezogen hatte, kann ich hier (mit etwas Zeitlichem Aufwand) schön vergleichen.
Nun ist mir im Latency Test aufgefallen, dass die alte Konfig einen aktuelleren Kernel verwendet (6.3.0), die Neuinstallation jedoch den 6.1.0. Nun wollte ich auf die Version 6.3.0 upgraden. Da ich nach wie vor kein Debian-Experte bin, Google mir hier nicht wirklich weiter hilft und ich bei diversen Versuchen über den Paketmanager Key-Errors bekomme, frage ich mal in die Runde.

Hier mal die alte Installation (Kernel 6.3.0)
  

Hier der frisch installierte Rechner
 

Vielen Dank schon mal
Gruß Jens

See above post to links for rc3 downloads.
Stupid things fixed:
Firefox-ESR installed
evince (pdf reader) installed
default kernel is aarch64 6.12.34+rpt-rpi-v8-rt (Raspberry Pi built RT_PREEMPT kernel)

I am trying to figure out a clean way to disable some buttons in the Probe Basic UI. We currently use an old version on our machine with a few buttons disabled. With the older version, it was as simple as adding something like "self.tool_diameter_probe_Btn.setEnabled(False)" to a properly setup custom_probebasic.py file in the config folder. On the new version installed via apt, this does not work to disable buttons. Our machine gets used by people who may or may not be trained on all aspects of it so I would like to limit some things. I am happy to go and comment out things in order to use buttons when I am working on the machine. Is there a "right" way to do this?

Sorry, missed this.

Yes, that's where i started with the xml. I don't change much other then to make it specific to the 3 motors i have. My xml file is in my other thread here:  New ethercat / probe basic control for minimonster - Page 13 - LinuxCNC

Sadly no time to make a how too, but its on the list to go with the launch of the machine

You didn't by chance use the new trixie image on the downloads page did you ?

I have a newly minted Linuxcnc 2.9.7 installed on a Raspberry PI 4. 

I have successfully compiled the remora.c component from cakeslob/rrw_lab
trying 'sudo halcompile --install remora-spi.c' from cakeslob/main and scottalford75 will not compile. Lots of errors. 
I have also a working linuxcnc 2.9.3 that compiles remora-spi.c fine

Are there any changes in linuxcnc from version 2.9.3 to 2.9.7 that makes this happen? 
I will make do with the earlier remora component...

I just wanted to inform that there is some issues

Ok if its an os image you require I may just be able to help.

tommylight,

Thanks for your info.
I changed the X-axis with an other old (3 fase) steppenmotor and a M3 spindle movement without any problem.
Nothing has been changed to the (4 fase) Y-axis steppenmotor, but there the issue starts.

Mechanically the Y-axis is indeed a mess, it is gear driven with 2 gears before moving a gear-bar (on which the laser is mounted)
Willing to change it into a spindle driven movement too, but the 28BYJ-48 is already x64 slowed down and is too slow for that.

But the old setup did worked for several years without problems, although the backlash of 1.315 (mm) on the Y-axis.
My setup was always with a Raspberry Pi 3B+ controlling 2 L293D and 2 (28BYJ-48) steppenmotors.

Now i only changed X-axis and updated the Raspberry OS which result in weird backlash issues on th Y-movement.
It looks like on picture drawings (2 way y-movement) it does now turn on the laser before doing the backlash.
On one way the laser burns much longer than usual (earlier).
I will add a picture with on top the old burning (g-code) and below the new ones, same g-code.
You will see much lines extra (longer) burned on the new ones (one way) regardless what backlash i give, although backlash does something.
In red the given backlash is written,

Btw: I added the BACKLASH_VELICITY as i found is somewhere on the internet, but it does not speed up the backlash nowadays.


Unknown,

Back to my original whould be building it completely new, as it broke after upgrading Raspberry OS the first time.
Although i can read the old (linuxCNC) data.
But I will try, but it was a big trouble to get the RT-OS version (bullseye?) working the first time, i know.
Ad need the 2.8.2 version of LinuxCNC.

Regards, DG.
 

Langdons read his post.

The OP did a fresh install.
If the checksum didn't match the install would have failed.

The GUI would not matter has this will be a hal issue.

Apologies to the OP, but the above poster is a nuisance.

The best thing to do is attach your hal & ini files and maybe your comp file as well.

I'm just wondering whether this thread may be of help.
forum.linuxcnc.org/qtvcp/52434-z-level-compensation#298898