Advanced Search

You might plot the switch  hal signals with halscope when homing to get a better
idea of whats going on.

(it might be contact bounce or EMI)

 

Worse than what you describe, apparently I've gotten a pre-release version? The grub.config line says its booting vmlinuz6-12.95+deb13-rt-amd64
the words debian 13 show on my screen after boot for awhile then go away, I got the iso file by searching the linuxcnc site because the link to download wouldn't work for me .
on the other hand, linuxcnc says its axis.ngc - Axes 2.9.10 on LinuxCNC-HAL-SIM-AXIS
and it will simulate some parts, I'm still checking. It seems to be working very good so far, internet works, playing mp3's work, terminal works, selecting applications seems to work, usb drives seem to work.
probably too early to submit bug report here but thanks for the reply.

Yes, the style sheet was appropriate for non-flashing.

But I ran in the the same problem(s) I reported on github after this round of edits... intermittent hang during PB startup.

As before, everything works fine in sim but about 75% of attempts on real machine hang up during start.  This time I followed your instructions, started from a clean update, and didn't touch anything other than the user ui files.  All editing was done with probe_basic.ui open via editvcp.

Testing on the real machine:

• Demo configs start fine
• Turning on/off the various user features (button panel, main/side tabs, atc btns, dro) didn't appear to make any difference.

The hang condition doesn't seem to follow any pattern.  I can try to start it, hangs, then I force-close the terminal window.  Next time it starts.  Or it hangs 4 times in a row before starting.  Or I have to re-start Debian and then it works... until it hangs again.

No other GUI demos hang, and I have a minimal but working Axis config that starts no problem 100%.

As I mentioned on github I don't have different (non-ethercat) hardware to test on.  And no clue if this is ethercat related, but the hangs always happen towards what should be the end of the qtpyvcp/probe basic startup sequence.
 

thanks for pointing that out, i have updated the configuration documents to reflect the missing config items, sorry about that, got missed somehow.. should be up shortly!

did you change the style sheet for non flashing?

Here is my HAL and INI files.
 
 

Fixed. The ini file was missing this.
[ATC]
# Number of pockets in the carousel (set to 0 or 1
I did not see that referenced in any of the installation manual documents. I may have just missed it.

It's hard to help you when we don't know what you're doing, how you're doing it and why you're doing it.
It happens that the installer has a problem using a partition formatted in a different operating system or with specific programs. Then the actual solution is to tell him to format the partition in his own way.
The rest of your post has no sense and difficult to respond to.

Had  three problems loading the Debian 10 iso (from a dvd I made)
1. the download script would not get past the step where it partitioned the disk until I used the menu option to format partition #3.
(I even waited whilst the script wrote 90 GB of zeroes on that drive, before discovering the format fix) 

2. The UUIDS in the grub .cfg file were changed (somehow) to where they were incorrct for my other linux kernel, although the UUIDS for debian were correct.  the /etc/fstab file for my other OS was adjusted to where the UUID entry were removed from that file, /etc/fstab for debian were correct and included swap)

3. Debian would crash on booting until I removed the boot=plainroot option from the debian vmlinux line in grub.cfg. (I also removed the quiet option) 

The function debounce is in 2.7

Can't find module 'dbounce' in /usr/realtime-3.4-9-rtai-686-pae/modules/linuxcnc
while executing
"hal loadrt dbounce names=dbounce_probe" 

JT

Thanks to one of the guys on the IRC Flex GUI now supports OpenGL 3.3 and works with Master aka 2.10

JT

Alle Hall Pins müssen einen eineindeutigen Namen haben.
Am besten benennst du die Pins nach der jeweiligen Achse, das macht die die spätere Zuordnung einfacher.
halPin="out-controlword" >>> halPin="X-out-controlword"
halPin="out-controlword" >>> halPin="Y-out-controlword"
halPin="out-controlword" >>> halPin="Z-out-controlword"

Hello Linuxcnc Friends,
i abused the WHB04b-6 with a bad behavior and i found some smal bugs again.
Here are now the final and stable version of the drivers for Linuxcnc 2.9.10 and the hal.cc for the guys they want compile by himself to use in other versions

Best Regards
Reinhard


 

A lot has changed in LatheEasyStep over the past few weeks. Much of the work has focused on further improving the existing machining functions and making the generated toolpaths more reliable.In particular, internal machining has been significantly revised. Internal contours can now be processed regardless of the Z direction in which the contour was originally defined. Roughing and finishing have been corrected accordingly, and the approach and retract movements for internal machining have also been revised.There have also been several improvements to contour machining. G1/G2/G3 geometry is now preserved more consistently, so arcs are no longer unnecessarily converted into straight-line segments. Relief grooves have also been further improved, including the automatic positioning of DIN 76 thread reliefs at the actual end of the thread.The handling of tool changes, retracts and safety movements has been revised in several areas. The same applies to switching between G96 and G97, as well as various plausibility checks intended to detect invalid or unreasonable inputs before G-code is generated.The preview has also received further work. The side view, front view and cross-sectional view have been revised, and the representation of the different machining operations has been made more consistent.Another improvement that is clearly noticeable in everyday use is the panel startup time. At one point, startup took more than 20 seconds. The initialization process has since been revised, and tasks that are not immediately required are now performed only when needed. As a result, the panel now starts significantly faster.The user interface and language system have also been further revised. In addition to German and English, Spanish is now fully available. All visible text is managed through external language files, allowing additional languages to be added without modifying the program code.The current development branch is now 0.8.0-dev. For the 0.8.0 release, only a few targeted acceptance checks remain, including facing with a radius and final checks for internal machining and the DIN 76 thread relief.After that, 0.8.0 is intended to provide a defined state of the existing machining functions before development continues towards 0.9.0.

Not a LinuxCNC install. Same class of box as the earlier J1900 eglfs vs Xorg thread.Posting because the useful knob was not another kernel cmdline flag.
Intel Celeron J1900 has 2 MiB L2 as two 1 MiB slices:
CPUs 0-1 share one L2
CPUs 2-3 share the other L2
We already isolated the EtherCAT loop on CPU3 (SCHED_FIFO 80, 1 kHz).
That is not enough if the fullscreen Qt/eglfs HMI is still allowed on CPU2.
The UI then sits on the L2 sibling of the RT core and contends for the same 1 MiB.
Change (HMI only, not a whole-system cgroup):
before: Qt main / touch / QML / render / GPU worker allowed on CPUs 0-2
after: those threads allowed on CPUs 0-1 only
RT thread stayed on CPU3 both times
Same binary, same recipe, same 1 ms period, 20 automatic press cycles each side.
Jitter = wake-to-wake CLOCK_MONOTONIC minus 1 ms, integer microseconds.
0 us means |error| < 1 us. This is period error, not latency-test / cyclictest.
All numbers below are the full captures (approach + press + retract), not a PID subset.
Absolute jitter, nearest-rank, all samples
UI on 0-2 (20 runs) UI on 0-1 (20 runs)
n 119159 119254
P50 0 us 0 us
P95 6 us 1 us
P99 13 us 1 us
P99.9 21 us 2 us
signed min/max -42 / +46 us -13 / +14 us
|j| >= 10 us 2983 8
|j| >= 20 us 198 0
|j| >= 30 us 22 0
|j|
Per-run P50 / P95 / P99 / P99.9 (|jitter|, us)
# UI 0-2 UI 0-1
1 1 / 9 / 14 / 23 0 / 1 / 1 / 2
2 0 / 2 / 9 / 19 0 / 1 / 1 / 2
3 0 / 5 / 12 / 21 0 / 1 / 1 / 2
4 0 / 6 / 15 / 20 0 / 1 / 1 / 2
5 0 / 7 / 15 / 20 0 / 1 / 1 / 2
6 0 / 1 / 1 / 2 0 / 1 / 1 / 2
7 0 / 6 / 14 / 20 0 / 1 / 1 / 2
8 0 / 7 / 15 / 20 0 / 1 / 1 / 2
9 0 / 4 / 13 / 19 0 / 1 / 1 / 2
10 0 / 6 / 16 / 26 0 / 1 / 1 / 2
11 0 / 3 / 11 / 22 0 / 1 / 1 / 3
12 1 / 9 / 15 / 23 0 / 1 / 1 / 2
13 1 / 9 / 14 / 26 0 / 1 / 1 / 2
14 1 / 9 / 15 / 32 0 / 1 / 1 / 2
15 0 / 8 / 14 / 19 0 / 1 / 1 / 2
16 1 / 9 / 14 / 26 0 / 1 / 1 / 2
17 0 / 1 / 6 / 13 0 / 1 / 1 / 2
18 0 / 6 / 13 / 19 0 / 1 / 1 / 2
19 0 / 1 / 5 / 15 0 / 1 / 1 / 2
20 0 / 1 / 1 / 2 0 / 1 / 1 / 2
After the pin, every run has P99 = 1 us. 15/20 runs have max |j|
The 8 remaining >=10 us samples are two ticks each in runs 1, 8, 15, 16.
Point of the numbers
- P50 was already 0 us. The HMI was not ruining the median.
- The L2 sibling shows up in the tail: P95 6->1, P99 13->1, P99.9 21->2.
- Moving i915 IRQ off CPU2 was not sufficient by itself. User-space Qt
render can still land on CPU2 and thrash the RT core's L2.
- Do not set a cgroup AllowedCPUs=0-1 on the whole process: the FIFO
thread must still be able to bind to CPU3.
- Do not park every system thread on 0-1. This was only the HMI/render path.
Box (for context, not the variable under test)
- Debian 13 PREEMPT_RT 6.12, Qt eglfs_kms, no X
- IgH EtherCAT, 1 kHz, Lost frames = 0
- isolcpus / rcu_nocbs on CPU3, i915 IRQ on CPU0
Happy to hear if anyone running a GL HMI on Bay Trail saw the same
CPU2/CPU3 L2 pairing.