Advanced Search

HOME_OFFSET is used to manage squaring during homing. If there is 1.5mm difference per side, make the home offsets different by 1.5mm.
For initial squaring, I used a dial indicator and homed againt that. Probably a more accurate way is to home the machine and mark positions in each corner with a tool and adjust the home_offsets untill the measured diagonals are exactly identical.

Why are you using Python when the feed rate is available in real time in motion? There are other options but try this pinmotion.feed-upm OUT FLOATCurrent feed rate in G-code program units per minute for motion.motion-type feed(2) and arc(3). Value is the G-code program F value multiplied by the current feed override value and the motion.adaptive-feed setting (if M52 active). Value is zero if motion.feed-hold or motion.feed-inhibit are asserted. If units (G20 or G21) are not specified in the G-code file then units will be the last units used.linuxcnc.org/docs/stable/html/man/man9/motion.9.html

Hi!
I am 99% sure that I do have G54 in my startup code, but I will double check tomorrow.

Thx!

Update: Confirmed - G54 was in the startup code line. 

ok, so then in your other config in the ini, add G54 to the start line and it should resolve for the time being. I will investigate the scenario here with it removed from the startup and see if i can reproduce, if so i will look at hardcoding a default work offset for startup to avoid the error in future releases. great job identifying the difference!

Looks like HDDs do have interrupts since they are slow and do need the OS to wait for datatransfers.
I'll see if the latency-test will get better or worse when the SSD will arrive

This is what comes up from that link

Alright, understood.
Today I spent some time with my cnc. I setup a new machine in LinuxCNC, and now I have two setups.. one is "good", and the other one shows this issue. 
What I found out - when I startup the "bad" machine and open the "probing" tab, none of the work offsets at the top is selected.
When I start the "good" machine, G54 always is preselected.

No idea if this makes sense or helps, but it fits to the error message imho...

 

Please notice that in step 2 at the end the 4 is missing from amd64
It should be:

$ sudo apt install -t bookworm-backports linux-image-rt-amd64 linux-headers-rt-amd64

Added 2 more.
@tomapc
@toma.cnc1
@toma.3d
@tomaberisha5688
Reminds me, i have to fix the name on the last one as it was the first one i registered.

Looks like 7I77 U15 (74LCX04) receives, buffers, and inverts
the ENCMUX signal to generate the EVEN/ODD signals that
enable the 26LS32 even and odd line receivers, so is a prime
suspect with encoder mux issues:

 

 

SSDs are overrated.

What is that supposed to mean? Any SSD is MUCH faster than a spinning hard drive, so how is this "overrated"

They are mostly good for Windows because NTFS has fragmentation issues.

They are good for all operating systems, not just Windows.

They do reduce boot time, but that is not really useful.

It is useful for everything that needs to be transferred from SSD to system RAM and back, especially when starting any application or closing it, or...

RAM is faster than any SSD, even "slow" DDR 866MHz is faster.

Not a valid comparison so why????

Make sure your RAM is dual-channel.

Yes, this is valid, but requires 2 or 4 sticks of RAM, same size, otherwise it defaults back to single channel.

You can get double speed with no drawback.

Not true, you get more speed, but never double speed, timings, latency, clocks, and some probably 50 more settings and parameters that prevent memory form physically reaching "double speed".

Why not?

Now i must ask, Why?
Why do you keep replying like this?
Again, i admire your will and effort to help others, and some times you do help so thank you for that, but sometimes your replies are like this causing more confusion and noise that is not helpful.

tommylight wrote:

Subbed with @tomapc and was already subbed with @toma.cnc1 , i think, will also check @toma.3d.

Thanks Tommy! (9 to go), keep up the good work.

kcjengr.github.io/probe_basic/machine_config.html
in the docs

If you just want to stop all axes when the cylinder support is extended then you can use “motion.enable” pin.

From doc, motion.enable:
If this pin is driven FALSE, motion stops, the machine is placed in the "machine off" state, and a message is displayed for the operator. For normal motion, drive this pin TRUE.

Practically: you need a limit switch wired to your hardware input. And you would need to add the following hal line to your existing hal file:

net cylndr.extnd   hm2.your-input  motion.enable
(Replace hm2.your-input with the correct address)

What the above hal code does: when hm2.your-input pin goes true the motion.enable pin will be true normal operation resume, when the cylinder is extended the switch opens and stop all axes motion. Assuming that the limit switch is normally open and your hardware input is sinking (positive logic). 

SSD will improve latency a bit, but adding more RAM would also help, 8GB is just fine, but i do not recall how much you already have.