Re: [Emc-developers] 2.9.3 release schedule inquiry

[Chris Morley]

Is there anything anyone else can do to help?



Sent from my Galaxy



 Original message 
From: andy pugh 
Date: 2024-05-11 2:51 p.m. (GMT-08:00)
To: EMC developers 
Subject: Re: [Emc-developers] 2.9.3 release schedule inquiry

On Sat, 11 May 2024 at 21:18, Chris Morley 
wrote:

> bump
>

I am really struggling to find time to even get started, I am afraid.

--
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] 2.9.3 release schedule inquiry

[Chris Morley]

bump

From: Chris Morley 
Sent: March 15, 2024 8:14 PM
To: EMC DEV 
Subject: 2.9.3 release schedule inquiry

I see there are a lot of bug fixes in 2.9.
I am getting a fair amount of request to fix things that are already fixed.
Any rough idea when we might?

Chris

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

[Emc-developers] 2.9.3 release schedule inquiry

[Chris Morley]

I see there are a lot of bug fixes in 2.9.
I am getting a fair amount of request to fix things that are already fixed.
Any rough idea when we might?

Chris

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

Re: [Emc-developers] probing in qtdragon

[Chris Morley]

Thank you for the report. What version of linuxcnc are you referring to?
I'll have to dig into the code to follow what you are getting at.
In summary, I think you are saying the Y probing is starting too close to the X 
edge and is hitting the radius.
If I remember right, EDGE length should control this - is this your 
understanding?
Also are you using this in Qtdragon or embedded in another GUI?

I am glad it is useful and worthy enough to report bugs on. it was a lot of 
work for (mostly) Jim and I to get where it is.
I am open to any other ideas for improvement/utility.

Chris M

From: rdp 
Sent: January 29, 2024 8:30 AM
To: EMC developers 
Subject: [Emc-developers] probing in qtdragon

I have been testing out versaprobe in qtdragon and noticed a problem
with inside corners.

The retract in the X-direction after the slow probe is typically to
small, so that when the Y-direction fast probe is done
it is to close to the inner y-dir edge. If there is a radius in the
corner (which there normally is with a pocket cut with a endmill), then
the probe in the y-dir will hit in the radius part and not on the x-dir
edge. This will produce an error in the y-position of the corner.

One can perhaps get around it by using a large latch retract, but this
will slow down the whole process.

The cause of this behaviour seems to be the new xplus and xminus
routines included in qtvcp/widgets/probe_routines.py (Not sure, probing
routines are at many places in linuxcnc under different names. Very
confusing. I hope it gets cleared up one day, with a clear distinction
between a tool setter (which cannot move, but has a height) and a 3d
probe (which moves)).

The original xplus.ngc and xminus.ngc routines of versaprobe are
different in that they have a fast retract after final slow probe to the
original point where fast probing starts from. The yplus and yminus
routines are also different but seem to  not effect the inner corner
probing since they occur after the x-dir movements. However they give a
wrong end result for the y-position of
the corner, since they touch on the radius part of the corner.

These differences do not seem to effect the end result of the other
probe routines, but is probably not in line with the aims of the
original author of the versaprobe routines.

Hope this helps to improve qtdragon. On the whole we (SA-CNC-CLUB) are
very impressed and thankful for the excellent work on it.

Kind regards
Rudy du Preez
Chairman SA-CNC-CLUB
___
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] buildbot is down

[Chris Morley]

help please :)
Thanks.

___
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

[Chris Morley]

Now that master is very active again, this will continue to be a problem
There is really no good clean solution to the problem as our process is now:

If you expect pull request mergers to also merge branch to branch then they 
will be less apt to approve pull requests.
(thought this is the good compromise in the mean time)
If you expect pull request makers to do it, you won't get pull requests.
We don't have enough developers with enough experience to do this - and it's a 
pain for those few that do.
If we wait and do it time to time (as we do) it become a huge problem.

Is there a way to do partial merges? so merge the work you are familiar with?
Is there another process that is less painful for our devs to work with?
Doing the same thing over and over is not going to fix the problem!

Chris

From: Hans Unzner 
Sent: December 31, 2023 1:23 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] Merge 2.9 to master



Am 31.12.23 um 13:29 schrieb andy pugh:
> On Sun, 31 Dec 2023 at 12:14, Hans Unzner  wrote:
>
>> 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.
> That assumes that the person who accepts the merge understands the
> code as well as the one creating the code, which is rarely likely to
> be the case?
>
I hope that the person who merges the PR have at least a rough idea what
the change is about. Otherwise how could this person judge if this PR is
good or bad?


___
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 - Partially completed

[Chris Morley]

Looks good to me Andy. Thank you.

From: andy pugh 
Sent: December 31, 2023 11:58 AM
To: EMC developers 
Subject: Re: [Emc-developers] Merge 2.9 to master - Partially completed

Chris M: Can you look at linuxcnc/lib/python/qtvcp/qt_pstat.py? Based
on commit dates I think you probably wanted both sets of changes in?
(functions mportDefaultHandler from 2.9 and isUsingDefaultHandler +
getQSSPaths from master?

Håvard F. Aasen: Can you take a look at emcrsh.cc lines 573-584 &
1246-1253,? Your commit 18f0295 changed the handling of some string
checks, but master was already significantly changed by
https://github.com/LinuxCNC/linuxcnc/commit/8b91f27d5f9c2523e4e4350efa38e5264aa51280
using rtapi_strlcpy, which I think is maybe better? I have kept the
master version.


--
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] How can users get hostmot2 XML files on modern os versions?

[Chris Morley]

I guess our hostmot2 builder was put to rest in 2021.
Are there (or could there be) packages for the last built firmware so users can 
configure old cards?
Pncconf uses the XML files for older cards.

https://forum.linuxcnc.org/39-pncconf/50902-no-7i43-on-linuxcnc-2-9-1-pncconf?start=10#287604

Chris

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

Re: [Emc-developers] RFC: Reduce number of HAL pin types.

[Chris Morley]

I assume one drawback/advantage is after the change if a component really 
expects an unsigned range the user can easily connect a signed component and it 
might take a while to find that bug.



Sent from my Galaxy



 Original message 
From: andy pugh 
Date: 2023-10-12 1:57 a.m. (GMT-08:00)
To: EMC developers 
Subject: Re: [Emc-developers] RFC: Reduce number of HAL pin types.

On Thu, 12 Oct 2023 at 04:05, Chris Morley  wrote:
.
> I assume you would use a feature branch to start anyways, so we could see 
> what problems crop up and assess.

Yes, this is definitely not something to drop straight into master.  (or 2.9)

--
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] RFC: Reduce number of HAL pin types.

[Chris Morley]

I like your idea of less integer types.
I assume you would use a feature branch to start anyways, so we could see what 
problems crop up and assess.

Chris

From: andy pugh 
Sent: October 11, 2023 7:44 PM
To: EMC developers 
Subject: Re: [Emc-developers] RFC: Reduce number of HAL pin types.

On Wed, 11 Oct 2023 at 20:33, Rod Webster  wrote:

> Look, I am only a casual programmer that dabbles on the fringes. You
> guys are going to do what you want to do. But the point I wanted to
> make is there are likely many cases you have not considered that could
> break and some of them won't have an active maintainer. I still don't
> understand why you want to give up one of C's strengths when
> interfacing with hardware and that is the rich variety of type
> definitions available.

I am sure that there will be things that I have not considered, but I
feel that the use of 4 different types of integer HAL pins just leads
to unnecessary type conversions and inconvenience.

If lcec has no active maintainer, then where do folk get packages
from?  If they are building from source then I currently expect my
proposed changes (_at_this_point_) to be pretty much transparent.

Please consider that HAL pins themselves only provide links between
HAL components, they do not themselves interface with any hardware.

--
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] Printing from Python (inside Axis)

[Chris Morley]

Everyone gets caught from time to time :)


From: andy pugh 
Sent: October 2, 2023 1:58 PM
To: EMC developers 
Subject: Re: [Emc-developers] Printing from Python (inside Axis)

On Mon, 2 Oct 2023 at 01:53, Chris Morley  wrote:
>
> Did you compile after adding the print statements?

It's not _quite_ that embarrassing. But I was debugging code that
doesn't run until you press the program start button.

--
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] Printing from Python (inside Axis)

[Chris Morley]

Did you compile after adding the print statements?

From: andy pugh 
Sent: October 2, 2023 12:28 AM
To: EMC developers 
Subject: [Emc-developers] Printing from Python (inside Axis)

I am trying to print some debug info from inside the Axis python
script, but do not seem to be able to see anything printed anywhere.

Does anyone else have any tips for viewing debug variables with Axis?

--
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] 2.9 must-fix

[Chris Morley]

Andy

Thanks for pushing this along a bit.
I think Phill has a pncconf fix to go in - I'll look at it now.

Chris


From: andy pugh 
Sent: September 30, 2023 2:29 PM
To: EMC developers 
Subject: [Emc-developers] 2.9 must-fix

I have been working through the 2.9 must-fix tagged issues on the Github.

But that list was created in Madison, several months ago, and it is
possible that there have been other issues raised since that should be
tagged as such.

Does anyone want to suggest any?

I am vaguely hopeful of releasing 2.9 in the next couple of days. Not
that anything internally has really changed to prompt this, it's more
about the upcoming debian point release focussing my mind.

--
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] What does gcodemodule.cc do?

[Chris Morley]

AFAIK yes it's used for the screen plot.

From: andy pugh 
Sent: September 8, 2023 11:20 PM
To: EMC developers 
Subject: [Emc-developers] What does gcodemodule.cc do?

The error reported here: https://github.com/LinuxCNC/linuxcnc/issues/2632
Appears to be raised in gcodemodule.cc. Is it purely related to the
graphical preview?

https://github.com/LinuxCNC/linuxcnc/blob/2.9/src/emc/rs274ngc/gcodemodule.cc#L802

--
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] debian recommends in control needs a small change

[Chris Morley]

Thanks for replying Steffen.
I guess I can push a test branch and find out.

Chris

From: Steffen Möller 
Sent: July 17, 2023 4:56 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] debian recommends in control needs a small change



> Gesendet: Sonntag, 16. Juli 2023 um 07:34 Uhr
> Von: "Chris Morley" 
> An: "EMC DEV" 
> Betreff: [Emc-developers] debian recommends in control needs a small change
>
> Recommends:
>
>
> python3-pyqt5.qtwebkit,
>
> qtwebkit has been replaced in newer system with python3-pyqt5.qtwebengine
> In some systems both are available.
>
> Is there a way to favor the new package but fallback on the old?
>
> is it:
> python3-pyqt5.qtwebengine | python3-pyqt5.qtwebkit
>
Hi Chris,
What you proposed looks perfectly fine to me. I am uncertain if this should 
have any effect on the automated testing - likely not.
Best,
Steffen


___
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] debian recommends in control needs a small change

[Chris Morley]

Recommends:
   

python3-pyqt5.qtwebkit,

qtwebkit has been replaced in newer system with python3-pyqt5.qtwebengine
In some systems both are available.

Is there a way to favor the new package but fallback on the old?

is it:
python3-pyqt5.qtwebengine | python3-pyqt5.qtwebkit

Thank you
Chris

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

[Emc-developers] website HTML docs are behind

[Chris Morley]

Anybody notice why? I saw some reported failures with arch?
Something about not being able to pull in updates? Is that the problem?

Thanks
Chris M

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

Re: [Emc-developers] Trajectory planner shortcomings

[Chris Morley]

Has anyone contacted the developers that worked on tormach's updates?
Could probably guess who was involved.
I would be willing to chip in for updates to the trajectory planner.

From: Marius 
Sent: July 4, 2023 5:30 PM
To: Emc-developers@lists.sourceforge.net 
; Enhanced Machine Controller (EMC) 

Subject: [Emc-developers] Trajectory planner shortcomings

Hi

I have been trying to get a rotary fourth axis setup going with the help
of regular and knowledgable contributors to LinuxCnc. We came up against
a brick wall as many other project developers have done.

The problem seems to be that our trajectory planner lack the ability to
look ahead for any rotary axis. This means that a coordinated move that
includes a rotary move will be dysfunctional at best.

I understand that there is a free trajectory planner on offer to
LinuxCnc but it has not been integrated. It would seem that some lack of
skills or time has a role to play in getting it integrated.

I unfortunately do not have the skills nor the time to tender to assist
with this however, someone made the suggestion that maybe the community
could embark on a fund raising project to enable us to pay for someone
to get the trajectory planner integrated. I am sure that many would
stand to benefit from this and other users that I have spoken to has
indicated that they would gladly contribute.

I would at least want to start a discussion around the idea.


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

Re: [Emc-developers] probe_basic -

[Chris Morley]

Probe_basic is an independent  project, not part of linuxcnc. I think it would 
be best to report problems to them directly.

Chatgpt is a weird way to look for information about linuxcnc IMHO and I don't 
think it gave good answers.

There are probing screens mostly based on an outside linuxcnc program Vesa (?) 
probe .
Qtvcp has a version called versa probe, qtvcp also has basicprobe undoubtedly 
inspired from  probe basic. There is minimal documentation on these.

There are many others, all outside of the linuxcnc project.

Iirc Linuxcnc also has some probing gcode routines but I don't have any info on 
that.
Sent from my Galaxy

Chris


 Original message 
From: Steffen Möller 
Date: 2023-04-18 2:51 a.m. (GMT-07:00)
To: LinuxCNC Dev Mailing List 
Subject: [Emc-developers] probe_basic -

Hello,
on https://www.facebook.com/groups/1887325441579936/posts/3264707197175080/ 
someone reported difficulties to get probe_basic to run because the 
auto-triggered attempt to install dependencies via pip had failed. Is there an 
alternative to probe_basic that is shipping as part of the regular LinuxCNC 
setup?

The following is what ChatGPT has answered:
"LinuxCNC does include some alternative probing scripts that are shipped as 
part of the regular LinuxCNC setup. These alternative probing scripts are 
written in the Tcl programming language and can be used as an alternative to 
probe_basic if you encounter issues with its installation or dependencies.

One such alternative probing script is called probe-tk.py, which is a graphical 
user interface (GUI) based probing script that comes with LinuxCNC. You can 
access it through the "Touch Off" button in the Axis interface of LinuxCNC. 
This script provides similar functionality to probe_basic and can be used for 
various probing operations, such as setting tool length offsets or finding 
workpiece edges.

To use probe-tk.py, you can open the Axis interface of LinuxCNC, navigate to 
the "Touch Off" button, and click on it to launch the probe-tk.py script. This 
will open a graphical window where you can interactively perform probing 
operations.

Alternatively, LinuxCNC also provides other built-in probing scripts, such as 
g38.2 and g38.3, which are G-code commands used for probing operations. These 
commands can be used directly in G-code programs to perform probing operations 
without the need for additional Python scripts.

It's worth noting that the availability and functionality of probing scripts 
may vary depending on the specific version of LinuxCNC you are using, as well 
as any modifications or configurations made to your system. It's always 
recommended to refer to the official LinuxCNC documentation and community 
resources for up-to-date information on probing operations and available 
scripts."

Is there anything to correct/improve/extend on that answer?

To mind came https://github.com/linuxcnc-probe-screen/probe-screen-ng and 
https://github.com/linuxcnc-probe-screen/probe-screen-ng but GMOCCAPY has its 
own, right?

Is there an easy way to direct our users a bit when they look into our 
documentation? I do not find any such info straight-forward to find.

Many thanks!

Steffen


___
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] dro bug is gone, but so is cam-align again

[Chris Morley]

Only thing I see is you asked to use port 1 but port 0 is the working port.
But it should have worked anyways.
Any other clues?

From: gene heskett 
Sent: February 18, 2023 5:37 PM
To: emc-developers@lists.sourceforge.net 
Subject: [Emc-developers] dro bug is gone, but so is cam-align again

Greetings all;

I just updated master on the go704, the preview dro overlay is clean
again, but the camera is blank, again.

Launched from an ssh -Y login, this is output behind the linuxcnc screen:
[QTvcp][DEBUG]  DEBUGGING logging on (qtvcp:494)
[QTvcp.QTVCP.QT_ISTAT][DEBUG]  Machine is IMPERIAL based. unit
Conversion constant=25.4 (qt_istat.py:157)
[QTvcp.QTVCP.QT_ISTAT][DEBUG]  TRAJ COORDINATES: XYZA (qt_istat.py:163)
[QTvcp.QTVCP.QT_ISTAT][WARNING]  Missing [DISPLAY] ANGULAR_INCREMENTS-
using defaults. (qt_istat.py:303)
[QTvcp.QTVCP.QT_ISTAT][DEBUG]  DEFAULT_LINEAR_VELOCITY = 15.0
(qt_istat.py:343)
[QTvcp.QTVCP.QT_ISTAT][DEBUG]  MIN_LINEAR_VELOCITY = 0.06 (qt_istat.py:344)
[QTvcp.QTVCP.QT_ISTAT][DEBUG]  MAX_LINEAR_VELOCITY = 90.0 (qt_istat.py:345)
[QTvcp.QTVCP.QT_ISTAT][WARNING]  Embedded tab configuration -invalid
number of TAB_NAMES vs TAB_LOCATION - guessing default. (qt_istat.py:432)
[QTvcp.QTVCP.LIB.SYS_NOTIFY][WARNING]  Desktop Notify not available::
org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible
causes include: the remote application did not send a reply, the message
bus security policy blocked the reply, the reply timeout expired, or the
network connection was broken. (sys_notify.py:71)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  BASEPATH cam_align (qt_pstat.py:95)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for handler file in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76-camera/qtvcp/panels/cam_align/cam_align_handler.py
(qt_pstat.py:110)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for handler file in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76-camera/cam_align_handler.py
(qt_pstat.py:110)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for default handler file in:
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qt_pstat.py:117)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Using DEFAULT handler file path:
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qt_pstat.py:120)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76-camera/qtvcp/panels/cam_align/cam_align.ui
(qt_pstat.py:142)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76-camera/cam_align.ui
(qt_pstat.py:142)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in:
/usr/share/qtvcp/panels/cam_align/cam_align.ui (qt_pstat.py:149)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Using DEFAULT ui file from:
/usr/share/qtvcp/panels/cam_align/cam_align.ui (qt_pstat.py:151)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76-camera/qtvcp/panels/cam_align/cam_align.qss
(qt_pstat.py:185)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76-camera/cam_align.qss
(qt_pstat.py:185)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in:
/usr/share/qtvcp/panels/cam_align/cam_align.qss (qt_pstat.py:192)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No qss file found. (qt_pstat.py:198)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76-camera/qtvcp/panels/cam_align/cam_align.qrc
(qt_pstat.py:213)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76-camera/cam_align.qrc
(qt_pstat.py:213)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in:
/usr/share/qtvcp/panels/cam_align/cam_align.qrc (qt_pstat.py:221)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No qrc file found. (qt_pstat.py:228)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for resources.py in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76-camera/qtvcp/panels/resources.py
(qt_pstat.py:238)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No resources.py file found, no QRC file to
compile one from. (qt_pstat.py:249)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76-camera/qtvcp/screens/cam_align/cam_align.qrc
(qt_pstat.py:260)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76-camera/cam_align/languages/cam_align_en.qm
(qt_pstat.py:260)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in:
/usr/share/qtvcp/screens/cam_align/languages/cam_align_en.qm
(qt_pstat.py:267)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using no translations, default system
locale is: en (qt_pstat.py:272)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for LOCAL about file in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76-camera/qtvcp/screens/cam_align_ABOUT
(qt_pstat.py:283)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for DEFAULT about file in:
/usr/share/qtvcp/panels/cam_align/cam_align_ABOUT (qt_pstat.py:289)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No about file found. (qt_pstat.py:295)
[QTvcp][INFO]  Building A VCP Panel with: 

[Emc-developers] Debian deadline.

[Chris Morley]

I read something about a deadline in 3 days.
Any info on that?

What is the plan for 2.9 updates/bug fixes after Debian release etc?

Chris
Sent from my Galaxy


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

Re: [Emc-developers] adding to linuxcnc/scripts

[Chris Morley]

Thanks Andy.

From: andy pugh 
Sent: January 27, 2023 5:34 PM
To: EMC developers 
Subject: Re: [Emc-developers] adding to linuxcnc/scripts

On Fri, 27 Jan 2023 at 05:35, Chris Morley  wrote:
>
> is there any other file that needs to be changed to have this file installed 
> too?

linuxcnc/debian/linuxcnc.install.in (based on searching the code for
an included script)

--
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] adding to linuxcnc/scripts

[Chris Morley]

We have a script to set up Designer in:
linuxcnc/lib/python/qtvcp/designer

it would be much nicer for installed versions for it to be accessible directly 
by the users.
I moved it (RIP version) to linuxcnc/scripts and it seems to work -  I type the 
script in the terminal and it finds and runs it.
Is this the right way for an installed version? If yes, is there any other file 
that needs to be changed to have this file installed too?
If no, is there a better way?

Chris

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

Re: [Emc-developers] Show used tools for loaded NC program?

[Chris Morley]

Ok I pushed this work to linuxcnc 2.9/master
AXIS Qtdragon/hd and Qtaxis now will display the tool change numbers with the 
gcode properties
Gremlin/Gladevcp was missing the gcode properties code all together so I added 
it.
GMoccapy could tap into this with GStat messages but I didn't go that far to 
add the capability.
One oddity is AXIS shows tool 0, the rest don't. I'd guess AXIS sets yool 0 by 
default somewhere.

Not sure if Basicprobe use glcanon.py but if it does canon.tool_list will give 
a list of found tools.

Chris

From: Chris Morley 
Sent: January 14, 2023 1:47 AM
To: EMC developers 
Subject: Re: [Emc-developers] Show used tools for loaded NC program?

I have this working (tool list gcode properties) in principle.
It's a small change in glcanon.py:

def change_tool(self, arg):
self.first_move = True
try:
self.tool_list.append(arg)
except Exception as e:
print(e)
Then requires an screen that looks for gcode properties to look for the tool 
list.

is anyone else working on this? If not I will try to get to it this week end.

Chris

From: Small Shop Concepts 
Sent: January 14, 2023 12:32 AM
To: EMC developers 
Subject: Re: [Emc-developers] Show used tools for loaded NC program?

If i do not have a tool in my carousel i get an error stating the tool not
in the carousel and the program wont start. It runs through and checks i am
guessing at cycle start.  I used to have an issue where if i called a tool
twice with a different tool between it would error because it was not
accounting for returning the tool to the carousel.

I  do like the idea of having the tool list read at program load and
displayed somewhere on the gui for those who do not have cam that prints
the tool list in the gcode file.



On Fri, Jan 13, 2023, 4:59 PM Nicklas SB Karlsson  wrote:

> Looking into file generated by post processor I used it does not print
> a list of tools used.
>
> It is easy to miss one and then program in best case quit then row to
> insert tool is reached, not a big problem but still annoying. In best
> case it would also check if tool is in tool table, this check should
> work if each tool get a unique number.
>
> Nicklas Karlsson
>
>
> fre 2023-01-13 klockan 16:39 -0500 skrev Small Shop Concepts:
> > That can be accomplished in the post processor of most cam softwares,
> > it
> > writes the tool lost at the top of the gcode file.
> >
> > On Fri, Jan 13, 2023, 4:32 PM Nicklas SB Karlsson  wrote:
> >
> > > Anyone else think it would be useful with possibility to show which
> > > tools a loaded NC file use?
> > >
> > > Then pressing a button list with tools needed is shown. So far I
> > > have
> > > manually read the g-code file to determine which tools must be
> > > prepared.
> > >
> > >
> > > Nicklas Karlsson
> > >
> > >
> > >
> > > ___
> > > 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 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] Show used tools for loaded NC program?

[Chris Morley]

I have this working (tool list gcode properties) in principle.
It's a small change in glcanon.py:

def change_tool(self, arg):
self.first_move = True
try:
self.tool_list.append(arg)
except Exception as e:
print(e)
Then requires an screen that looks for gcode properties to look for the tool 
list.

is anyone else working on this? If not I will try to get to it this week end.

Chris

From: Small Shop Concepts 
Sent: January 14, 2023 12:32 AM
To: EMC developers 
Subject: Re: [Emc-developers] Show used tools for loaded NC program?

If i do not have a tool in my carousel i get an error stating the tool not
in the carousel and the program wont start. It runs through and checks i am
guessing at cycle start.  I used to have an issue where if i called a tool
twice with a different tool between it would error because it was not
accounting for returning the tool to the carousel.

I  do like the idea of having the tool list read at program load and
displayed somewhere on the gui for those who do not have cam that prints
the tool list in the gcode file.



On Fri, Jan 13, 2023, 4:59 PM Nicklas SB Karlsson  wrote:

> Looking into file generated by post processor I used it does not print
> a list of tools used.
>
> It is easy to miss one and then program in best case quit then row to
> insert tool is reached, not a big problem but still annoying. In best
> case it would also check if tool is in tool table, this check should
> work if each tool get a unique number.
>
> Nicklas Karlsson
>
>
> fre 2023-01-13 klockan 16:39 -0500 skrev Small Shop Concepts:
> > That can be accomplished in the post processor of most cam softwares,
> > it
> > writes the tool lost at the top of the gcode file.
> >
> > On Fri, Jan 13, 2023, 4:32 PM Nicklas SB Karlsson  wrote:
> >
> > > Anyone else think it would be useful with possibility to show which
> > > tools a loaded NC file use?
> > >
> > > Then pressing a button list with tools needed is shown. So far I
> > > have
> > > manually read the g-code file to determine which tools must be
> > > prepared.
> > >
> > >
> > > Nicklas Karlsson
> > >
> > >
> > >
> > > ___
> > > 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 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] Show used tools for loaded NC program?

[Chris Morley]

In qtdragon one can load an HTML or PDF 'setup' documents.
If the document is the same name as the gcode file it loads at the same time on 
a separate page.

Qtdragon allows writing HTML files though PDF has alluded me.
Apparently come gcode making programs make the PDFs.

So yes, while not standard this has been found useful.

Chris

From: Nicklas SB Karlsson 
Sent: January 13, 2023 9:27 PM
To: EMC developers 
Subject: [Emc-developers] Show used tools for loaded NC program?

Anyone else think it would be useful with possibility to show which
tools a loaded NC file use?

Then pressing a button list with tools needed is shown. So far I have
manually read the g-code file to determine which tools must be
prepared.


Nicklas Karlsson



___
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] Broken master 06jan23

[Chris Morley]

the -d in this line:
EMBED_TAB_COMMAND = halcmd loadusr qtvcp -d -c cam_align -x {XID} -o 
camnumber=1 cam_align
is the debug switch - that is why qtvcp is noisy. You can remove it when all is 
good.

I have no experience with linuxcnc over ssh so cannot really help with those 
problems.
I don't know why the camera port number changes but maybe it has to do with 
ssh/logging in locally.

I'll push a change soon that trys the designated camera number and if that 
fails tries to test for a working one and use it.

Thanks for th ebug reports.
Chris



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

Re: [Emc-developers] Broken master 06jan23

[Chris Morley]

ok good it seems the useable camera number is 1 rather then the assumed 0:


Port 1 is working and reads images (480.0 x 640.0)


This can be set in the INI but looks like you need to pull in an update.
Or I can show you what to fix.

after that then you need to use this in the ini.
EMBED_TAB_COMMAND = halcmd loadusr qtvcp -d -c cam_align -x {XID} -o 
camnumber=1 cam_align

Chris

From: gene heskett 
Sent: January 12, 2023 5:43 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] Broken master 06jan23

On 1/11/23 16:43, Chris Morley wrote:
> looks like you are using a command like this:
>
> EMBED_TAB_COMMAND = qtvcp -d -c cam_align -x {XID} cam_align
>
> try changing it to:
> EMBED_TAB_COMMAND = halcmd loadusr qtvcp -d -c cam_align -x {XID} cam_align

Thats better, at least lcnc runs, but prints this on the terminal screen:

[QTvcp.QTVCP.QT_MAKEPINS][INFO]  No preference file - cannot set
preference geometry. (qt_makepins.py:160)
VIDEOIO ERROR: V4L: index 0 is not correct!
Could not open video device 0
VIDEOIO ERROR: V4L: index 0 is not correct!
Port 0 is not working.
Port 1 is working and reads images (480.0 x 640.0)
Unable to stop the stream: Invalid argument
Port 2 is not working.
VIDEOIO ERROR: V4L: index 3 is not correct!
Port 3 is not working.
VIDEOIO ERROR: V4L: index 4 is not correct!
Port 4 is not working.
VIDEOIO ERROR: V4L: index 5 is not correct!
Port 5 is not working.
VIDEOIO ERROR: V4L: index 6 is not correct!
Port 6 is not working.
[QTvcp][INFO]  Preference path: None (qtvcp:421)

So I issued a sudo reboot in case something has it running already. I'm
in the house, ssh'd into it.
so I'll restore the sshfs share, and attach the qtvcp.log. Done. I know
zip about qtvcp. Everything I done so far has been pyvcp.

Thank you Chris.  Take care & stay well.

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

Re: [Emc-developers] Broken master 06jan23

[Chris Morley]

looks like you are using a command like this:

EMBED_TAB_COMMAND = qtvcp -d -c cam_align -x {XID} cam_align

try changing it to:
EMBED_TAB_COMMAND = halcmd loadusr qtvcp -d -c cam_align -x {XID} cam_align

From: gene heskett 
Sent: January 11, 2023 9:17 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] Broken master 06jan23

On 1/11/23 16:02, Chris Morley wrote:
> FileNotFoundError: [Errno 2] No such file or directory:
> '/usr/share/qtvcp/panels/-d/-d.ui'
>
> This is weird, it's picking up the -d as a panel name.
>
> Can you post a link to your INI file?
>
> Chris

I'll put it on my web page (in the sig) under the GO704 directory when I
get some food hidden. Half an hour maybe.
> 
> From: gene heskett 
> Sent: January 11, 2023 3:10 PM
> To: emc-developers@lists.sourceforge.net 
> 
> Subject: Re: [Emc-developers] Broken master 06jan23
>
> [QTvcp][CRITICAL]  Aborted from Error Dialog
>Qtvcp encountered an error.  The following information may be useful
> in troubleshooting:
> LinuxCNC Version  : 2.10.0-pre0-483-g47f4f07e2
>
> Traceback (most recent call last):
> File "/usr/bin/qtvcp", line 511, in 
>   APP = QTVCP()
> File "/usr/bin/qtvcp", line 304, in __init__
>   self.panel = qt_makepins.QTPanel(self.hal, PATH, window, opts.debug)
> File "/usr/lib/python3/dist-packages/qtvcp/qt_makepins.py", line 96,
> in __init__
>   window[pName].instance(os.path.join(path.PANELDIR , cmd, cmd+'.ui'))
> File "/usr/lib/python3/dist-packages/qtvcp/qt_makegui.py", line 382,
> in instance
>   instance = uic.loadUi(filename, self)
> File "/usr/lib/python3/dist-packages/PyQt5/uic/__init__.py", line
> 226, in loadUi
>   return DynamicUILoader(package).loadUi(uifile, baseinstance,
> resource_suffix)
> File "/usr/lib/python3/dist-packages/PyQt5/uic/Loader/loader.py",
> line 72, in loadUi
>   return self.parse(filename, resource_suffix, basedir)
> File "/usr/lib/python3/dist-packages/PyQt5/uic/uiparser.py", line
> 1013, in parse
>   document = parse(filename)
> File "/usr/lib/python3.7/xml/etree/ElementTree.py", line 1197, in parse
>   tree.parse(source, parser)
> File "/usr/lib/python3.7/xml/etree/ElementTree.py", line 587, in parse
>   source = open(source, "rb")
> FileNotFoundError: [Errno 2] No such file or directory:
> '/usr/share/qtvcp/panels/-d/-d.ui'
>
>(qtvcp:503)
> 'QTVCP' object has no attribute 'panel'
> 'QTVCP' object has no attribute 'panel'
> Error in sys.excepthook:
> Traceback (most recent call last):
> File "/usr/bin/qtvcp", line 504, in excepthook
>   self.shutdown()
> File "/usr/bin/qtvcp", line 462, in shutdown
>   self.panel.window.sync_qsettings()
> AttributeError: 'QTVCP' object has no attribute 'panel'
>
> Original exception was:
> Traceback (most recent call last):
> File "/usr/bin/qtvcp", line 511, in 
>   APP = QTVCP()
> File "/usr/bin/qtvcp", line 304, in __init__
>   self.panel = qt_makepins.QTPanel(self.hal, PATH, window, opts.debug)
> File "/usr/lib/python3/dist-packages/qtvcp/qt_makepins.py", line 96,
> in __init__
>   window[pName].instance(os.path.join(path.PANELDIR , cmd, cmd+'.ui'))
> File "/usr/lib/python3/dist-packages/qtvcp/qt_makegui.py", line 382,
> in instance
>   instance = uic.loadUi(filename, self)
> File "/usr/lib/python3/dist-packages/PyQt5/uic/__init__.py", line
> 226, in loadUi
>   return DynamicUILoader(package).loadUi(uifile, baseinstance,
> resource_suffix)
> File "/usr/lib/python3/dist-packages/PyQt5/uic/Loader/loader.py",
> line 72, in loadUi
>   return self.parse(filename, resource_suffix, basedir)
> File "/usr/lib/python3/dist-packages/PyQt5/uic/uiparser.py", line
> 1013, in parse
>   document = parse(filename)
> File "/usr/lib/python3.7/xml/etree/ElementTree.py", line 1197, in parse
>   tree.parse(source, parser)
> File "/usr/lib/python3.7/xml/etree/ElementTree.py", line 587, in parse
>   source = open(source, "rb")
> FileNotFoundError: [Errno 2] No such file or directory:
> '/usr/share/qtvcp/panels/-d/-d.ui'
>
>
>
> ___
> 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 

Re: [Emc-developers] Broken master 06jan23

[Chris Morley]

FileNotFoundError: [Errno 2] No such file or directory:
'/usr/share/qtvcp/panels/-d/-d.ui'

This is weird, it's picking up the -d as a panel name.

Can you post a link to your INI file?

Chris

From: gene heskett 
Sent: January 11, 2023 3:10 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] Broken master 06jan23

[QTvcp][CRITICAL]  Aborted from Error Dialog
  Qtvcp encountered an error.  The following information may be useful
in troubleshooting:
LinuxCNC Version  : 2.10.0-pre0-483-g47f4f07e2

Traceback (most recent call last):
   File "/usr/bin/qtvcp", line 511, in 
 APP = QTVCP()
   File "/usr/bin/qtvcp", line 304, in __init__
 self.panel = qt_makepins.QTPanel(self.hal, PATH, window, opts.debug)
   File "/usr/lib/python3/dist-packages/qtvcp/qt_makepins.py", line 96,
in __init__
 window[pName].instance(os.path.join(path.PANELDIR , cmd, cmd+'.ui'))
   File "/usr/lib/python3/dist-packages/qtvcp/qt_makegui.py", line 382,
in instance
 instance = uic.loadUi(filename, self)
   File "/usr/lib/python3/dist-packages/PyQt5/uic/__init__.py", line
226, in loadUi
 return DynamicUILoader(package).loadUi(uifile, baseinstance,
resource_suffix)
   File "/usr/lib/python3/dist-packages/PyQt5/uic/Loader/loader.py",
line 72, in loadUi
 return self.parse(filename, resource_suffix, basedir)
   File "/usr/lib/python3/dist-packages/PyQt5/uic/uiparser.py", line
1013, in parse
 document = parse(filename)
   File "/usr/lib/python3.7/xml/etree/ElementTree.py", line 1197, in parse
 tree.parse(source, parser)
   File "/usr/lib/python3.7/xml/etree/ElementTree.py", line 587, in parse
 source = open(source, "rb")
FileNotFoundError: [Errno 2] No such file or directory:
'/usr/share/qtvcp/panels/-d/-d.ui'

  (qtvcp:503)
'QTVCP' object has no attribute 'panel'
'QTVCP' object has no attribute 'panel'
Error in sys.excepthook:
Traceback (most recent call last):
   File "/usr/bin/qtvcp", line 504, in excepthook
 self.shutdown()
   File "/usr/bin/qtvcp", line 462, in shutdown
 self.panel.window.sync_qsettings()
AttributeError: 'QTVCP' object has no attribute 'panel'

Original exception was:
Traceback (most recent call last):
   File "/usr/bin/qtvcp", line 511, in 
 APP = QTVCP()
   File "/usr/bin/qtvcp", line 304, in __init__
 self.panel = qt_makepins.QTPanel(self.hal, PATH, window, opts.debug)
   File "/usr/lib/python3/dist-packages/qtvcp/qt_makepins.py", line 96,
in __init__
 window[pName].instance(os.path.join(path.PANELDIR , cmd, cmd+'.ui'))
   File "/usr/lib/python3/dist-packages/qtvcp/qt_makegui.py", line 382,
in instance
 instance = uic.loadUi(filename, self)
   File "/usr/lib/python3/dist-packages/PyQt5/uic/__init__.py", line
226, in loadUi
 return DynamicUILoader(package).loadUi(uifile, baseinstance,
resource_suffix)
   File "/usr/lib/python3/dist-packages/PyQt5/uic/Loader/loader.py",
line 72, in loadUi
 return self.parse(filename, resource_suffix, basedir)
   File "/usr/lib/python3/dist-packages/PyQt5/uic/uiparser.py", line
1013, in parse
 document = parse(filename)
   File "/usr/lib/python3.7/xml/etree/ElementTree.py", line 1197, in parse
 tree.parse(source, parser)
   File "/usr/lib/python3.7/xml/etree/ElementTree.py", line 587, in parse
 source = open(source, "rb")
FileNotFoundError: [Errno 2] No such file or directory:
'/usr/share/qtvcp/panels/-d/-d.ui'



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

Re: [Emc-developers] Broken master 06jan23

[Chris Morley]

I looked at the qt camview problem. I have an installed version of linuxcnc and 
it is broken there.
Strangley I can not find where it got broken in the source.
The fix is easy
In camview.py need to change to these lines.

try:
import cv2 as CV
DEFAULT_API = CV.CAP_ANY
except:
LOG.error('Qtvcp Error with camview - is python3-opencv installed?')
LIB_GOOD = False
DEFAULT_API = 0 # CV.CAP_ANY

Chris


From: gene heskett 
Sent: January 7, 2023 11:27 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] Broken master 06jan23

And of course the camera on the go704 doesn't work making qt upset at
init time for about 40 seconds of . spew. It only worked for 3
or 4 days a couple/three months back. With cheese it Just Works. This is
upsetting, it works for 2 or 4 upgrades, then disappears again for 6
months until I start pestering the list again.

I'm as tired of that as you all are reading about my camera woes.

It never works long enough for me to get the align kit from our wiki
fully calibrated. Yet it works with cheese on any machine I plug it into.



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

Re: [Emc-developers] Broken master 06jan23

[Chris Morley]

Thank you Jeff.
Chris

From: Jeff Epler 
Sent: January 9, 2023 3:06 AM
To: EMC developers 
Subject: Re: [Emc-developers] Broken master 06jan23

Thank you all for the discussion.

I merged #2251, closed #2250, and in a moment I'll "unlock" the master
branch.

Take care,
Jeff


___
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] Broken master 06jan23

[chris morley]

On 2023-01-08 10:38, Jeff Epler wrote:

[Chris requested that I explicitly respond to each part of his message.
I will do so even though I have little that is constructive to add]


Thank you, the discussion is important for everyone I think.


These things seem like radical responses to an uncomon mistake.
This will be only be the second time in about 15 years something like this 
happened.
You're right, in that I would like to use this as an opportunity to move
the project in a direction I think is good. The term "radical" is
charged, of course. From my point of view, I'm promoting styles of
working that are what I do everyday and which I perceive as working
well.


The word radical was not intended to be charged, feel free to use 'rash'

I was asking questions and giving my opinion.

We can't move forward without discussion - I am interested in your and 
others point of view.



If you want to talk merge strategies see my other maillist talk.
The jest of is - why merge released branches into master at all.

As my colleague said, the idea to end the project's long-standing policy
of merging from stable to main seems like a "radical [response] to an
uncomon mistake."


Yes It is radical change to current norms but not without precedence.

IIRC with cvs , we did not merge branch upto branch, only feature branch 
to branch.


Also my suggestion was before the problem occurred - so not a radical 
_response_ :)


Chris



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

Re: [Emc-developers] Broken master 06jan23

[Chris Morley]

Yes Andy I knew that from last time and I think it should have been stated this 
time.
But I left it open that maybe there was some other technical reason/advantage.
I am also opposed to doing a bunch of changes - with possible errors added just 
to change a word that is out of vogue.
Nothing wrong with asking the question again I suppose - maybe the project has 
changed it's mind.
But I don't think so.

Chris

From: andy pugh 
Sent: January 8, 2023 7:13 PM
To: EMC developers 
Subject: Re: [Emc-developers] Broken master 06jan23

On Sun, 8 Jan 2023 at 04:10, Chris Morley  wrote:
>
> Why would we change to 'main' ?

Github have a problem with the word "master"

I think that they are misguided in this particular case, but at the
same time I think that "main" is a clearer name than "master". Though
perhaps "dev" would be better still.

--
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] Broken master 06jan23

[chris morley]

On 2023-01-08 06:43, Jeff Epler wrote:

On Sun, Jan 08, 2023 at 04:06:07AM +, Chris Morley wrote:

AFAICT the code (I didn't look at the docs mind you) is fixed.
What is actually broken in master now?
What are we trying to fix? The history?

Content of changes in 2.9 were discarded, instead of being added to
master. This includes documentation fixes. I hope you will respect that
just like code changes, documentation changes are valuable contributions
to this project.

For a list of changes between master and jepler/alternate-bad-merge-fix
see https://gist.github.com/jepler/86390ab9be17babf0349a1a8c5198e2e --
these represent changes in 2.9 that were NOT taken by the bad merge
commit but probably should have been.

The majority are documentation changes (which does not mean they are
lower value than code changes). That said, a lot of code changes were
discarded too.  For instance, an entire config is missing.  As far as
source code goes it looks like bugfixes to gremlin, qtvcp, and others
are missing.  To get an idea this "git diff --stat" summary of
differences in lib/ src/ bin/ and scripts/ provides an overview:


I'm not sure where you got the idea I don't think docs are important. 
I've done a lot of docs myself. I only said I hadn't checked them.


Thank you for showing me there was a lot more changes then i was aware of.

You didn't address my other comments.


Chris



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

Re: [Emc-developers] Broken master 06jan23

[Chris Morley]

AFAICT the code (I didn't look at the docs mind you) is fixed.
What is actually broken in master now?
What are we trying to fix? The history?

Why would we change to 'main' ?
How does the name change fix merge problems?
It does create doc and web reference problems.

I disagree with having to use pull requests for devs. (if I understood that 
right)
We already have problems getting pull request reviewed and aproved.

These things seem like radical responses to an uncomon mistake.
This will be only be the second time in about 15 years something like this 
happened.

If you want to talk merge strategies see my other maillist talk.
The jest of is - why merge released branches into master at all.

Thanks
Chris


From: Jeff Epler 
Sent: January 8, 2023 2:34 AM
To: EMC developers 
Subject: Re: [Emc-developers] Broken master 06jan23

Thanks for speaking up about the problem as soon as you realized it.
I have temporarily locked the "master" branch on github until this
problem is resolved.

I understand that the idea of force-pushing master to 1d836df^ before
the problem was discussed and dismissed (on IRC?). I did not see this
discussion.

Seb and I have each prepared PRs that approach fixing the problem. I
have a third, non-pull-request suggestion.

https://github.com/LinuxCNC/linuxcnc/pull/2250 --

Seb re-cherry-picks work from 2.9, excluding doc work that did not apply
cleanly. This would mean the doc work is lost from master if nobody else
steps up to cherry-pick and pull request the changes to master too:

https://github.com/LinuxCNC/linuxcnc/pull/2251 --
I merge 2.9 into 1d836df^ (git notation for "the commit before 1d836df),
doing my best to take the better side of each conflict in the
documentation (usually it was pretty clear; a total of 4 files had
conflicts), then merge 1d836df with the "ours" strategy (to effectively
discard its version of the changes), and then cherry-pick commits
subsequent to 1d836df, only one of which introduced changes.  This
hopefully catches the majority of doc work, but I merely selected one
side or the other of the doc changes, rather than carefully merging them
word by word.


The third suggestion is to use this as the moment to adopt the github
standard "main" branch name, instead of the deprecated branch name
"master". I would prepare a new branch similar to #2251, but NOT merge
1d836df in it, and push this as "main".


Besides fixing things in one of these ways, I think we should strongly
consider using github "branch protection", so that any change to main
and a "branch that looks like a version number" must go through the pull
request process.  This doesn't catch all problems, and it would require
folks to step up as pull request reviewers, but it might have avoided
this problem.


I'll check back on this thread as well as the developers IRC channel to
see if a consensus develops and then implement it.  Because this is
blocking ongoing work it's problably better to resolve it in a timely
fashion than to spend a long time figuring out the best possible
resolution.

It sounds like Seb is not available for the rest of the week-end fwiw.

Jeff


___
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] feed hold ?

[Chris Morley]

Lots Spring left in that chicken. We have guys still coming to work at the 
plant full time at 72 and part time ..up to 79!


Chris



Sent from my Galaxy



 Original message 
From: John Thornton 
Date: 2022-12-05 6:29 a.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] feed hold ?

Wait till you get my age... I'm 69 now.

JT

On 12/4/2022 5:00 PM, Chris Morley wrote:
> lol thanks Phil. I hit 50 and can only remember half of anything :)
>
> Chris
> 
> From: Phill Carter 
> Sent: December 4, 2022 10:48 PM
> To: linuxcnc-developers 
> Subject: Re: [Emc-developers] feed hold ?
>
> There is a motion.jog-inhibit pin in 2.9 and later
>
>
>> On 5 Dec 2022, at 7:16 am, Chris Morley  wrote:
>>
>> Yes it was miss named but it was meant to stop all motion. Only a thread 
>> pass would finish. Which you could certainly argue was wrong too.
>>
>> After I realized the name was bad it was kinda too late.
>>
>> Chris
>>
>>
>>
>> Sent from my Galaxy
>>
>>
>>
>>  Original message 
>> From: andy pugh 
>> Date: 2022-12-04 11:32 a.m. (GMT-08:00)
>> To: EMC developers 
>> Subject: Re: [Emc-developers] feed hold ?
>>
>> On Sun, 4 Dec 2022 at 19:19, Jon Elson  wrote:
>>
>>> Yikes!  I can see arguments both ways, but feed hold or feed
>>> inhibit seems like it should stop all motion,
>>
>> I think it should stop feeds (or it would be called
>> "all-motion-inhibit" :-)
>>
>> --
>> 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
>
> ___
> 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] feed hold ?

[Chris Morley]

lol thanks Phil. I hit 50 and can only remember half of anything :)

Chris

From: Phill Carter 
Sent: December 4, 2022 10:48 PM
To: linuxcnc-developers 
Subject: Re: [Emc-developers] feed hold ?

There is a motion.jog-inhibit pin in 2.9 and later


> On 5 Dec 2022, at 7:16 am, Chris Morley  wrote:
>
> Yes it was miss named but it was meant to stop all motion. Only a thread pass 
> would finish. Which you could certainly argue was wrong too.
>
> After I realized the name was bad it was kinda too late.
>
> Chris
>
>
>
> Sent from my Galaxy
>
>
>
>  Original message 
> From: andy pugh 
> Date: 2022-12-04 11:32 a.m. (GMT-08:00)
> To: EMC developers 
> Subject: Re: [Emc-developers] feed hold ?
>
> On Sun, 4 Dec 2022 at 19:19, Jon Elson  wrote:
>
>>
>> Yikes!  I can see arguments both ways, but feed hold or feed
>> inhibit seems like it should stop all motion,
>
>
> I think it should stop feeds (or it would be called
> "all-motion-inhibit" :-)
>
> --
> 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

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

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Chris Morley]

>My work on this will  continue, initially getting the required network
>code in place for both TCP and UDP connections and also the Redis base
>to handle the distribution of Cmd, Status and Error data to where ever
>it is needed. Once that is done change my routing commands away from the
>NML remote TCP ports into the newly created TCP server ports for further
>testing and evaluation and development of any additional code
>requirements. The same for status and errors.


Do you mean linuxcnc would NML into a redis database and then network out of 
redis?

A couple of things come to mind that I run into as a UI builder:

How does HAL fall into this? Many things the uis currently interact with are 
HAL related.

Error handling is terribly difficult. The 'consumed' error messages make it 
very difficult to detect errors and act accordingly, particularly if you have 
multiple ui sources.

The fact that linuxcnc doesn't have an internal memory of say jog rate, means 
every ui has one, yet unless you use HAL you can not communicate between uis. 
This is what I think you mean by 'python based addons' we worked around this in 
qtvcp and gladevcp by adding jograte to python's status module. Mostly because 
linuxcnc and NML are too big of a black box with no docs/examples.

Can your proposal help with the 'no docs blackbox' problem too? Redis is 
certainly mainstream.

Chris



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

Re: [Emc-developers] feed hold ?

[Chris Morley]

Yes it was miss named but it was meant to stop all motion. Only a thread pass 
would finish. Which you could certainly argue was wrong too.

After I realized the name was bad it was kinda too late.

Chris



Sent from my Galaxy



 Original message 
From: andy pugh 
Date: 2022-12-04 11:32 a.m. (GMT-08:00)
To: EMC developers 
Subject: Re: [Emc-developers] feed hold ?

On Sun, 4 Dec 2022 at 19:19, Jon Elson  wrote:

>
> Yikes!  I can see arguments both ways, but feed hold or feed
> inhibit seems like it should stop all motion,


I think it should stop feeds (or it would be called
"all-motion-inhibit" :-)

--
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] feed hold ?

[Chris Morley]

The jog inhibiting code from motion-inhibit was purposely removed some time ago.
Why, I don't know because it was put in by me specifically for that purpose a 
long while back.

as for feed-hold, my guess would be the code change affected it too - probably 
by accident.

maybe adding separate jog-inhibit pins would satisfy everyone?

Chris

From: Jon Elson 
Sent: December 4, 2022 5:03 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] feed hold ?

On 12/4/22 10:44, Jon Elson wrote:
> I was demoing my touch probe yesterday and saw something
> odd. This probe uses IR signals, and so the interface will
> detect loss of IR communication and cause a feed hold.  I
> was astonished to see that the keyboard jog keys allowed
> me to move the axes while feed hold was true!  The probe
> interface sends that status to motion.feed-hold, and I
> have a tally LED in PyVCP to show the status.  I'm using
> LinuxCNC 2.8.2

Looking at the docs, there is an option that needs to be
set, so I tried connecting the feed hold to
motion.feed-inhibit.  That made no difference it still
allowed jog keys to move the axes when motion.feed-inhibit
was true!

This seems like a real bug!

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] A vision for working now to LinuxCnc version 10

[chris morley]

On 2022-12-03 16:06, Johannes Fassotte wrote:

I’m fairly familiar with machine kit and it has nothing to do with that. It has 
strictly to do with modernizing the built in remote interface that Linuxcnc was 
born with..


ok You must realize almost no one uses the networking capability of 
linuxcnc.


It seems to be the case that most machines have the controls on the 
machine so over network is not that important. Certainly its a 
limitation in some cases. I guess I don't see why its 
the-most-important-thing that you seem to?



I think that this will get done individuals like me that get together and see 
the advantages that this offers. I usually get  referred to machinekit liked 
you did which is really like saying go away, we don’t want to hear this because 
it is not compatible with existing plans and therefore rejected.
I am not sure why you are hostile. I am really trying to understand 
exactly what you want. Machinekit did work on networking, though I think 
it was just HAL. It's why I mentioned it.


Using this method can allow any Ui including your efforts to function with 
minimum changes and with mostly the addition of a built in secure TCP 
interface.  It would be nice if you could help with development of the Python 
version of the proposed interface.


I'll tell you I know almost nothing about networking. I'm a self taught 
programmer that uses hack-till-it-works more then engineering a 
solution. I have done tons of work in linuxcnc, but not so much on NML.


I'd be happy if NML was replaced to something mainstream so there was 
examples to go by. Machinekit wanted to use ZMQ but never got all the 
way there as I understand it. But it is beyond my skill.


I certainly agree that inter-ui communication is not good in linuxcnc 
and often a real pain to work around. Some hardware paradigm don't lend 
themselves to multiple 'blind' ui control.


Oh you are  auto-mation-assist on the forum - guy that did labview work.

Chris



Johannes -
Fairbanks, AK 99712


On Dec 3, 2022, at 10:58 AM, Chris Morley  wrote:

Have you looked at machinekit code? Is that similar to what you want?

Chris



Sent from my Galaxy



 Original message 
From: Johannes P Fassotte 
Date: 2022-12-03 11:48 a.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: [Emc-developers] A vision for working now to LinuxCnc version 10

In order to help clarify what I would like to see in not only version 10
of LinuxCnc but also in the current version 9 future work. I will start
working on this as soon as my new circuits board for my metal detectors
are populated with all the SMD components. The circuit blank circuit
boards arrived yesterday. This requires placing 235 SMD componets on
each of the boards and likely take about seven days.

My goal for LinuxCnc is to provide a way for any user to interface any
UI to LinuxCnc with a secure TCP network connection. LinuxCnc has had
such an interface from its inception via the NML network servers however
these are absolutely insecure and anyone with a bit of knowledge of
remote NML commands can take control of LinuxCnc if those network ports
are left open. Thus LinuxCnc needs modern secure network interfaces to
replace the ones that were designed in from the very start government
development and just ignored. Not many use this interface because it
does not provide complete information due to developers add-ons such as
Python that seem to just live in their own world within LinuxCnc and do
not provide  any info into the NML network links. NML is likely the
hardest thing to deal with and very difficult to replace but in general
works just fine.

About 12 years ago I developed code to allow remote control of a lot of
time sensitive  industrial and electronic equipment that was  over 500
miles from the actual normal user interface. The equipment being
remotely controlled was located in a isolated area and without
communication links and thus those also had to be designed and
implemented. The overall bandwidth of the communication link was divided
into remote receive data, multiple command channels,  status and error
channels. The system was designed for very high reliability and met all
design goals and is still in operation with some equipment updates
having been made.

The goal of me mentioning this is that I know that having a distributed
data system with equipment to be controlled in one location and the user
interface in an other more convenient location doe not have to suffer
from reliability issues when properly executed. What it does provide is
flexibility. In case of LinuxCnc which runs on Linux user interfaces and
there support requirements can be offloaded from the Linux system and
run on Windows based system instead or even on another Linux Based
computer. Which as I mentioned before reduces the need to load up the
machine control computer with support code that is not directly related
to its main function which if of course to control a machine

Re: [Emc-developers] A vision for working now to LinuxCnc version 10

[Chris Morley]

Have you looked at machinekit code? Is that similar to what you want?

Chris



Sent from my Galaxy



 Original message 
From: Johannes P Fassotte 
Date: 2022-12-03 11:48 a.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: [Emc-developers] A vision for working now to LinuxCnc version 10

In order to help clarify what I would like to see in not only version 10
of LinuxCnc but also in the current version 9 future work. I will start
working on this as soon as my new circuits board for my metal detectors
are populated with all the SMD components. The circuit blank circuit
boards arrived yesterday. This requires placing 235 SMD componets on
each of the boards and likely take about seven days.

My goal for LinuxCnc is to provide a way for any user to interface any
UI to LinuxCnc with a secure TCP network connection. LinuxCnc has had
such an interface from its inception via the NML network servers however
these are absolutely insecure and anyone with a bit of knowledge of
remote NML commands can take control of LinuxCnc if those network ports
are left open. Thus LinuxCnc needs modern secure network interfaces to
replace the ones that were designed in from the very start government
development and just ignored. Not many use this interface because it
does not provide complete information due to developers add-ons such as
Python that seem to just live in their own world within LinuxCnc and do
not provide  any info into the NML network links. NML is likely the
hardest thing to deal with and very difficult to replace but in general
works just fine.

About 12 years ago I developed code to allow remote control of a lot of
time sensitive  industrial and electronic equipment that was  over 500
miles from the actual normal user interface. The equipment being
remotely controlled was located in a isolated area and without
communication links and thus those also had to be designed and
implemented. The overall bandwidth of the communication link was divided
into remote receive data, multiple command channels,  status and error
channels. The system was designed for very high reliability and met all
design goals and is still in operation with some equipment updates
having been made.

The goal of me mentioning this is that I know that having a distributed
data system with equipment to be controlled in one location and the user
interface in an other more convenient location doe not have to suffer
from reliability issues when properly executed. What it does provide is
flexibility. In case of LinuxCnc which runs on Linux user interfaces and
there support requirements can be offloaded from the Linux system and
run on Windows based system instead or even on another Linux Based
computer. Which as I mentioned before reduces the need to load up the
machine control computer with support code that is not directly related
to its main function which if of course to control a machine and output
status info back to the user and process commands from the UI that may
be located some distance away and not in a noisy environment. There are
of coarse other ways to snoop into a Machine controller and some have
implemented one or more o those methods strictly because LinuxCnc does
not have a proper way of handing remote UI's.

I thing that even version 9 master has a good deal of the required code
to fix that problem by just adding some code to do some data routing and
adding some secure TCP channels. I have drawn a basic block diagram of
what would be required and attached it.



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

[Emc-developers] Fwd: A vision for working now to LinuxCnc version 10

[chris morley]

Sory should have gone to list...

 Forwarded Message 
Subject: 	Re: [Emc-developers] A vision for working now to LinuxCnc 
version 10

Date:   Fri, 2 Dec 2022 12:53:31 -0800
From:   chris morley 
To: Johannes P Fassotte 




On 2022-12-02 10:38, Johannes P Fassotte wrote:
 That requirement is secure distributed networking interfaces for all 
user interfaces and implemented as plugins for LinuxCnc.


As such I would like to see plugin code developed to allow user 
interfaces to have full control of LinuxCnc, along with consolidated 
status and errors with plugin interfaces for Python, C/C++ and NML.


Are you talking distributed as in across network or distributed as in 
individual distributed packages?


With such a plugin system for user interfaces there is no need to 
include anything related to user interface development withing 
LinuxCnc code itself since those are all handled as completely 
separate projects by the various UI developers.
I guess in my mind this is already true -Qtpyvcp is a separate project 
that is added to linuxcnc is it not?


I don't understand why I see so much resistance in getting such a 
relatively simple thing done by the experts in LinuxCnc development. 
Everyone knows that distributed networking is extremely viable so 
there should be no reason not to implement this concept for 
interfacing with UI's. You cannot keep on adding UI development things 
to LinuxCnc without it becoming a big big mess. I think to do so is 
just due to hardheadedness.


Probably because its a actually a lot of work on code that require 
specialized knowledge.


I also don't see the 'big mess' part.

i think it's somewhat of an advantage to have everything needed to use 
linuxcnc under one project.


For instance i as a mostly ui guy, needs to know almost nothing about 
packaging and make files.


This lowers the bar to being a developer on the project.

There is surely some disadvantages too - you are not completely free to 
do whatever you want or even whats best.


Lets develop the UI plugin interface concept for LinuxCnc version 10 
that allows UI interfaces to run as a distributed data system and 
which at the same time simplifies maintaining LinuxCnc a thousand fold 
and also reducing the size of its footprint.


I'm not sue it simplifies it - just distributes it among more projects. 
Again advantages and disadvantages


.

Its up you, the LinuxCnc developers and also the UI developers to  get 
started on implementing something like this for LinuxCnc version 10! 
You are all the experts and developing the standard code for this is 
likely not difficult. For those of us who are somewhat on the outside 
the development group we will have to do less customizing  work by not 
having to customize LinuxCnc to suit our desires and which causes a 
great deal of  update difficulties.


So one obvious way to help is to become a part of the linuxcnc group 
instead of staying on the 'outside'.


Now this can be a frustrating experience sometimes and you will have to 
compromise - a lot.


We are currently way too short on developers to do much big changes.

Another way is to develop on the side and work on getting it accepted.

But if your work massively overlaps on going work already in the 
project, expect resistance - that is just human nature.


In this case Kurt probably could have avoided this by not disappearing 
from qtvcp project. I don't remember any big fights with him. i very 
much enjoyed working with him at the time. looking back at it though, it 
does seem clear he always wanted to do his own thing - fair enough.


When you look at history there have been a number of warnings that 
this needed to be done a long time ago. One such example was the split 
and development of Machinekit which I feel was the direct result of 
developers being to stubborn to explore other points of view and their 
potential long term benefits. Just think about how much was lost by 
these two teams not being able to work together to resolve issues.


It is disappointing what happened with machinekit - In truth I think it 
should have happened earlier before feeling were hurt and walls were 
built up - so that we could come back together with the best of both.


Linuxcnc has always been a slow moving project. It's often frustrating. 
But it seems to have something that keeps it popular. I mean Qtpyvcp 
isn't using machinekit's network distributed ui system.



Chris

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

Re: [Emc-developers] Eye candy is important - Titan got a new German friend - want that reaction for a LinuxCNC controller

[Chris Morley]

Because qtpyvcp and qtvcp do the same job using mostly the same tools (python 
and qt)

If qtpyvcp wanted to be under the linuxcnc unberella they could have continued 
working in qtvcp instead of making a new independent, project. Nothing wrong 
with being independent, seems to work for both projects.
It is too bad we divided the effort but what is done is done.

I'm sure neither project wants their years of work trampled on.

Chris




Sent from my Galaxy

 Original message 
From: Jérémie Tarot 
Date: 2022-12-01 8:06 a.m. (GMT-08:00)
To: EMC developers 
Subject: Re: [Emc-developers] Eye candy is important - Titan got a new German 
friend - want that reaction for a LinuxCNC controller

Le jeu. 1 déc. 2022 à 16:47, Small Shop Concepts  a
écrit :

> I think it would be great if QtPyVCP were included in Linuxcnc. I'm not
> sure how you mean it would undermine qtvcp?  Isn't Linuxcnc stronger with
> more options for users?


Further, IIRC @cmorley, you're our UI API uniformization champion, aren't
you ? And I support that 1000% !
What could be better on this front than to bring the other modern VCP
toolkit to the table ? And another awesome chap like @TurBoss !


> I know JT also has been working on a config builder that is
> working really nicely and has added some features making setting up Mesa
> very simple and streamlined.
>

Absolutely ! I already told JT and said here that MesaCT repository surely
deserves to join the LinuxCNC organization 

___
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] Eye candy is important - Titan got a new German friend - want that reaction for a LinuxCNC controller

[Chris Morley]

The difference is free cad doesn't compete with anything in linuxcnc. Qtpycp 
does. If they wanted to be included in linuxcnc, then they would have been part 
of the project. They made a choice.
Otherwise as I said you are undermining the hard work of the devs that are 
active in our project.

Chris

Sent from my Galaxy



 Original message 
From: Steffen Moeller 
Date: 2022-11-30 9:35 a.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] Eye candy is important - Titan got a new German 
friend - want that reaction for a LinuxCNC controller


Am 29.11.2022 um 19:06 schrieb Chris Morley:
> Are you discussing an official linuxcnc release of ISOs?
So I hope.
> Are you suggesting including qtpyvcp on the ISO?
There are four Python modules missing in Debian to do so, from what I
have yet understood. But I feel motivated to help out, just locally
packaged oyaml.
> In my mind that undermines qtvcp which is actually part of linuxcnc.
> Full disclosure, qtvcp is project I started so I am slightly biased.

My motivation is to bring the best of Open Source CNC on Linux together
to help myself and others. And from what I hear and see, this includes
PyQtVCP. You may have a point for the minimal version of that .iso, but
for the full featured one it should be in, also FreeCAD and inkscape.

Steffen

>  Original message 
> From: Steffen Möller 
> Date: 2022-11-29 8:53 a.m. (GMT-08:00)
> To: LinuxCNC Dev Mailing List 
> Subject: [Emc-developers] Eye candy is important - Titan got a new German 
> friend - want that reaction for a LinuxCNC controller
>
> Hello,
>
> No need to watch this, really. Titan has a nice Heller machine and passes the 
> Sinumeric control
> https://youtu.be/zToKZtqQMIo?t=354
> with some excitement. I actually find LinuxCNC even nicer, especially for 
> what I saw from https://www.qtpyvcp.com/ .
>
> When we yesterday had this OpenMike session again, we had felt like there 
> should be four USB sticks prepared:
>a) for two distros - Bullseye (Debian stable) and Bookworm (Debian 
> testing, soon stable)
>b) in two flavours - minimalistic and fully-featured (including FreeCAD 
> and Inkscape to make a good impression on those who come from the other OS)
>
> Andy had some confidence (and I share that) that the generation of those .iso 
> files per se is not difficult. It was not immediately clear where the 
> generation of those .iso files should happen, but the builders maintained by 
> Sebastian are a likely target IMO.
>
> Question: Is there anybody out there who would like to work with me on a 
> description and implementation of what the fully-featured .ISO should like 
> alike? This would be Intel-only as a start, leaving everything for the RPi to 
> Raspbian for the time being.
>
> There are a couple of Python libraries still missing on Debian to get QtPyVCP 
> installed. This would likely be something for me to address.
>
> Best,
> Steffem
>
>
>
> ___
> 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 mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] Merge Strategy

[Chris Morley]

Yes that is an advantage in theory. though I think people are over stating that 
problem.
The eventual cost is, error prone, slow to happen merges that only a couple 
developers can/will do.
Hopefully we can gain a bunch more savvy developers and this would be a much 
smaller problem.

Chris

From: andy pugh 
Sent: November 30, 2022 12:11 PM
To: EMC developers 
Subject: Re: [Emc-developers] Merge Strategy

On Wed, 30 Nov 2022 at 12:04, Chris Morley 
wrote:

I presented my idea to see if anyone could show a fatal flaw of it so I
> appreciate the discussion/feedback.


I think the only advantage of our current strategy (and it's not a good
one) is that if things get forgotten then they will still be merged by
accident when someone merges their own work, so less stuff gets lost.

--
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] Merge Strategy

[Chris Morley]

We could possibly establish a "forgotten but still pressing PR"-committee that 
submitters can call when they (I mean, their patches) feel neglected?

Best,
Steffen

To be clear, I was discussing strategy of branch-to-branch merges not pull 
request merges.

Chris

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

Re: [Emc-developers] Merge Strategy

[Chris Morley]

Our current strategy has not been always right in the past.
I have occasionally had to fix merges after the fact because someone merged 
them wrong.
(People have occasionally had to fix my merge mistakes too.)
Which is not surprising considering the type of files I usually work on (XML).
I have had to wait for up merges to get needed work to master.
The conflicts you are talking of are probably because I put separate commits in 
each branch because I was tired of waiting.

Of course 2.9 to master will be easy for a while but the same problem will come 
back.
Even more so if the Debian inclusion gives us many more pull requests from non 
devs.

I just think that having only about 4 devs that actually do merges is not a 
good games plan.
I presented my idea to see if anyone could show a fatal flaw of it so I 
appreciate the discussion/feedback.
So far no fatal flaw, other then it's different.

But I also recognise I'm not convincing anyone so I guess I will try to let it 
go :)
But again thanks for the discussion, that was the most important part!

Chris

From: andy pugh 
Sent: November 30, 2022 10:24 AM
To: EMC developers 
Subject: Re: [Emc-developers] Merge Strategy

On Wed, 30 Nov 2022 at 07:38, Chris Morley 
wrote:

>
> The only solution, given our current strategy, is to wait/ask for someone
> else to fix it.
> This is the crux of the problem.


I think that our current merge-up strategy has been right in the past and
will be right again, but currently there are significant conflicts between
the tip of 2.8 and 2.9. These seem to be mainly docs and the fallout of me
merging 7i96S support "backwards".

I think we need a one-off effort to make sure that there aren't any
important bug fixes in 2.8 needed in 2.9 but in general I think that the
outstanding commits should be marked as merged (for housekeeping reasons)
but with the code remaining as the 2.9 version unless there is an obviously
necessary fix. I think that in general this is going to mean just git
checkout --ours conflicted.file but with a look at the commit
description to see if a fix (possibly one different from either existing
file) is needed.

Here is the conflict list.

Auto-merging src/hal/drivers/mesa-hostmot2/pins.c

CONFLICT (content): Merge conflict in src/hal/drivers/mesa-hostmot2/pins.c

Auto-merging src/hal/drivers/mesa-hostmot2/hostmot2.h

CONFLICT (content): Merge conflict in
src/hal/drivers/mesa-hostmot2/hostmot2.h

Auto-merging src/hal/drivers/mesa-hostmot2/hostmot2.c

CONFLICT (content): Merge conflict in
src/hal/drivers/mesa-hostmot2/hostmot2.c

Auto-merging src/hal/drivers/mesa-hostmot2/hm2_eth.c

Auto-merging src/emc/usr_intf/pncconf/private_data.py

CONFLICT (content): Merge conflict in
src/emc/usr_intf/pncconf/private_data.py

Auto-merging src/emc/usr_intf/pncconf/pncconf.py

CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/pncconf.py

Auto-merging src/emc/usr_intf/pncconf/build_HAL.py

CONFLICT (content): Merge conflict in src/emc/usr_intf/pncconf/build_HAL.py

Auto-merging src/emc/usr_intf/gmoccapy/release_notes.txt

CONFLICT (content): Merge conflict in
src/emc/usr_intf/gmoccapy/release_notes.txt

Auto-merging src/emc/usr_intf/gmoccapy/gmoccapy.py

Auto-merging src/emc/usr_intf/gmoccapy/getiniinfo.py

Auto-merging src/emc/usr_intf/emcrsh.cc

Auto-merging src/Makefile

Auto-merging share/qtvcp/panels/cam_align/cam_align_handler.py

CONFLICT (content): Merge conflict in
share/qtvcp/panels/cam_align/cam_align_handler.py

CONFLICT (modify/delete): docs/src/gui/gmoccapy.txt deleted in HEAD and
modified in 2.8. Version 2.8 of docs/src/gui/gmoccapy.txt left in tree.

CONFLICT (modify/delete): docs/src/getting-started/getting-linuxcnc_es.txt
deleted in HEAD and modified in 2.8. Version 2.8 of
docs/src/getting-started/getting-linuxcnc_es.txt left in tree.

CONFLICT (modify/delete): docs/src/getting-started/getting-linuxcnc.txt
deleted in HEAD and modified in 2.8. Version 2.8 of
docs/src/getting-started/getting-linuxcnc.txt left in tree.

CONFLICT (modify/delete): docs/src/getting-started/getting-linuxcnc-cn.txt
deleted in HEAD and modified in 2.8. Version 2.8 of
docs/src/getting-started/getting-linuxcnc-cn.txt left in tree.

Auto-merging docs/man/man9/hostmot2.9

CONFLICT (content): Merge conflict in docs/man/man9/hostmot2.9

Auto-merging docs/man/man9/hm2_eth.9

Auto-merging debian/changelog

CONFLICT (content): Merge conflict in debian/changelog

Auto-merging VERSION

CONFLICT (content): Merge conflict in VERSION

warning: inexact rename detection was skipped due to too many files.

warning: you may want to set your merge.renamelimit variable to at least
2086 and retry the command.

Automatic merge failed; fix conflicts and then commit the result.



pins.c, hostmot2.h, hostmot2.c, release_notes.txt, hostmot2.9, hm2_eth.9
changelog and VERSION should all be resolved by --ours.

That leaves pncconf private_data.py, pnconf.py builf_HAL.py from pncconf. I

Re: [Emc-developers] Merge Strategy

[Chris Morley]

From: Hans Unzner 
Sent: November 29, 2022 6:35 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] Merge Strategy

>>
>> Then email the folks who know more about the conflict and ask them to
>> merge their bugfix into 2.9.
>A problem I see here is if the person who introduced this change doesn't
>have push permissions to the repository to resolve the merge conflict by
>himself.
>What is the best solution to resolve it in this case?

The only solution, given our current strategy, is to wait/ask for someone else 
to fix it.
This is the crux of the problem.

Chris
___
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] Eye candy is important - Titan got a new German friend - want that reaction for a LinuxCNC controller

[Chris Morley]

Are you discussing an official linuxcnc release of ISOs? Are you suggesting 
including qtpyvcp on the ISO? In my mind that undermines qtvcp which is 
actually part of linuxcnc.
Full disclosure, qtvcp is project I started so I am slightly biased.

Chris



Sent from my Galaxy



 Original message 
From: Steffen Möller 
Date: 2022-11-29 8:53 a.m. (GMT-08:00)
To: LinuxCNC Dev Mailing List 
Subject: [Emc-developers] Eye candy is important - Titan got a new German 
friend - want that reaction for a LinuxCNC controller

Hello,

No need to watch this, really. Titan has a nice Heller machine and passes the 
Sinumeric control
https://youtu.be/zToKZtqQMIo?t=354
with some excitement. I actually find LinuxCNC even nicer, especially for what 
I saw from https://www.qtpyvcp.com/ .

When we yesterday had this OpenMike session again, we had felt like there 
should be four USB sticks prepared:
  a) for two distros - Bullseye (Debian stable) and Bookworm (Debian testing, 
soon stable)
  b) in two flavours - minimalistic and fully-featured (including FreeCAD and 
Inkscape to make a good impression on those who come from the other OS)

Andy had some confidence (and I share that) that the generation of those .iso 
files per se is not difficult. It was not immediately clear where the 
generation of those .iso files should happen, but the builders maintained by 
Sebastian are a likely target IMO.

Question: Is there anybody out there who would like to work with me on a 
description and implementation of what the fully-featured .ISO should like 
alike? This would be Intel-only as a start, leaving everything for the RPi to 
Raspbian for the time being.

There are a couple of Python libraries still missing on Debian to get QtPyVCP 
installed. This would likely be something for me to address.

Best,
Steffem



___
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 Strategy

[Chris Morley]

Strategy is just the agreed upon approach we use in the project. Currently our 
strategy is to merge up released branches up to master. In practice we almost 
always just merge up the last last release branch up to master.

See my answer to Seb for morexdetails of my reasoning of why I think we could 
do better using a different strategy, but the jest of it is there is never 
multiple merge conflicts and the person who knows the code would be doing the 
cherrypick or commit to the next branch.

Chris



 Original message 
From: Steffen Möller 
Date: 2022-11-28 8:54 a.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] Merge Strategy



> Gesendet: Montag, 28. November 2022 um 06:43 Uhr
> Von: "Chris Morley" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Merge Strategy
>
> Can you explain why merging up is better then cherry-picking or separate 
> commits?

@Seb explains this better, my short answer would be that it seems easier.

> Merge strategy should not change based on what should or should not be moved 
> forward.
> The strategy must be the same.

I may misunderstand the word "strategy".  The strategy I think is that every 
bug is fixed at its root. That strategy is the operationalized with the help of 
the assumption that if that root existed prior to 2.9 then the fix should also 
be performed on the branch that represents 2.9 and that if the master branch 
can pull from 2.9 then the fix gets fixed in the current version, too.

Now, I know that this is not always possible. The most trivial counter-example 
coming to my mind is a typo in the name of a pin. If a correction involves that 
changed pin name (or another part of an API change) then the mere pull is not 
sufficient to fix the bug. Extra insights are required. Also, a problem may 
refer to a function that was removed. But this does not interfere with the 
basic strategy to fix early and pull. Some un-pull-able change should likely 
then be in another branch like "2.9-release" that branches off from "2.9".

The benefit of merging up over a cherry-pick IMHO is that it looks like more 
robust. But that is more like a gut feeling than me knowing. If the 
cherry-patches go into 2.9 and the 2.9-only-fruits go into a 2.9-release branch 
then I think this looks mostly equivalent?

Best,
Steffen

> 
> From: Steffen Möller 
> Sent: November 28, 2022 1:04 AM
> To: emc-developers@lists.sourceforge.net 
> 
> Subject: Re: [Emc-developers] Merge Strategy
>
> IMHO we should continue with the merge-up and start thinking again when there 
> is a change to 2.9 that should not be forwarded.
> Best,
> Steffen
>
> > Gesendet: Sonntag, 27. November 2022 um 19:11 Uhr
> > Von: "Chris Morley" 
> > An: "EMC developers" 
> > Betreff: Re: [Emc-developers] Merge Strategy
> >
> > Well we will never agree on anything different if we never discuss it.
> > How about throwing out an opinion here?
> >
> > Chris
> > 
> > From: Hans Unzner 
> > Sent: November 27, 2022 10:54 AM
> > To: emc-developers@lists.sourceforge.net 
> > 
> > Subject: Re: [Emc-developers] Merge Strategy
> >
> > I agree that we should stick to "merge up" until we reach an agreement
> > to change this.
> >
> > Hans
> >
> > Am 23.11.22 um 22:42 schrieb Chris Morley:
> > > Ya it's always been hard to consistently get answers in our project.
> > > It just seems the nature of our group.
> > > Thanks for continuing to try.
> > >
> > > Currently strategy is to merge up, though you can cherry-pick up too, as 
> > > a merge later should understand this.
> > > But we rarely do anything with an older-then-current-release (I realize 
> > > that 2.8 is still sorta current)
> > >
> > > On the absence of an agreement, I am merging up 2.9 to master to keep in 
> > > sync.
> > >
> > > Chris
> > > 
> > > From: andy pugh 
> > > Sent: November 23, 2022 4:59 PM
> > > To: EMC developers 
> > > Subject: [Emc-developers] Merge Strategy
> > >
> > > On Tue, 8 Nov 2022 at 21:38, Chris Morley  
> > > wrote:
> > >> I wonder if we might discuss a different merging strategy for 2 9/master.
> > >> This would be relative to work being done in 2.9 for release.
> > >>
> > >> I suggest we don't merge up any more.
> > >> Cherry pick or a separate commit makes more sense to me.
> > >>
> > > Well, the discussion seems to have resulted in nothing happening,

Re: [Emc-developers] Merge Strategy

[Chris Morley]

Can you explain why merging up is better then cherry-picking or separate 
commits?
Merge strategy should not change based on what should or should not be moved 
forward.
The strategy must be the same.

Chris

From: Steffen Möller 
Sent: November 28, 2022 1:04 AM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] Merge Strategy

IMHO we should continue with the merge-up and start thinking again when there 
is a change to 2.9 that should not be forwarded.
Best,
Steffen

> Gesendet: Sonntag, 27. November 2022 um 19:11 Uhr
> Von: "Chris Morley" 
> An: "EMC developers" 
> Betreff: Re: [Emc-developers] Merge Strategy
>
> Well we will never agree on anything different if we never discuss it.
> How about throwing out an opinion here?
>
> Chris
> 
> From: Hans Unzner 
> Sent: November 27, 2022 10:54 AM
> To: emc-developers@lists.sourceforge.net 
> 
> Subject: Re: [Emc-developers] Merge Strategy
>
> I agree that we should stick to "merge up" until we reach an agreement
> to change this.
>
> Hans
>
> Am 23.11.22 um 22:42 schrieb Chris Morley:
> > Ya it's always been hard to consistently get answers in our project.
> > It just seems the nature of our group.
> > Thanks for continuing to try.
> >
> > Currently strategy is to merge up, though you can cherry-pick up too, as a 
> > merge later should understand this.
> > But we rarely do anything with an older-then-current-release (I realize 
> > that 2.8 is still sorta current)
> >
> > On the absence of an agreement, I am merging up 2.9 to master to keep in 
> > sync.
> >
> > Chris
> > ____
> > From: andy pugh 
> > Sent: November 23, 2022 4:59 PM
> > To: EMC developers 
> > Subject: [Emc-developers] Merge Strategy
> >
> > On Tue, 8 Nov 2022 at 21:38, Chris Morley  
> > wrote:
> >> I wonder if we might discuss a different merging strategy for 2 9/master.
> >> This would be relative to work being done in 2.9 for release.
> >>
> >> I suggest we don't merge up any more.
> >> Cherry pick or a separate commit makes more sense to me.
> >>
> > Well, the discussion seems to have resulted in nothing happening, and
> > some things in 2,8 that probably do belong in 2.9 and master.
> >
> > So what _is_ the current policy?
> >
> >
> > --
> > 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
>
> ___
> 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 Strategy

[Chris Morley]

Well we will never agree on anything different if we never discuss it.
How about throwing out an opinion here?

Chris

From: Hans Unzner 
Sent: November 27, 2022 10:54 AM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] Merge Strategy

I agree that we should stick to "merge up" until we reach an agreement
to change this.

Hans

Am 23.11.22 um 22:42 schrieb Chris Morley:
> Ya it's always been hard to consistently get answers in our project.
> It just seems the nature of our group.
> Thanks for continuing to try.
>
> Currently strategy is to merge up, though you can cherry-pick up too, as a 
> merge later should understand this.
> But we rarely do anything with an older-then-current-release (I realize that 
> 2.8 is still sorta current)
>
> On the absence of an agreement, I am merging up 2.9 to master to keep in sync.
>
> Chris
> 
> From: andy pugh 
> Sent: November 23, 2022 4:59 PM
> To: EMC developers 
> Subject: [Emc-developers] Merge Strategy
>
> On Tue, 8 Nov 2022 at 21:38, Chris Morley  wrote:
>> I wonder if we might discuss a different merging strategy for 2 9/master.
>> This would be relative to work being done in 2.9 for release.
>>
>> I suggest we don't merge up any more.
>> Cherry pick or a separate commit makes more sense to me.
>>
> Well, the discussion seems to have resulted in nothing happening, and
> some things in 2,8 that probably do belong in 2.9 and master.
>
> So what _is_ the current policy?
>
>
> --
> 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

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

Re: [Emc-developers] Next LinuxCNC video chat

[Chris Morley]

We were hardly zero tier.
My complaint is that if you didn't go to the video meeting that there seemed to 
be no way to find out what happened, nor a way to see the discussion after the 
fact.

That is what I meant by two tier.

IMHO the first order of business of the video meeting would be to figure out 
how to include people not there with reasonable effort. The nice thing about 
maillists and chats is that they are self documenting.

There is nothing wrong with having video chats from time to time. But I think 
you are using it to force (relatively) quick decisions rather then an 
alternative way to comunnicate.

You want to get something done in this project faster - then become a developer 
and do it.
We very seldom refuse to incorporate work that was been merged.
I found out pretty early that if I wanted to do work that I thought might be a 
problem then I would ty to discuss on the maillist. Sometimes people answered, 
sometimes not. If not, then I would merge my work when ready. Nothing like 
merged work to motivate people to get involved.

Obviously, there are some things that we need to agree on - such as merge 
strategy that we must discuss to change, but the time it takes to discuss on 
mail list is actually an advantage.

What we are really missing is a vision to converge on and a leader to see it 
through.
And more developers. But that is no guarantee either - mackinekit had those and 
has petered out it seems, unfortunately.

But now that I have a link, at least I can see the summary of what you were 
thinking/discussing.

Chris

From: Jérémie Tarot 
Sent: November 24, 2022 3:40 PM
To: EMC developers 
Subject: Re: [Emc-developers] Next LinuxCNC video chat

Le jeu. 24 nov. 2022 à 06:19, Chris Morley  a
écrit :

> How about a summary write up?
>

Andy has just pointed to them so won't double.


> We are making a two tier project if we continue like this.
>

At least that's some tiers !
Seeing our inability to discuss and decide lately, at least to support
and/or free Andy, if not to look forward and plan for the future, we almost
look like a zero tier no-org :'(
Hopefully some things will come out of it because written channels have
proven inoperative these days...

___
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] Next LinuxCNC video chat

[Chris Morley]

Thanks Andy.

Is this link recorded somewhere officially for reference?

Chris

From: andy pugh 
Sent: November 24, 2022 2:01 PM
To: EMC developers 
Subject: Re: [Emc-developers] Next LinuxCNC video chat

On Thu, 24 Nov 2022 at 05:19, Chris Morley  wrote:
>
> How about a summary write up?

There are some notes here:
https://docs.google.com/document/d/1aWMxBY8IbCYXFLFvjgqUXZ09inZp5u0r-pZcjeb2bWk/edit?usp=sharing

--
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] Next LinuxCNC video chat

[Chris Morley]

How about a summary write up?
We are making a two tier project if we continue like this.

From: Jérémie Tarot 
Sent: November 18, 2022 8:13 AM
To: EMC developers 
Subject: Re: [Emc-developers] Next LinuxCNC video chat

Le ven. 18 nov. 2022 à 03:51, Chris Morley  a
écrit :

> Are these videos available to view after the fact?
>


It would be nice indeed

___
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 Strategy

[Chris Morley]

Ya it's always been hard to consistently get answers in our project.
It just seems the nature of our group.
Thanks for continuing to try.

Currently strategy is to merge up, though you can cherry-pick up too, as a 
merge later should understand this.
But we rarely do anything with an older-then-current-release (I realize that 
2.8 is still sorta current)

On the absence of an agreement, I am merging up 2.9 to master to keep in sync.

Chris

From: andy pugh 
Sent: November 23, 2022 4:59 PM
To: EMC developers 
Subject: [Emc-developers] Merge Strategy

On Tue, 8 Nov 2022 at 21:38, Chris Morley  wrote:
>
> I wonder if we might discuss a different merging strategy for 2 9/master.
> This would be relative to work being done in 2.9 for release.
>
> I suggest we don't merge up any more.
> Cherry pick or a separate commit makes more sense to me.
>

Well, the discussion seems to have resulted in nothing happening, and
some things in 2,8 that probably do belong in 2.9 and master.

So what _is_ the current policy?


--
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] Next LinuxCNC video chat

[Chris Morley]

Are these videos available to view after the fact?

From: Petter Reinholdtsen 
Sent: November 17, 2022 9:02 AM
To: emc-developers@lists.sourceforge.net 
Cc: Jeff Epler 
Subject: Re: [Emc-developers] Next LinuxCNC video chat


Just a small reminder, this time with some key individual email
addresses on CC, as my initial email was not yet approved into the
mailing list.

[Petter Reinholdtsen 2022-11-11]
> The next LinuxCNC video chat is scheduled for 2022-11-28 19:00 UTC
> (19:00 London time, 20:00 Central Europe time).  Same location as last
> time:
>
>   https://meet.jit.si/LinuxCNC-meeting-november-2022

Please CC me on any replies, I am not subscribed to the list.

--
Happy hacking
Petter Reinholdtsen


___
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] 2.9-pre1

[Chris Morley]

Just so you at least hear a voice...

I hear what you are saying, I remember this has come up before but we never did 
get another build bot up and running that I know of. Single point of failure.

I'm sorry I can't help you. Is there other options for the future that you know 
of?

Is there any complete documentation of the process of releasing, so others 
could try to understand?

Chris
Sent from my Galaxy



 Original message 
From: andy pugh 
Date: 2022-11-09 5:16 p.m. (GMT-08:00)
To: EMC developers 
Subject: Re: [Emc-developers] 2.9-pre1

On Thu, 10 Nov 2022 at 00:14, Rod Webster  wrote:

> It's not useful to have RTAI in Bullseye as we don't have any debs for that
> platform.


Well, this comes back to a question I asked some time ago (which did not
get a single reply (30th Oct 18:15 GMT timestamp)). What _should_ we be
releasing 2.9 on?

Currently the LinuxCNC buildbot only builds for Buster- and the Debian
system is doing Bookworm+

 I have no control over the LinuxCNC buildbot and Seb (who does) has said
nothing on the question.

Basically the buildbot is integral to our current release process, and I
have no idea what is going on or what the plan is.

This is not a tenable position for a co-opted release manager to be in.

I can't do this by myself.

--
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] 2.9-pre1

[Chris Morley]

Thanks for chiming in.

I don't really think in practice multiple pull requests are  much more work. We 
generally stop releasing updates to any branch older then released, so you are 
only talking of two branches.

The no-conflicts-commits more then makes up for this.
It might be a different story if the project had 20 expert experienced devs to 
to all the merges, but even then I doubt it



Sent from my Galaxy



 Original message 
From: Hans Unzner 
Date: 2022-11-10 9:20 a.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] 2.9-pre1

Both strategies have their pros and cons I think.

Without merge up:
con: You have to create multiple pull requests to fix one issue --> more
work for both developer and reviewer and a bigger mess of PR's
pro: No merge conflicts resp. the developer can solve those himself

With merge up:
pro: Only one merge request per issue, bringing them all with one merge
into the upper branch
con: The person who does the merge may not know how to resolve the merge
conflicts


Am 09.11.22 um 15:56 schrieb Chris Morley:
> As the dev that must approve the request, you can send a comment:
>
> This looks like it needs to go in master too, "can you make another pull that 
> cherrypicks or commits this to master"
>
>
> Or if you are so inclined you could take this on for your self.
>
>
> So rather then you as the dev, having to figure out the merge conflicts of 
> all the conflicted code, the committer, who knows the code figures out the 
> conflicts only on his code.
>
>
> Sent from my Galaxy
>
>
>
>  Original message 
> From: andy pugh 
> Date: 2022-11-09 1:34 a.m. (GMT-08:00)
> To: EMC developers 
> Subject: Re: [Emc-developers] 2.9-pre1
>
> On Wed, 9 Nov 2022 at 01:49, Chris Morley 
> wrote:
>
>> But it really doesn't make sense.
>> That is my point.
>>
> So, we get a pull-request for a bug fix in 2.8.
>
> Who now decides whether it needs to be cherry-picked into 2.9 and 2.10? And
> who does that?
>
> --
> 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] 2.9-pre1

[Chris Morley]

Master is wide open now, things commited to master create conflicts in 2.9.
So as soon as master or 2.9 moves then the problem comes to the surface.



Sent from my Galaxy



 Original message 
From: Hans Unzner 
Date: 2022-11-09 12:12 a.m. (GMT-08:00)
To: EMC developers 
Subject: Re: [Emc-developers] 2.9-pre1

I would say the "degree of making sense" depends on how much the branches
are diverged. Currently I think it makes much sense, because 2.9 and master
are (almost) identical and the bug fixes for 2.9 are 100% applicable for
master.

Am Mi., 9. Nov. 2022 um 02:49 Uhr schrieb Chris Morley <
chrisinnana...@hotmail.com>:

> But it really doesn't make sense.
> That is my point.
>
>
>
> Sent from my Galaxy
>
>
>
>  Original message 
> From: andy pugh 
> Date: 2022-11-08 2:41 p.m. (GMT-08:00)
> To: EMC developers 
> Subject: Re: [Emc-developers] 2.9-pre1
>
> On Tue, 8 Nov 2022 at 21:38, Chris Morley 
> wrote:
>
> >
> > I suggest we don't merge up any more.
> > Cherry pick or a separate commit makes more sense to me.
>
>
> I think it makes sense for the GUIs between 2.8 and 2.9 because bug fixes
> for Python2 / Gtk2 are probably not correct for Py3 / Gtk3.
>
> Going forward I rather expect it to start making sense again, though.
>
> --
> 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

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

Re: [Emc-developers] 2.9-pre1

[Chris Morley]

As the dev that must approve the request, you can send a comment:

This looks like it needs to go in master too, "can you make another pull that 
cherrypicks or commits this to master"


Or if you are so inclined you could take this on for your self.


So rather then you as the dev, having to figure out the merge conflicts of all 
the conflicted code, the committer, who knows the code figures out the 
conflicts only on his code.


Sent from my Galaxy



 Original message 
From: andy pugh 
Date: 2022-11-09 1:34 a.m. (GMT-08:00)
To: EMC developers 
Subject: Re: [Emc-developers] 2.9-pre1

On Wed, 9 Nov 2022 at 01:49, Chris Morley 
wrote:

> But it really doesn't make sense.
> That is my point.
>

So, we get a pull-request for a bug fix in 2.8.

Who now decides whether it needs to be cherry-picked into 2.9 and 2.10? And
who does that?

--
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] 2.9-pre1

[Chris Morley]

But it really doesn't make sense.
That is my point.



Sent from my Galaxy



 Original message 
From: andy pugh 
Date: 2022-11-08 2:41 p.m. (GMT-08:00)
To: EMC developers 
Subject: Re: [Emc-developers] 2.9-pre1

On Tue, 8 Nov 2022 at 21:38, Chris Morley 
wrote:

>
> I suggest we don't merge up any more.
> Cherry pick or a separate commit makes more sense to me.


I think it makes sense for the GUIs between 2.8 and 2.9 because bug fixes
for Python2 / Gtk2 are probably not correct for Py3 / Gtk3.

Going forward I rather expect it to start making sense again, though.

--
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] 2.9-pre1

[Chris Morley]

I wonder if we might discuss a different merging strategy for 2 9/master.
This would be relative to work being done in 2.9 for release.

I suggest we don't merge up any more.
Cherry pick or a separate commit makes more sense to me.

Chris



Sent from my Galaxy



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

Re: [Emc-developers] Problem with PNCConf and dpll

[Chris Morley]

Yes it's possible to add a dpll flag to pncconf.
I am currently busy working to add this at the moment.
Hopefully the weekend looks better.

Thank you.
Chris

From: Alan Condit 
Sent: October 30, 2022 6:11 PM
To: emc-developers 
Subject: [Emc-developers] Problem with PNCConf and dpll

Chris Morley,
It seems to me that there is a problem with PNCConf in master. It uses dpll
for watchdog timer on the Mesa 5i25 but the 5i25 firmware doesn’t support
dpll. Is there a way to change that so that pncconf tests to see if the
user is actually using firmware that supports dpll? Peter said that the pci
boards generally don’t support dpll.

Thanks,
Alan

___
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] Merging 2.8 into Master

[Chris Morley]

Probably the fact we usually work on different code, reveals the different 
ideas.
Components and motion for instance don't change much between branches. Gui code 
and now docs/translations change drastically.



Sent from my Galaxy



 Original message 
From: andy pugh 
Date: 2022-09-24 7:27 a.m. (GMT-08:00)
To: EMC developers 
Subject: Re: [Emc-developers] Merging 2.8 into Master

On Fri, 23 Sept 2022 at 08:14, Hans Unzner  wrote:

> If I do that and use "ours" on all conflicts, I get only three changed
> files. One only with whitespace changes.


git merge -s ours 2.8
git push --dry-run
git log -p da99e19495..f0ad48afa1 > merge.txt

Gives: https://paste.debian.net/1254868/

Which seems to include a lot of changes that I _think_ are already
handled in master?

--
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] Merging 2.8 into Master

[Chris Morley]

While 2.8 should only get bug fixes, master gets developed so 2.8 and master 
can diverge sign8ficantly and in fact should.

It's the divergence that complicate merges.

It's easy to cherry pick a 2.8 fix that will merge easily to master. This also 
avoid having to merge others work that I wouldn't know the proper changes.

For work that doesn't merge easily ...then separate commits to each branch is 
much easier.



Sent from my Galaxy



 Original message 
From: andy pugh 
Date: 2022-09-25 10:23 a.m. (GMT-08:00)
To: EMC developers 
Subject: Re: [Emc-developers] Merging 2.8 into Master

On Fri, 23 Sept 2022 at 01:50, Chris Morley  wrote:

> We could avoid any merge problems by changing our policy to not merge stable 
> branches into master.
> It seems to me that cherry picking or preparing separate commits is far 
> easier and less error prone then what we are doing.

In theory the stable branch should only get bug-fixes, and these
should always be not only safe but also required upstream.

So the question is more, "why have we got things in 2.8 that do not
belong in master"

There is a difference at the moment as I have introduced a reduced
version of the 7i96S support into 2.8.

--
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] Merging 2.8 into Master

[Chris Morley]

I'm disappointed that nobody will discuss this merging strategy proposal .  I 
certainly may be wrong on this iidea,  but it seems obvious to me, so would 
like to consider other's ideas ans make sure I didn't miss something.



Sent from my Galaxy



 Original message 
From: Chris Morley 
Date: 2022-09-22 6:35 p.m. (GMT-08:00)
To: EMC developers 
Subject: Re: [Emc-developers] Merging 2.8 into Master

Sorry I don't understand what you mean.
I understand you wouldn't 'blindly' merge things.
I am suggesting we, as a project should stop 'up' merging released branches.

Chris

From: andy pugh 
Sent: September 23, 2022 12:57 AM
To: EMC developers 
Subject: Re: [Emc-developers] Merging 2.8 into Master

On Fri, 23 Sept 2022 at 01:50, Chris Morley 
wrote:

> At the risk of starting a discussion...

We could avoid any merge problems by changing our policy to not merge
> stable branches into master.
> It seems to me that cherry picking or preparing separate commits is far
> easier and less error prone then what we are doing.
>

Which is why I didn't just blindly do it. I was just doing this to see what
would happen, and what would be the effect.

--
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] Merging 2.8 into Master

[Chris Morley]

Sorry I don't understand what you mean.
I understand you wouldn't 'blindly' merge things.
I am suggesting we, as a project should stop 'up' merging released branches.

Chris

From: andy pugh 
Sent: September 23, 2022 12:57 AM
To: EMC developers 
Subject: Re: [Emc-developers] Merging 2.8 into Master

On Fri, 23 Sept 2022 at 01:50, Chris Morley 
wrote:

> At the risk of starting a discussion...

We could avoid any merge problems by changing our policy to not merge
> stable branches into master.
> It seems to me that cherry picking or preparing separate commits is far
> easier and less error prone then what we are doing.
>

Which is why I didn't just blindly do it. I was just doing this to see what
would happen, and what would be the effect.

--
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] Time to split 2.9 and master?

[Chris Morley]

Hey Andy, it may be helpful to new devs if you could go over the rough process 
of release candidate to officially release.

Chris

From: andy pugh 
Sent: September 21, 2022 3:45 PM
To: EMC developers 
Subject: Re: [Emc-developers] Time to split 2.9 and master?

On Wed, 21 Sept 2022 at 15:05, Chris Morley 
wrote:

> I think we should make the branch now. Making the branch does not preclude
> doing finishing work in the branch.


Indeed, it just makes "master" back into more of a testing playground.

--
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] Merging 2.8 into Master

[Chris Morley]

At the risk of starting a discussion...
We could avoid any merge problems by changing our policy to not merge stable 
branches into master.
It seems to me that cherry picking or preparing separate commits is far easier 
and less error prone then what we are doing.

Chris


From: andy pugh 
Sent: September 22, 2022 9:54 PM
To: EMC developers 
Subject: [Emc-developers] Merging 2.8 into Master

I just tried to (locally) merge 2.8 into Master. I decided to use the
"ours" strategy so that nothing actually changed, all I wanted to do was
mark them as merged, without changing anything,

Looking at the dry-run patch, though, quite a lot seemed to change, though
comparing the patches to the current master on github, most of the changes
seemed to already be included.

So I am puzzled. Especially as Hans merged on the 16th September.

Is there anything in 2.8 that _should_ be merged up to Master?

--
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] Time to split 2.9 and master?

[Chris Morley]

I think we should make the branch now. Making the branch does not preclude 
doing finishing work in the branch.

Cheis



Sent from my Galaxy



 Original message 
From: Alec Ari via Emc-developers 
Date: 2022-09-20 9:48 p.m. (GMT-08:00)
To: Alec Ari via Emc-developers 
Cc: Alec Ari 
Subject: Re: [Emc-developers] Time to split 2.9 and master?

Ah, it's already fixed:

https://github.com/LinuxCNC/linuxcnc/commit/9471c059d133f7d14363f6a7cdcf87a4de4666e6

On Wednesday, September 21, 2022 at 03:55:44 AM UTC, Alec Ari via 
Emc-developers  wrote:





I think fixing the SIGFPE (signal 8 error, floating point exception) should be 
fixed as well prior to the branch point.

Can RTAI be a milestone before the final 2.9 release btw?

Thanks,

Alec






On Wednesday, September 21, 2022 at 02:21:16 AM UTC, Phill Carter 
 wrote:







> On 21 Sep 2022, at 6:59 am, andy pugh  wrote:
>
> Is it time to split 2.9 off as a stable-ish branch with a 2.9.0~pre0 tag?

I have some plasmac work that I would like to push before that happens. It 
should be completed by the end of this month.

I also have a question regarding packaging. Is there any good reason that we 
have a separate "-dev" package ?

Cheers, Phill


> --
> 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


___
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] Possible 2.8.4 release this weekend

[Chris Morley]

Ahh perfect. Thanks.
And thanks for managing the updates.

Chris

From: andy pugh 
Sent: September 17, 2022 11:31 PM
To: EMC developers 
Subject: Re: [Emc-developers] Possible 2.8.4 release this weekend

On Sat, 17 Sept 2022 at 22:16, Chris Morley  wrote:
>
> Thanks for the heads up Andy. I've lost track ..did the pncconf update for 
> the card get added too?

https://github.com/LinuxCNC/linuxcnc/commit/674b9319518eda392bd7f625bc0410b50043e9ed

--
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] Possible 2.8.4 release this weekend

[Chris Morley]

Thanks for the heads up Andy. I've lost track ..did the pncconf update for the 
card get added too?



Sent from my Galaxy



 Original message 
From: Hans Unzner 
Date: 2022-09-17 12:54 p.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] Possible 2.8.4 release this weekend



Am 17.09.22 um 10:39 schrieb andy pugh:
> I think that the pieces are in place for a 2.8.4 release, mainly to
> add 7i96S support as one of the few cards currently available)
>
> Does anyone have any opinions on this matter?
>
Yes I think so too. Go ahead 
And when you update the version number, please also update the
gmoccapy/release_notes.txt.
Thanks!

Hans

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

Re: [Emc-developers] PYVCP Long Term Support

[Chris Morley]

Ok python3 starts with 2.9
You are safe :)


From: Tom Eagan 
Sent: September 14, 2022 1:41 AM
To: EMC developers 
Subject: Re: [Emc-developers] PYVCP Long Term Support

Currently 2.8.2, recompiled with larger HAL_SIZE.

Thanks,
Tom Eagan
Lead Engineer | INTEGRIS Engineering | 
www.Integrisgp.com<http://www.Integrisgp.com>
office: 309-245-1589 | mobile: 309-696-6743 | tom.ea...@integrisgp.com

From: Chris Morley 
Sent: Tuesday, September 13, 2022 8:37:51 PM
To: EMC developers 
Subject: Re: [Emc-developers] PYVCP Long Term Support

Not sure what version of linuxcnc you are currently using but the big change is 
using python3 instead of python2.
For PyVCP  - this should be transparent anyways.

Chris


From: Tom Eagan 
Sent: September 14, 2022 1:16 AM
To: EMC developers 
Subject: Re: [Emc-developers] PYVCP Long Term Support

Thank you very much for your answers, I’ll move forward with that information.

Thanks,
Tom Eagan
Lead Engineer | INTEGRIS Engineering | 
www.Integrisgp.com<http://www.Integrisgp.com>
office: 309-245-1589 | mobile: 309-696-6743 | tom.ea...@integrisgp.com
____
From: Chris Morley 
Sent: Tuesday, September 13, 2022 8:13:04 PM
To: EMC developers 
Subject: Re: [Emc-developers] PYVCP Long Term Support

The are no plans that I am aware of or ever heard of not supporting pyvcp, 
gladevcp or qtvcp.
Each has it's place.

Chris


From: Tom Eagan 
Sent: September 13, 2022 1:23 PM
To: emc-developers@lists.sourceforge.net 
Subject: [Emc-developers] PYVCP Long Term Support

Hello LinuxCNC Developers -

I've seen posts that indicate that GladeVCP may not have future support, and I 
was wondering what the future status is for PYVCP. Will it continue to be 
supported? I have a rather large UI built with PYVCP, and am hoping I don't 
have to redo it in something else.

Thanks, Tom Eagan




Notice of Confidentiality: This email message and any attachments are intended 
only for the use of the individual or entity to which it is addressed, and may 
contain information that is privileged, confidential and exempt from disclosure 
under applicable law. If you are not the intended recipient, any dissemination, 
distribution or copying of this communication is strictly prohibited and may be 
unlawful. If you have received this communication in error, please notify us 
immediately by reply email and delete and/or destroy all copies of the original 
message and attachments hereto. Email sent to or from INTEGRIS Group LLC may be 
retained as required by law or regulations.

___
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




Notice of Confidentiality: This email message and any attachments are intended 
only for the use of the individual or entity to which it is addressed, and may 
contain information that is privileged, confidential and exempt from disclosure 
under applicable law. If you are not the intended recipient, any dissemination, 
distribution or copying of this communication is strictly prohibited and may be 
unlawful. If you have received this communication in error, please notify us 
immediately by reply email and delete and/or destroy all copies of the original 
message and attachments hereto. Email sent to or from INTEGRIS Group LLC may be 
retained as required by law or regulations.

___
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




Notice of Confidentiality: This email message and any attachments are intended 
only for the use of the individual or entity to which it is addressed, and may 
contain information that is privileged, confidential and exempt from disclosure 
under applicable law. If you are not the intended recipient, any dissemination, 
distribution or copying of this communication is strictly prohibited and may be 
unlawful. If you have received this communication in error, please notify us 
immediately by reply email and delete and/or destroy all copies of the original 
message and attachments hereto. Email sent to or from INTEGRIS Group LLC may be 
retained as required by law or regulations.

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

Re: [Emc-developers] PYVCP Long Term Support

[Chris Morley]

Not sure what version of linuxcnc you are currently using but the big change is 
using python3 instead of python2.
For PyVCP  - this should be transparent anyways.

Chris


From: Tom Eagan 
Sent: September 14, 2022 1:16 AM
To: EMC developers 
Subject: Re: [Emc-developers] PYVCP Long Term Support

Thank you very much for your answers, I’ll move forward with that information.

Thanks,
Tom Eagan
Lead Engineer | INTEGRIS Engineering | 
www.Integrisgp.com<http://www.Integrisgp.com>
office: 309-245-1589 | mobile: 309-696-6743 | tom.ea...@integrisgp.com

From: Chris Morley 
Sent: Tuesday, September 13, 2022 8:13:04 PM
To: EMC developers 
Subject: Re: [Emc-developers] PYVCP Long Term Support

The are no plans that I am aware of or ever heard of not supporting pyvcp, 
gladevcp or qtvcp.
Each has it's place.

Chris


From: Tom Eagan 
Sent: September 13, 2022 1:23 PM
To: emc-developers@lists.sourceforge.net 
Subject: [Emc-developers] PYVCP Long Term Support

Hello LinuxCNC Developers -

I've seen posts that indicate that GladeVCP may not have future support, and I 
was wondering what the future status is for PYVCP. Will it continue to be 
supported? I have a rather large UI built with PYVCP, and am hoping I don't 
have to redo it in something else.

Thanks, Tom Eagan




Notice of Confidentiality: This email message and any attachments are intended 
only for the use of the individual or entity to which it is addressed, and may 
contain information that is privileged, confidential and exempt from disclosure 
under applicable law. If you are not the intended recipient, any dissemination, 
distribution or copying of this communication is strictly prohibited and may be 
unlawful. If you have received this communication in error, please notify us 
immediately by reply email and delete and/or destroy all copies of the original 
message and attachments hereto. Email sent to or from INTEGRIS Group LLC may be 
retained as required by law or regulations.

___
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




Notice of Confidentiality: This email message and any attachments are intended 
only for the use of the individual or entity to which it is addressed, and may 
contain information that is privileged, confidential and exempt from disclosure 
under applicable law. If you are not the intended recipient, any dissemination, 
distribution or copying of this communication is strictly prohibited and may be 
unlawful. If you have received this communication in error, please notify us 
immediately by reply email and delete and/or destroy all copies of the original 
message and attachments hereto. Email sent to or from INTEGRIS Group LLC may be 
retained as required by law or regulations.

___
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] PYVCP Long Term Support

[Chris Morley]

The are no plans that I am aware of or ever heard of not supporting pyvcp, 
gladevcp or qtvcp.
Each has it's place.

Chris


From: Tom Eagan 
Sent: September 13, 2022 1:23 PM
To: emc-developers@lists.sourceforge.net 
Subject: [Emc-developers] PYVCP Long Term Support

Hello LinuxCNC Developers -

I've seen posts that indicate that GladeVCP may not have future support, and I 
was wondering what the future status is for PYVCP. Will it continue to be 
supported? I have a rather large UI built with PYVCP, and am hoping I don't 
have to redo it in something else.

Thanks, Tom Eagan




Notice of Confidentiality: This email message and any attachments are intended 
only for the use of the individual or entity to which it is addressed, and may 
contain information that is privileged, confidential and exempt from disclosure 
under applicable law. If you are not the intended recipient, any dissemination, 
distribution or copying of this communication is strictly prohibited and may be 
unlawful. If you have received this communication in error, please notify us 
immediately by reply email and delete and/or destroy all copies of the original 
message and attachments hereto. Email sent to or from INTEGRIS Group LLC may be 
retained as required by law or regulations.

___
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] lack of camera revisited.

[Chris Morley]

Thats great news Gene - you had me stumped.

I also wanted to say that the buttons on the top, require INI entries to do 
anything.
Something like this (but can be any legal gcode - semi-colons separate 
commands):

[MDI_COMMAND_LIST]
MDI_COMMAND = G10 L20 P0 Z0,Zero\nUser\nOrigin
MDI_COMMAND = G0 Z25;X0 Y0;Z0,Goto\nUser\nOrigin

In this case it also changes the text of the button.
You can change or delete the comma-and-text  part if you are happy with the 
default text.

There is a adjustable circle, adjustable angled crosshair and digital zoom 
available using the mouse/buttons

I hope it works well for you.
Chris

From: gene heskett 
Sent: September 9, 2022 2:54 AM
To: EMC Developers 
Subject: [Emc-developers] lack of camera revisited.

Greetings Chris M.;

The camera failures I've been posting were from an ssh -Y login, which
apparently is part
of the trouble.  Out to mow my jungle today, I stepped into the garage
and logged in from its own screen.

And it instantly worked!! So now I need to find my mount, which is part
of the spindle lock, mount the camera,
and see it I can calibrate it.

Thank you very much. I should have checked for that a week ago, so my
apologies for the noise.

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] cam align

[Chris Morley]

Hi Gene.
I actually see no apparent show stoppers.
The Desktop Notify error is weird but seems to not stop anything.
It just seems not to embed.


Could your try the sim sim/axis/qtvcp/qtvcp_tabs sample.

It should embed a cam window too.
also is the new tab window completely plain or is there text?

Chris


From: gene heskett 
Sent: September 5, 2022 1:21 AM
To: EMC developers 
Subject: [Emc-developers] cam align

Gretibgs all;

I se some debugging has been turned on so it not a showstopper on my g0704.

The camera tab is created, but empty.

The terminal its launched from now contains some debugging info that may
be useful:

halcmd loadusr -Wn qtvcp_embed qtvcp -d -c qtvcp_embed -x {XID} cam_align
[False]
Waiting for component 'qtvcp_embed' to become
ready[QTvcp.QTVCP.LIB.SYS_NOTIFY][WARNING]
Desktop Notify not available:: org.freedesktop.DBus.Error.NoReply: Did
not receive a reply. Possible causes include: the remote application did
not send a reply, the message bus security policy blocked the reply, the
reply timeout expired, or the network connection was broken.
(sys_notify.py:71)
Namespace Gst not available
[QTvcp.QTVCP.LIB.AUDIO_PLAYER][WARNING]  audio alerts - Is
python3-gst1.0 installed? (audio_player.py:37)
.[QTvcp][INFO]  Logging to: /home/gene/qtvcp.log (logger.py:67)
[QTvcp][INFO]  Base log level set to: 10 (logger.py:68)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  BASEPATH cam_align (qt_pstat.py:86)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for handler file in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align_handler.py
(qt_pstat.py:96)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for default handler file in:
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qt_pstat.py:102)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using DEFAULT handler file path:
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qt_pstat.py:105)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.ui (qt_pstat.py:123)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in:
/usr/share/qtvcp/panels/cam_align/cam_align.ui (qt_pstat.py:128)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using DEFAULT ui file from:
/usr/share/qtvcp/panels/cam_align/cam_align.ui (qt_pstat.py:130)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.qss (qt_pstat.py:160)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in:
/usr/share/qtvcp/panels/cam_align/cam_align.qss (qt_pstat.py:165)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No qss file found. (qt_pstat.py:171)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.qrc (qt_pstat.py:182)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in:
/usr/share/qtvcp/panels/cam_align/cam_align.qrc (qt_pstat.py:188)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No qrc file found. (qt_pstat.py:195)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for resources.py in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/qtvcp/panels/resources.py
(qt_pstat.py:205)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No resources.py file found, no QRC file to
compile one from. (qt_pstat.py:216)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align/languages/cam_align_en.qm
(qt_pstat.py:223)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in:
/usr/share/qtvcp/screens/cam_align/languages/cam_align_en.qm
(qt_pstat.py:228)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using no translations, default system
locale is: en (qt_pstat.py:233)
[QTvcp][INFO]  Building A VCP Panel with: Python 3 (qtvcp:215)
[QTvcp][INFO]  No handler file specified - using:
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qtvcp:218)
[QTvcp.QTVCP.QT_MAKEGUI][INFO]  Qsettings file path:
/home/gene/.config/QtVcp/cam_align.conf (qt_makegui.py:97)
[QTvcp][DEBUG]  Loading the handler file. (qtvcp:276)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Adding import dir:
/usr/share/qtvcp/panels/cam_align (qt_makegui.py:290)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Module 'cam_align_handler' imported OK
(qt_makegui.py:301)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Module 'cam_align_handler' :
'get_handlers' function found. (qt_makegui.py:307)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Registering handlers in module
cam_align_handler object  (qt_makegui.py:317)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Register callback 'call_user_command_'
(qt_makegui.py:326)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Register callback 'initialized__'
(qt_makegui.py:326)
[QTvcp][DEBUG]  Adding the key events filter. (qtvcp:286)
[QTvcp.QTVCP.QT_MAKEGUI][INFO]  No resource file to load: None
(qt_makegui.py:192)
.[QTvcp.QTVCP.QT_MAKEPINS][DEBUG]  QTVCP: Parsing for HAL widgets.
(qt_makepins.py:114)
[QTvcp][DEBUG]  Calling the handler file's 

Re: [Emc-developers] Debian package - what is the future?

[Chris Morley]

I'm not sure you could say it adds _no_ value - the code is compiled and tested 
by the buildbot.
Just not on the target you wish yet. - not perfect but still lots of goodness.

I personally don't see how we could have a good release candidate anywhere soon 
(depends what you mean soon of course - Andy implied weeks or the end of the 
year recently)
I got basically no response on my discussion on it here on the maillist and I 
see no action towards it.
We have run out of developers/developers time I think.

But I was more wondering if anyone had thought through the logistics of dealing 
with another parallel release and potentially many(?) more users.
I may be making a big deal out of nothing but I thought I'd ask others thoughts.

Chris

From: Rod Webster 
Sent: September 4, 2022 9:27 PM
To: EMC developers 
Subject: Re: [Emc-developers] Debian package - what is the future?

What has been overlooked  so far is that there is still no buildbot version
for 2.9 on Bullseye so its increasingly difficult to deploy Linuxcnc on
newer hardware that requires say 5.10 kernel and higher. Buildbot is a long
way behind current kernel versions.


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

Re: [Emc-developers] Debian package - what is the future?

[Chris Morley]

Thank you for the explanation.
It sounds to me we will likely/potentially have 3 or 4 versions to maintain.
buildbot debs release version (for early bugfix users)
Debian version that may or may not be up to date with the buildbot.
Master version for development and traditionally daily use by early adopters.

I'm just thinking aloud about how to help people and fix bugs.
It's already a bit of a pain with installed vrs compiled of say two different 
versions.
Add a Debian version that might be in between 

I guess I hope we keep the Debian version in close lock step with the buildbot 
version.
I am glad to hear we can update Debian package we ever we need to. I would 
guess the time to go
from pushed fix to Debian update would be quite some time though.

Chris

From: Sebastian Kuzminsky 
Sent: September 4, 2022 6:00 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] Debian package - what is the future?

On 9/4/22 10:36, Sebastian Kuzminsky wrote:
> There are currently four ways to get pre-built debs of linuxcnc:
>
> 1. debian.org
>
> 2. buildbot
>
> 3. www.linuxcnc.org
>
> 4. github "artifacts"

I forgot to mention another important difference between the debian.org
debs and the buildbot debs:

The buildbot builds debs from every commit that passes our tests, so the
buildbot debs are very up to date.  The debian.org debs are prepared by
a human, so they get updated much less often.


--
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

[Emc-developers] Debian package - what is the future?

[Chris Morley]

I see the action with Debian package.
I hope that gets us some more exposure and more develops/users.

I did wonder what that means for the project as far as maintaining versions.
How are bug fixes addressed with Debian packages after (Debian) release?

Will Debian users be directed to the forum or github for issues?

Will it end up we have a current buildbot released version, current Debian 
version and master version?

Will having Debian force us on a time schedule?
What happens if we are not on time?

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

Re: [Emc-developers] Gremlin preview offset lag issue

[Chris Morley]

Just so you get a response...
I will try to find some time this weekend to at least confirm your findings.

Thanks for bring it up.

Chris

From: Thaddeus Waldner 
Sent: August 24, 2022 2:29 AM
To: EMC developers 
Subject: [Emc-developers] Gremlin preview offset lag issue

Hi

I'm working on a custom user interface based on gscreen. Part of it involves 
adjusting/fine-tuning axis offsets via a small MPG, and watching the preview 
move in response. I have the mpg moving a spinbutton that contains the axis 
offset. After the user stops twiddling the mpg for a reasonable amount of time, 
I issue a linuxcnc MDI G10L2P1 with the spinbutton value for axis offsets. 
Finally, I refresh the gremlin by calling gremlin.reloadfile(None).

This has the effect of moving the workpiece origin marker to the current offset 
position, and moving the gcode preview to the *previous* offset position. Upon 
running the program, the live plot correctly plots the path at the new offset.

After struggling with this for a while, I finally got it to work as I want by 
issuing the G10 MDI command twice in succession. This caused both the workpiece 
origin markers and the gcode preveiew to move to the new offset.

This appears to be a bug in gremlin.

___
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] looks like I need a python3 patch

[Chris Morley]

Unfortunately, I can not see an obvious clue.
Is this running on a raspberry pi?
The desktop notify error is probably from that, and posibly why there is a big 
delay.
I am stumped at this point.

Chris

From: gene heskett 
Sent: August 22, 2022 3:22 AM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] looks like I need a python3 patch

On 8/21/22 00:34, Chris Morley wrote:
> [QTvcp.QTVCP.QT_MAKEPINS][INFO]  QTVCP: Found external qtvcp
> loadusr panel to instantiate (qt_makepins.py:87)
>
> This indicates that you didn't get the code changes I added - maybe it didn't 
> get through the  buildbot yet.
>
> Chris
Updated at 23:30, now have a long delay, and a camalign tab, but no
camera. Blank white screen there.

konsole trace:
halcmd loadusr -Wn qtvcp_embed qtvcp -d -c qtvcp_embed -x {XID} cam_align
[False]
Waiting for component 'qtvcp_embed' to become
ready...[QTvcp.QTVCP.LIB.SYS_NOTIFY][WARNING]
Desktop Notify not available:: org.freedesktop.DBus.Error.NoReply: Did
not receive a reply. Possible causes include: the remote application did
not send a reply, the message bus security policy blocked the reply, the
reply timeout expired, or the network connection was broken.
(sys_notify.py:71)
Namespace Gst not available
[QTvcp.QTVCP.LIB.AUDIO_PLAYER][WARNING]  audio alerts - Is
python3-gst1.0 installed? (audio_player.py:37)
..[QTvcp][INFO]  Logging to: /home/gene/qtvcp.log (logger.py:67)
[QTvcp][INFO]  Base log level set to: 10 (logger.py:68)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  BASEPATH cam_align (qt_pstat.py:86)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for handler file in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align_handler.py
(qt_pstat.py:96)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for default handler file in:
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qt_pstat.py:102)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using DEFAULT handler file path:
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qt_pstat.py:105)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.ui (qt_pstat.py:119)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in:
/usr/share/qtvcp/panels/cam_align/cam_align.ui (qt_pstat.py:124)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using DEFAULT ui file from:
/usr/share/qtvcp/panels/cam_align/cam_align.ui (qt_pstat.py:126)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.qss (qt_pstat.py:151)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in:
/usr/share/qtvcp/panels/cam_align/cam_align.qss (qt_pstat.py:156)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No qss file found. (qt_pstat.py:162)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.qrc (qt_pstat.py:173)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in:
/usr/share/qtvcp/panels/cam_align/cam_align.qrc (qt_pstat.py:179)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No qrc file found. (qt_pstat.py:186)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for resources.py in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/qtvcp/panels/resources.py
(qt_pstat.py:196)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No resources.py file found, no QRC file to
compile one from. (qt_pstat.py:207)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align/languages/cam_align_en.qm
(qt_pstat.py:214)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in:
/usr/share/qtvcp/screens/cam_align/languages/cam_align_en.qm
(qt_pstat.py:219)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using no translations, default system
locale is: en (qt_pstat.py:224)
[QTvcp][INFO]  Building A VCP Panel with: Python 3 (qtvcp:215)
[QTvcp][INFO]  No handler file specified - using:
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qtvcp:218)
.[QTvcp.QTVCP.QT_MAKEGUI][INFO]  Qsettings file path:
/home/gene/.config/QtVcp/cam_align.conf (qt_makegui.py:97)
[QTvcp][DEBUG]  Loading the handler file. (qtvcp:276)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Adding import dir:
/usr/share/qtvcp/panels/cam_align (qt_makegui.py:290)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Module 'cam_align_handler' imported OK
(qt_makegui.py:301)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Module 'cam_align_handler' :
'get_handlers' function found. (qt_makegui.py:307)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Registering handlers in module
cam_align_handler object  (qt_makegui.py:317)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Register callback 'call_user_command_'
(qt_makegui.py:326)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Register callback 'initialized__'
(qt_makegui.py:326)
[QTvcp][DEBUG]  Adding the key events filter. (qtvcp:286)
[QTvcp.QTVCP.QT_MAKEGUI][INFO]  No resour

Re: [Emc-developers] looks like I need a python3 patch

[Chris Morley]

[QTvcp.QTVCP.QT_MAKEPINS][INFO]  QTVCP: Found external qtvcp
loadusr panel to instantiate (qt_makepins.py:87)

This indicates that you didn't get the code changes I added - maybe it didn't 
get through the  buildbot yet.

Chris

From: gene heskett 
Sent: August 21, 2022 2:46 AM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] looks like I need a python3 patch

On 8/20/22 15:25, gene heskett wrote:
> On 8/20/22 15:05, Chris Morley wrote:
>> Gene
>>
>> I looked at the errors and found the problem in the code.
>> Thanks for posting the error messages.
>> I guess I broke it a month ago or so.
>> I have pushed a fix to master.
>> Sorry about that.
>>
>> Chris
>
> I appreciate the effort Chris, but historically its been work for a
> week, fail for a year. Am I the only
> one who wants to use a camera for an edge finder? Or to align the
> machine to a part? Somewhat
> difficult since the post on my go704 is leaning like the tower of
> Pisa. I bought a circular square and
> will see if that will help me fix it. But I keep miss-laying my round
> tuit.
>
> I'll update around the evening and see if it works then, and advise.
> Thanks a bunch.

No luck. Even after I restored the EMBED_TAB_POSITION = ntb_preview.
Terninal trace:

alcmd loadusr -Wn qtvcp_embed qtvcp -d -c qtvcp_embed -x {XID} cam_align
[False]
Waiting for component 'qtvcp_embed' to become
ready...[QTvcp.QTVCP.LIB.SYS_NOTIFY][WARNING]
Desktop Notify not available:: org.freedesktop.DBus.Error.NoReply: Did
not receive a reply. Possible causes include: the remote application did
not send a reply, the message bus security policy blocked the reply, the
reply timeout expired, or the network connection was broken.
(sys_notify.py:71)
Namespace Gst not available
[QTvcp.QTVCP.LIB.AUDIO_PLAYER][WARNING]  audio alerts - Is
python3-gst1.0 installed? (audio_player.py:37)
..[QTvcp][INFO]  Logging to: /home/gene/qtvcp.log (logger.py:67)
[QTvcp][INFO]  Base log level set to: 10 (logger.py:68)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  BASEPATH cam_align (qt_pstat.py:86)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for handler file in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align_handler.py
(qt_pstat.py:96)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for default handler file in:
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qt_pstat.py:102)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using DEFAULT handler file path:
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qt_pstat.py:105)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.ui (qt_pstat.py:119)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .ui in:
/usr/share/qtvcp/panels/cam_align/cam_align.ui (qt_pstat.py:124)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using DEFAULT ui file from:
/usr/share/qtvcp/panels/cam_align/cam_align.ui (qt_pstat.py:126)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.qss (qt_pstat.py:151)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qss in:
/usr/share/qtvcp/panels/cam_align/cam_align.qss (qt_pstat.py:156)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No qss file found. (qt_pstat.py:162)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align.qrc (qt_pstat.py:173)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for .qrc in:
/usr/share/qtvcp/panels/cam_align/cam_align.qrc (qt_pstat.py:179)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No qrc file found. (qt_pstat.py:186)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for resources.py in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/qtvcp/panels/resources.py
(qt_pstat.py:196)
[QTvcp.QTVCP.QT_PSTAT][INFO]  No resources.py file found, no QRC file to
compile one from. (qt_pstat.py:207)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in:
/home/gene/linuxcnc/configs/GO704-5i25-7i76/cam_align/languages/cam_align_en.qm
(qt_pstat.py:214)
[QTvcp.QTVCP.QT_PSTAT][DEBUG]  Checking for translation file in:
/usr/share/qtvcp/screens/cam_align/languages/cam_align_en.qm
(qt_pstat.py:219)
[QTvcp.QTVCP.QT_PSTAT][INFO]  Using no translations, default system
locale is: en (qt_pstat.py:224)
[QTvcp][INFO]  Building A VCP Panel with: Python 3 (qtvcp:215)
[QTvcp][INFO]  No handler file specified - using:
/usr/share/qtvcp/panels/cam_align/cam_align_handler.py (qtvcp:218)
[QTvcp.QTVCP.QT_MAKEGUI][INFO]  Qsettings file path:
/home/gene/.config/QtVcp/cam_align.conf (qt_makegui.py:97)
[QTvcp][DEBUG]  Loading the handler file. (qtvcp:276)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Adding import dir:
/usr/share/qtvcp/panels/cam_align (qt_makegui.py:290)
[QTvcp.QTVCP.QT_MAKEGUI][DEBUG]  Modul

Re: [Emc-developers] looks like I need a python3 patch

[Chris Morley]

I am not sure which program you are referring to now.
I am referring to qtvcp's cam_align - I just fixed it - as soon as I realized 
it was broken.

cam-view was never officially supported - I am surprised it still worked at all.


From: gene heskett 
Sent: August 20, 2022 7:21 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] looks like I need a python3 patch

On 8/20/22 15:05, Chris Morley wrote:
> Gene
>
> I looked at the errors and found the problem in the code.
> Thanks for posting the error messages.
> I guess I broke it a month ago or so.
> I have pushed a fix to master.
> Sorry about that.
>
> Chris

I appreciate the effort Chris, but historically its been work for a
week, fail for a year. Am I the only
one who wants to use a camera for an edge finder? Or to align the
machine to a part? Somewhat
difficult since the post on my go704 is leaning like the tower of Pisa.
I bought a circular square and
will see if that will help me fix it. But I keep miss-laying my round tuit.

I'll update around the evening and see if it works then, and advise.
Thanks a bunch.
> 
> From: gene heskett 
> Sent: August 16, 2022 1:44 PM
> To: emc-developers@lists.sourceforge.net 
> 
> Subject: Re: [Emc-developers] looks like I need a python3 patch
>
> On 8/15/22 23:22, gene heskett wrote:
> update, see below.
>> On 8/15/22 21:56, Chris Morley wrote:
>>> Gene. Open a terminal for linuxcnc and type qtvcp cam_align  see if
>>> that works with your camera.
>>>
>>> Chrid
>>>
>> No, eventually drew a window frame but the background wasn't cleared,
>> but it did
>> get some interesting warnings:
>>
>> gene@GO704:~/linuxcnc/configs/GO704-5i25-7i76$ qtvcp cam_align
>> [QTvcp.QTVCP.QT_ISTAT][CRITICAL]  Missing LINEAR_UNITS in TRAJ,
>> guessing units for machine from JOINT 0 (qt_istat.py:133)
>> [QTvcp.QTVCP.QT_ISTAT][CRITICAL]  Missing UNITS in JOINT_0, assuming
>> metric based machine (qt_istat.py:137)
>> [QTvcp.QTVCP.QT_ISTAT][CRITICAL]  INI Parsing Error, No
>> MAX_LINEAR_VELOCITY Entry in TRAJ (qt_istat.py:364)
>> tool_mmap_user(): file open fail: No such file or directory
>> tool_mmap_user(): no mmap file,continuing
>> mmap tool data not available, continuing
>> emc/usr_intf/axis/extensions/emcmodule.cc
>> [QTvcp.QTVCP.LIB.SYS_NOTIFY][WARNING]  Desktop Notify not available::
>> org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible
>> causes include: the remote application did not send a reply, the
>> message bus security policy blocked the reply, the reply timeout
>> expired, or the network connection was broken. (sys_notify.py:71)
>> Namespace Gst not available
>> [QTvcp.QTVCP.LIB.AUDIO_PLAYER][WARNING]  audio alerts - Is
>> python3-gst1.0 installed? (audio_player.py:37)
>> Could not open video device 0
>> Port 0 is not working.
>> Port 1 is not working.
>> Port 2 is not working.
>> Port 3 is not working.
>> Port 4 is not working.
>> Port 5 is not working.
>>
> Come daylight, and a caffeine transfusion, I went out and found the 6040
> was waiting for me to log
> into a text screen, and had to startx after I had done that..
> And qtvcp cam_align works just fine.
>
> Turning around to the GO704, it too was waiting for a local login, but
> once that was done, there
> was no /dev/video0. So I found another camera and plugged it into the
> front of that Dell,
> THEN it had a /dev/video0. And mpv -av /dev/video0 looks exactly like
> qtvcp's version.
>
> So both cameras are working just fine by themselves.
>
> Now, it seems to me that the first two EMBED lines in the [DISPLAY]
> section for either machine
> should generate an empty third tab on the preview window, w/o the third
> line that
> launches the actual camera function, but it does not, and axis doesn't
> complain. But both configs
> have an all balls debug= statement.
>
> Do I have more than one problem?
>
> The one on the 6040, IIRC, was working until a kernel update, whenever
> that was.
> 2-3 months ago? But it is spindle mounted, and a cast iron bitch to use
> because
> changing an ER spindle tool is such a pita. I need to setup a TLO
> target, and write
> a std tool zeroing .ngc. But haven't found the round tuit. Been busier
> than a 1
> armed paper hanger making a B axis for the 6040, and fighting a losing
> battle
> with a series of 3d printers that claimed to be able to print PETG but
> haven't
> long survived the 50C higher nozzle temps that takes.
>
> Take care and stay well Chris.
>
> Cheers, Gene Heskett.
> --
> "There ar

Re: [Emc-developers] looks like I need a python3 patch

[Chris Morley]

Gene

I looked at the errors and found the problem in the code.
Thanks for posting the error messages.
I guess I broke it a month ago or so.
I have pushed a fix to master.
Sorry about that.

Chris

From: gene heskett 
Sent: August 16, 2022 1:44 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] looks like I need a python3 patch

On 8/15/22 23:22, gene heskett wrote:
update, see below.
> On 8/15/22 21:56, Chris Morley wrote:
>> Gene. Open a terminal for linuxcnc and type qtvcp cam_align  see if
>> that works with your camera.
>>
>> Chrid
>>
> No, eventually drew a window frame but the background wasn't cleared,
> but it did
> get some interesting warnings:
>
> gene@GO704:~/linuxcnc/configs/GO704-5i25-7i76$ qtvcp cam_align
> [QTvcp.QTVCP.QT_ISTAT][CRITICAL]  Missing LINEAR_UNITS in TRAJ,
> guessing units for machine from JOINT 0 (qt_istat.py:133)
> [QTvcp.QTVCP.QT_ISTAT][CRITICAL]  Missing UNITS in JOINT_0, assuming
> metric based machine (qt_istat.py:137)
> [QTvcp.QTVCP.QT_ISTAT][CRITICAL]  INI Parsing Error, No
> MAX_LINEAR_VELOCITY Entry in TRAJ (qt_istat.py:364)
> tool_mmap_user(): file open fail: No such file or directory
> tool_mmap_user(): no mmap file,continuing
> mmap tool data not available, continuing
> emc/usr_intf/axis/extensions/emcmodule.cc
> [QTvcp.QTVCP.LIB.SYS_NOTIFY][WARNING]  Desktop Notify not available::
> org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible
> causes include: the remote application did not send a reply, the
> message bus security policy blocked the reply, the reply timeout
> expired, or the network connection was broken. (sys_notify.py:71)
> Namespace Gst not available
> [QTvcp.QTVCP.LIB.AUDIO_PLAYER][WARNING]  audio alerts - Is
> python3-gst1.0 installed? (audio_player.py:37)
> Could not open video device 0
> Port 0 is not working.
> Port 1 is not working.
> Port 2 is not working.
> Port 3 is not working.
> Port 4 is not working.
> Port 5 is not working.
>
Come daylight, and a caffeine transfusion, I went out and found the 6040
was waiting for me to log
into a text screen, and had to startx after I had done that..
And qtvcp cam_align works just fine.

Turning around to the GO704, it too was waiting for a local login, but
once that was done, there
was no /dev/video0. So I found another camera and plugged it into the
front of that Dell,
THEN it had a /dev/video0. And mpv -av /dev/video0 looks exactly like
qtvcp's version.

So both cameras are working just fine by themselves.

Now, it seems to me that the first two EMBED lines in the [DISPLAY]
section for either machine
should generate an empty third tab on the preview window, w/o the third
line that
launches the actual camera function, but it does not, and axis doesn't
complain. But both configs
have an all balls debug= statement.

Do I have more than one problem?

The one on the 6040, IIRC, was working until a kernel update, whenever
that was.
2-3 months ago? But it is spindle mounted, and a cast iron bitch to use
because
changing an ER spindle tool is such a pita. I need to setup a TLO
target, and write
a std tool zeroing .ngc. But haven't found the round tuit. Been busier
than a 1
armed paper hanger making a B axis for the 6040, and fighting a losing
battle
with a series of 3d printers that claimed to be able to print PETG but
haven't
long survived the 50C higher nozzle temps that takes.

Take care and stay well Chris.

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] looks like I need a python3 patch

[Chris Morley]

Are you by chance using a raspberry pi?



Sent from my Galaxy



 Original message 
From: gene heskett 
Date: 2022-08-19 4:29 p.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] looks like I need a python3 patch

On 8/17/22 16:46, gene heskett wrote:
> On 8/17/22 15:12, Chris Morley wrote:
>> What ae you using to load qtvcp in the INI?
>> Something like this should work;
>>
>> # Embed tabs
>> EMBED_TAB_NAME= CamAlign
>> EMBED_TAB_COMMAND= halcmd loadusr -Wn qtvcp_embed qtvcp -d -c
>> qtvcp_embed  -x {XID} cam_align
>
After todays update, I seem to be getting a different, but the same end
result, error:

[QTvcp.QTVCP.QT_ISTAT][WARNING]  Embeded tab configuration -invalaid
number of TAB_NAMES vrs TAB_LOCATION - guessng default. (qt_istat.py:411)
halcmd loadusr -Wn qtvcp_embed qtvcp -d -c qtvcp_embed -x {XID} cam_align
[False]
Waiting for component 'qtvcp_embed' to become
ready^Ctask:
1534 cycles, min=0.07, max=0.036086, avg=0.009952, 0 latency
excursions (> 10x expected cycle time of 0.01s)
Traceback (most recent call last):
   File "/usr/bin/axis", line 4222, in 
 o.mainloop()
   File "/usr/lib/python3.7/tkinter/__init__.py", line 1283, in mainloop
.self.tk.mainloop(n)
   File "/usr/lib/python3.7/tkinter/__init__.py", line 1700, in __call__
 def __call__(self, *args):
KeyboardInterrupt
.Shutting down and cleaning up LinuxCNC...
..Running HAL shutdown script
.hm2_5i25.0: dropping AnyIO board at :01:02.0
hm2/hm2_5i25.0: unregistered
RTAPI_PCI: Unmapped 65536 bytes at 0x7f73afd72000
hm2_pci: driver unloaded
hm2: unloading
..^C..Note: Using POSIX realtime
.gene@GO704:~$ ^C
gene@GO704:~$ ..^C
gene@GO704:~$ ^C
gene@GO704:~$ ...^C
gene@GO704:~$ ..^C
gene@GO704:~$ ...^C
gene@GO704:~$ ..^C
gene@GO704:~$ ..^C
gene@GO704:~$ ..^C
gene@GO704:~$ ...^C
gene@GO704:~$ ..^C
gene@GO704:~$ ..^C
gene@GO704:~$ ..^C
gene@GO704:~$ ..^C
gene@GO704:~$ ...^C
gene@GO704:~$ ..^C
gene@GO704:~$ ..^C
gene@GO704:~$ ..^C
gene@GO704:~$ ...^C
gene@GO704:~$ ..^C
gene@GO704:~$ ..^C
gene@GO704:~$ ..^C
gene@GO704:~$ ..^C
gene@GO704:~$ ...^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$ ^C
gene@GO704:~$ .^C
gene@GO704:~$
..[QTvcp][CRITICAL]
Aborted from Error Dialog
  Qtvcp encountered an error.  The following information may be useful
in troubleshooting:
LinuxCNC Version  : 2.9.0-pre0-7465-gc8dd11e89

Traceback (most recent call last):
   File "/usr/lib/python3/dist-packages/dbus/bus.py", line 175, in
activate_name_owner
 return self.get_name_owner(bus_name)
   File "/usr/lib/python3/dist-packages/dbus/bus.py", line 361, in
get_name_owner
 's', (bus_name,), **keywords)
   File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651,
in call_blocking
 message, timeout)
dbus.exceptions.DBusException:
org.freedesktop.DBus.Error.NameHasNoOwner: Could not get owner of name
'org.freedesktop.Notifications': no such name

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
   File "/usr/bin/qtvcp", line 511, in 
 APP = QTVCP()
   File "/usr/bin/qtvcp", line 133, in __init__
 

Re: [Emc-developers] looks like I need a python3 patch

[Chris Morley]

I am assuming you are using AXIS.
loadusr is required.
Please run from a terminal and post all the qtvcp messages.

EMBED_TAB_LOCATION is only for Gmoccapy, gscreen and qtvcp screens.

Chris

From: gene heskett 
Sent: August 17, 2022 8:42 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] looks like I need a python3 patch

On 8/17/22 15:12, Chris Morley wrote:
> What ae you using to load qtvcp in the INI?
> Something like this should work;
>
> # Embed tabs
> EMBED_TAB_NAME= CamAlign
> EMBED_TAB_COMMAND= halcmd loadusr -Wn qtvcp_embed qtvcp -d -c qtvcp_embed  -x 
> {XID} cam_align
This almost works, IF the loadusr is removed, otherwise the qtvcp error
message says it's
looking in /usr/share/qtvcp/loadusr for cam_align.

The loadusr subdir does not exist. The camera is presently occupied so I'm
getting a blank white tab.
And halcmd now says invalid option "W"

Does it no longer need the EMBED_TAB_LOCATION line in the {DISPLAY} section?

Something else, that machine is running buster yet, and to synaptic,
qtvcp does not exist.

So is this bullseye advice only?

Thanks Chris.
> . The loadusr
>
> There should be a sample configuration in sim/axis/qtvcp that demos the code.
>
> Chris
> 
> From: gene heskett 
> Sent: August 16, 2022 1:44 PM
> To: emc-developers@lists.sourceforge.net 
> 
> Subject: Re: [Emc-developers] looks like I need a python3 patch
>
> On 8/15/22 23:22, gene heskett wrote:
> update, see below.
>> On 8/15/22 21:56, Chris Morley wrote:
>>> Gene. Open a terminal for linuxcnc and type qtvcp cam_align  see if
>>> that works with your camera.
>>>
>>> Chrid
>>>
>> No, eventually drew a window frame but the background wasn't cleared,
>> but it did
>> get some interesting warnings:
>>
>> gene@GO704:~/linuxcnc/configs/GO704-5i25-7i76$ qtvcp cam_align
>> [QTvcp.QTVCP.QT_ISTAT][CRITICAL]  Missing LINEAR_UNITS in TRAJ,
>> guessing units for machine from JOINT 0 (qt_istat.py:133)
>> [QTvcp.QTVCP.QT_ISTAT][CRITICAL]  Missing UNITS in JOINT_0, assuming
>> metric based machine (qt_istat.py:137)
>> [QTvcp.QTVCP.QT_ISTAT][CRITICAL]  INI Parsing Error, No
>> MAX_LINEAR_VELOCITY Entry in TRAJ (qt_istat.py:364)
>> tool_mmap_user(): file open fail: No such file or directory
>> tool_mmap_user(): no mmap file,continuing
>> mmap tool data not available, continuing
>> emc/usr_intf/axis/extensions/emcmodule.cc
>> [QTvcp.QTVCP.LIB.SYS_NOTIFY][WARNING]  Desktop Notify not available::
>> org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible
>> causes include: the remote application did not send a reply, the
>> message bus security policy blocked the reply, the reply timeout
>> expired, or the network connection was broken. (sys_notify.py:71)
>> Namespace Gst not available
>> [QTvcp.QTVCP.LIB.AUDIO_PLAYER][WARNING]  audio alerts - Is
>> python3-gst1.0 installed? (audio_player.py:37)
>> Could not open video device 0
>> Port 0 is not working.
>> Port 1 is not working.
>> Port 2 is not working.
>> Port 3 is not working.
>> Port 4 is not working.
>> Port 5 is not working.
>>
> Come daylight, and a caffeine transfusion, I went out and found the 6040
> was waiting for me to log
> into a text screen, and had to startx after I had done that..
> And qtvcp cam_align works just fine.
>
> Turning around to the GO704, it too was waiting for a local login, but
> once that was done, there
> was no /dev/video0. So I found another camera and plugged it into the
> front of that Dell,
> THEN it had a /dev/video0. And mpv -av /dev/video0 looks exactly like
> qtvcp's version.
>
> So both cameras are working just fine by themselves.
>
> Now, it seems to me that the first two EMBED lines in the [DISPLAY]
> section for either machine
> should generate an empty third tab on the preview window, w/o the third
> line that
> launches the actual camera function, but it does not, and axis doesn't
> complain. But both configs
> have an all balls debug= statement.
>
> Do I have more than one problem?
>
> The one on the 6040, IIRC, was working until a kernel update, whenever
> that was.
> 2-3 months ago? But it is spindle mounted, and a cast iron bitch to use
> because
> changing an ER spindle tool is such a pita. I need to setup a TLO
> target, and write
> a std tool zeroing .ngc. But haven't found the round tuit. Been busier
> than a 1
> armed paper hanger making a B axis for the 6040, and fighting a losing
> battle
> with a series of 3d printers that claimed to be able to print PETG but
> haven't
> 

Re: [Emc-developers] looks like I need a python3 patch

[Chris Morley]

What ae you using to load qtvcp in the INI?
Something like this should work;

# Embed tabs
EMBED_TAB_NAME= CamAlign
EMBED_TAB_COMMAND= halcmd loadusr -Wn qtvcp_embed qtvcp -d -c qtvcp_embed  -x 
{XID} cam_align


There should be a sample configuration in sim/axis/qtvcp that demos the code.

Chris

From: gene heskett 
Sent: August 16, 2022 1:44 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] looks like I need a python3 patch

On 8/15/22 23:22, gene heskett wrote:
update, see below.
> On 8/15/22 21:56, Chris Morley wrote:
>> Gene. Open a terminal for linuxcnc and type qtvcp cam_align  see if
>> that works with your camera.
>>
>> Chrid
>>
> No, eventually drew a window frame but the background wasn't cleared,
> but it did
> get some interesting warnings:
>
> gene@GO704:~/linuxcnc/configs/GO704-5i25-7i76$ qtvcp cam_align
> [QTvcp.QTVCP.QT_ISTAT][CRITICAL]  Missing LINEAR_UNITS in TRAJ,
> guessing units for machine from JOINT 0 (qt_istat.py:133)
> [QTvcp.QTVCP.QT_ISTAT][CRITICAL]  Missing UNITS in JOINT_0, assuming
> metric based machine (qt_istat.py:137)
> [QTvcp.QTVCP.QT_ISTAT][CRITICAL]  INI Parsing Error, No
> MAX_LINEAR_VELOCITY Entry in TRAJ (qt_istat.py:364)
> tool_mmap_user(): file open fail: No such file or directory
> tool_mmap_user(): no mmap file,continuing
> mmap tool data not available, continuing
> emc/usr_intf/axis/extensions/emcmodule.cc
> [QTvcp.QTVCP.LIB.SYS_NOTIFY][WARNING]  Desktop Notify not available::
> org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible
> causes include: the remote application did not send a reply, the
> message bus security policy blocked the reply, the reply timeout
> expired, or the network connection was broken. (sys_notify.py:71)
> Namespace Gst not available
> [QTvcp.QTVCP.LIB.AUDIO_PLAYER][WARNING]  audio alerts - Is
> python3-gst1.0 installed? (audio_player.py:37)
> Could not open video device 0
> Port 0 is not working.
> Port 1 is not working.
> Port 2 is not working.
> Port 3 is not working.
> Port 4 is not working.
> Port 5 is not working.
>
Come daylight, and a caffeine transfusion, I went out and found the 6040
was waiting for me to log
into a text screen, and had to startx after I had done that..
And qtvcp cam_align works just fine.

Turning around to the GO704, it too was waiting for a local login, but
once that was done, there
was no /dev/video0. So I found another camera and plugged it into the
front of that Dell,
THEN it had a /dev/video0. And mpv -av /dev/video0 looks exactly like
qtvcp's version.

So both cameras are working just fine by themselves.

Now, it seems to me that the first two EMBED lines in the [DISPLAY]
section for either machine
should generate an empty third tab on the preview window, w/o the third
line that
launches the actual camera function, but it does not, and axis doesn't
complain. But both configs
have an all balls debug= statement.

Do I have more than one problem?

The one on the 6040, IIRC, was working until a kernel update, whenever
that was.
2-3 months ago? But it is spindle mounted, and a cast iron bitch to use
because
changing an ER spindle tool is such a pita. I need to setup a TLO
target, and write
a std tool zeroing .ngc. But haven't found the round tuit. Been busier
than a 1
armed paper hanger making a B axis for the 6040, and fighting a losing
battle
with a series of 3d printers that claimed to be able to print PETG but
haven't
long survived the 50C higher nozzle temps that takes.

Take care and stay well Chris.

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] looks like I need a python3 patch

[Chris Morley]

Gene. Open a terminal for linuxcnc and type qtvcp cam_align  see if that works 
with your camera.

Chrid



Sent from my Galaxy



 Original message 
From: gene heskett 
Date: 2022-08-15 6:48 p.m. (GMT-08:00)
To: emc-developers@lists.sourceforge.net
Subject: Re: [Emc-developers] looks like I need a python3 patch

On 8/15/22 06:41, andy pugh wrote:
> On Mon, 15 Aug 2022 at 10:25, gene heskett  wrote:
>
>> On my GO704, I've a camera that uses emc_cam.py,
My mental copy/paste mistake Andy, the above s/b emb_cam.py, but its
still pretty old by now.
> Where does that come from?  The presence of "emc" in the name makes me
> suspect that it is quite old.
>


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] next release discussion: Why not make the branch new

[Chris Morley]

My point is that if the branch is made now - work they we do know needs to be 
done can be done -now.
It also allows work to be merged to master now.

Careful about having 'meetings about meetings'

Chris

From: Hans Unzner 
Sent: August 10, 2022 7:18 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] next release discussion: Why not make the branch 
new

I think we all agree that setting a date for the next release is
mandatory, but nobody of the candidates has the adequate time for that job.
Maybe we could start by picking the issues/tasks we want to have have/do
in/for 2.9. We talked about creating a GitHub project
<https://docs.github.com/en/issues/organizing-your-work-with-project-boards/managing-project-boards/about-project-boards>
to chose the issues to get an overview what has to be done for the 2.9
release. That would make it easier to estimate a deadline.
Andy, should I assist you by creating such a project?
We can discuss the task further in the next meeting, I already set it on
the agenda of the  next meeting.

Hans

Am 10.08.22 um 20:14 schrieb Chris Morley:
> We seem to all agree that 2.9 (or whatever) is reassembly close.
> Why not make the 2.9 branch now?
>
> To get things done you must set a GOAL and a DATE.
> We have done neither.
>
> For instance I am not going to go through all my configs in master.
> i have configs I want in master but will prune for 2.9.
> If there was a 2.9 branch I would prune them now.
>
> It would also allow us to merge master stuff (classicladder!) into master.
> It we had done that months ago then we could now probably back port it to 2.9
> reasonably bug free about now.
>
> We have traditionally talked for months (years even) on releasing, then one 
> random weekend someone finds the time to do it and it ends up trapping code 
> that is not ready. then we make a buggy ISO, which we never update in the 
> life of the release. This leads first-time users of the ISO to not have a 
> good experience.
> It's also annoying as a developer.
>
> Please, let's discuss and be more organised.
>
> Chris
>
> ___
> 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] next release discussion: Why not make the branch new

[Chris Morley]

We seem to all agree that 2.9 (or whatever) is reassembly close.
Why not make the 2.9 branch now?

To get things done you must set a GOAL and a DATE.
We have done neither.

For instance I am not going to go through all my configs in master.
i have configs I want in master but will prune for 2.9.
If there was a 2.9 branch I would prune them now.

It would also allow us to merge master stuff (classicladder!) into master.
It we had done that months ago then we could now probably back port it to 2.9
reasonably bug free about now.

We have traditionally talked for months (years even) on releasing, then one 
random weekend someone finds the time to do it and it ends up trapping code 
that is not ready. then we make a buggy ISO, which we never update in the life 
of the release. This leads first-time users of the ISO to not have a good 
experience.
It's also annoying as a developer.

Please, let's discuss and be more organised.

Chris

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

Re: [Emc-developers] Next Linuxcnc Online meeting

[Chris Morley]

I unfortunately found the meeting frustrating. The audio was unusable about 50% 
of the time.
For mw,It got to the point it was useless to continue trying.
Not sure if it was on my end or if there were any other options.
Seb did mention he had some trouble too.

Next meeting:
Is there a way to post small writeups of subjects keen to be discussed?
I had opinions on 2.9 release but could not be heard?

Thanks for organising the meeting. Nice to see a try on an organised direction 
again :)

Chris

From: Steffen Moeller 
Sent: August 10, 2022 1:25 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] Next Linuxcnc Online meeting

Got something resembling a protocol here
https://docs.google.com/document/d/1aWMxBY8IbCYXFLFvjgqUXZ09inZp5u0r-pZcjeb2bWk/edit?usp=sharing

The other attendees please edit and in a few days we can then paste it here.

Am 09.08.2022 um 05:22 schrieb Feral Engineer:
> Yeah, I missed it too (New Jersey)
>
> Phil T.
> The Feral Engineer
>
> Check out my LinuxCNC tutorials, machine builds and other antics at
> www.youtube.com/c/theferalengineer
>
> Help support my channel efforts and coffee addiction:
> www.patreon.com/theferalengineer
>
> Order one of the coolest label makers on the market at
> http://labelworks.epson.com, use coupon code "theferalengineer" and receive
> 20% off of your order 
>
> On Mon, Aug 8, 2022, 8:15 PM  wrote:
>
>> Well, it seems that Eastern Standard Time and Central European Summer
>> Time are somewhat different, maybe next time! :)
>>
>> Thanks,
>> Matt
>>
>> On 2022-08-08 10:01, Rene Hopf via Emc-developers wrote:
>>> On 06.08.22 17:58, Sebastian Kuzminsky wrote:
 On 8/5/22 05:41, Rene Hopf via Emc-developers wrote:
> Meeting will be Monday 8.8. 20:00 CEST.
 What's the link to join?  I'll try to be there.
>>> https://meet.jit.si/NearbyMythsScoreVery
>>>
>>> looking forward to see you all
>>>
 Thanks for organizing!
>>
>> ___
>> 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 mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Re: [Emc-developers] GTK

[Chris Morley]

It's been a long time since using GTK and almost nothing in GTK3 but...
You can reference the widget hierarchy to do fancy stuff.
https://docs.gtk.org/gtk3/class.SpinButton.html

Here you can see the spinbox has an entry widget reference.
With luck you can catch a focus in of the entry vrs a focus in of the total 
widget.

There are probably other ways too.

Chris


From: Hans Unzner 
Sent: August 9, 2022 3:21 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] GTK



Am 09.08.22 um 15:24 schrieb andy pugh:
> On Tue, 9 Aug 2022 at 13:39, Hans Unzner  wrote:
>> Sorry, I don't really got it. What do you mean with 'passing-through a
>> click on the + or - buttons.'?
>> Do you want to react only to a click in text/value area but not to a
>> click on the +/- buttons?
> If the user clicks in the text area then I want to bring up the
> onscreen keyboard. If they click + or - I want the usual
> increment/decrement behaviour controlled by the GTK adjustment in the
> usual way.
>
> So, default behaviour for + / - and my special keyboard for the text area.
>

I thought about the 'focus-in-event' but that is also generated when you
click the +/- button.
I think it's not possible because it is one widget. You could change the
HAL_SpinButton so that it will be assembled of a Gtk.Entry and two
buttons. Then it would be possible I guess but not sure if it's worth
the effort.


___
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] Next Linuxcnc Online meeting

[Chris Morley]

How do you join the chat?

From: Rene Hopf via Emc-developers 
Sent: August 4, 2022 9:46 AM
To: emc-developers@lists.sourceforge.net 
Cc: Rene Hopf 
Subject: [Emc-developers] Next Linuxcnc Online meeting

Hi,

Recently we had an online meeting about things happening in linuxcnc,
and we chose do do another one.

last time we had a long chat about translations, the build system, and
toolchangers.

anyone can join, lets find a date and time:

https://nuudel.digitalcourage.de/aNkDAtiHrtsA1RFB

Rene



___
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] [Hosted Weblate] New comment inLinuxCNC/LinuxCNC Documentation

[Chris Morley]

I am 99% sure it only restarts at the line with what ever modes are present.
It certainly doesn't go back through the program.
In fact that is one of the big drawbacks of it.


From: gene heskett 
Sent: July 28, 2022 5:27 PM
To: emc-developers@lists.sourceforge.net 
Subject: Re: [Emc-developers] [Hosted Weblate] New comment inLinuxCNC/LinuxCNC 
Documentation

On 7/28/22 06:37, Hans Unzner wrote:
> Maybe
> will restart the program at the following line. --> will continue executing
> the program at the following line.
> ?
I'm not happy with this, the word restart is IMO correct because the
state of the machine
can only be determined by scanning and re-executing all the mode changes
that have
occurred since the file was initially ran, or at least that's how I've
understood it since
that "start from line" was added several years ago.  The motion code may
not be
re-executed, but the mode changes it implies are.

Am I mistaken?
> Am Do., 28. Juli 2022 um 11:55 Uhr schrieb Steffen Möller via
> Emc-developers :
>
>>
>> #  Comment added
>>
>> [ smoe](https://hosted.weblate.org/user/smoe/ "Steffen Möller"): [Hosted
>> Weblate](https://hosted.weblate.org) /
>> [LinuxCNC](https://hosted.weblate.org/projects/linuxcnc/) / [LinuxCNC
>> Documentation](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/)
>> /
>> [English](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/en/)
>>
>> ## Source string
>>
>> 'M0' - pause a running program temporarily. LinuxCNC remains in the Auto
>> Mode
>> so MDI and other manual actions are not enabled. Pressing the resume button
>> will restart the program at the following line.
>>
>> ## Source string description
>>
>> type: Plain text
>>
>> ## Comment
>>
>> I am unhappy with the term "restart". That would imply that something
>> would be
>> "re"-executed, which is not the case, and variables are not affected,
>> either.
>> I would prefer "the execution of that program continues in the following
>> line."
>>
>> [Edit this string](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-
>> docs/en/?checksum=acfba46ddc59075d#comments
>> 
>> )
>>
>> ## Source string location
>>
>> [src/gcode/m-code.adoc:47](
>> https://github.com/LinuxCNC/linuxcnc/blob/master/docs/src/gcode/m-code.adoc?plain=1#L47
>> )
>>
>> ##  Translation Info
>>
>> All strings|  [
>> 29,515
>> ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-docs/en/) |
>>
>>
>> ---|---|
>> Translated strings |  [
>> 29,515
>> ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-
>> docs/en/?q=state:>=translated) |  [
>> 100%
>> ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-
>> docs/en/?q=state:>=translated)
>> Untranslated strings   |  [ 0
>>
>> ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-
>> docs/en/?q=state:empty)|  [
>> 0%
>> ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-
>> docs/en/?q=state:empty)
>> Unfinished strings |  [ 0
>>
>> ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-
>> docs/en/?q=state:> 0%
>> ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-
>> docs/en/?q=state:> Strings marked for edit|  [ 0
>>
>> ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-
>> docs/en/?q=state:needs-editing)|  [
>> 0%
>> ](https://hosted.weblate.org/translate/linuxcnc/linuxcnc-
>> docs/en/?q=state:needs-editing)
>>
>>
>> [View](https://hosted.weblate.org/projects/linuxcnc/linuxcnc-docs/en/)
>>
>>
>> [Weblate, the libre continuous localization system.](https://weblate.org/)
>>
>> Generated on July 28, 2022, 11:53 a.m..
>>
>> ___
>> 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 



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

Re: [Emc-developers] tool database in python

[Chris Morley]

My discussion was to bring to light how Lathe tools are normally used so that a 
database might keep them in mind when hashing out a protocol.

My 'complaint' about linuxcnc offsets for lathes was to point out it's 
suboptimal, not that it wasn't possible. Using g43.2 to add wear offsets works 
for sure.. but it a hack and doesn't allow proper standard support in screens.

I certainly don't suggest we eliminate g43.2 functionality though.


From: andy pugh 
Sent: June 29, 2022 10:13 PM
To: EMC developers 
Subject: Re: [Emc-developers] tool database in python

On Fri, 24 Jun 2022 at 02:46, Chris Morley  wrote:
>
> Different edges of the same tool is done by having different offsets, not 
> tool number.

It certainly _can_ be done that way, but I see no reason to preclude
doing it a different way.

And (as delivered) LinuxCNC does not handle T11 to mean anything other
than Tool 11.

If you allow more than one tool in one pocket then you can use M6 T1
G43 / M6 T2 G43 to get the same tool, same pocket, different edge,
without having to remember where you kept the second-edge offset (or,
more practically, without having to tell the CAM software to use an
offset that does not match the too)


--
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] tool database in python

[Chris Morley]

Different edges of the same tool is done by having different offsets, not tool 
number.
t11 = tool pocket 1 offset 1
t12 = tool pocket 1 offset 2

There is also
 T111 = tool 1 offset 1 wear offsets 1

To pick a particular tool for a pocket in Gcode is not standard on a lathe.
I'm quoting Okuma, I believe Fanuc is similar but I'm sure there are exceptions 
of course.

Anyways the problem of the GUI knowing what offset/wear offset is currently set 
is still the same.

Chris

From: andy pugh 
Sent: June 23, 2022 7:29 PM
To: EMC developers 
Subject: Re: [Emc-developers] tool database in python

On Thu, 23 Jun 2022 at 06:42, Chris Morley  wrote:

> for instance, you can use multiple tool offsets (one at a time) on a single 
> tool position.

Indeed, which is why a database needs to allow several tools to be
simultaneously in the same pocket.
(To store different edges of the same tool as different T-numbers
using different offsets)

--
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