Discussion:
[Emc-users] Question for Peter C. Wallace
Gene Heskett
2017-06-12 16:07:15 UTC
Permalink
Hello Peter;

I have a problem trying to run linuxcnc on a pi 3b.

I think it could be solved if somehow, I could generate a
watchdog.has_bit=false coincident with enabling the machine, but hals
parser refuses to allow even a tristate_bit module to access and reset
the watchdog.

Have you a hal snippet that will do that?

Thank you.

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)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Peter C. Wallace
2017-06-12 17:45:58 UTC
Permalink
Date: Mon, 12 Jun 2017 12:07:15 -0400
Reply-To: "Enhanced Machine Controller (EMC)"
Subject: [Emc-users] Question for Peter C. Wallace
Hello Peter;
I have a problem trying to run linuxcnc on a pi 3b.
I think it could be solved if somehow, I could generate a
watchdog.has_bit=false coincident with enabling the machine, but hals
parser refuses to allow even a tristate_bit module to access and reset
the watchdog.
Have you a hal snippet that will do that?
Thank you.
Cheers, Gene Heskett
I dont see any issue with clearing WD has bit:

halcmd net clearwd hm2_7i92.0.watchdog.has_bit
halcmd setp hm2_7i92.0.watchdog.timeout_ns 1000000 (this causes a WD bite)
halcmd setp hm2_7i92.0.watchdog.timeout_ns 2000000 (back to a value that wont bite)
halcmd sets clearwd false (this clears the WD)
--
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
Gene Heskett
2017-06-12 20:30:55 UTC
Permalink
Post by Peter C. Wallace
Date: Mon, 12 Jun 2017 12:07:15 -0400
Reply-To: "Enhanced Machine Controller (EMC)"
To: "Enhanced Machine Controller (EMC)"
Peter C. Wallace
Hello Peter;
I have a problem trying to run linuxcnc on a pi 3b.
I think it could be solved if somehow, I could generate a
watchdog.has_bit=false coincident with enabling the machine, but
hals parser refuses to allow even a tristate_bit module to access
and reset the watchdog.
Have you a hal snippet that will do that?
Thank you.
Cheers, Gene Heskett
halcmd net clearwd hm2_7i92.0.watchdog.has_bit
halcmd setp hm2_7i92.0.watchdog.timeout_ns 1000000 (this causes a WD
This is a 7i90, timeout_ns is not adjustable ANAICT. Or it wasn't nearly
a year ago the first time I tried, now it works. Thank you.
Post by Peter C. Wallace
bite) halcmd setp hm2_7i92.0.watchdog.timeout_ns 20000000 (back to a
value that wont bite) halcmd sets clearwd false (this clears the WD)
And that works, now to arrange that its done whenever I enable the
machine. hal needs an if/then/else/endif command. Badly.

Thank you Peter.

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)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Nicklas Karlsson
2017-06-12 18:02:28 UTC
Permalink
Post by Gene Heskett
Hello Peter;
I have a problem trying to run linuxcnc on a pi 3b.
I think it could be solved if somehow, I could generate a
watchdog.has_bit=false coincident with enabling the machine, but hals
parser refuses to allow even a tristate_bit module to access and reset
the watchdog.
I could vaguely remember a problem with the watchdog but can't remember how I solved it. I run 2.8.x and there is now word watchdog in neither the *.ini file nor the *.hal file.

Do the real time threads work well on a raspberry?
Bertho Stultiens
2017-06-12 18:27:48 UTC
Permalink
Post by Nicklas Karlsson
Do the real time threads work well on a raspberry?
Lets just say that we're not that far yet...

From what I can tell, the initial start of linuxcnc results in a few
missed deadlines in the main task. But once all code is cached, it seems
to be fast enough. But time will tell.


The realtime kernels I've compiled so far are unstable and crash
randomly (kernel issues). So we're trying to get it running on a non-rt
kernel first. If that somehow works without crashing, then we can
concentrate on the kernel issues. I've a message about a stable kernel
from MK, but it needs to be seen if it has responsive mouse/keyboard,
which has been another issue.
--
Greetings Bertho

(disclaimers are disclaimed)
Nicklas Karlsson
2017-06-12 19:30:46 UTC
Permalink
Post by Bertho Stultiens
Lets just say that we're not that far yet...
From what I can tell, the initial start of linuxcnc results in a few
missed deadlines in the main task. But once all code is cached, it seems
to be fast enough. But time will tell.
I also one missed dead line during the initial start. I have nothing to compare against so I can't tell if this is the same for everyone else?
Bertho Stultiens
2017-06-12 20:31:04 UTC
Permalink
Post by Nicklas Karlsson
Post by Bertho Stultiens
Lets just say that we're not that far yet...
From what I can tell, the initial start of linuxcnc results in a few
missed deadlines in the main task. But once all code is cached, it seems
to be fast enough. But time will tell.
I also one missed dead line during the initial start. I have nothing
to compare against so I can't tell if this is the same for everyone
else?
I just installed an MK kernel(*):
Linux picnc 4.4.4-rt9-v7+ #7 SMP PREEMPT RT Mon Mar 7 14:53:11 UTC 2016
armv7l GNU/Linux

It still results in some initial missed deadlines. However, as before,
once the system is running it is stable. It also seems that this kernel
is actually usable.

I was able to drag the lcnc window over the screen with the preview tab
visible and there were no additional missed deadlines. So, it seems that
we are getting closer.


(*) There are some hacks to get this kernel installed. The documentation
at states that you need an updated bootloader, which, of course, I
promptly ignored. Then you need to reorganize the /boot content a bit to
get the kernel running. The old bootloader has apparently some fixed
paths which it uses (like kernel7.img and overlays/).
--
Greetings Bertho

(disclaimers are disclaimed)
Gene Heskett
2017-06-12 21:04:59 UTC
Permalink
Post by Nicklas Karlsson
Post by Gene Heskett
Hello Peter;
I have a problem trying to run linuxcnc on a pi 3b.
I think it could be solved if somehow, I could generate a
watchdog.has_bit=false coincident with enabling the machine, but
hals parser refuses to allow even a tristate_bit module to access
and reset the watchdog.
I could vaguely remember a problem with the watchdog but can't
remember how I solved it. I run 2.8.x and there is now word watchdog
in neither the *.ini file nor the *.hal file.
Do the real time threads work well on a raspberry?
Definite sometimes, Nicklass. latency-test actually shows less jitter
with a stock kernel, but figures lie. I am getting joint following
errors with the stock kernel and 15 minute maximum uptimes with what
purports to be a realtime kernel.

The stocker so far has just sat there and ducked everything I've thrown
at it. So this particular rt build is a very fragile bust IMNSHO. This
kernel is crap: rpi3-kernel-4.9.30-rt20-v7+.tar.gz, uptimes are as short
as 30 seconds even with my air hose keeping everything at ambient. And
latency-test results in the 2 millisecond jitter area.

Ambinent in the garage is mid-70's F. unless I leave the big door open
too long. 90F outside in the shade ATM.

So what we need is an rtai patched kernel for armhf, that also see's all
the mouse clicks and keyboard strokes. Most of these so-called rt
kernels make me click the mouse 1-3 times, then miss the keyup, and the
keyboard is even worse missing 75% of both the keydown's and worse yet,
keyup's. I'd had the backspace key wipe out 4 lines of hal code before I
can get it stopped. There's a good thing I don't have a tape running,
some of the expletives are pretty incendiary when that happens for the
3rd time in the same minute.

Thinking about breaking down and buying a udoo x86, but the kickstarter
page looks like the only place. They keep ballyhooing the $89 price
tag, but a buy button can't be found. Its also too big w/o starting over
with an even bigger box.

Has anyone here received theirs yet?

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)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Bertho Stultiens
2017-06-12 21:16:05 UTC
Permalink
Post by Gene Heskett
Post by Nicklas Karlsson
Do the real time threads work well on a raspberry?
Definite sometimes, Nicklass. latency-test actually shows less jitter
with a stock kernel, but figures lie. I am getting joint following
errors with the stock kernel and 15 minute maximum uptimes with what
purports to be a realtime kernel.
The stocker so far has just sat there and ducked everything I've thrown
at it. So this particular rt build is a very fragile bust IMNSHO. This
kernel is crap: rpi3-kernel-4.9.30-rt20-v7+.tar.gz, uptimes are as short
as 30 seconds even with my air hose keeping everything at ambient. And
latency-test results in the 2 millisecond jitter area.
I think we should try 4.4.4-rt9-v7+. It looks like a stable version
(currently running here).
--
Greetings Bertho

(disclaimers are disclaimed)
Gene Heskett
2017-06-12 21:32:48 UTC
Permalink
Post by Bertho Stultiens
Post by Gene Heskett
Post by Nicklas Karlsson
Do the real time threads work well on a raspberry?
Definite sometimes, Nicklass. latency-test actually shows less
jitter with a stock kernel, but figures lie. I am getting joint
following errors with the stock kernel and 15 minute maximum uptimes
with what purports to be a realtime kernel.
The stocker so far has just sat there and ducked everything I've
thrown at it. So this particular rt build is a very fragile bust
IMNSHO. This kernel is crap: rpi3-kernel-4.9.30-rt20-v7+.tar.gz,
uptimes are as short as 30 seconds even with my air hose keeping
everything at ambient. And latency-test results in the 2 millisecond
jitter area.
I think we should try 4.4.4-rt9-v7+. It looks like a stable version
(currently running here).
I don't seem to have that one. Hows the keyboard and mouse doing?

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)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Bertho Stultiens
2017-06-12 21:36:08 UTC
Permalink
Post by Gene Heskett
Post by Bertho Stultiens
I think we should try 4.4.4-rt9-v7+. It looks like a stable version
(currently running here).
I don't seem to have that one. Hows the keyboard and mouse doing?
Smooth...

Sent PM with details how to install.
--
Greetings Bertho

(disclaimers are disclaimed)
Nicklas Karlsson
2017-06-13 05:34:54 UTC
Permalink
Maybe there is no need for a linux kernel. Have you read the manual for the
ARM CPU? Or what kind of CPU is it?
Post by Bertho Stultiens
Post by Gene Heskett
Post by Bertho Stultiens
I think we should try 4.4.4-rt9-v7+. It looks like a stable version
(currently running here).
I don't seem to have that one. Hows the keyboard and mouse doing?
Smooth...
Sent PM with details how to install.
--
Greetings Bertho
(disclaimers are disclaimed)
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
Bertho Stultiens
2017-06-13 06:58:18 UTC
Permalink
Post by Nicklas Karlsson
Maybe there is no need for a linux kernel. Have you read the manual for the
ARM CPU? Or what kind of CPU is it?
RPI3 uses a quad-core ARMv8 (Cortex-A53) with all kinds of bells and
whistles. Have you read the manual for that core?

I've been using many of those small ARM cores (M0...M4) from different
manufacturers and each is about a 1000 pages. The core in the RPI is
utterly more complex.

But, if that is not enough, there are so many internal and external
peripherals that you need to go through all other documentation too.
Designing and writing a bare-bone OS is an uphill battle and you do not
want to do that if there is no /extremely/ specific need.

Linux provides an infrastructure that is very hard to write yourself,
like file-system, network, process- and memory-management to name a few.
Just consider the amount of dev-time that is put into Linux.

Surely, there are other OSes, but it is all about support and a very
large community's effort to pool and combine resources.
--
Greetings Bertho

(disclaimers are disclaimed)
Nicklas Karlsson
2017-06-13 15:31:47 UTC
Permalink
Post by Bertho Stultiens
Post by Nicklas Karlsson
Maybe there is no need for a linux kernel. Have you read the manual for the
ARM CPU? Or what kind of CPU is it?
RPI3 uses a quad-core ARMv8 (Cortex-A53) with all kinds of bells and
whistles. Have you read the manual for that core?
No and I did not read the manual for the smaller cortex-m* cores either even though I use them daily.
Post by Bertho Stultiens
I've been using many of those small ARM cores (M0...M4) from different
manufacturers and each is about a 1000 pages. The core in the RPI is
utterly more complex.
I have only read manual for a few of the peripherals I use and that's enough.
Post by Bertho Stultiens
But, if that is not enough, there are so many internal and external
peripherals that you need to go through all other documentation too.
Designing and writing a bare-bone OS is an uphill battle and you do not
want to do that if there is no /extremely/ specific need.
Linux provides an infrastructure that is very hard to write yourself,
like file-system, network, process- and memory-management to name a few.
Just consider the amount of dev-time that is put into Linux.
In no doubt there are plenty of infra structure and if the infrastructure is needed there are not much choice. I think there is need for only one task and have been looking on some of the smaller micro controllers.
Chris Albertson
2017-06-13 16:19:32 UTC
Permalink
If you are looking for a small uP to use as a real-time controller, today
in 2017 its the ARM cortex M. The range is wide enough that you can find
one to suit. At the low end there is nothing to be gained by going with
say, Atmel AVR or some other 8-bit chip and at the high end are some 32-bit
200MHz chips.

Cortex M does not run Linux and that is the good thing if doing real-time.
But still I'd NEVER write to the "bare metal". Not only is that very time
consuming but then your code is forever tried to one specific chip. In
stead choose a good RTOS to run on the Cortex M. This will come with a
very light weight hardware abstraction that will let you do things like
connect a timer output to a specific pin in a portable way

Yes you can work with only one loop to task but many times your work is
made easier and you introduce fewer bugs if you divide the job into
multiple tasks. For example monitoring limit switches while generating
pluses and at the same time reading commands over a serial link and also
maybe even writing to a debug log file that lives on an SD card.

On my robot platforms I have 4 or 6 wheels each driven with a DC servo
motor from a LiPo battery. The Cortex M gets commands from a Linux
powered Pi3. The commands are in the form of translation and rotation
vectors. The ARM M converts this to motor currents for each motor and
reads the motor encoders and create PWM for the motor h-bridge controllers.
I'm using an RTOS and writing in C++. The M4 under an RTOS is fast
enough to run 4 PID loops, generate PWM and service 11,000 interrupts per
second from four quadrature encoders and also read a 9-axis IMU, update a
small LCD status display and write to the debug log.

I have several different ARM M boards some M3 and some M4 from low to high
end from a couple different manufactures and the code moves between boards

I learned long ago that portability is impotent. Suppliers change their
product and you want to be able to take advantage of newer advances in uP
as they come out.



On Tue, Jun 13, 2017 at 8:31 AM, Nicklas Karlsson <
Post by Gene Heskett
Post by Bertho Stultiens
Post by Nicklas Karlsson
Maybe there is no need for a linux kernel. Have you read the manual
for the
Post by Bertho Stultiens
Post by Nicklas Karlsson
ARM CPU? Or what kind of CPU is it?
RPI3 uses a quad-core ARMv8 (Cortex-A53) with all kinds of bells and
whistles. Have you read the manual for that core?
No and I did not read the manual for the smaller cortex-m* cores either
even though I use them daily.
Post by Bertho Stultiens
I've been using many of those small ARM cores (M0...M4) from different
manufacturers and each is about a 1000 pages. The core in the RPI is
utterly more complex.
I have only read manual for a few of the peripherals I use and that's enough.
Post by Bertho Stultiens
But, if that is not enough, there are so many internal and external
peripherals that you need to go through all other documentation too.
Designing and writing a bare-bone OS is an uphill battle and you do not
want to do that if there is no /extremely/ specific need.
Linux provides an infrastructure that is very hard to write yourself,
like file-system, network, process- and memory-management to name a few.
Just consider the amount of dev-time that is put into Linux.
In no doubt there are plenty of infra structure and if the infrastructure
is needed there are not much choice. I think there is need for only one
task and have been looking on some of the smaller micro controllers.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Emc-users mailing list
https://lists.sourceforge.net/lists/listinfo/emc-users
--
Chris Albertson
Redondo Beach, California
Loading...