Advanced Search

If your're running a mes card there is no need to test with a base thread. Servo thread is all that is needed.
Usual advice, turn off power saving, anything that attempts to change clock speed in the BIOS, also turn off hyper threading if that is an option, for a 4 coremachine you might get some relief from isolcpus=2,3

It may help to supply some details regarding the machine you're using.

RADXA Cuby A7Z
radxa.com/products/cubie/a7z/

SoCAllwinner A733 CPU2x Arm® Cortex®-A76 up to 2.0GHz6x Arm® Cortex®‑A55 up to 1.8GHz1x Alibaba RISC-V XuanTie E902 up to 200MHz

GPIO40-Pin GPIO Header with I2C / SPI / PWM / I2S etc

MCU: RISC-V E902 (200MHz) Coprocessor, Real-time tasks and low power management

Unfortunately I didn't see documentation yet

I'm trying to get EasyProbe running on my mill. I had an older version running, but am having problems with the probe signal.
The report file shows: Probe_postgui.hal:14: Pin 'hm2_7i96s.0.gpio.040.in_not' was already linked to signal 'probe-in'
Probe_postgui.hal has:
#

---

Probe signal and LED control (see readme.md)

---

# dbounce_probe.in must be linked to the probe tool input of the interface card
 
setp  dbounce_probe.delay      [PROBE]DEBOUNCE_TIME
setp  xor_probe.in0            [PROBE]PROBE_SWITCH
 
net   probe-raw                dbounce_probe.in             <=    hm2_7i96s.0.gpio.040.in_not
net   probe-switch             dbounce_probe.out            =>    xor_probe.in1
net   probe-signal             xor_probe.out                =>    motion.probe-input pyvcp.probe_led

I can't find any other instances of probe_in. Where might it be?

 

That got me up - but now I've got "Unexpected realtime delay on task 0 with period 1000000"

Latency test gives 60624 ns jitter on the servo thread and 70111 ns jitter on the base thread.

I've been using Linuxcnc for the past 5-6 years (I use to be Clark22 but I got locked out).   More accurately, I've been making baby steps towards getting my cnc to work properly before taking an extended break (build the machine and get it moving, stop for a long break, get the spindle working properly, take a break, get endstops working then take a break ......).  The last big step was getting the spring probe and edge probe to play nicely with each other and then to get the auto tool change and updated tool.table working.  I've don't tend to ask for help but rather keep plugging at it until I get it figured out.  The past month has been going around and around, but today I finally got it working.  I've seen you ask for people to test out the probe_routine.py and the versa_probe.ui and I wanted to let you know that I got it working today and I really like how it's doing.  I have a lot more testing on it to make sure it's actually working but after a month the tool.tbl finally updates.  For anyone else wanting to try these out there's on part that was causing a lot of confusion for me.  the python_probe.py goes in the /usr/lib/python3/dist-packages/qtvcp/widgets/probe_routines.py directory and the versa_probe.ui goes in the /usr/share/qtvcp/widgets_ui directory.  For some reason I had the versa_probe.us in the first directory (who knows how it ended up in there). I thought clarifying that might help somebody.

That is not really helpful, need to know the QtPlasmaC version in the window's header.

For what it's worth, I ran your G-Code on v2.10-009.071, it runs fine.

I added a feature in 2.10 that changes the "VEL:" label to show when a reduction is present. In this case, the line read "VEL@60%: 1020"