emc-developers — Developer specific. For issues of interest to users see emc-users list (below)

Re: [Emc-developers] Typos in Changelog

[andy p. <bod...@gm...>]

On Mon, 24 Nov 2025 at 10:33, andy pugh <bod...@gm...> wrote:
>
> Buildbot builds are currently failing Lintian on typos in the changelog.
> http://buildbot2.highlab.com/buildbot/#/builders/2/builds/2394

Well, I am baffled now, as the spelling errors are the same in all
packages. But I can't find the typos mentioned anywhere in the
codebase (not even after unzipping the changelog.gz files that are
referenced)

W: linuxcnc-uspace: spelling-error-in-changelog appearence appearance
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog conection connection
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog consistancy
consistency [usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog consistant consistent
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog controler controller
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog depricated deprecated
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog disapearing
disappearing [usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog doesnt doesn't
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog dont don't
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog embeded embedded
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog emtpy empty
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog erronous erroneous
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog exapmles examples
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog exeption exception
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog extention extension
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog fuction function
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog funciton function
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog interal internal
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog interpeter interpreter
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog keybord keyboard
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog lintain lintian
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog mantained maintained
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog mispelled misspelled
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog paramater parameter
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog paremeters parameters
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog pin pin (duplicate
word) pin [usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog supress suppress
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog surpress suppress
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog tempararily
temporarily [usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog temparary temporary
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog travese traverse
[usr/share/doc/linuxcnc-uspace/changelog.gz]
W: linuxcnc-uspace: spelling-error-in-changelog unsued unused
[usr/share/doc/linuxcnc-uspace/changelog.gz]


-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

[Emc-developers] Typos in Changelog

[andy p. <bod...@gm...>]

Buildbot builds are currently failing Lintian on typos in the changelog.
http://buildbot2.highlab.com/buildbot/#/builders/2/builds/2394
The problem here is that the changelog was generated from commit
messages, and has inherited errors from there.

Should I correct the errors in the changelog? Or would it be better to
add something to lintian-overrides?

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

[Emc-developers] New Trixie ISO image for testing

[andy p. <bod...@gm...>]

http://www.linuxcnc.org/iso/linuxcnc_2.9.7-amd64.hybrid.iso

It doesn't work on my (slightly dodgy) N100DC board (graphics glitches)

It only seems to have the right splash-screen in BIOS mode. (not UEFI)

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

[Emc-developers] Quick reminder - video meetup in four hours (20:00 CET) Aw: Another Video Meetup on Sunday the 23rd of November, 20:00 GMT+1 (CET)

[Steffen M. <ste...@gm...>]

> Gesendet: Donnerstag, 13. November 2025 um 01:04
> Von: "Steffen Möller via Emc-developers" <emc...@li...>
> An: rm...@un..., emc...@li...
> CC: "Steffen Möller" <ste...@gm...>
> Betreff: [Emc-developers] Another Video Meetup on Sunday the 23rd of November, 20:00 GMT+1 (CET)
>
> 
> Hello,
> 
> we had a good experience last Sunday with this "Big Blue Button" instance
>  
> https://greenlight.bbb.uni-rostock.de/b/ste-c4d-brs-3k6
> Access code: 869782
> Date: November 23rd, 2025
> https://www.timeanddate.com/time/zones/cet
> 20:00
> 
> and agreed to reuse that room two weeks later again. For the agenda 
> it was suggested to jointly go through the issues.
> 
> @Robert, yes, please be the moderator of this upcoming one. Technically,
> this one has now worked without a glitch. Since also Open Source, it seems
> unwise to go back to what we had before, but let us test how well this
> now scales.
> 
> Best,
> Steffen
> 
> 
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

Re: [Emc-developers] hal_meter

[gene h. <ghe...@sh...>]

On 11/21/25 16:47, Hans Unzner wrote:
> With that CSS I get a white background with 20 pt font size (though it 
> needs some fine tuning to not affect other applications hat much):
>
> notebook*,box*{
>     background-color: white;
>     font-size: 20;
> }
>
> Hans
>
> Am 21.11.25 um 19:18 schrieb gene heskett:
>>
>>
>> On 11/20/25 16:05, andy pugh wrote:
>>> On Thu, 20 Nov 2025 at 20:10, gene heskett <ghe...@sh...> 
>>> wrote:
>>>
>>>> Is there a way to A; get rid of the very low contrast and
>>>> B: force the use of a larger font such that I can still
>>>> read it when it does not have "focus"?
>>> You could experiment with the high contrast styles in the desktop
>>> manager, though that doesn't seem to have much effect on halmeter.
>> I have added that dir and css file which didn't exist, getting
>> a fixed black background which helps a bit but the text size
>> of 20 doesn't make it bigger. I've not tried larger values.  I will
>> when next at the machines own keyboard. Currently I am
>> attempting to reconfigure it back to 3 axis for doing some
>> simple EDM. I have the hardware to make the edm feed
>> automatic, winding my own transformer to measure the
>> sparking activity & making that an analogue voltage to
>> present to a 7i76D analogue input pin. If I am successful, you
>> will get schematics that could be used  W-EDM machine.
>>>
That would be quite a bit better, but how did you get it?, and I note 
the selection frame has focus, while the halmeter display is still the 
low contrast no focus & greyed out state although the text is bigger.  
I've now tried font-size: up to 40; with no effect.
>>
>> Cheers, Gene Heskett, CET.
>
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.

Re: [Emc-developers] hal_meter

[gene h. <ghe...@sh...>]

On 11/21/25 16:47, Hans Unzner wrote:
> With that CSS I get a white background with 20 pt font size (though it 
> needs some fine tuning to not affect other applications hat much):
>
> notebook*,box*{
>     background-color: white;
>     font-size: 20;
> }
> this:
notebooK*,box* {
        background-color: black;
         font-size: 40;
}
gets me a black border, a bright white background inside that border and 
greyed out text I cannot read unless it has focus, at the normal text 
font size.

Several questions result, Hans:

1: Where can I find the Document describing how to use this css stuff?

2: And where can I find the file I need to set and make chattr +i, 
everytime I use nano to remotely edit something like this, I loose the 
keyboard repeat globally, a PITA that takes me half an hour to find and 
fix with the bookworms hiding of everything important

3: Spectacle, the screen shot taker, doesn't work on screens logged into 
other machines. So I can't even try to show you what I see.
> Hans
>
> Am 21.11.25 um 19:18 schrieb gene heskett:
>>
>>
>> On 11/20/25 16:05, andy pugh wrote:
>>> On Thu, 20 Nov 2025 at 20:10, gene heskett <ghe...@sh...> 
>>> wrote:
>>>
>>>> Is there a way to A; get rid of the very low contrast and
>>>> B: force the use of a larger font such that I can still
>>>> read it when it does not have "focus"?
>>> You could experiment with the high contrast styles in the desktop
>>> manager, though that doesn't seem to have much effect on halmeter.
>> I have added that dir and css file which didn't exist, getting
>> a fixed black background which helps a bit but the text size
>> of 20 doesn't make it bigger. I've not tried larger values.  I will
>> when next at the machines own keyboard. Currently I am
>> attempting to reconfigure it back to 3 axis for doing some
>> simple EDM. I have the hardware to make the edm feed
>> automatic, winding my own transformer to measure the
>> sparking activity & making that an analogue voltage to
>> present to a 7i76D analogue input pin. If I am successful, you
>> will get schematics that could be used  W-EDM machine.
>>>
>>
>> Cheers, Gene Heskett, CET.
>
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.

Re: [Emc-developers] hal_meter

[Hans U. <han...@gm...>]

With that CSS I get a white background with 20 pt font size (though it 
needs some fine tuning to not affect other applications hat much):

notebook*,box*{
     background-color: white;
     font-size: 20;
}

Hans

Am 21.11.25 um 19:18 schrieb gene heskett:
>
>
> On 11/20/25 16:05, andy pugh wrote:
>> On Thu, 20 Nov 2025 at 20:10, gene heskett <ghe...@sh...> wrote:
>>
>>> Is there a way to A; get rid of the very low contrast and
>>> B: force the use of a larger font such that I can still
>>> read it when it does not have "focus"?
>> You could experiment with the high contrast styles in the desktop
>> manager, though that doesn't seem to have much effect on halmeter.
> I have added that dir and css file which didn't exist, getting
> a fixed black background which helps a bit but the text size
> of 20 doesn't make it bigger. I've not tried larger values.  I will
> when next at the machines own keyboard. Currently I am
> attempting to reconfigure it back to 3 axis for doing some
> simple EDM. I have the hardware to make the edm feed
> automatic, winding my own transformer to measure the
> sparking activity & making that an analogue voltage to
> present to a 7i76D analogue input pin. If I am successful, you
> will get schematics that could be used  W-EDM machine.
>>
>
> Cheers, Gene Heskett, CET.

Re: [Emc-developers] hal_meter

[gene h. <ghe...@sh...>]

On 11/20/25 16:05, andy pugh wrote:
> On Thu, 20 Nov 2025 at 20:10, gene heskett <ghe...@sh...> wrote:
>
>> Is there a way to A; get rid of the very low contrast and
>> B: force the use of a larger font such that I can still
>> read it when it does not have "focus"?
> You could experiment with the high contrast styles in the desktop
> manager, though that doesn't seem to have much effect on halmeter.
I have added that dir and css file which didn't exist, getting
a fixed black background which helps a bit but the text size
of 20 doesn't make it bigger. I've not tried larger values.  I will
when next at the machines own keyboard. Currently I am
attempting to reconfigure it back to 3 axis for doing some
simple EDM. I have the hardware to make the edm feed
automatic, winding my own transformer to measure the
sparking activity & making that an analogue voltage to
present to a 7i76D analogue input pin. If I am successful, you
will get schematics that could be used  W-EDM machine.
>

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.

Re: [Emc-developers] hal_meter

[gene h. <ghe...@sh...>]

On 11/21/25 06:46, J.M. Garcia wrote:
> El jue, 20 nov 2025 a las 23:55, gene heskett (<ghe...@sh...>)
> escribió:
>
>>> from the hal file:
>>> #  ---manual tool change signals---
>>> loadusr -W hal_manualtoolchange
>>> net     tool-change-request     <=      iocontrol.0.tool-change      =>
>>> hal_manualtoolchange.change <<< does not exist.
>>> net     tool-change-confirmed   <=      iocontrol.0.tool-changed     =>
>>> hal_manualtoolchange.changed
>>> net     tool-number             <= iocontrol.0.tool-prep-number  =>
>>> hal_manualtoolchange.number
>>> net     tool-prepare-loopback   <=      iocontrol.0.tool-prepare     =>
>>> iocontrol.0.tool-prepared
And it all works normally IF I login with ssh -X gene@alias.  W/o the -X 
no gfx which was the REAL error.  At 91 I've reached that age where I 
don't recall what if anything. I had for breakfast. Embarrassing.  All 
of this takes place on my side of a router running dd-wrt.  So I don't 
worry much about hackers, no one has gotten in in 25 years yet every 
machine here can browse the net. dd-wrt has very sharp teeth, an 
excellent guard dog..
>>> This is 2.10-pre running on an old bullseye install
>>
> Ok, Gene.
>
> My first question would be whether the user component hal_manualtoolchange
> loads and functions correctly.
>
> In a terminal:
>
> xiuser@HPi7:~$halrun
> halcmd: loadusr -W hal_manualtoolchange ( + popup window)
> halcmd: show pin
> Component Pins:
> Owner   Type  Dir                 Value  Name
>       4  bit   IN                  FALSE  hal_manualtoolchange.change
>       4  bit   IN                  FALSE  hal_manualtoolchange.change_button
>       4  bit   OUT                 FALSE  hal_manualtoolchange.changed
>       4  s32   IN                      0  hal_manualtoolchange.number
>
> halcmd: start
> halcmd: setp hal_manualtoolchange.change TRUE (+ manual tool change popup
> window)
> halcmd: show pin
> Component Pins:
> Owner   Type  Dir                 Value  Name
>       4  bit   IN                   TRUE  hal_manualtoolchange.change
>       4  bit   IN                  FALSE  hal_manualtoolchange.change_button
>       4  bit   OUT                  TRUE  hal_manualtoolchange.changed
>       4  s32   IN                      0  hal_manualtoolchange.number
> halcmd: stop
> halcmd: exit
>
> As you can see, the component loads and changes values correctly.
> I am using a RIP 2.10.pre installation. The component compiled perfectly.
>
> Regards
Thanks  J.M. Garcia.
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.

Re: [Emc-developers] hal_meter

[J.M. G. <jmg...@gm...>]

El jue, 20 nov 2025 a las 23:55, gene heskett (<ghe...@sh...>)
escribió:

> > from the hal file:
> > #  ---manual tool change signals---
>
> > loadusr -W hal_manualtoolchange
> > net     tool-change-request     <=      iocontrol.0.tool-change      =>
> > hal_manualtoolchange.change <<< does not exist.
> > net     tool-change-confirmed   <=      iocontrol.0.tool-changed     =>
> > hal_manualtoolchange.changed
> > net     tool-number             <= iocontrol.0.tool-prep-number  =>
> > hal_manualtoolchange.number
> > net     tool-prepare-loopback   <=      iocontrol.0.tool-prepare     =>
> > iocontrol.0.tool-prepared
>
> > This is 2.10-pre running on an old bullseye install
>
>
Ok, Gene.

My first question would be whether the user component hal_manualtoolchange
loads and functions correctly.

In a terminal:

xiuser@HPi7:~$halrun
halcmd: loadusr -W hal_manualtoolchange ( + popup window)
halcmd: show pin
Component Pins:
Owner   Type  Dir                 Value  Name
     4  bit   IN                  FALSE  hal_manualtoolchange.change
     4  bit   IN                  FALSE  hal_manualtoolchange.change_button
     4  bit   OUT                 FALSE  hal_manualtoolchange.changed
     4  s32   IN                      0  hal_manualtoolchange.number

halcmd: start
halcmd: setp hal_manualtoolchange.change TRUE (+ manual tool change popup
window)
halcmd: show pin
Component Pins:
Owner   Type  Dir                 Value  Name
     4  bit   IN                   TRUE  hal_manualtoolchange.change
     4  bit   IN                  FALSE  hal_manualtoolchange.change_button
     4  bit   OUT                  TRUE  hal_manualtoolchange.changed
     4  s32   IN                      0  hal_manualtoolchange.number
halcmd: stop
halcmd: exit

As you can see, the component loads and changes values correctly.
I am using a RIP 2.10.pre installation. The component compiled perfectly.

Regards

Re: [Emc-developers] hal_meter

[Robert S. <rm...@un...>]

Am Donnerstag, dem 20.11.2025 um 17:10 -0500 schrieb gene heskett:
> > Which document are you missing in the docs?
> docs for hal.  Its pretty simple but I find I need to experiment with
> the == and =< => syntax from time to time.

the "net" command in hal ignores "==", "=>" and so on, that is purely
there to document intent.

LinuxCNC HAL documentation is here 
https://linuxcnc.org/docs/html/ under "HAL"
resp. Chapter 5 in
https://linuxcnc.org/docs/stable/pdf/LinuxCNC_Documentation.pdf


-- 
Robert Schöftner <rm...@un...>

Re: [Emc-developers] hal_meter

[andy p. <bod...@gm...>]

On Thu, 20 Nov 2025 at 22:55, gene heskett <ghe...@sh...> wrote:

>      Pin 'hal_manualtoolchange.change' does not exist

Presumably hal_manualtoolchange isn't loading. There should be further
clues in the debug output.

> This is 2.10-pre running on an old bullseye install

Technically 2.10 isn't supported on anything older than Bookworm. But
that's unlikely to _suddenly_ be the problem.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

Re: [Emc-developers] hal_meter

[gene h. <ghe...@sh...>]

On 11/20/25 15:26, Hans Unzner wrote:
> I think you can play around with the CSS to get a higher contrast 
> (adjust the background color etc.).
> For the font I can only refer to my answer of your question from march 
> 2022: https://sourceforge.net/p/emc/mailman/message/37647667/
> Which document are you missing in the docs?
>
New problem:  none of my previous configs will now run. This code at the 
bottom of the .hal file, unchanged in 2 decades; errors now:
twopass: Error in file ./go704-xyz-edm.hal:
     Pin 'hal_manualtoolchange.change' does not exist
Shutting down and cleaning up LinuxCNC...

from the hal file:
#  ---manual tool change signals---

loadusr -W hal_manualtoolchange
net     tool-change-request     <=      iocontrol.0.tool-change      =>  
hal_manualtoolchange.change <<< does not exist.
net     tool-change-confirmed   <=      iocontrol.0.tool-changed     =>  
hal_manualtoolchange.changed
net     tool-number             <= iocontrol.0.tool-prep-number  =>  
hal_manualtoolchange.number
net     tool-prepare-loopback   <=      iocontrol.0.tool-prepare     =>  
iocontrol.0.tool-prepared

This is 2.10-pre running on an old bullseye install

> Hans
>
> Am 20.11.25 um 21:07 schrieb gene heskett:
>> Diabetes other medication and 91 years is beginning to
>> affect my eyesight.
>>
>> Is there a way to A; get rid of the very low contrast and
>> B: force the use of a larger font such that I can still
>> read it when it does not have "focus"?
>>
>> ISTR there was a mention of such in the now apparently
>> discontinued hal document. But that been gone about a
>> decade now. Where is that documentation now?
>>
>> Thanks everybody.
>>
>> Cheers, Gene Heskett, CET.
>
>
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
> .

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.

Re: [Emc-developers] hal_meter

[gene h. <ghe...@sh...>]

On 11/20/25 15:26, Hans Unzner wrote:
> I think you can play around with the CSS to get a higher contrast 
> (adjust the background color etc.).
> For the font I can only refer to my answer of your question from march 
> 2022: https://sourceforge.net/p/emc/mailman/message/37647667/
Creating that file gave me an unchanging dark grey background but did 
not appear to effect a size of text change, but the black does help the 
visibility enough to be read a little easier.   Thank you Hans.
> Which document are you missing in the docs?
docs for hal.  Its pretty simple but I find I need to experiment with 
the == and =< => syntax from time to time.
>
> Hans
>
> Am 20.11.25 um 21:07 schrieb gene heskett:
>> Diabetes other medication and 91 years is beginning to
>> affect my eyesight.
>>
>> Is there a way to A; get rid of the very low contrast and
>> B: force the use of a larger font such that I can still
>> read it when it does not have "focus"?
>>
>> ISTR there was a mention of such in the now apparently
>> discontinued hal document. But that been gone about a
>> decade now. Where is that documentation now?
>>
>> Thanks everybody.
>>
>> Cheers, Gene Heskett, CET.
>
>
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
> .

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.

Re: [Emc-developers] hal_meter

[andy p. <bod...@gm...>]

On Thu, 20 Nov 2025 at 20:10, gene heskett <ghe...@sh...> wrote:

> Is there a way to A; get rid of the very low contrast and
> B: force the use of a larger font such that I can still
> read it when it does not have "focus"?

You could experiment with the high contrast styles in the desktop
manager, though that doesn't seem to have much effect on halmeter.

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

Re: [Emc-developers] hal_meter

[Hans U. <han...@gm...>]

I think you can play around with the CSS to get a higher contrast 
(adjust the background color etc.).
For the font I can only refer to my answer of your question from march 
2022: https://sourceforge.net/p/emc/mailman/message/37647667/
Which document are you missing in the docs?

Hans

Am 20.11.25 um 21:07 schrieb gene heskett:
> Diabetes other medication and 91 years is beginning to
> affect my eyesight.
>
> Is there a way to A; get rid of the very low contrast and
> B: force the use of a larger font such that I can still
> read it when it does not have "focus"?
>
> ISTR there was a mention of such in the now apparently
> discontinued hal document. But that been gone about a
> decade now. Where is that documentation now?
>
> Thanks everybody.
>
> Cheers, Gene Heskett, CET.

[Emc-developers] hal_meter

[gene h. <ghe...@sh...>]

Diabetes other medication and 91 years is beginning to
affect my eyesight.

Is there a way to A; get rid of the very low contrast and
B: force the use of a larger font such that I can still
read it when it does not have "focus"?

ISTR there was a mention of such in the now apparently
discontinued hal document. But that been gone about a
decade now. Where is that documentation now?

Thanks everybody.

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis
Don't poison our oceans, interdict drugs at the src.

Re: [Emc-developers] pciE driver - successive write

[klemen d. <k.d...@gm...>]

Dear Bertho,

Thank you for your fast response. You were right, this (volatile) solved
the problem.
The same program now works fine :)

So much time wasted for such a stupid mistake... Thank you! :)
Regards,
Klemen



On Thu, 20 Nov 2025 at 13:26, Bertho Stultiens <lc...@va...> wrote:

> On 11/20/25 12:51 PM, klemen dovrtel wrote:
> >    *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0000) = 0x11111111; nanosleep
> > (&ts_dtLong, NULL);
> >    *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0004) = 0x22222222;
>
> Using '*(rtapi_u32 *)(ptr + 0) = xyz' several times may not result in
> what you expect. The compiler sees multiple references to the same
> address(es) and may opt to cache the result(s). These addresses are
> actually volatile targets and must be declared as such.
>
>
> Maybe you should try:
> volatile rtapi_u32 *addr0 = (volatile rtapi_u32 *)(pci_device.ptr_bar2 +
> 0x0000);
> volatile rtapi_u32 *addr4 = (volatile rtapi_u32 *)(pci_device.ptr_bar2 +
> 0x0004);
>
> // Write
> *addr0 = 0x11111111;
> *addr4 = 0x22222222;
>
> // Read
> rtapi_print_msg(RTAPI_MSG_INFO, "rd offs 0: %08x.\n", *addr0);
> rtapi_print_msg(RTAPI_MSG_INFO, "rd offs 4: %08x.\n", *addr4);
>
> // Write
> *addr0 = 0x33333333;
> *addr4 = 0x44444444;
>
> // Read
> rtapi_print_msg(RTAPI_MSG_INFO, "rd offs 0: %08x.\n", *addr0);
> rtapi_print_msg(RTAPI_MSG_INFO, "rd offs 4: %08x.\n", *addr4);
>
> ... etc ...
>
>
> --
> Greetings Bertho
>
> (disclaimers are disclaimed)
>
>
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

Re: [Emc-developers] pciE driver - successive write

[Bertho S. <lc...@va...>]

On 11/20/25 12:51 PM, klemen dovrtel wrote:
>    *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0000) = 0x11111111; nanosleep
> (&ts_dtLong, NULL);
>    *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0004) = 0x22222222;

Using '*(rtapi_u32 *)(ptr + 0) = xyz' several times may not result in 
what you expect. The compiler sees multiple references to the same 
address(es) and may opt to cache the result(s). These addresses are 
actually volatile targets and must be declared as such.


Maybe you should try:
volatile rtapi_u32 *addr0 = (volatile rtapi_u32 *)(pci_device.ptr_bar2 + 
0x0000);
volatile rtapi_u32 *addr4 = (volatile rtapi_u32 *)(pci_device.ptr_bar2 + 
0x0004);

// Write
*addr0 = 0x11111111;
*addr4 = 0x22222222;

// Read
rtapi_print_msg(RTAPI_MSG_INFO, "rd offs 0: %08x.\n", *addr0);
rtapi_print_msg(RTAPI_MSG_INFO, "rd offs 4: %08x.\n", *addr4);

// Write
*addr0 = 0x33333333;
*addr4 = 0x44444444;

// Read
rtapi_print_msg(RTAPI_MSG_INFO, "rd offs 0: %08x.\n", *addr0);
rtapi_print_msg(RTAPI_MSG_INFO, "rd offs 4: %08x.\n", *addr4);

... etc ...


-- 
Greetings Bertho

(disclaimers are disclaimed)

[Emc-developers] pciE driver - successive write

[klemen d. <k.d...@gm...>]

Hello everybody,

I am working with a pciE FPGA card and i am trying to write to memory
mapped memory as fast as possible. If I generate a sequence of
successive write commands, nothing gets written.

I was not sure if there is a problem with the fpga pcie IP core, so I
decided to buy a LPT port pcie card (based on AX99100 chip) and test it. I
tried the same test again and the result is the same - nothing gets
written. The registers seem to have just one byte writable, but I think
this is not crucial here.

Does anybody have an idea how I should write an array of data to a pcie
card as fast as possible? I did try to add a delay in between and that
helped, but this added a lot of delay and I am not sure how close to the
limitation is that.

Please find my code and the result (on LPT port card) below.
Regards
Klemen

code snippet
---------------
  pci_device.ptr_bar0 = rtapi_pci_ioremap_bar(dev, 0);
  rtapi_print_msg(RTAPI_MSG_INFO, "lptPortdriver: bar 0 mapped to %p\n",
pci_device.ptr_bar0);

  pci_device.ptr_bar2 = rtapi_pci_ioremap_bar(dev, 2);
  rtapi_print_msg(RTAPI_MSG_INFO, "pciLedTest_wb: bar 2 mapped to %p\n",
pci_device.ptr_bar2);
  rtapi_print_msg(RTAPI_MSG_INFO, "\n\n");



  rtapi_print("max_delay_avaliable = %ld ns\n", rtapi_delay_max());

  rtapi_print_msg(RTAPI_MSG_INFO, "lptPortdriver - test1: write to led
register\n");
  t1 = rtapi_get_time(); // returns time in ns
  *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0000) = 0x11111111; nanosleep
(&ts_dtLong, NULL);
  *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0004) = 0x22222222;
  t2 = rtapi_get_time(); // returns time in ns
  rtapi_print_msg(RTAPI_MSG_INFO, "lptPortDriver read32: offset 0x0000:
%08x.\n", *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0000) );
  rtapi_print_msg(RTAPI_MSG_INFO, "lptPortDriver read32: offset 0x0004:
%08x.\n", *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0004) );


  rtapi_print_msg(RTAPI_MSG_INFO, "lptPortdriver - test2: write to led
register\n");
  t3 = rtapi_get_time(); // returns time in ns
  *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0000) = 0x33333333; rtapi_delay(1);
  *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0004) = 0x44444444;
  t4 = rtapi_get_time(); // returns time in ns
  rtapi_print_msg(RTAPI_MSG_INFO, "lptPortDriver read32: offset 0x0000:
%08x.\n", *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0000) );
  rtapi_print_msg(RTAPI_MSG_INFO, "lptPortDriver read32: offset 0x0004:
%08x.\n", *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0004) );


  rtapi_print_msg(RTAPI_MSG_INFO, "lptPortdriver - test3: write to led
register\n");
  t5 = rtapi_get_time(); // returns time in ns
  *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0000) = 0x55555555;
  *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0004) = 0x66666666;
  t6 = rtapi_get_time(); // returns time in ns
  rtapi_print_msg(RTAPI_MSG_INFO, "lptPortDriver read32: offset 0x0000:
%08x.\n", *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0000) );
  rtapi_print_msg(RTAPI_MSG_INFO, "lptPortDriver read32: offset 0x0004:
%08x.\n", *(rtapi_u32*)(pci_device.ptr_bar2 + 0x0004) );


  tdiff1 = t2 - t1;
  tdiff2 = t4 - t3;
  tdiff3 = t6 - t5;
  rtapi_print("nanosleep  Tdiff1 = %ld ns\n", tdiff1);
  rtapi_print("rtapidelay Tdiff2 = %ld ns\n", tdiff2);
  rtapi_print("rtapidelay Tdiff3 = %ld ns\n", tdiff3);


output
---------------
RTAPI_PCI: Map BAR 0
Failed to remap MMIO 0 of PCI device 0000:05:00.2: No such device
lptPortdriver: bar 0 mapped to (nil)
RTAPI_PCI: Map BAR 2
pciLedTest_wb: bar 2 mapped to 0x7f2d4b2bd000
max_delay_avaliable = 10000 ns
lptPortdriver - test1: write to led register
lptPortDriver read32: offset 0x0000: 00000011.
lptPortDriver read32: offset 0x0004: 00000022.
lptPortdriver - test2: write to led register
lptPortDriver read32: offset 0x0000: 00000033.
lptPortDriver read32: offset 0x0004: 00000044.
lptPortdriver - test3: write to led register
lptPortDriver read32: offset 0x0000: 00000033.
lptPortDriver read32: offset 0x0004: 00000044.
nanosleep  Tdiff1 = 100054728 ns
rtapidelay Tdiff2 = 55561 ns
rtapidelay Tdiff3 = 38 ns

Re: [Emc-developers] Tool Data Synchronization (Smooth-Core)

[Brad C. <sho...@gm...>]

Yes, there's overlap.  MT Connect builds on the ISO 13399 standard.

However, MTConnect is a 'read only' protocol so it can't be used for data
synchronization.

I would really like loobric to support MTConnect for data gathering. Though
I haven't even thought about what that means yet.

On Wed, Nov 19, 2025 at 10:22 AM Steffen Möller via Emc-developers <
emc...@li...> wrote:

>
>
>
>
> > Gesendet: Mittwoch, 19. November 2025 um 16:19
> > Von: "andy pugh" <bod...@gm...>
> > An: "EMC developers" <emc...@li...>
> > Betreff: Re: [Emc-developers] Tool Data Synchronization (Smooth-Core)
> >
> > On Wed, 5 Nov 2025 at 18:05, Brad Collette <sho...@gm...>
> wrote:
> >
> > > I've put together a new Github organization (loobric) and started work
> on
> > > several repos within it.
> >
> > Someone on the LinuxCNC forum just asked about MTConnect
> > (https://en.wikipedia.org/wiki/MTConnect )
> > Is there any overlap there?
>
>
> https://github.com/mtconnect/mtconnect_sysml_model/blob/master/figures/Cutting%20Tool%20Composition.png
> Makes a good impression on me.
>
> Am also impressed by all the many bits in the loobric repository. Will set
> it up  locally and see where it carries me.
>
> Steffen
>
>
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>


-- 
Brad Collette
573-427-7132

Re: [Emc-developers] Tool Data Synchronization (Smooth-Core)

[Steffen M. <ste...@gm...>]

> Gesendet: Mittwoch, 19. November 2025 um 16:19
> Von: "andy pugh" <bod...@gm...>
> An: "EMC developers" <emc...@li...>
> Betreff: Re: [Emc-developers] Tool Data Synchronization (Smooth-Core)
>
> On Wed, 5 Nov 2025 at 18:05, Brad Collette <sho...@gm...> wrote:
> 
> > I've put together a new Github organization (loobric) and started work on
> > several repos within it.
> 
> Someone on the LinuxCNC forum just asked about MTConnect
> (https://en.wikipedia.org/wiki/MTConnect )
> Is there any overlap there?

https://github.com/mtconnect/mtconnect_sysml_model/blob/master/figures/Cutting%20Tool%20Composition.png
Makes a good impression on me.

Am also impressed by all the many bits in the loobric repository. Will set it up  locally and see where it carries me.

Steffen

Re: [Emc-developers] Tool Data Synchronization (Smooth-Core)

[Robert S. <rm...@un...>]

Am Mittwoch, dem 19.11.2025 um 15:19 +0000 schrieb andy pugh:
> 
> Someone on the LinuxCNC forum just asked about MTConnect
> (https://en.wikipedia.org/wiki/MTConnect )
> Is there any overlap there?
> 

this 
https://github.com/mtconnect/vtech_learningfactory_tormach_adapter
at least has some overlap with linuxcnc, but I didn't really look into
it -- seems to be an abandoned university project/demo fake?.

from the description on wikipedia, MTConnect seems to aim at
"visibility" into machine tool data, similiar to what one would use
prometheus+extractors/grafana for to monitor IT infrastructure.

reader beware, this rabbit hole seems to go deep --- I ran out of
buzzword bingo cards in minutes. maybe somewhere in there some
functionality is buried that can actually mutate data.

so at first glance MTConnect could help with linuxcnc->CAD but not the
other way round. 

-- 
Robert Schöftner <rm...@un...>

Re: [Emc-developers] Tool Data Synchronization (Smooth-Core)

[andy p. <bod...@gm...>]

On Wed, 5 Nov 2025 at 18:05, Brad Collette <sho...@gm...> wrote:

> I've put together a new Github organization (loobric) and started work on
> several repos within it.

Someone on the LinuxCNC forum just asked about MTConnect
(https://en.wikipedia.org/wiki/MTConnect )
Is there any overlap there?

-- 
atp
"A motorcycle is a bicycle with a pandemonium attachment and is
designed for the especial use of mechanical geniuses, daredevils and
lunatics."
— George Fitch, Atlanta Constitution Newspaper, 1912

[Emc-developers] Don't get the UK documentation to build

[Steffen M. <ste...@gm...>]

Hello,

We have the weird situation that changes in Weblate can break our build. And we have the even weirder situation that the Ukrainian translations are not building and I have been trying all over this and the past weekend to find the culprit(s) - but I fail to find them. And when I bisect the XML file to those lines that look suspicious, I still do not see what may be wrong with the lines whose removal allows PDF creation. I found some likely bugs, like [ [ ] ] instead of simple [ ] or backticks that were not matched or followed by a single quote. But apparently I have not found them all and/or it is something very different.

So, when I cannot find problems with those lines, I have some confident that a well-meaning translator cannot find those problems either.  And this then indicates to me that our approach to translations is too fragile. We need better error messages. And we need them preferably already in weblate. I had a quick look at asciidoc-linter (https://github.com/docToolchain/asciidoc-linter/), but that tool is still in development and the current version in master has a stupid bug that is not fixed.  What would also be darn cool would be the possibility to bisect over subsets of po.uk. Somewhat unfortunate I only got this idea now whle I am writing these lines.

If there is someone who could have a look independent of mine, this would be much preferred. Some insights in the Ukrainian language may be beneficial but I guess not required.

Best,

Steffen