On Fri, 20 Mar 2020 at 20:48, andy pugh wrote:
> Maybe the answer is for the tool to make a copy of the library file to
> the config
> folder, and mess with that.
I tried that, and it ran, but created a broken config.
The problem is that this is a lathe config with a full set of Y pins,
even
On Mon, 23 Dec 2019 at 04:08, Thomas D. Dean wrote:
> At last, I remembered the .tgz!
And I finally got round to looking at it.
The problem seems to be that your config uses a library file (core
stepper.hal) that the tool can't (and probably shouldn't) change.
Maybe the answer is for the tool
On 12/20/19 3:59 AM, andy pugh wrote:
On Fri, 20 Dec 2019 at 11:57, Thomas D. Dean wrote:
The conversion tool failed to convert my old sherline lathe config.
Can you attach the zipped-up converted config? (That should contain
the original config in an "old" directory)
I will try to spot
On 12/20/19 3:59 AM, andy pugh wrote:
On Fri, 20 Dec 2019 at 11:57, Thomas D. Dean wrote:
The conversion tool failed to convert my old sherline lathe config.
Can you attach the zipped-up converted config? (That should contain
the original config in an "old" directory)
I will try to spot
On Fri, 20 Dec 2019 at 11:57, Thomas D. Dean wrote:
> The conversion tool failed to convert my old sherline lathe config.
Can you attach the zipped-up converted config? (That should contain
the original config in an "old" directory)
I will try to spot what is going wrong.
--
atp
"A motorcycle
On 12/20/19 2:43 AM, andy pugh wrote:
On Fri, 20 Dec 2019 at 03:34, Thomas D. Dean wrote:
I did a 'git pull' and built the 'run in place' version.
I modified the SherlineLathe_inch.ini file to have 2 axis and removed
the [Y Axis] and [joint_1] sections. I changed the [Z Axis] [joint_2]
to
On Fri, 20 Dec 2019 at 03:34, Thomas D. Dean wrote:
>
> I did a 'git pull' and built the 'run in place' version.
>
> I modified the SherlineLathe_inch.ini file to have 2 axis and removed
> the [Y Axis] and [joint_1] sections. I changed the [Z Axis] [joint_2]
> to [Joint_1].
The patch that Dewey
On 12/19/19 5:38 PM, Dewey Garrett wrote:
With both the installed and the 'run in place' versions,
the home Axis button for the Z axis does nothing.
This is a newly reported bug for the axis gui and 'historical' lathe
configurations that specified 3 axes (xyz) for a lathe (xz). In earlier
I did a 'git pull' and built the 'run in place' version.
I modified the SherlineLathe_inch.ini file to have 2 axis and removed
the [Y Axis] and [joint_1] sections. I changed the [Z Axis] [joint_2]
to [Joint_1].
The SherlineLathe_inch.ini uses
HALFILE = core_stepper.hal
I think I need to
> With both the installed and the 'run in place' versions,
> the home Axis button for the Z axis does nothing.
This is a newly reported bug for the axis gui and 'historical' lathe
configurations that specified 3 axes (xyz) for a lathe (xz). In earlier
branches, the 'y' entry was required to make
with the lathe axis lettering. There is a section
on that page that discusses lathe issues.
-Original Message-
From: Thomas D. Dean [mailto:tomd...@wavecable.com]
Sent: Friday, 20 December 2019 10:09 AM
To: emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] Buster RTAI Lathe
On 12/19/19 2:38 PM, Thomas D. Dean wrote:
I installed linuxcnc from git sources.
The mill config seems to work OK with my old 'wheezy' config as
converted by linuxcnc_2.9.0~pre0_amd64. Manual control seems to work.
MDI seems to work.
The lathe config from 'wheezy' would not work after
I installed linuxcnc from git sources.
The mill config seems to work OK with my old 'wheezy' config as
converted by linuxcnc_2.9.0~pre0_amd64. Manual control seems to work.
MDI seems to work.
The lathe config from 'wheezy' would not work after conversion by
linuxcnc_2.9.0~pre0_amd64.
I
As noted above, I build .deb from git sources.
I installed using the method given by Dewey.
Initial install shows the following depends not met:
linuxcnc depends on python2.7-glade2 | python-glade2; however:
Package python2.7-glade2 is not installed.
Package python-glade2 is not installed.
On 12/19/19 5:34 AM, Dewey Garrett wrote:
$ man dpkg
...
--force-help
Give help about the --force-thing options.
...
The command: 'dpkg --force-help' shows how to force an install.
$ dpkg --force-help|grep depend
[!] dependsTurn all dependency problems into
On 12/19/19 5:34 AM, Dewey Garrett wrote:
$ man dpkg
...
--force-help
Give help about the --force-thing options.
...
The command: 'dpkg --force-help' shows how to force an install.
$ dpkg --force-help|grep depend
[!] dependsTurn all dependency problems into
$ man dpkg
...
--force-help
Give help about the --force-thing options.
...
The command: 'dpkg --force-help' shows how to force an install.
$ dpkg --force-help|grep depend
[!] dependsTurn all dependency problems into warnings
[!] depends-versionTurn dependency
On Thu, 19 Dec 2019 at 06:10, Thomas D. Dean wrote:
> order to do that, the python-vte problem has to be fixed.
>
> Where should this fix be applied?
I think that it is in the Debian control files.
https://github.com/LinuxCNC/linuxcnc/blob/master/debian/control.bottom.in
I have been away from
On 12/18/19 9:35 PM, bari wrote:
"Gmoccapy and Gscreen want python-vte, but you should be able to run
other GUIs without it."
On 12/18/19 11:26 PM, Thomas D. Dean wrote:
Now, if the problem with python-vte can be fixed, I can install linuxcnc.
Again, I can run the 'run in place' version.
"Gmoccapy and Gscreen want python-vte, but you should be able to run
other GUIs without it."
On 12/18/19 11:26 PM, Thomas D. Dean wrote:
> Now, if the problem with python-vte can be fixed, I can install linuxcnc.
___
Emc-users mailing list
Most of my computers are multi-user, although that is becoming more
difficult. I have one install for an application for all users.
Since the package creation/installation is broken, I decided to go back
to one computer, one person philosophy.
I cleaned the build tree, configured, and built
I built linuxcnc from git sources. Build was OK. Install was not.
The problem is still python-vte and mismatched version of libvte-common.
Tom Dean
Here is what I did.
Building linuxcnc in debial 10 from linuxcnc/tmp:
On Wed, 18 Dec 2019 at 11:21, Thomas D. Dean wrote:
>
> How do I get kernel-mode RTAI? That is a new term...
The fact of the matter is that I am being vague because I am fuzzy on
how the build config works.
(I hope somebody else understands it :)
"Normal" RTAI, as used historically with
On 12/18/19 2:43 AM, andy pugh wrote:
On Wed, 18 Dec 2019 at 10:18, Thomas D. Dean wrote:
--with-realtime=uspace
Build for any realtime platform, or for non-realtime. The resulting
LinuxCNC executables will run on both a Linux kernel with Preempt-RT
patches (providing realtime
On Wed, 18 Dec 2019 at 10:18, Thomas D. Dean wrote:
> --with-realtime=uspace
>
> Build for any realtime platform, or for non-realtime. The resulting
> LinuxCNC executables will run on both a Linux kernel with Preempt-RT
> patches (providing realtime machine control) and on a vanilla
>
On 12/18/19 1:14 AM, andy pugh wrote:
On Wed, 18 Dec 2019 at 03:19, Thomas D. Dean wrote:
I have buster installed and
rtai-modules-4.14.148_5.2.3-linuxcnc_amd64.deb
I built linuxcnc, running the buster rtai kernel, from the git sources.
...
linuxcnc-uspace_2.9.0~pre0_amd64.deb
On Wed, 18 Dec 2019 at 03:19, Thomas D. Dean wrote:
>
> I have buster installed and
> rtai-modules-4.14.148_5.2.3-linuxcnc_amd64.deb
>
> I built linuxcnc, running the buster rtai kernel, from the git sources.
...
> linuxcnc-uspace_2.9.0~pre0_amd64.deb
> linuxcnc-uspace-rtai_2.9.0~pre0_amd64.deb
On Tue, 17 Dec 2019 at 20:31, Thomas D. Dean wrote:
> linuxcnc has dependency problems. It wants python-vte,
Gmoccapy and Gscreen want python-vte, but you should be able to run
other GUIs without it.
python-vte appears to exist in sid, but not in buster.
--
atp
"A motorcycle is a bicycle with
I have buster installed and
rtai-modules-4.14.148_5.2.3-linuxcnc_amd64.deb
I built linuxcnc, running the buster rtai kernel, from the git sources.
dpkg-checkbuilddeps found most of the needed packages. It missed 5,
bwidgit, libtk-img, tclx, python-gtk2, and python-yapps.
After build-in-place,
Upgrading to buster was successful.
I got the RTAI kernel installed.
linuxcnc has dependency problems. It wants python-vte, which wants
libvte-common=1:0.28.2-5. libvte-common=1:0.28.2-6 is on the repo's.
If I install libvte-common=1:0.28.2-5, it breaks other things...
Trying to fix this
On Tue, 17 Dec 2019 at 16:03, Thomas D. Dean wrote:
> 4. Install the deb's
> cd ~/RTAI
> sudo dpkg -i *.deb
>
> The part I am most unsure about is the dpkg command. Does that look
> reasonable?
I think I would do the install one at a time, (kernel then RTAI then
LinuxCNC then docs)
apt-get
Changing from the 'Latency Warning Messages', thread,
I plan to test upgrading stretch to buster rtai. The steps are:
1. Fetch the RTAI deb's into ~/RTAI:
cd ~/RTAI
wget http://www.linuxcnc.org/temp/linux-headers-4.14.148-rtai-amd64.deb
wget
32 matches
Mail list logo
