Re: [Emc-developers] Where to inspect the latest documentation->GitHub (was Buildbot(s))

[Greg C]

On Fri, Sep 20, 2024 at 1:45 PM andy pugh  wrote:

> On Fri, 20 Sept 2024 at 18:24, Greg C  wrote:
> >
> > I am all for moving the ball forward, but the commit without any warning
> > was definitely a hard pill to swallow.
>
> It does only affect those using buildbot builds and master. Normal
> users, working with released versions of 2.9 are unaffected.
>

I am aware.  The point was not to speculate on how many users were
impacted, but rather to point out the unannounced impact to the users.
Changes of this magnitude could benefit from clearer communication,
especially since some "normal" (non developer) users rely on the master
branch, and updates to it, for legitimate reasons.

 On Fri, Sep 20, 2024 at 12:26 PM andy pugh  wrote:

> On Fri, 20 Sept 2024 at 17:13, Marius Liebenberg 
> wrote:
>
> > So please do not drop the ball on the Buster users. At least not until
> > there are a new stable Debian release.
>
> Buster is out of support, though.
>
> However, the reason for dropping support was not that, it was the
> unavailability of various software packages (a working version of po4a
> for example)


I know it happened slowly over time, but it seems like this project has
become the LinuxCNC Document Translation project.  While I appreciate that
document translations were deemed necessary, it seems to have drawn focus
away from the main project and had a counterproductive effect. Perhaps
managing document translations in a separate repository could help us focus
more on the core project while still supporting that important work.  The
shear number of commits that have broken things, as well as the the
increase in size of the project (now hundreds of megabytes) due to document
translations is concerning.

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Where to inspect the latest documentation->GitHub (was Buildbot(s))

[Greg C]

Seb,

I was wondering if that was the case.  I saw an error about the python
version being out of date on my phone, but couldn't find it again when I
went looking on my PC.

I am all for moving the ball forward, but the commit without any warning
was definitely a hard pill to swallow.  It would have been nice to have
some warning "we are going to deprecate Buster on Master branch on July 7,
2024, prepare accordingly" (a month or 3 in advance).  Given adequate
notice it would have allowed time for you to update the build bot, and
everyone else to get their affairs in order before being forced into it.
Not to mention the users who are just confused as to why they
aren't getting updates, because they dont understand how any of this works.

I'm just now upgrading my plasma table to MX Linux 23.

At any rate, it seems there aren't many devs left, so I suppose there are
fewer and fewer people to worry about pissing off.

Thank you for what you do to keep things moving.

-Greg

On Fri, Sep 20, 2024 at 10:45 AM Sebastian Kuzminsky 
wrote:

> That commit also broke building of the docs, since that currently happens
> on a buster machine.
>
> --
> Sebastian Kuzminsky
>
>
> On September 20, 2024 8:06:44 AM MDT, Greg C 
> wrote:
>
>> Support for Buster on the master branch was dropped with this commit by
>> Rene on July 7, 2024:
>>
>> https://github.com/LinuxCNC/linuxcnc/commit/855577cd773817a585abc495e30fcd9c2405e79a
>>
>> There was no warning or communication about it whatsoever (*at least none
>> that I saw).
>>
>> Sorry to be the bearer of bad news.
>>
>> -Greg
>>
>> On Fri, Sep 20, 2024 at 9:32 AM andy pugh  wrote:
>>
>> On Fri, 20 Sept 2024 at 14:20, gene heskett  wrote:
>>>
>>> Which buildbot are you using?
>>>>>
>>>>> deb http://buildbot.linuxcnc.org/ buster master-rtpreempt
>>>>
>>>
>>> For some reason buildbot.linuxcnc.org isn't building buster debs for
>>> master:
>>> http://buildbot.linuxcnc.org/buildbot/grid
>>> (but is for 2.9)
>>>
>>> Oddly, neither is buildbot2, but that is building debs for Bullseye
>>> and Bookworm.
>>> http://buildbot2.highlab.com/debian/dists/
>>>
>>> --
>>> 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 mailing list
>>> Emc-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>>
>>> --
>> Emc-developers mailing list
>> Emc-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/emc-developers
>>
>>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Where to inspect the latest documentation->GitHub (was Buildbot(s))

[Greg C]

Support for Buster on the master branch was dropped with this commit by
Rene on July 7, 2024:

https://github.com/LinuxCNC/linuxcnc/commit/855577cd773817a585abc495e30fcd9c2405e79a

There was no warning or communication about it whatsoever (*at least none
that I saw).

Sorry to be the bearer of bad news.

-Greg

On Fri, Sep 20, 2024 at 9:32 AM andy pugh  wrote:

> On Fri, 20 Sept 2024 at 14:20, gene heskett  wrote:
>
> > > Which buildbot are you using?
> > >
> > deb http://buildbot.linuxcnc.org/ buster master-rtpreempt
>
> For some reason buildbot.linuxcnc.org isn't building buster debs for
> master:
> http://buildbot.linuxcnc.org/buildbot/grid
> (but is for 2.9)
>
> Oddly, neither is buildbot2, but that is building debs for Bullseye
> and Bookworm.
> http://buildbot2.highlab.com/debian/dists/
>
> --
> 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 mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Where to inspect the latest documentation -> GitHub (was Buildbot(s))

[Greg C]

I hate to be the bearer of bad news, but the buildbot appears to still be hung 
up … no new docs, etc.  

Is there a way to maybe skip all the previous builds that may have caused it 
angst until Andy committed the one release that fixed the po4a problem?  Of 
course I don’t know what the problem is so I’m just thinking out loud.

Thanks!!

-Greg

> On Sep 16, 2024, at 10:31 PM, Sebastian Kuzminsky  wrote:
> 
> buildbot2 had crashed, the buildbot process itself was killed by the
> out-of-memory killer.  The docs are built by buildbot2, so this explains
> why they haven't been updating.
> 
> (Maybe a memory leak in the buildbot process, or maybe i just
> under-provisioned that VM?  I was at 2 GB RAM, i bumped it up to 4 GB,
> which exhausts the memory on the VM host...)
> 
> I restarted it and builds have started up again, hopefully there will be
> fresh docs in a few hours (lots of builds to get through).
> 
> 
> If we *can* move the docs builder to github, that might be a good idea.
> I'm a bit worried since the docs builder currently has an ssh key that
> allows it to rsync the docs to www.linuxcnc.org, and we'd have to be
> careful if we put that key on github somewhere.  Or to come up with some
> other way to deliver the docs.
> 
> Or just host the built docs on github, though i've always taken it as a
> point of pride that we're mostly self hosting.  But clearly i don't have
> the energy to do a good job of it any more.
> 
> --
> Sebastian Kuzminsky
> 
> 
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Buildbot(s)

[Greg C]

**politely taps microphone ... is this thing on??**

Just wanted to bump this as it was brought up on the forum today.  It seems
the buildbot(s) have been down since July.  Docs arent being built.

Is there a way to get this going again, or should we start to direct users
to build their own packages?  I am not sure how the docs get build and
updated, so I'm not sure what the work around would be there.

I know this is all basically volunteer, so just politely asking, I know
everyone's time is valuable.

Thanks,
Greg

On Tue, Sep 3, 2024 at 10:33 PM Greg C  wrote:

> In the event this has somehow gone unnoticed, it seems both buildbots are
> broken.
>
> The html doc pages haven't been updated in quite some time.
>
> I believe Andy committed the PRs that fixed the conflits, but alas,
> they're still down.
>
> -Greg
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Buildbot(s)

[Greg C]

In the event this has somehow gone unnoticed, it seems both buildbots are
broken.

The html doc pages haven't been updated in quite some time.

I believe Andy committed the PRs that fixed the conflits, but alas, they're
still down.

-Greg

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Got workflow

[Greg C]

Glad to see it shook loose.  

Thanks for checking into it anyhow, Andy.  I appreciate it!

-Greg 

> On May 28, 2024, at 1:55 PM, andy pugh  wrote:
> 
> On Wed, 22 May 2024 at 12:29, Greg C  wrote:
> 
>> Looks like the git workflow is sticking on the package-arch “Test Debian
>> packages” step for Sid:
> 
> 
> I finally found the time to look at this (not that I have any idea how the
> git workflows work) and found that, as far as I can see, it is now working.
> 
> https://github.com/LinuxCNC/linuxcnc/pull/2982/checks
> 
> I don't know if anyone did anything. I do know that I didn't.
> 
> --
> 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 mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Got workflow

[Greg C]

Looks like the git workflow is sticking on the package-arch “Test Debian 
packages” step for Sid:



While it started falling on its face after my commit, I don’t believe my commit 
to be the cause of the issue.  Seems like a package is missing or broken.  Just 
wanted to bring it to …someone’s… attention.

Also, I sent this several times trying to work around the 128kb restriction, 
sorry for whoever had to endure that.

-Greg 

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Error fetching from buildbot

[Greg C]

 http://buildbot2.highlab.com/  is necessary for Bullseye and Bookworm.

Marius is talking about Buster.

The original buildbot is still building for Buster:

[image: image (1).png]
[image: image (2).png]


2.9.2:

[image: image (3).png]


Changing the Section(s) field to "master-rtpreempt" yields the following:

master:

[image: image (4).png]


Note:  these screenshots were grabbed yesterday before I pushed changes so
the latest version for master will be higher.

-Greg


On Mon, Feb 5, 2024 at 3:36 AM Rod Webster  wrote:

> You need to change your sources to http://buildbot2.highlab.com/ per the
> instructions there
> Linuxcnc never really released a version on other  than Bookworm
> I'm not sure if it will give you exactly what was on the Bookworm release
> which was a snapshot but it will be close.
>
>
> Rod Webster
> *1300 896 832*
> +61 435 765 611
> Vehicle Modifications Network
> www.vehiclemods.net.au
>
>
> On Mon, 5 Feb 2024 at 18:17, Marius  wrote:
>
> > Hi
> >
> > I have a machine on Buster and I tried to update to the latest 2.9.2.
> > These are the errors.
> >
> > Failed to fetch http://buildbot.linuxcnc.org/dists/buster/InRelease
> > Temporary failure resolving 'buildbot.linuxcnc.org'Failed to fetch
> > http://linuxcnc.org/dists/buster/InRelease
> > Temporary failure resolving 'linuxcnc.org'Some index files failed to
> > download. They have been ignored, or old ones used instead.
> >
> > This is in my /etc/apt/sources.list
> >
> > deb http://buildbot.linuxcnc.org buster 2.9-rtpreempt
> > deb-src http://linuxcnc.org buster 2.9-rtpreempts
> >
> > regards
> >
> > Marius
> >
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Merge 2.9 to master

[Greg C]

My (perhaps unsolicited) opinion is that the person who merges the
PR/commits their own changes should carry it through to the upstream
branch(es).  That way it's always tidy and there's no questions when the
next person goes to merge changes to code they're familiar with.

I generally try to do that, however sometimes find that I have to "leave it
for someone else" when there's a pile of unmerged items with conflicts I'm
ignorant to resolving.  There would be less of this if the above were the
rule.

It also helps when things get messy.  Recently I worked with a member who
created a PR against master that applied to 2.9.  I tried unsuccessfully to
get them to make the PR against 2.9 instead so I could merge it upstream.
In an effort to not discourage collaboration, and after talking with Andy
offline, I ended up recreating it in 2.9 on their behalf.  There was a pile
of unmerged commits at the time, so I didn't clean up after myself.

I am also by no means a git expert, so I'm alway open to learn/correct
anything I'm doing incorrectly.

Happy New Year all!

-Greg

On Sun, Dec 31, 2023 at 7:14 AM Hans Unzner  wrote:

>
>
> Am 31.12.23 um 13:01 schrieb andy pugh:
> > On Sun, 31 Dec 2023 at 11:50, Hans Unzner  wrote:
> >
> >>> Is it the job of the person who accepts the PR to merge it upstream?
> >>> Or a secondary task for the Pull Requestor?
> >>>
> >> I think it would be the best if the person who accepts the PR or the
> >> persons who makes changes which could cause conflicts merge the branch
> >> upwards.
> > Yes, so do I. I was asking which it should be.
> >
> > Maybe PRs to 2.9 (and earlier) should also be presented with a
> > merge-PR to upstream branches?
> You mean via Github by the author of the PR? Not sure if that will work.
> Better that the person who merges it keep track of it.
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Task/Motion startup race

[Greg C]

Sebastian,

I made an issue on Monday that also speaks to this race condition that's
been exposed by the recent iocontrol moves.

Here is the issue:  https://github.com/LinuxCNC/linuxcnc/issues/2700

I am not sure if Rene is on the dev list, so it might be prudent to make
these observations in the issue I created?  If nothing else, it's tracked
that way.

Thanks,

Greg

On Wed, Oct 18, 2023 at 5:21 PM Sebastian Kuzminsky  wrote:

> When the `linuxcnc` script launches linuxcnc it starts Task, then loads
> motmod (as one of the commands in the [HAL]HALFILE list).
>
> I believe this is racey, leading to at least some of the intermittent
> failures on the buildbot.
>
> Task does this at startup:
>
> 1. Runs `usrmotInit()` which connects to the emcmotStruct shm, including
> emcmotCommand and emcmotStatus.
>
> 2. Runs `usrmotWriteEmcmotCommand()` to copy the first initialization
> command into emcmotCommand, then polls emcmotStatus waiting for motmod
> to echo the first command's commandNum.
>
> 3. If the commandNum does not echo in emcmotStatus within a timeout,
> Task gives up on the command.
>
> Motion/motmod does this at startup:
>
> 1. Runs `init_comm_buffers()` to connect to the emcmotStruct shm,
> including emcmotCommand and emcmotStatus.  Calls `memset()` on
> emcmotStruct to initialize it to all-bytes-zero.
>
> 2. Start polling emcmotCommand for new commands (this happens in a hal
> thread via the `motion-command-handler` function).
>
> The race happens when Task does its 1 and 2, then Motion does *its* 1,
> discarding Task's first command.
>
>
> I think the recent move of iocontrol into Task changed system timing and
> made this race more likely to bite.
>
> Any thoughts?
>
>
> --
> Sebastian Kuzminsky
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Proposed 2.9 code freeze

[Greg C]

Andy,

I think if Craftsman isn’t going to be updated to python3, then we should
consider removing it at least for this release.  It can stay in master if
someone intends to do the work to update it.

Just my $0.02.

-Greg

On Mon, Oct 2, 2023 at 8:26 AM andy pugh  wrote:

> I propose to freeze 2.9 tomorrow evening (3rd October) at around 8pm
> UTC to release the v9.0 tag.
>
> If there is anything that you are working in that you need to get in
> before then, let me know ASAP.
>
> Don't panic if there is anything longer-term that you are working on.
> There is likely to be a 2.9.1 fairly soon afterwards.
>
> --
> 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 mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] 5-axis video at Tormach meet up

[Greg C]

In the spirit of being helpful, making this as easy as possible, and saving
people from ~500Mb of downloads, I put them on my youtube unlisted (anyone
with the links below can see them).

Here are the links:

Stevenson: https://youtu.be/17dF8cYcYDs
Stevenson2:  https://youtu.be/Tffo8J8XhQE

If that pisses anyone off, please let me know and I'm happy to remove them.

-Greg


On Mon, May 1, 2023 at 8:20 PM Sam Sokolik  wrote:

> downloading them first probably is the best solution...
>
> On Mon, May 1, 2023 at 7:15 PM gene heskett  wrote:
>
> > On 5/1/23 19:37, John Allwine wrote:
> > > I used VLC to view them.
> > >
> > >> On May 1, 2023, at 5:02 PM, gene heskett 
> wrote:
> > >>
> > >> On 5/1/23 17:25, John Allwine wrote:
> > >>> Hi everyone,
> > >>> Jon sent them over to me and I've uploaded them here:
> > >>> https://demos.pentamachine.com/linuxcnc/stevenson.wmv
> > >>> https://demos.pentamachine.com/linuxcnc/stevenson2.wmv
> > >>> I don't think this is a great permanent spot for them, but I imagine
> > they
> > >>> can sit here for a while.
> > >>> -John
> > vlc from a cli, stuttered and paused 90% of the time complaing mightily
> > about a lacking reference clock.
> > my connection seems to be sub par. or the site is busier than a one
> > armed paper hanger. :o)>  I have also seen them before.  thanks.
> >
> > >> and firefox doesn't know what to do with a .wmv.  Am I missing a
> plugin?
> > >>
> > >>>> On Wed, Apr 26, 2023 at 7:17 PM Greg C 
> > wrote:
> > >>>> I think we’d all like to see them (and I don’t even know what “them”
> > >>>> entails).
> > >>>>
> > >>>> Can they be uploaded to YouTube or something?
> > >>>>
> > >>>> -Greg
> > >>>>
> > >>>> On Wed, Apr 26, 2023 at 8:49 PM Stuart Stevenson  >
> > >>>> wrote:
> > >>>>
> > >>>>> I sent Jon copies. He can give them to anyone he wishes. I will
> give
> > them
> > >>>>> to anyone that asks.
> > >>>>> regards
> > >>>>> Stuart
> > >>>>>
> > >>>>> On Wed, Apr 26, 2023 at 2:53 PM Bari  wrote:
> > >>>>>
> > >>>>>> Looks like it might be Jon Elson's PC showing a 5-axis machine
> > video by
> > >>>>>> Stuart Stevenson.
> > >>>>>>
> > >>>>>> I believe that Stuart took his "youtubes" down. Maybe someone has
> > >>>> copies
> > >>>>>> to share.
> > >>>>>>
> > >>>>>> On 4/26/23 13:57, John Allwine wrote:
> > >>>>>>> Hi all,
> > >>>>>>>
> > >>>>>>> Thanks for the great weekend! It was nice to be able to put faces
> > to
> > >>>>> all
> > >>>>>>> the names I see in the commits and forums.
> > >>>>>>>
> > >>>>>>> I forget who was showing it, but I was hoping to get the video of
> > the
> > >>>>> big
> > >>>>>>> 5-axis machine that was rigged up with dial indicators.  I
> snapped
> > a
> > >>>>>>> picture of it (see here,
> > >>>>>>> https://demos.pentamachine.com/linuxcnc/linuxcnc-5-axis.jpg).
> Does
> > >>>>>> anyone
> > >>>>>>> have that?
> > >>>>>>>
> > >>>>>>> Thanks!
> > >>>>>>>
> > >>>>>>> -John
> > >>>>>>>
> > >>>>>>> ___
> > >>>>>>> Emc-developers mailing list
> > >>>>>>> Emc-developers@lists.sourceforge.net
> > >>>>>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
> > >>>>>>
> > >>>>>>
> > >>>>>> ___
> > >>>>>> Emc-developers mailing list
> > >>>>>> Emc-developers@lists.sourceforge.net
> > >>>>>> https://lists.sourceforge.net/lists/listinfo/emc-developers
> > >>>>>>

Re: [Emc-developers] 5-axis video at Tormach meet up

[Greg C]

I think we’d all like to see them (and I don’t even know what “them”
entails).

Can they be uploaded to YouTube or something?

-Greg

On Wed, Apr 26, 2023 at 8:49 PM Stuart Stevenson  wrote:

> I sent Jon copies. He can give them to anyone he wishes. I will give them
> to anyone that asks.
> regards
> Stuart
>
> On Wed, Apr 26, 2023 at 2:53 PM Bari  wrote:
>
> > Looks like it might be Jon Elson's PC showing a 5-axis machine video by
> > Stuart Stevenson.
> >
> > I believe that Stuart took his "youtubes" down. Maybe someone has copies
> > to share.
> >
> > On 4/26/23 13:57, John Allwine wrote:
> > > Hi all,
> > >
> > > Thanks for the great weekend! It was nice to be able to put faces to
> all
> > > the names I see in the commits and forums.
> > >
> > > I forget who was showing it, but I was hoping to get the video of the
> big
> > > 5-axis machine that was rigged up with dial indicators.  I snapped a
> > > picture of it (see here,
> > > https://demos.pentamachine.com/linuxcnc/linuxcnc-5-axis.jpg). Does
> > anyone
> > > have that?
> > >
> > > Thanks!
> > >
> > > -John
> > >
> > > ___
> > > Emc-developers mailing list
> > > Emc-developers@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
>
>
> --
> Addressee is the intended audience.
> If you are not the addressee then my consent is not given for you to read
> this email furthermore it is my wish you would close this without saving or
> reading, and cease and desist from saving or opening my private
> correspondence.
> Thank you for honoring my wish.
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] my copy of bullseye git repo needs a hardreset, but its not in git manual, howto?

[Greg C]

No meeting for me, just making a sign as a wedding gift in the garage.

It’s likely mad because you made changes to some file (or added a file).
You need to stash the changes before rebasing or resetting (or even
pulling).

git stash

Then afterward you can do:  (Of course if you didn’t intend to have any
changes  this step isn’t necessary).

gif stash pop

And your changes would be put back.  I’m not sure what you changed.

If you may have added new files then you need “git stash -u” for the first
stanza.



On Sat, Apr 22, 2023 at 11:23 AM gene heskett  wrote:

> On 4/22/23 09:35, Greg C wrote:
> > Hey Gene,
> >
> > I’m not a GitHub expert, but I the last time I had this issue the
> following
> > fixed it:
> >
> > git rebase
> >
> Thanks Greg, but it also fails:
>
> pi@rpi4:/media/pi/workspace/bullseye-linuxcnc $ git rebase
> docs/po/de.po: needs merge
> docs/src/gui/qtvcp.adoc: needs merge
> lib/python/gladevcp/drowidget.py: needs merge
> src/po/es.po: needs merge
> src/po/gmoccapy/cs.po: needs merge
> src/po/gmoccapy/es.po: needs merge
> src/po/gmoccapy/tr.po: needs merge
> src/po/tr.po: needs merge
> error: cannot rebase: You have unstaged changes.
> error: additionally, your index contains uncommitted changes.
> error: Please commit or stash them.
>
> my cron scripts only do git pulls, I haven't touched it in yonks.
>
> > I think the worst case is you delete the folder and re-clone and
> recompile
> > the project to a folder with the same name.  Your configs and such should
> > be separate.
>
> I had to do that a couple years back.  Its not a showstopper as buster
> is running it fine, but the buildbot may be hung again, I've had wintel
> updates but not armhf's for a few days.  Have fun if you re going to the
> meeting. This can wait.
> >
> > -Greg
> >
> > On Sat, Apr 22, 2023 at 4:45 AM gene heskett 
> wrote:
> >
> >> Hi all; Subject says it all
> >>
> >> A git pull or merge reports:
> >>
> >> pi@rpi4:/media/pi/workspace/bullseye-linuxcnc $ git pull
> >> error: Pulling is not possible because you have unmerged files.
> >> hint: Fix them up in the work tree, and then use 'git add/rm '
> >> hint: as appropriate to mark resolution and make a commit.
> >> fatal: Exiting because of an unresolved conflict.
> >> pi@rpi4:/media/pi/workspace/bullseye-linuxcnc $ git merge
> >> error: Merging is not possible because you have unmerged files.
> >> hint: Fix them up in the work tree, and then use 'git add/rm '
> >> hint: as appropriate to mark resolution and make a commit.
> >> fatal: Exiting because of an unresolved conflict.
> >>
> >> Fix?
> >>
> >> Thanks,
> >>
> >> Cheers, Gene Heskett.
> >> --
> >> "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
> >> Genes Web page <http://geneslinuxbox.net:6309/>
> >>
> >>
> >> ___
> >> Emc-developers mailing list
> >> Emc-developers@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >>
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
>
> Cheers, Gene Heskett.
> --
> "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
> Genes Web page <http://geneslinuxbox.net:6309/>
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] my copy of bullseye git repo needs a hard reset, but its not in git manual, howto?

[Greg C]

Hey Gene,

I’m not a GitHub expert, but I the last time I had this issue the following
fixed it:

git rebase

I think the worst case is you delete the folder and re-clone and recompile
the project to a folder with the same name.  Your configs and such should
be separate.

-Greg

On Sat, Apr 22, 2023 at 4:45 AM gene heskett  wrote:

> Hi all; Subject says it all
>
> A git pull or merge reports:
>
> pi@rpi4:/media/pi/workspace/bullseye-linuxcnc $ git pull
> error: Pulling is not possible because you have unmerged files.
> hint: Fix them up in the work tree, and then use 'git add/rm '
> hint: as appropriate to mark resolution and make a commit.
> fatal: Exiting because of an unresolved conflict.
> pi@rpi4:/media/pi/workspace/bullseye-linuxcnc $ git merge
> error: Merging is not possible because you have unmerged files.
> hint: Fix them up in the work tree, and then use 'git add/rm '
> hint: as appropriate to mark resolution and make a commit.
> fatal: Exiting because of an unresolved conflict.
>
> Fix?
>
> Thanks,
>
> Cheers, Gene Heskett.
> --
> "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
> Genes Web page 
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] heads up buglet

[Greg C]

Gene, et al,

After the buildbot does it’s thing (if you use package installs), this
should be fixed.

-Greg

On Sun, Feb 12, 2023 at 7:15 PM gene heskett  wrote:

> On 2/12/23 11:49, Greg C wrote:
> > Good morning Gene,
> >
> > There is some discussion on this issue here:
> >
> https://github.com/LinuxCNC/linuxcnc/commit/56ecf76e11c5ce9feb78d3cd830c135db83c09d7#commitcomment-99885313
> >
> > Thanks for the extra data points.
> >
> > Looks like the fix for Bookworm and Sid inadvertently caused some noise
> for
> > those of us on Buster, and had no effect for those of us on Bullseye.
> >
> > Making code work across the different distros, python versions, etc is
> ...
> > fun :)
> >
> > -Greg
>
> A job I'm not qualified for. Wet ram is too old. And after tonights
> update, is still wrong.
> >
> > On Sat, Feb 11, 2023 at 10:47 PM gene heskett 
> wrote:
> >
> >> Greetings all;
> >>
> >> After everything was updated just now, the preview DRO is either size is
> >> contaminated with dots in the buffer area above and below the characters
> >> of the DRO, which are properly displayed. Works but is distracting.
> >> Only in the wintel versions, the pi is fine.
> >>
> >> Cheers, Gene Heskett.
> >> --
> >> "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
> >> Genes Web page <http://geneslinuxbox.net:6309/>
> >>
> >>
> >> ___
> >> Emc-developers mailing list
> >> Emc-developers@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/emc-developers
> >>
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> > .
>
> Cheers, Gene Heskett.
> --
> "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
> Genes Web page <http://geneslinuxbox.net:6309/>
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] heads up buglet

[Greg C]

Good morning Gene,

There is some discussion on this issue here:
https://github.com/LinuxCNC/linuxcnc/commit/56ecf76e11c5ce9feb78d3cd830c135db83c09d7#commitcomment-99885313

Thanks for the extra data points.

Looks like the fix for Bookworm and Sid inadvertently caused some noise for
those of us on Buster, and had no effect for those of us on Bullseye.

Making code work across the different distros, python versions, etc is ...
fun :)

-Greg

On Sat, Feb 11, 2023 at 10:47 PM gene heskett  wrote:

> Greetings all;
>
> After everything was updated just now, the preview DRO is either size is
> contaminated with dots in the buffer area above and below the characters
> of the DRO, which are properly displayed. Works but is distracting.
> Only in the wintel versions, the pi is fine.
>
> Cheers, Gene Heskett.
> --
> "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
> Genes Web page 
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Reminder: It's Today! (January 2023 Online Meeting)

[Greg C]

What is the agenda of Daniel/Tormach's meeting?

-Greg

On Wed, Jan 18, 2023 at 7:33 PM Jon Elson  wrote:

> Daniel Rogge of Tormach has mentioned that he is trying to
> set up a meeting in April with Robert Ellenberg, John Morris
> and Alex Rossler over a weekend.  Does anybody have a
> specific date they would prefer or can't attend?  We could
> possibly set up a meeting that partly overlaps the one with
> the above people.
>
> Thanks,
>
> Jon
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Unknown g code used

[Greg C]

On Fri, Dec 23, 2022 at 6:39 AM  wrote:

> I get the Message "Unknown g code used".
> How to debug this?
>

It may help to know what the gcode is...

>
>
> My beloved debug method "printf(...)" does not work.
>

use:  fprintf(stderr, "your debug stuff here")

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Arc Bug, help needed.

[Greg C]

If it helps, after following the steps below, I can reproduce everything
described.

-Greg

On Sat, Dec 10, 2022 at 6:14 PM Dewey Garrett  wrote:

>
> > Is anyone else able to reproduce this behaviour?
>
> $ wget www.panix.com/~dgarrett/stuff/arc.tgz
> $ tar xzf arc.tgz
> $ cd arc
>
> 1) start from command line
> $ linuxcnc arc.ini
>
> 2) Initialize
> F1 -- Machine on
> F2 -- Estop off
> Ctrl-HOME --- Home all
> # Display shows one turn spiral
>
> 3) Examine residual settings after homing:
> (too small to be visible on display)
> # example:
> $ halcmd show pin axis.[xyz].pos-cmd
> Component Pins:
> Owner   Type  Dir Value  Name
> 23  float OUT  2.569163e-08  axis.x.pos-cmd
> 23  float OUT  2.845021e-09  axis.y.pos-cmd
> 23  float OUT  2.569163e-08  axis.z.pos-cmd
>
> 4) r - Run program
> #  observe errant linear (z) move, no spiral
>
> 5) r - Run program
> # observe correct execution of circle at z=-1
>
>
> 6) Start over: repeat 1),2),3) (at home position)
> 7) Ctrl-R  Reload program
> # note display shows the incorrect errant linear move only
>
> Notes:
> a) not reproducible if  all joints set immediate homing
> as there are no residual position errors
> --
> Dewey Garrett
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Backplot MAX_POINTS

[Greg C]

Haha, thanks Andy.  I'll save this for when others inevitably forget  :-D

-Greg

On Sat, Dec 10, 2022 at 2:41 PM andy pugh  wrote:

> On Sat, 10 Dec 2022 at 19:08, Greg C  wrote:
>
> I wonder if anyone is opposed to adding a 0 and bumping it up 10x?
>
>
> Master is open for such daredevil experimentation :-)
>
> --
> 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 mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Backplot MAX_POINTS

[Greg C]

On Thu, Dec 8, 2022 at 10:39 PM Jon Elson  wrote:

> On 12/8/22 20:12, Greg C wrote:
> > I wonder if anyone has insight to:
> > 1. Why MAX_POINTS was lowered?
> > 2. If I increased this back to 10 or even 100, are there any
> > potential negative side effects (I didn't see anything obvious in the
> brief
> > testing I did)?
> >
> There were complaints that very long G-code files could take
> up to 45 minutes to render, and apparently you could not
> begin running the program until that had completed.
>

Just to make sure we are in alignment, I am talking about the live
plotter.  AFAIK, that's information is populated in real time while running
the program.

I tested this by using eoffsets to deviate from the tool path while the
program is running.  If the information was populated ahead of time,
there's no way my deviations would be plotted properly, which they were.


> Jon


On Thu, Dec 8, 2022 at 9:27 PM Sam Sokolik  wrote:

> Iirc it was just to make the preview more responsive...
>

Interesting.  I bumped it back to the original setting from 2009, and in my
albeit brief testing, I see no appreciable difference other than the tail
of the tool path does not unwind anymore.  There didn't seem to be any
noticeable effects on memory resources either.

I wonder if anyone is opposed to adding a 0 and bumping it up 10x?

>
> On Thu, Dec 8, 2022, 8:16 PM Greg C  wrote:
>
> > Good evening all,
> >
> > Recently on the forum turbostew brought up an issue that I've noticed in
> > the past (in PathPilot) where on large cut files, the backplot starts to
> > turn back to white at the beginning of the previewed cut paths.  Thread
> > <
> >
> https://forum.linuxcnc.org/qtvcp/41566-seems-like-a-buffer-size-limit-on-toolpath-highlighting?start=0#200370
> > >
> >
> > What is actually happening is the max number of points is reached and the
> > oldest points are falling off as the new points are added.  Since the
> > number of MAX_POINTS is defined in emcmodule.cc, this would affect all
> > guis.  emcmodule.cc L1981
> > <
> >
> https://github.com/LinuxCNC/linuxcnc/blob/131761f462ff0194a5403500f03f1f47c5899896/src/emc/usr_intf/axis/extensions/emcmodule.cc#L1981
> > >
> >
> > Back in June of 2009 Jeff Epler lowered this value from 10 to 1,
> > and unfortunately the commit doesn't give any details as to why.  Jeff's
> > Commit
> > <
> >
> https://github.com/LinuxCNC/linuxcnc/commit/13e76953aaa61da0c560418cfbc117436d8c9f38
> > >
> >
> > I wonder if anyone has insight to:
> > 1. Why MAX_POINTS was lowered?
> > 2. If I increased this back to 10 or even 100, are there any
> > potential negative side effects (I didn't see anything obvious in the
> brief
> > testing I did)?
> >
> > Thanks,
> > Greg
> >
> > P.S. the way the backplotter "unwinds" on the beginning of the preview
> > while adding to the current points of the cut path reminds me of the old
> > computer game "Snake".  So I wonder if I increase the length of the
> snake,
> > is there potential for it to "crash" into itself.  🙂
> >
> > ___
> > Emc-developers mailing list
> > Emc-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/emc-developers
> >
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] Backplot MAX_POINTS

[Greg C]

Good evening all,

Recently on the forum turbostew brought up an issue that I've noticed in
the past (in PathPilot) where on large cut files, the backplot starts to
turn back to white at the beginning of the previewed cut paths.  Thread


What is actually happening is the max number of points is reached and the
oldest points are falling off as the new points are added.  Since the
number of MAX_POINTS is defined in emcmodule.cc, this would affect all
guis.  emcmodule.cc L1981


Back in June of 2009 Jeff Epler lowered this value from 10 to 1,
and unfortunately the commit doesn't give any details as to why.  Jeff's
Commit


I wonder if anyone has insight to:
1. Why MAX_POINTS was lowered?
2. If I increased this back to 10 or even 100, are there any
potential negative side effects (I didn't see anything obvious in the brief
testing I did)?

Thanks,
Greg

P.S. the way the backplotter "unwinds" on the beginning of the preview
while adding to the current points of the cut path reminds me of the old
computer game "Snake".  So I wonder if I increase the length of the snake,
is there potential for it to "crash" into itself.  🙂

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Arc Bug, help needed.

[Greg C]

FWIW the preview works here on a Virtual Machine, homed in place with g2 as
the first move, G20 or G21.

12th Gen Intel(R) Core(TM) i7-12700KF

-Greg

On Wed, Dec 7, 2022 at 6:43 PM Peter C. Wallace  wrote:

> On Wed, 7 Dec 2022, andy pugh wrote:
>
> > Date: Wed, 7 Dec 2022 21:54:41 +
> > From: andy pugh 
> > Reply-To: EMC developers 
> > To: EMC developers 
> > Subject: Re: [Emc-developers] Arc Bug, help needed.
> >
> >> On Wed, 7 Dec 2022 at 20:36, John Thornton  wrote:
> >>
> >> I can confirm the bug is in the 2.9 branch that is currently in Debian,
> >> I'm unable to build a RIP on 2.9 to see if it's still there as I get
>
>
> >metric or imperial config?
> >Did you run the test command in G20 or G21?
> >NO_FORCE_HOMING?
> >
> >What CPU are you running? (It is getting to the point that I am wondering
> >if that matters)
>
>
> I have no issue with G20 or G21 with current master
>
> (with g2 x0 y0 j5 z-2 f1000 as the first linuxCNC motion at startup)
>
> of course X,Y must be 0 at the start
>
> Peter Wallace
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Forum down?

[Greg C]

JT had said he was taking it down today around 5am central time to upgrade
from 30Gb to 50Gb storage since we were running at 90% used for quite some
time.

-Greg

On Thu, Jul 21, 2022 at 6:35 AM andy pugh  wrote:

> I was on the forum earlier, but currently seem unable to connect.
>
> This is somewhat annoying as I am spending most of today on a train,
> which is a perfect opportunity to catch up with my forum backlog.
>
> --
> 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 mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC documentation is now available on Weblate!

[Greg C]

>
>
> Does https://github.com/LinuxCNC/linuxcnc/pull/1764 fix this for you?
>
> Yes, it does.  I took liberty to merge it.  Thank you for noticing it was
out there.

-Greg

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC documentation is now available on Weblate!

[Greg C]

Thanks Hans.

Are you tracking that the "no-docs" switch is not currently working for
building the debian packages?

Steps:
cd linuxcnc-dev/debian
./configure uspace no-docs
cd ..
dpkg-buildpackage -b -uc

Error:
dpkg-buildpackage: error: syntax error in debian/control at line 45: block
lacks the 'Package' field

However if you try again with ./configure uspace, then it will work, but it
builds all docs.

-Greg


On Sat, Jun 11, 2022 at 4:41 PM Hans Unzner  wrote:

>
>
> Am 04.06.22 um 12:41 schrieb Greg C:
> > Additionally, I would like to suggest that whether or not the translated
> > documents are built or not should be controlled by a switch/option when
> you
> > set the option to build for HTML, PDF, or BOTH.  There may be no need for
> > most developers to build the translated docs 99% of the time.
> This is now possible with |./configure ...
> --disable-build-documentation-translation|
>
> /Hans
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] buildbot? no updates in about a week now.

[Greg C]

I am confused on this as well.  Unless I am reading this incorrectly, there
were builds that did complete (albeit with warnings) after that commit was
merged?

http://buildbot.linuxcnc.org/buildbot/grid

On Thu, Jun 9, 2022 at 8:11 AM Hans Unzner  wrote:

> Am Do., 9. Juni 2022 um 11:25 Uhr schrieb Sebastian Kuzminsky <
> s...@highlab.com>:
>
> > On 6/9/22 10:42, andy pugh wrote:
> > > .deb builds are currently failing:
> > >
> > >
> >
> http://buildbot.linuxcnc.org/buildbot/builders/4041.deb-buster-rtpreempt-amd64/builds/1818
> >
> > debs are failing because the wonderful new translation infrastructure
> > that just went into master requires a newer po4a than what's available
> > on Buster.  (The version in Bullseye and newer works.)
> >
> > So I think the best fix is to backport a working po4a to buster, and add
> > the updated po4a debs to our deb archive on wlo.
> >
> > I'm working on this now, hope to have something up later today.
> >
> >
> > --
> > Sebastian Kuzminsky
> >
> >
> I only wonder why Petters fix (
> https://github.com/LinuxCNC/linuxcnc/pull/1754) which should use po4a only
> when the correct version is available, didn't resolve that.
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] LinuxCNC documentation is now available on Weblate!

[Greg C]

Hans, et al,

I don't mean for this email to take anything away from the 9 month effort
you and the team has put into making the docs more cohesive, as well as
translatable.  Thank you to everyone on the team.

Unfortunately, the latest commit breaks a few things:
1. Building for anyone running the official ISO with the official distro
(Buster), whether or not they are building the docs as well.
2. The buildbot for package installs.

Additionally, I would like to suggest that whether or not the translated
documents are built or not should be controlled by a switch/option when you
set the option to build for HTML, PDF, or BOTH.  There may be no need for
most developers to build the translated docs 99% of the time.

I frequently build the HTML docs when making changes to the documents to
ensure it looks correct, and I didn't break anything.  It takes long enough
as it is, waiting 2-4 hours to verify a change looks as it should is simply
unacceptable, especially when the English documents are considered the
master.

Thanks again,

Greg

On Sat, Jun 4, 2022 at 5:35 AM Hans Unzner  wrote:

> Dear all,
>
> the documentation build system of LinuxCNC is now enhanced to support
> GNU gettext, which in turn is supported by online translation
> communities. It now uses the po4a system to generate POT and PO files
> from the English documentation. LinuxCNC is already present in Weblate
> for the translation of the graphical user interfaces, and now a
> sub-project for the docs can be found there as well:
> https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/
>
> Thanks to Petter Reinholdtsen (@petterreinholdtsen), Jérémie Tarot
> (@silopolis) and Steffen Möller (@smoe) for their great work and
> engagement!
>
> The Spanish and French translations were synced with the English
> documentation in order to transfer the previous translations as closely
> as possible.
> But all these translations need to be confirmed/verified in order to be
> shown on the website.
> Translations to other languages need to start from scratch or find the
> corresponding paragraphs in earlier versions of the LinuxCNC documentation.
>
>  From now on, all documentation should be performed for the English
> pages only. Those shying away from writing in English, we suggest to
> just choose a language they are comfortable with and put them into the
> English docs. We will then find someone to perform the translation to
> English.
>
> While syncing, we found that the formatting of the document was often
> superior in the translation, while the content was typically improved
> only in the English - with exceptions. We have done our best to sync
> towards a symbiosis of best from translations and the original. So
> please pay attention to the English docs as well in case anything has
> changed to the worse.
>
> Work on "getting docs into Weblate" started about 9 months ago, and,
> admittedly, this took much longer than any of us anticipated. We
> admittedly thus made a few compromises to finish this up and to bring
> the docs into Weblate.
> To get those done we would appreciate some help:
>   * Style: Authors (and translators) have different styles to enumerate,
> define, warn, narrate, describe tables/figures, reference ... at some
> point the community should decide how the community wants it. Jérémie is
> preparing a respective style guide.
>   * Verification: While syncing between languages, we may have messed
> something up. It shouldn't be anything serious, but this all needs a
> review. A series of whitespace-corrections are still being prepared for
> QtVCP in particular. For reference and comparison, the version of the
> docs before the Weblate-related work started:
> https://hansu.github.io/linuxcnc-doc/16736d86
>   * Build-time: Whenever a translation is not available, the original
> English text will be used. So every language will get a full set of
> documentation and that increases the build time, which is almost two
> hours now. We need to decide what to do for the CI or find other ways to
> optimize the build time since with an increasing number of languages
> that build time will increase - otherwise, with one additional language
> per continent, we would be at >4 hours build time just to fix a comma.
>
>   Cheers,
>   Hans
>   (@hansu)
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G74 and G84 docs and L-

[Greg C]

Thank you Andy for committing the docs changes.

Rainer - Perhaps one rainy cold Fall day I will start combing through them
to see if there is anything I can do to make it more clear.  If nothing
else, I personally think it would be good to explicitly define the letters
for each G-Code.  Especially since, for example R- means the retract height
for one code, and the thread pitch for another.  The user shouldn't have to
scroll around and assume (guess) at the variables.

At any rate, thank you all for the feedback.

-Greg

On Tue, Oct 19, 2021 at 11:33 AM Rainer Stelzer 
wrote:

> Hi Greg,
>
> > Please let me know if you think anything about it should be changed.
> perfectly fine.
> > I did think of adding the R- and L- explanations to G81 too.  But I am
> > trying to refrain from going too far down the docs editing rabbit hole.
>
> IMHO it should be done.
> LinuxCNC is a great piece of software and it shouldn't suffer from
> poor/incomplete or misleading  documentation.
> ( I'm not a native English speaker, so I'ld greatly appreciate your work)
>
> Cheer
>
> Rainer
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G74 and G84 docs and L-

[Greg C]

Done.

https://github.com/LinuxCNC/linuxcnc/pull/1319

-Greg

On Mon, Oct 18, 2021 at 8:14 PM andy pugh  wrote:

> On Mon, 18 Oct 2021 at 23:50, Greg C  wrote:
>
> > Attached is my proposed changes to G74 and G84 in the docs.
>
> Is it possible to submit it as a pull request at:
> https://github.com/LinuxCNC/linuxcnc/pulls
> (If not, we can still look at it, but it's harder)
>
> --
> 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 mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G74 and G84 docs and L-

[Greg C]

Ok no worries, I will submit the pull request.  I wasn’t sure which was
easier so I erred on this side.

Thanks Andy!

On Mon, Oct 18, 2021 at 8:14 PM andy pugh  wrote:

> On Mon, 18 Oct 2021 at 23:50, Greg C  wrote:
>
> > Attached is my proposed changes to G74 and G84 in the docs.
>
> Is it possible to submit it as a pull request at:
> https://github.com/LinuxCNC/linuxcnc/pulls
> (If not, we can still look at it, but it's harder)
>
> --
> 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 mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G74 and G84 docs and L-

[Greg C]

Rainer,

Attached is my proposed changes to G74 and G84 in the docs.

Please let me know if you think anything about it should be changed.

I did think of adding the R- and L- explanations to G81 too.  But I am
trying to refrain from going too far down the docs editing rabbit hole.
Let me know if you'd like me to add that as well before I PR.

Thanks,

Greg

On Mon, Oct 18, 2021 at 7:00 AM Rainer Stelzer 
wrote:

> Hi Greg,
>
> > Although, I do wonder if no X or Y are given, should L still be valid?
>
> totally agree.
>
> I retrofitted some machines with Sinumerik 810 controls.
> Tapping and rigid tapping are done with the same G code on this controls
> but ask for different  parameters.
> In combination with a very "economic" way of telling the user about the
> detailed error,
> you often find yourself in a stopped state and you have no clue whats
> wrong.
>
> Linuxcnc should through an error if  L  is used in absolute mode with
> G84, or without an X or Y Axis  (like e.g. G53 does if it is not).
>
> I made some extensions to the homing procedures, and had some issues
> with M19 and G33.1 ,
> so I'm working/reviewing the source anyhow right now.
> I will have a look into to the  G84 implementation and figure out how
> hard it is to add this warning.
>
> Cheers
>
> Rainer
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>
diff --git a/docs/src/gcode/g-code.txt b/docs/src/gcode/g-code.txt
index 23576110b..7d3469493 100755
--- a/docs/src/gcode/g-code.txt
+++ b/docs/src/gcode/g-code.txt
@@ -1637,9 +1637,17 @@ It is an error if:
 (((G74 Left-hand Tapping Cycle Dwell)))
 
 
-G74 (X- Y- Z-) or (U- V- W-) R- L- P- $-
+G74 (X- Y- Z-) or (U- V- W-) R- L- P- $- F-
 
 
+* 'R-' - Retract position along the Z axis.
+* 'L-' - Used in incremental mode; number of times to repeat the cycle. See <> for examples.
+* 'P-' - Dwell time (seconds).
+* '$-' - Selected spindle.
+* 'F-' - Feed rate (spindle speed multiplied by distance traveled per revolution (thread pitch)).
+
+WARNING: G74 does not use synchronized motion.
+
 The 'G74' cycle is intended for tapping with floating chuck and dwell at the bottom of the hole.
 
 1. Preliminary motion, as described in the
@@ -1659,8 +1667,8 @@ The 'G74' cycle is intended for tapping with floating chuck and dwell at the bot
 
 8. Restore Feed and Speed override enables to previous state
 
-The length of the dwell is specified by a 'P-' word in the G74 block. Thread pitch is F divided by S.
-In example S100 F125 gives pitch of 1.25MM per revolution.
+The length of the dwell is specified by a 'P-' word in the G74 block. The feed rate 'F-' is spindle speed multiplied by distance per revolution (thread pitch).
+In example S100 with 1.25MM per revolution thread pitch gives a feed of F125.
 
 [[gcode:g76]]
 == G76 Threading Cycle
@@ -2240,9 +2248,17 @@ It is an error if:
 (((G84 Right-hand Tapping Cycle Dwell)))
 
 
-G84 (X- Y- Z-) or (U- V- W-) R- L- P- $-
+G84 (X- Y- Z-) or (U- V- W-) R- L- P- $- F-
 
 
+* 'R-' - Retract position along the Z axis.
+* 'L-' - Used in incremental mode; number of times to repeat the cycle. See <> for examples.
+* 'P-' - Dwell time (seconds).
+* '$-' - Selected spindle.
+* 'F-' - Feed rate (spindle speed multiplied by distance traveled per revolution (thread pitch)).
+
+WARNING: G84 does not use synchronized motion.
+
 The 'G84' cycle is intended for tapping with floating chuck and dwell at the bottom of the hole.
 
 1. Preliminary motion, as described in the
@@ -2262,8 +2278,8 @@ The 'G84' cycle is intended for tapping with floating chuck and dwell at the bot
 
 8. Restore Feed and Speed override enables to previous state
 
-The length of the dwell is specified by a 'P-' word in the G84 block. Thread pitch is F divided by S.
-In example S100 F125 gives pitch of 1.25MM per revolution.
+The length of the dwell is specified by a 'P-' word in the G84 block. The feed rate 'F-' is spindle speed multiplied by distance per revolution (thread pitch).
+In example S100 with 1.25MM per revolution thread pitch gives a feed of F125.
 
 [[gcode:g85]]
 == G85 Boring Cycle, Feed Out
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G74 and G84 docs and L-

[Greg C]

Rainer,

Thank you for looking into it, very much appreciated!

Thanks,
Greg

On Mon, Oct 18, 2021 at 7:00 AM Rainer Stelzer 
wrote:

> Hi Greg,
>
> > Although, I do wonder if no X or Y are given, should L still be valid?
>
> totally agree.
>
> I retrofitted some machines with Sinumerik 810 controls.
> Tapping and rigid tapping are done with the same G code on this controls
> but ask for different  parameters.
> In combination with a very "economic" way of telling the user about the
> detailed error,
> you often find yourself in a stopped state and you have no clue whats
> wrong.
>
> Linuxcnc should through an error if  L  is used in absolute mode with
> G84, or without an X or Y Axis  (like e.g. G53 does if it is not).
>
> I made some extensions to the homing procedures, and had some issues
> with M19 and G33.1 ,
> so I'm working/reviewing the source anyhow right now.
> I will have a look into to the  G84 implementation and figure out how
> hard it is to add this warning.
>
> Cheers
>
> Rainer
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] G74 and G84 docs and L-

[Greg C]

Good morning Rainer,

Thanks for the explanation, that makes sense.

Although, I do wonder if no X or Y are given, should L still be valid?

I will take a look at the docs later and see what I can do and submit a PR
to make it a bit more clear (at least for G74 and G84) for future “me’s”
 :)

Thanks again,
Greg

On Mon, Oct 18, 2021 at 4:23 AM Rainer Stelzer 
wrote:

> Hi Greg,
>
> the L in a tapping cycle is not intended to tap the same location.
>
> In incremental mode and with a X or Y axis given, it taps at different
> locations.
> Handy when you do manual programming, confusing when you are used to use
> CAM tools.
>
> It is explained in the G81 cycle.
> The documentation does not repeat this explanation(s) what may lead to
> the confusion.
> I agree that there should be at least a hint like "all unmentioned
> parameters operate as explained under G81"
>
>
> cheers
>
> Rainer
>
>
>
> ___
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers
>

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

[Emc-developers] G74 and G84 docs and L-

[Greg C]

Good evening,

I spent some time today in the G-Code docs looking at G74 and G84 (left and
right hand tapping with a tension-compression head in mind) in an attempt
to fully understand the options.

I found the docs for these G-Codes to be a bit vague, and confusing.
Especially given that R- and L- seems to change around depending on the
G-Code associated (not a complaint, just an observation) and F- was not
mentioned at all.  I made some changes that I would like to submit for a
Pull Request, but I wanted to ping the group and clear something up first.

G74 and G84 don't explicitly mention that the Z axis movement is* not*
synchronous with the spindle speed, and as such, I found it troubling that
both G-Codes will accept an L- value to determine the number of times the
cycle will be ran at the same XY coordinates.  I can't think of any reason
to try to tap the same hole more than once with a tension-compression
head.  Unless one really likes gambling ... or messed up threads :)

In Axis SIM, LinuxCNC is happy to try to tap the same hole any number of
times (determined by L- of course).  However I have a Tormach mill and
found it interesting in Pathpilot, LinuxCNC will ignore any value entered
for L-, so obviously at some point they removed this "feature".

The question I have is:  Is it better to pursue removing the L-
functionality from G74 and G84, or is it better to remove the reference
from the docs?  Or, lastly, is there a legitimate use case I am missing
here?

I am not sure if this email service will accept attachments, but if it does
and if anyone is interested, I am happy to send the .diff of my proposed
changes to the docs.

Thanks,

Greg
(Snowgoer540)

___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers