Advanced Search

I think those Trixie files may have been built on Bookworm, when I built an image last night it pulled the Linuxcnc packages from Debian. Trying to manually install brought up a lot of messages regarding packages that could not be installed.

DO we actually need an image anymore of the Pi is using Trixie? Why not just try one of the official Deb files here?
linuxcnc.org/dists/trixie/2.9-uspace/binary-arm64/

unknown wrote:

Now that I have a working Trixie image, one image will work for the 4 & 5 would it be useful for package building for Trixie ?

I doubt it. As of today Andy has got GitHub workflows working for all OS'es including Trixie for both AMD64 and ARM and a full complement of builds on our repo at linuxcnc.org/dists

tommylight wrote:

Young??? I am 55!
And the dog got banned from the shop for a while as i got tired of monitoring her so she does not pee at everything!
 

Young!!! you are still a veritable pup compared to some of us like me!

With newer operating systems like bookworm, there is a huge number of additional features outside of linuxcnc that affect real time and network latency. Plus the world is more complex so there is more hardware to consider. Plus the big push to power saving features has permeated everything.

If you are not using a parallel port, the old latency test is not relevant. Its all about network latency. The network is not real time but we want it to be.

Probably the biggest issue is using the wrong network driver (mainly on Realtek NICs), followed by NIC interrupt affinity. By default all system interrupts including the NIC's are placed on CPU 0 so we need to move the interrupt for your NIC to another core.  

I think this means you now need at least a 4 core CPU (eg Celeron J1900 or higher) as you need to have CPU 0 for the system and a core for the NIC and a core for the real time servo thread.

In summary, if you are not prepared to oprimise the OS for a RT environment, stay on an old and obsolete OS and hardware.

I have had to set some register in the drive to make it use Modbus.
Could be permission problem, almost anything.
Load the modbus driver only using halrun and diagnoze from there.
Something like this forum.linuxcnc.org/24-hal-components/310...-speed-control#75848
but for your Modbus drive, not the huanyang.

toogle2nist works perfectly, but I have to change the debouncetime in the componet. it will be more comfortable if the debounce-time is changed by a hal pin
    

Yes, I tried to download it here.
It only gave me a blank page, I tried several times all day.
In the evening, I left the blank page open and after 10 minutes, I refreshed the blank page and the download started.
I'll try with Xilinix.
Thank you very much for everyone's help.

This was a case of needing to really dig into it "one more time" - The problem I was facing (and just couldn't see until I was documenting it all for 'You', was that the following section was also missing from my hal file:

net max-home-z => joint.2.home-sw-in
net max-home-z => joint.2.neg-lim-sw-in

At some point in the process, I thought I saw it - I don't know if I misread it (seeing either the X or Y version) or if I somehow accidentally deleted it right after seeing it, but putting it in allowed the home switch to work, and now the mill is one step closer to working.

I am having some teething issues with getting Z set up nicely (why is Z always the complicated one!?), but I think I'll get that sorted out soon enough once I dig into it tomorrow.

Although this is resolved already, I'll just leave it out here for the benefit of anyone else searching for help on this problem.

I'm using LinuxCNC as part of a wire EDM, and it's also my first experience with Linux of any sort.

When I load a job, a 2D representation appears on the Preview tab and on the figure is an "X", where cutting will start. Depending upon the shape of the blank and the outline of the part, it's sometimes better to have the starting point elsewhere. Is this something that can be changed within LinuxCNC, or can it only be done in the program that generated the G-code file (Vcarve, in my case)?

Thanks

Hm.
Drive connected to adapter, but they aren't talking. Seems everything is set right, i dont see any mistakes.

hmmm

sorry for the confusion, i have 6 drives powered by 2 power supplies. each power supply is powering 3 drives. my machine setup is 5 axis  with the X (gantry) has a tandem, total of 6 axis.

Hi,
I'm refreshing / updating a minimill I built back in 2010.  It's been idle for probably 12 years or so, and I decided to dust it off and see if it still worked (and if I remembered anything at all about it!). This was partially prompted because I learned that maybe FreeCad could generate tool paths...?  (unconfirmed, but I think hearing that is what piqued my interest again.)

Anyway, it's an old beast - I've installed a new disk and installed the latest linuxcnc I could download, set up the RTAI kernel (I'm using a parallel port, not a Mesa board - for now at least, and my latencies were sometimes getting up above 100 nS).

Sorry, that's all just context - the point: My home / limit switch is not working for my Z-Axis.  Mind you, electrically it works - I had it operating under the old OS / EMC2 before upgrading, and I've confirmed with a voltmeter that it's getting a 5v signal, and the switch opens when I push it.  But when I push it, I see no indication in LinuxCNC that limit has been hit.  
This was discovered right after running through the StepConf wizard. I looked around a bit, and saw that StepConf had written "max-home-u" instead of the expected (by me) "max-home-z" into my .hal file.  For x & y, it had written "min-home-x" and "min-home-y".  

So, I double-checked that I'd selected the right entry in stepconf wizard (I had), and tried again.  Same.  In fact, the error even existed in the .stepconf file:
<property type="string" name="pin12" value="max-home-u"/> <!-- Jason: Should be max-home-z instead, and that's essentially what was shown in the UI. -->

So, I manually changed the entry in the hal file to say the max-home-z value that I expect is correct.  I also saw that max-home-z was already present in another part of the file (where that value is 'mapped' to the limit and the home inputs.). EDIT : When I came back to add detail and attachments, I couldn't confirm this - I swear I saw it before, but maybe I was actually looking at the info for the X or Y axis.  I can't find it for Z now.  That's my leading suspect at the moment, now!

net max-home-u      <= parport.0.pin-12-in-not
became
net max-home-z      <= parport.0.pin-12-in-not

I restarted linuxcnc, and that didn't fix it.  I restarted the whole computer, and it still didn't fix it.  I'm at a bit of a loss.  

I did a lot of searching, and my AI sidekick told me I'd found a known issue in StepConf Wizard, but I don't actually see much confirmation of that in reality.  I did find this thread (forum.linuxcnc.org/49-basic-configuratio...is-homing-and-travel) so I suspect it at least one person before has been affected by it. Unfortunately, I didn't see any indication that that issue was ever really resolved.  

I guess you'll like to see my .hal and .ini files, if you are inclined to look into this at all (helpful unknown reader!), so, I'll attach them as soon as I have them handy.  I'm walking back and forth to do everything now, because that computer is too uncomfortable to sit and type at for any stretch, and I don't have SSH working yet.

Thanks!
Jason 

 

AkkiSan wrote:

What are you using?

 

If this was for me, by now probably over 70 or 80 (i would bet more) of Mesa cards, on over 40 machines, from EMC2 to the latest LinuxCNC 2.10 still in development.
Most of them use LinuxCNC 2.8.4, and all of them use old "enterprise" computers and laptops from Dell, HP. Lenovo and Fujitsu.
But none of them use probing, so far.
-
Do the issues occur without probing involved?

Oh sorry, this was not meant as a complaint or rant.

My intention was to make clear, that basically all my completely different setups are failing to work - including
the ones which include a Mesa card. Which, at least to what I understood, is recommended or even the only option
after the golden parallel port times.

Issues started with 2.8.x on Wheezy. At that time, only the probing was affected, but I found that out
much later, after I deleted the 2.7 partitions bc I probed on a non-LinuxCNC machine.
Fixed it with a flipflop:
forum.linuxcnc.org/38-general-linuxcnc-q...move-deadlock#332412  
But there's sth wrong in the code, probably related to the RT system, as a longer latency makes things
significantly worse.

Everything with Bookworm and >=2.8.x doubled the latency and also brought the bespoken queue and
now also joint following errors. This does even happen on a Machinekit setup, after upgrading to a
tool center point capabale version on a five axis machine.
The most annoying thing is that there is no workaround. Not even increasing the following limits to absurd
values do help here. So the machine stops (without any mechanical errors) and there's nothing one can do.
On one machine this excusively happens with a rotary table. Randomly.

GUI doesn't matter. I only use the "blue one" and Axis. Stock settings, no plugins or mods - zero difference.


I have this Mesa Ethernet thing and the RPi variant. Both also have these issues with a bookworm setup.
What are you using?