On 29.01.22 05:14, gene heskett wrote:
On Friday, January 28, 2022 9:15:18 PM EST Steffen Möller wrote:
On 28.01.22 23:25, gene heskett wrote:
On Friday, January 28, 2022 2:21:50 PM EST gene heskett wrote:
On Friday, January 28, 2022 1:32:52 PM EST gene heskett wrote:
On Friday, January 28, 2022 10:18:38 AM EST Steffen Möller wrote:
...
Processing linuxcnc-uspace_2.9.0~pre0_arm64.deb...
...
Install them on a pi, and run latency-test please.
Are you running on 64bit? Then the packages should work.
Not on the pi's, always armhf. arm64 is too slow. This runs fine on
a
pi3 even, but the rpi3 is dragging its tongue on the floor, I had
to
move some of the lower response stuff to a slower thread to give
the
quick stuff enough time to work on the rpi3b and can't do much else
at
the same time, but it did get the job done before the rpi4 came
out.
Machine control, in close enough to real time demand low irq
latency.
For normal pc's AMD processors don't do that even running rtai
kernels, but intels from about 586 had managed it well enough to
work
but i5's are amazing. Even atoms ran it well enough to get the job
done here for about a decade but they've all died for various
reasons
associated with the bblb syndrome now. I've got 2 I need to recycle
but haven't made the trip to the recycle trailer yet. I bought a
stack
of off-lease Dells to replace the atoms with, works very well with
my
only complaint about Dells being the 2 sata ports max. Running from
SSD's you would swear they are brand new state of the art machines.
You may be able to build it on arm64's but linuxcnc checks to see
if
certain resources are available that are only available from a
realtime, fully preemptable kernel, making a graceful exit if they
aren't found.
Tell you what, I just found a debian armhf net-install image for
armhf
in 11.2, and since I can't get it built on a raspios bullseye, I'll
rewrite that card and start from scratch with a genuine debian 11.2
install, just to see if I can make it run, with this kernel, on your
bullseye.
When I have something to report, I will.
And I can confirm that the armhf net-install of 11.2, will not boot
on a pi. That is assuming dd can write a valid .iso to an sd card
just as it writes the raspios .img files. So a good .iso should, and
has worked just fine several times, but two writes of the .iso have
refused to look at the card after the first green flash of the disk
activity led.
Then I found my card reader was on strike, so I drove out to the
other
side of town to walmart and bought two more readers, along with a
keyboard cuz the space bar on this one is getting funkity, and 2 more
64G micro-cards.
I rewrote the debian net-install image, then inspected it with fdisk,
to discover the debian iso I had just written to it for /dev/sdk,
partition 1 while a dos (vfat to linux) image is also an EFI image,
the first one that pi has ever seen.
So Steffen, if you want me to try your distro, respin that .iso w/o
the EFI. The pi doesn't take more than a 10 millisecond glance at
this .iso.
Thank you tons for your efforts.
I am blown away. You are indeed the right man for the job. Most of the
devs I've interfaced with would have taken that as an insult no matter
how I worded it, which I didn't really mean it to be. Thank you very
much.
I happily concentrate on getting you mill functional with your RPi, and
do not really care what you use for it. Also I am only peripheral to
LinuxCNC, have only helped with the last meters of the Debian packaging
(and this works, just not for your RPi). My local situation is that I
have the Duet3 Main+Extension boards (from Duet3d.com) arriving next
week. They have their own CNC interface as part of their firmware. That
extension board (without that firmware) can be contacted directly via
CAN, so my summer project will be to use that interface, likely also on
top of an RPi, and have LinuxCNC talk to it. Should I be successful with
that then I may decide to call myself very close to LinuxCNC and
familiar with all that HAL interiors. If I am not successful then I need
to find out why that is. The biggest danger is that I am too happy with
what Duet3 already provides via their web interface and that their
firmware is too easy to modify (Open Source it all is). Their hardware
seems excellent.
TL;DR - I also need an RPi with LinuxCNC, just a bit later.
Now I have a problem. The config commands in my scripts, worked a week
ago before I started futzing with them to do it like you wanted. Linuxcnc
has a runinplace mode, where its is built, then commanded to runinplace
w/o an install, and then perform around 240 test runs to make sure it all
returns the correct results. I have those scripts so that the whole
build does this testing, which is a rather prolonged process taking
around 40 minutes just to do the tests, But now its not making the debs
because the runinplace is surviving the transition to making the debs,
which it cannot then do, so what I'm doing as I type this, with my pi
back to running raspian buster, is an extra make clean and that seems to
be working ok now. Except it just bailed out, complaining about the
runinplace settings,
So I fired up synaptic and brought it up to date plus installing the
latest buildbot output for rpi4's, and I see halscope is fixed. Better
than before, nice, thanks guys.
Ok, this means you are productive again with Raspbian. This is good.
I need to learn about the buildbot. From what I got it is just fine for
everyone to run the latest Raspbian images, and there is no reason that
I could see why the buildbot not also used the same. Hm. Maybe this
email catches Sebastian's attention.
But since theres so many configure scripts here and there, and our build
instructions in our wiki are a bit long in the tooth, I need someone to
tell me which configure I should be executing for which results so I can
restore them to Just Works defaults.
This cannot be me - yet.
Back to boost::python splats, buster has python 3.7, and it works, but
the 3.9.2 in bullseye doesn't. Should this be brought to the python lists
attention, or do we need some conditionals in our code to change the
calls to the new syntax? Quite a bit of LinuxCNC is python based.
There is a possibility that the Raspbian folks have derived somehow from
the bullseye packages. I mean, that is the main point in having their
own distribution. I would just not have expected that for these boost
packages. And, sorry, I think I need to see this on my own RPi to make
any sort of constructive comment.
I gave all my RPis away, so I must admit, so I cannot easily follow up.
It will take a bit for an RPi4 to arrive. And a comparison of
latencies on 32 and 64 bits will also be interesting.
I was hoping debian had one already. Having to buy one for this is a
bummer. I could reimburse you if I could figure out how without somebody
in the middle wanting 10x the cost to do it. I'm doing all this on a 2gig
of dram rpi4, but doing the disk traffic for the build on a 240Gig SSD,
so I'm not beating its 64Gig u-sd to death.
All nice.
I have consulted my (almost)local ARM-hero about it, some know him as
N30dG, and he was not a fan of the Debian ARM images. Also suggesting
that this would not be what Debian should be bothering too much about in
the first place because all the fine differences in hardware that only
the manufacturer knows about. But your problem this now fails in exactly
what Debian _should_ be providing, i.e. a consistent software interface.
Concerning timing, I mean, once that we have working .debs for your RPi,
his suggestion was to try
sudo echo performance >
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
together with proper cooling.
32 or 64 bits, well, I think we want to see packages for both. Let's
wait for what Sebastian replies. I just saw on his page
http://buildbot.linuxcnc.org/buildslave-admin-guide.html that there are
buildbot difficulties with newer version that ship with bullseye and up.
Best,
Steffen
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
