Config error for Probotix cape. 'PRU control files not found in /sys/class/uio/uio0'

[Nick Collier]

I am trying to get a BBB A6A running with some config files that are written for a Probotix cape.

This bit of code in the shell scrip setup.sh is generating an error when I run Machinekit

if [ ! -r /sys/class/uio/uio0 ] ; then
    echo PRU control files not found in /sys/class/uio/uio0 >&2
    exit 1;
fi

Do I need to install the files for the PRU? If so how do i do this?

I have attached the full error message and some of the relevant config files.

[Charles Steinkuehler]

On 4/27/2017 10:26 AM, 'Nick Collier' via Machinekit wrote:
> I am trying to get a BBB A6A running with some config files that are written for
> a Probotix cape.
>
> This bit of code in the shell scrip setup.sh is generating an error when I run
> Machinekit
>
> if [ ! -r /sys/class/uio/uio0 ] ; then
> echo PRU control files not found in /sys/class/uio/uio0 >&2
> exit 1;
> fi
>
> Do I need to install the files for the PRU? If so how do i do this?

There's nothing to install for the PRU. The file it's looking for is
created in sysfs when the UIO PRU driver loads, which is triggered by
the device tree overlay.

> I have attached the full error message and some of the relevant config files.

It looks like everything is OK, you are using a 3.18 kernel and the
cape-universal overlay appears to have loaded.

What is in your slots file?

cat /sys/devices/bone_capemgr.*/slots

What is in /sys/class/uio?

ls -l /sys/class/uio


--
Charles Steinkuehler
cha...@steinkuehler.net

[Nick Collier]

Sorry for the late reply, I am new to Google Groups. I ended up deleting that version of Machinekit, and getting Probotix's own custom version, but I am having trouble with it because it is nearly 8GB and doesn't fit on my SD card. So I may go back to the version that this message was originally about.

[gburbeck]

Hi Charles/Nick

I too am having an issue with a PRU control files not found in /sys/class/uio/uio0 >&2 error - I'm not sure it this will help but I'll explain my findings from the little testing I have done today.

Yesterday I rebuilt my "bone-debian-8.5-machinekit-armhf-2016-07-18-4gb.img" based machinekit to the "bone-debian-8.7-machinekit-armhf-2017-02-12-4gb.img" and with a couple of small tweaks to the .hal and ,ini files I got it working.

When I rebooted this morning I got the PRU error.

I have now had a little time to investigate and find that on the second attempt of starting machinekit it works - this is consistent across multiple reboot attempts.

Happy to provide further input if requested.

@Charles - I'd also like to thank you for all you effort.  Reading your posts inspired me to get my linuxcnc system running on a Beaglebone and I am very grateful.

[Charles Steinkuehler]

On 5/2/2017 11:38 AM, gburbeck wrote:
> Hi Charles/Nick
>
> I too am having an issue with a PRU control files not found in
> /sys/class/uio/uio0 >&2 error - I'm not sure it this will help but I'll explain
> my findings from the little testing I have done today.
>
> Yesterday I rebuilt my "bone-debian-8.5-machinekit-armhf-2016-07-18-4gb.img"
> based machinekit to the "bone-debian-8.7-machinekit-armhf-2017-02-12-4gb.img"
> and with a couple of small tweaks to the .hal and ,ini files I got it working.
>
> When I rebooted this morning I got the PRU error.

So it's probably a kernel error, since the file that's gone missing is
in sysfs and the problem happens after a reboot.

What does "uname -a" report for your kernel version?

Is there anything at all in /sys/class/uio ?

...besides the kernel, it could also be an issue with the device tree
or maybe device naming conventions (ie: udev and friends), so it could
be that a user-space update or configuration change triggered the
problem even though it's related to the kernel.

--
Charles Steinkuehler
cha...@steinkuehler.net

[gburbeck]

so the output immediately after a reboot:

$ uname -a

Linux beaglebone 3.8.13-xenomai-r83 #1 Thu Jan 5 01:32:32 UTC 2017 armv71 GNU/Linux

$ ls -l /sys/class/uio

total 0

on trying to start machinekit -> the usual failure

inspected /sys/class/uio -> still empty

machinekit persistently failed to start

reboot and did the same as above

after the first failure

inspected /sys/class/uio -> populated with eight symlinks uio0-uio7

subsequent start of machinekit was successful

[Charles Steinkuehler]

On 5/2/2017 2:25 PM, gburbeck wrote:
> so the output immediately after a reboot:
>
> $ uname -a
>

> /Linux beaglebone 3.8.13-xenomai-r83 #1 Thu Jan 5 01:32:32 UTC 2017 armv71
> GNU/Linux/

That should be fine.

> on trying to start machinekit -> the usual failure
> inspected /sys/class/uio -> still empty
> machinekit persistently failed to start
>
> reboot and did the same as above
> after the first failure
> inspected /sys/class/uio -> populated with eight symlinks uio0-uio7
>
> subsequent start of machinekit was successful

Hmm...maybe it's just a timing issue. Can you try manually loading
the overlay prior to launching Machinekit? To do this, reboot, and
before you try to launch machinekit run:

config-pin overlay cape-universal

...then see if the uio devices are there. If they are, Machinekit
should start normally. If the uio symlinks aren't there, the problem
has something to do with the overlay not properly loading.

...but if it's a timing problem (the uio device symlinks taking too
long to show up), I'm not sure why they wouldn't eventually appear and
Machinekit ought to work if you tried launching it again.

--
Charles Steinkuehler
cha...@steinkuehler.net

[gburbeck]

yes the symklnks appeared after reloading the overlay and machinekit started ok

Tested:

• reboot
• check the /sys/class/uio folder every minute, or so, for a 5 minutes -> the symlinks didn't appear
• reloaded the overlay -> symlinks reappeared
• machinekit started ok

Tested:

• reboot
• check the /sys/class/uio folder after 10 minutes of total inactivity from reboot -> the symlinks didn't appear

• 
  

[Charles Steinkuehler]

You say "reloading the overlay", but unless you've changed something
the overlay isn't loaded at boot. The overlay is generally loaded the
first time setup.sh gets run.

So it sounds like there may need to be a bit of delay added to the
setup.sh to allow the sysfs files to appear, or you could configure
your uEnv.txt to load the overlay at boot time.

Exactly which configuration are you using? I can send you a modified
setup.sh to test.

On 5/3/2017 4:49 AM, gburbeck wrote:
> yes the symklnks appeared after reloading the overlay and machinekit started ok
>
> Tested:
>

> * reboot
> * check the /sys/class/uio folder every minute, or so, for a 5 minutes -> the
> symlinks didn't appear
> * reloaded the overlay -> symlinks reappeared
> * machinekit started ok
>
> Tested:
>
> * reboot
> * check the /sys/class/uio folder after 10 minutes of total inactivity from

> reboot -> the symlinks didn't appear
>
>

> *
>
>
>
>
>
>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io github:
> https://github.com/machinekit
> ---
> You received this message because you are subscribed to the Google Groups
> "Machinekit" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to machinekit+...@googlegroups.com
> <mailto:machinekit+...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/machinekit.
> For more options, visit https://groups.google.com/d/optout.
>


--
Charles Steinkuehler
cha...@steinkuehler.net

[gburbeck]

Hi Charles

I say 'reloading' loosely - thanks for the clarification.

It's a custom configuration based on:

• comet.hal
• Designspark Novamill0.hal in the article - upgrading-a-cnc-machine
• http://7xcnc.com/software/probing/z-touch-plate
• https://forum.linuxcnc.org/forum/10-advanced-configuration/5596-manual-tool-change-tool-lengh-touch-off?start=30#48235
  

I've attached the key configuration files.

I'm happy to test a new setup.sh file.

Whilst it's irritating to have to start machinekit twice in order to get it working, it's not the end of the world.  

[gburbeck]

I can confirm that adding an additional element of delay into the shell script does resolve the problem for me.

The change I made to the setup.sh:

. . . 

if grep -q $DTB0 $SLOTS ; then

echo $DTB0 overlay found

else

echo Loading $DTB0 overlay

sudo -A su -c "echo $DTB0 > $SLOTS" || dtbo_err

sleep 1.2

fi

. . .

Thanks for your help. 

[Nick Collier]

@gburbeck

I am back to this problem again, but it looks like you have solved it.

Do I simply need to add the delay into the .sh file?
Do I need to change anything else?
Are you using these config files? https://github.com/abopen/cnc-configs/tree/master/Novamill

[Charles Steinkuehler]

On 5/7/2017 3:59 PM, 'Nick Collier' via Machinekit wrote:
> @gburbeck
>
> I am back to this problem again, but it looks like you have solved it.
>
> Do I simply need to add the delay into the .sh file?

Adding a short delay seems to be the fix.

I'll add a polling loop with a timeout to the setup.sh file, but don't
have the time (pun intended) to do it right now...weekends are busy! :)

...anyone else feel free to dive in and make the change if you're
handy with shell scripting, just turn the check for the PRU UIO files
in sysfs into a polling loop with a sleep, and wait for a timeout
before it throws the error (instead of expecting the UIO file to be
there immediately after loading the overlay).

Another work-around is to load the cape-universal overly via your
uEnv.txt file instead of waiting to load it when you first launch
Machinekit.

--
Charles Steinkuehler
cha...@steinkuehler.net

[Frederic RIBLE]

Hello,

I have coded this kind of waiting loop for my emco120 retrofit project.
See attached "setup.sh" file, line #48 to #56

Also I have discovered that disabling some unused services can accelerate a lot the BBB boot time:

systemctl disable jekyll-autorun.service

systemctl disable bonescript-autorun.service

sudo service apache2 disable

Frederic.
http://cnc.f1oat.org

[gburbeck]

@Frederic

I can confirm that your waiting loop also worked for me - thanks, hopefully that will make the boot a little more predictable than simply applying a delay

However I did not find that jekyll-autorun.service or bonescript-autorun.service were running.  I did gracefully stop the apache2 server but didn't find that it made very much difference to the load time of machinekit.

@Nick

In terms of your PRU error: I would recommend using Frederic's solution rather than adding a simple delay.  

I did a compare between Frederic's setup.sh file and my own to ensure that I knew the full extent of the changes I needed to make.

I am afraid I'm not qualified to advise on your configuration - there was a lot of trial and error for me when I produced my configuration files as previously attached.  I did find this link from rs very useful:

• https://www.rs-online.com/designspark/upgrading-a-cnc-milling-machine-part-1 and then the subsequent sections 2 & 3

Sorry not to be able to help further.

[Nick Collier]

@gburbeck

Thank you, that works for me. So does starting Machinekit twice.
I am also using the Design Spark guide.
I need to read the Machinekit manual properly understand the config files.

[Alexander Rössler]

The delay is also used in the config-pin utility:

https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/config-pin#L883

However, the waiting loop seems to be the nicer solution.