On Montag, 6. April 2020, 02:20:34 CEST andy pugh wrote:
> Further oddness, trying with thermistor.comp in user_comps, first with
> plain gcc and minimal options:
>
> gcc -I/home/andypugh/linuxcnc-dev/include/ -DULAPI -H thermistor.c
>
> Seems OK (up to the point that it can't find HAL). It find
On Mon, 6 Apr 2020 at 00:56, andy pugh wrote:
> 1) Does anyone else see this problem, on Buster x86 preempt-rt for example?
> 2) Where does gcc get those paths from?
Further oddness, trying with thermistor.comp in user_comps, first with
plain gcc and minimal options:
gcc -I/home/andypugh/linuxc
On Sunday 05 April 2020 19:41:46 Robert Ellenberg wrote:
> Gene, what linuxcnc version are you running?
Master, on an rpi4, built on the rpi4 today starting with a git pull on
the sheldon. And master from the buildbot on the other 3 wintel
boxes... None over 8 to 10 days old.
> On Sun, Apr 5,
On my Buster / RTAI test machine I can't get halcompile to work on
_userspace_ components.
it can't find stddef.h, stdarg.h or spawn,h (included in rtapi.h)
It also fails on a standard Buster install with the test debs applied
to install RTAI and LinuxCNC.
However, trying it on a Pi4 running Ras
Gene, what linuxcnc version are you running?
On Sun, Apr 5, 2020, 7:35 PM Jon Elson wrote:
> On 04/05/2020 01:12 PM, Gene Heskett wrote:
> > So I'm back to the Z backlash as a possible culprit.. I
> > assume it is applied as the spindle is doing its turnaround.
> It just seems to me that compens
On 04/05/2020 01:12 PM, Gene Heskett wrote:
So I'm back to the Z backlash as a possible culprit.. I
assume it is applied as the spindle is doing its turnaround.
It just seems to me that compensating for backlash in a
rigid tapping move could have a lot of (bad) side effects.
So, I'm just wonde
On Sunday 05 April 2020 16:36:37 andy pugh wrote:
> On Sun, 5 Apr 2020 at 20:25, Gene Heskett wrote:
> > But I don't know that. And w/o a base thread its not readily seen on
> > a halscope setup. Its too slow.
>
> It's fast enough to capture everything that motion does, as motion
> runs in the s
On Sun, 5 Apr 2020 at 22:17, Chris Morley wrote:
>
> I think there are other commits to move to 2.8 for reverse run or at
> least make sure the code is correct.
>
> 7a517a7 axis.py restore redraw_dro()
>
> b4d0b228 motion.c tp-reverse is an output
If you think so, do it :-)
--
atp
"A motorcycl
On Sun, 5 Apr 2020 at 20:25, Gene Heskett wrote:
>
> But I don't know that. And w/o a base thread its not readily seen on a
> halscope setup. Its too slow.
It's fast enough to capture everything that motion does, as motion
runs in the servo thread.
--
atp
"A motorcycle is a bicycle with a pand
I think there are other commits to move to 2.8 for reverse run or at
least make sure the code is correct.
7a517a7 axis.py restore redraw_dro()
b4d0b228 motion.c tp-reverse is an ouput
Chris
___
Emc-developers mailing list
Emc-developers@lists.so
On Sunday 05 April 2020 11:54:08 andy pugh wrote:
> On Sun, 5 Apr 2020 at 16:39, Gene Heskett wrote:
> > Is the Z backlash setting used by a g33.1? if it is I might be able
> > to play with that and tighten up the thread,
>
> It might be interesting to log the Z position and spindle angle with
>
On Sun, 5 Apr 2020 at 16:39, Gene Heskett wrote:
> Is the Z backlash setting used by a g33.1? if it is I might be able to
> play with that and tighten up the thread,
It might be interesting to log the Z position and spindle angle with halscope.
(It is possible to save the data to file)
Do conse
Greetings all;
one of the other minor niggles about G33.1 that I've noted on 2 of my
machines. Not bad enough to be a showstopper but a 3/8" tap does get
sloppy
If the tap is big enough that I have to write a peck routine, the tapped
hole is a bit sloppy, as if its out of time a few degrees o
On Sunday 05 April 2020 09:10:23 andy pugh wrote:
> On Sun, 5 Apr 2020 at 13:21, Robert Murphy
wrote:
> > RTAI has no support for UEFI, booting issues are seeing only a
> > single core
>
> Is this shown in lscpu or is it more subtle than that?
>
> It might be something that we just have to docum
Dmesg confirms it with RTAI, I can’t recall the exact message, but it’s along
the lines of can’t CPU0 info from BIOS then it basically goes into uniprocessor
mode.
Running latency histogram reports only one core, /proc/cpuinfo only reports a
single core.
I’d try to exorcise the PC before burning
On Sun, 5 Apr 2020 at 13:21, Robert Murphy wrote:
> RTAI has no support for UEFI, booting issues are seeing only a single
> core
Is this shown in lscpu or is it more subtle than that?
It might be something that we just have to document in the
installation notes. Something along the lines of:
"
I don't know how many of you are aware of.
RTAI has no support for UEFI, booting issues are seeing only a single
core and installation will fail when installing grub as efivars can not
be mounted.
RT_PREEMPT, from the kernel version I have being using on the Mint
respins, 4.19.106-rt44, unle
17 matches
Mail list logo
