Machinekit on the BeagleBone Green Wireless (BBGW) + CRAMPS

[Unai Antero]

Dear all,

trying to use a SeeedStudio BeagleBone Green Wireless (+ the CRAMPS board) to run machinekit, but without much success...

Tried using the SD image on https://rcn-ee.com/rootfs/bb.org/testing/2016-09-18/machinekit/bone-debian-8.6-machinekit-armhf-2016-09-18-4gb.img.xz , but although it works fine on a Beagle Bone Black, the BB Green Wireless refuses to boot (seems it doesn't like the 3.8 kernel...).

On a second attempt, was able to start from a fresh Debian Jessie on the BeagleBone Green Wireless (that uses the 4.4.9 kernel), installed the 4.4.9-bone-rt-r10 kernel, and installed machinekit-rt-preempt (apt-get install from packages at http://deb.machinekit.io/debian)

Machinekit tries to start the CRAMPS setup, but fails as it expects things to be in /sys/devices/bone_capemgr.*/slots .... and on this kernel, seems things are on /sys/devices/platform/bone_capemgr/slots (among other changes...)

Has anyone been able to run machinekit on the BeagleBone Green Wireless? 

Thanks

[Charles Steinkuehler]

I haven't worked with the Green. All of the cape and I/O
configuration is handled before machinekit really starts by launching
the "setup.sh" script at the top of the HAL file. You can edit this
script to work with the new kernel and/or just comment it from the HAL
file and setup things manually. To run the example CRAMPS setup, you
need the uio PRU driver loaded, the ADC driver loaded, and the I/O
pins setup to the appropriate mode (typically GPIO input or output).

Potential problems are with the PRU driver (some kernels have the uio
driver and some have the remoteproc version) and maybe the ADC (the
sysfs files for the ADC might have moved around in newer kernels, I'm
not sure). The I/O setup should be straight-forward, as the universal
overlay I use for the CRAMPS board is now included in all the
BeagleBone kernels. You may need to tweak something to get the
overlay loaded, but the same config-pin commands should work to setup
the I/O.

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

[Daren Schwenke]

I tried the same, with the same results.  I went back to using the BBB plus this.

Should be noted for all you will either need to remove the USB port where the Power port used to be, or use a set of headers to raise the CRAMPS board up as it doesn't clear it.

I should get back to figuring out why the BBGW fails in a week or so.

[Marius Alksnys]

I used BBG a lot with wheezy. AFAIK the flash type was not supported by
kernel. Changing some files in the image solved the problem.

But I did not ran jessie yet - neither base jessie image nor machinekit
image does not boot from uSD card.

Any progress on this?

[Daren Schwenke]

The new image boots now if I recall correctly.  The wifi chip doesn't work though, so not all that useful atm and I grew tired of working on it via serial.

The wifi driver for mere mortals currently only works with pre-packaged kernels, and xenomi wasn't one of them.

On Wednesday, September 28, 2016 at 6:10:09 AM UTC-4, Unai Antero wrote:

[Marius Alksnys]

I am using BBG without WiFi and I am happy with them. They just don't
have HDMI output.

[Daren Schwenke]

I've built about 80% of a garage sized, tripodkins cable driven, pellet fed 3D printer for making statues.  

If the BBGW's wifi worked, my steppers and the BBGW could be relocated to the flying bit and all that would need to tether it would be a power cord.  USB wifi makes the BBB unstable due to the USB reset bug, and I'm trying to avoid buying another micro router.

I'm eagerly awaiting someone figuring it out.  :)

On Wednesday, September 28, 2016 at 6:10:09 AM UTC-4, Unai Antero wrote:

[Doug LaRue]

On Friday, March 3, 2017 at 11:21:38 AM UTC-8, Daren Schwenke wrote:

I've built about 80% of a garage sized, tripodkins cable driven, pellet fed 3D printer for making statues.  

If the BBGW's wifi worked, my steppers and the BBGW could be relocated to the flying bit and all that would need to tether it would be a power cord.  USB wifi makes the BBB unstable due to the USB reset bug, and I'm trying to avoid buying another micro router.

I'm eagerly awaiting someone figuring it out.  :)

And I'm eager to see pictures and video of that machine!  

[Daren Schwenke]

scooter motor, 27:1 planetary drive extruder, nema23 4:1 planetary cable drives

OpenSCAD is my friend now.

The green part is printed in 50/50 ABS/nylon mixed.

I'll post another thread when it's done.

[Deemarc Burakitbumrung]

 I'm working on the similar things. I am using beaglebone black and with xenomai on linux 3.8.13 and I tried to use it with BBGW and yeah it refuse to boot and my SD card and boot with the image in emmc instead. Have you by any chance be able to run BBGW with 3.8.13?

Thanks

Deemarc B.
เมื่อ วันพุธที่ 28 กันยายน ค.ศ. 2016 17 นาฬิกา 10 นาที 09 วินาที UTC+7, Unai Antero เขียนว่า:

[Daren Schwenke]

I can confirm the both the BBG and BBGW will boot with this image from an SD card:  

https://rcn-ee.com/rootfs/bb.org/testing/2017-02-12/machinekit/bone-debian-8.7-machinekit-armhf-2017-02-12-4gb.img.xz

Getting wireless to actually work is a whole other ball game which I have yet to achieve, but at least the image boots now.

[Robert Nelson]

On Tue, Jul 25, 2017 at 8:43 PM, Daren Schwenke <darens...@gmail.com> wrote:
> I can confirm the both the BBG and BBGW will boot with this image from an SD
> card:
> https://rcn-ee.com/rootfs/bb.org/testing/2017-02-12/machinekit/bone-debian-8.7-machinekit-armhf-2017-02-12-4gb.img.xz
>
> Getting wireless to actually work is a whole other ball game which I have
> yet to achieve, but at least the image boots now.

Correct, that "3.8.x" based image will support the BBGW/BBBW but with
wireless disabled. To enable wireless, sadly you will need a v4.4.x+
kernel. While we have a xenomai based v4.4.x build, it's based on
Xenomai 3.0.x, and not the 2.6.x based Xenomai machinekit expects..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[Charles Steinkuehler]

Machinekit can also run with the 4.x preempt_rt kernel on the 'bone,
but the PRU driver hasn't been updated for the re-arranged files in
/sysfs so it won't work "out of the box".

...but there's a lot less coding to do to get a 4.x-rt kernel working
than the latest Xenomai kernel.

The Xenomai kernel will still have less IRQ latency and jitter, but
the -rt kernels have gotten *DRAMATICALLY* better in this regard than
when the 'Bone first came out (the "White" with no HDMI). Back then
the Xenomai kernel was pretty much required for decent performance,
but the Linux kernel on ARM has come a long way since then.

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

[Robert Nelson]

On Wed, Jul 26, 2017 at 10:32 AM, Charles Steinkuehler
<cha...@steinkuehler.net> wrote:
> On 7/26/2017 10:12 AM, Robert Nelson wrote:
>> On Tue, Jul 25, 2017 at 8:43 PM, Daren Schwenke <darens...@gmail.com> wrote:
>>> I can confirm the both the BBG and BBGW will boot with this image from an SD
>>> card:
>>> https://rcn-ee.com/rootfs/bb.org/testing/2017-02-12/machinekit/bone-debian-8.7-machinekit-armhf-2017-02-12-4gb.img.xz
>>>
>>> Getting wireless to actually work is a whole other ball game which I have
>>> yet to achieve, but at least the image boots now.
>>
>> Correct, that "3.8.x" based image will support the BBGW/BBBW but with
>> wireless disabled. To enable wireless, sadly you will need a v4.4.x+
>> kernel. While we have a xenomai based v4.4.x build, it's based on
>> Xenomai 3.0.x, and not the 2.6.x based Xenomai machinekit expects..
>
> Machinekit can also run with the 4.x preempt_rt kernel on the 'bone,
> but the PRU driver hasn't been updated for the re-arranged files in
> /sysfs so it won't work "out of the box".

What is it looking for in /sysfs? With the v4.4.x-rt we can enable the
3.8.13 compatible uio driver, then as long as config-pin is used, it
should sync up with what it use to do with 3.8.13..

[Charles Steinkuehler]

IIRC, several of the setup scripts are looking for the slots file to
verify/load an overlay, some code is looking for the ADC entries in
sysfs (which have moved IIRC), and the actual HAL driver for the PRU
may have a sysfs path or two hard-coded (I'd have to check).

So nothing really that complex (particularly vs. updating to Xenomai
3), but a 4.x kernel won't work without a few tweaks and maybe a bit
of coding.

Anyone with a BBG/BBGW want to try getting things running with a 4.x
kernel? I can provide guidance and maybe do the bit of coding if
someone's willing to help with the shell scripts and do testing.

Deemarc / Daren?

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

[Daren Schwenke]

I would be happy to help with this. 

Point me to an image I should use to get started and I'll have the physical up this evening.

My version of cross compiling is probably not what is used anymore, so I may need some help there as well.

--
website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit
---
You received this message because you are subscribed to a topic in the Google Groups "Machinekit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/machinekit/RrNLUo4ASP4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to machinekit+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.

[Charles Steinkuehler]

On 7/26/2017 2:03 PM, Daren Schwenke wrote:
> I would be happy to help with this.
> Point me to an image I should use to get started and I'll have the physical up
> this evening.

There are two options:

1) Add a 4.x-rt kernel to an existing Machinekit image. This is
probably the easiest way to get the 4.x kernel issues ironed out.

2) Add Machinekit to one of Robert's Jessie images that already uses a
4.x kernel. This makes the most sense if you're worried about getting
things like WiFi to work.

I'd recommend starting with a working configuration for the BBB and
switching to a 4.x kernel (#1). Make sure you add the machinekit
package for preempt-rt installed! Once a 4.x kernel is working with
Machinekit, approach #2 can be used to get WiFi and other new features
working.

Then I can craft a new image configuration for Robert and we'll get
back to having automatically built/updated images on eLinux.org.

Let me know what configuration you're working with and I'll try to
setup something similar here for testing.

> My version of cross compiling is probably not what is used anymore, so I may
> need some help there as well.

I don't think you will need to do much in the way of compiling, most
of the things that will need to be changed are just shell scripts.

I can modify and compile the PRU driver if you don't want to setup a
build environment (it's painfully slow on the BBB, at least for the
first build, and you may not have a higher-powered ARM system available).

The first hurdles you'll hit trying to run a 4.x kernel will be the
logic that's making sure the appropriate overlay(s) is(are) installed
and that the appropriate UIO devices are available (for the PRU and
maybe the A/D if you're running a 3D printer). If you can get past
these issues (which ought to just be shell scripting) it should be
pretty easy to get the PRU driver working.

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

[Bas de Bruijn]

On 26 Jul 2017, at 21:03, Daren Schwenke <darens...@gmail.com> wrote:

I would be happy to help with this. 

Point me to an image I should use to get started and I'll have the physical up this evening.

Thanks for helping out Daren!

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.

[Daren Schwenke]

This is in my best interest.  :)  

My tripodkins cable printer would be much nicer, without an Ethernet cable running to it.

To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscribe@googlegroups.com.

[Robert Nelson]

Here you go, fresh build with v4.4.x-ti-rt

https://rcn-ee.net/rootfs/bb.org/testing/2017-07-26/machinekit/bone-debian-8.9-machinekit-armhf-2017-07-26-4gb.img.xz

on first bootup, make sure u-boot overlays is active:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays

(it should be, but if your eMMC u-boot is too old it won't be)

To disable hdmi/emmc/etc:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Disable_on-board_devices

cape universal is setup to load automaticlly too. (config-pin doesn't
require root ;) )

This image also defaults to uio mode for the pru, so you won't have to
change, as it's setup correctly

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_PRU_Options

[Daren Schwenke]

Thank you all... 

You are doing me a favor, not the other way around.  

I'll have a BBGW and BBG loaded up and ssh-able for you gents as soon as I can open the ports on my "idiot proof" router.

Likely it will be 2am or tomorrow at this point though, but still.. Faster.

Plan is follow Robert's instructions, expand / to fill two 16gb SD cards, assign static IP's, and put them on the network.

Given the intent is to make an image, I should probably ask...  Should I even expand to fill 16gb?

Anything else specific you need to this goal, speak now.  (like swap, or a local i7 cross compiling linux host)

-Daren

[Charles Steinkuehler]

On 7/26/2017 8:15 PM, Daren Schwenke wrote:
> Thank you all...

> You are doing *me* a favor, not the other way around.

>
> I'll have a BBGW and BBG loaded up and ssh-able for you gents as soon as I can
> open the ports on my "idiot proof" router.
> Likely it will be 2am or tomorrow at this point though, but still.. Faster.
>
> Plan is follow Robert's instructions, expand / to fill two 16gb SD cards, assign
> static IP's, and put them on the network.
> Given the intent is to make an image, I should probably ask... Should I even
> expand to fill 16gb?

Partition size (beyond 4G) is not really significant. The image needs
to be created from original sources, so the important part is to get
things working, then we can figure out how to merge any required
changes into the image build scripts (and the ~4GB images they use
when building from scratch).

> Anything else specific you need to this goal, speak now. (like swap, or a local
> i7 cross compiling linux host)

I always add 1-2 GB of swap (depending on the uSD size), but it's
probably not a huge issue in your case. Cross compiling is nice, but
likely more trouble than it's worth unless you already have something
setup.

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

[Daren Schwenke]

I did (cross compiling), but honesty I can't remember what i had setup. I'll add swap.

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

[Daren Schwenke]

Well the ethernet over usb isn't coming up like it should, I can't seem to get wireless configured via connmanctl via scripts, and my serial->usb thingy has gone missing.

So I've been going back and forth editing the ssd config files booting, shutting down, then reading the logs... this is getting old.

The ethernet over usb appears to configure itself in the logs on the BBGW, and on the PC side they get created as eth6 and eth7, but they don't get an IP assigned.

Assigning one manually doesn't work.

[Charles Steinkuehler]

Are you using the image Robert created?

https://rcn-ee.net/rootfs/bb.org/testing/2017-07-26/machinekit/bone-debian-8.9-machinekit-armhf-2017-07-26-4gb.img.xz

...I'd hope that has the proper setup logic to handle the BBG/BBGW.

On 7/27/2017 3:28 PM, Daren Schwenke wrote:
> Well the ethernet over usb isn't coming up like it should, I can't seem to get
> wireless configured via connmanctl via scripts, and my serial->usb thingy has
> gone missing.
> So I've been going back and forth editing the ssd config files booting, shutting
> down, then reading the logs... this is getting old.
>
> The ethernet over usb appears to configure itself in the logs on the BBGW, and
> on the PC side they get created as eth6 and eth7, but they don't get an IP assigned.
> Assigning one manually doesn't work.
>
> On Wednesday, July 26, 2017 at 11:15:21 PM UTC-4, Daren Schwenke wrote:
>
> I did (cross compiling), but honesty I can't remember what i had setup. I'll
> add swap.
>
> On Jul 26, 2017 21:27, "Charles Steinkuehler" <cha...@steinkuehler.net

> cha...@steinkuehler.net <mailto:cha...@steinkuehler.net>

>
> --
> website: http://www.machinekit.io blog: http://blog.machinekit.io
> github: https://github.com/machinekit
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Machinekit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/machinekit/RrNLUo4ASP4/unsubscribe

> <https://groups.google.com/d/topic/machinekit/RrNLUo4ASP4/unsubscribe>.

> To unsubscribe from this group and all its topics, send an email to

> machinekit+...@googlegroups.com
> <mailto:machinekit%2Bunsu...@googlegroups.com>.

> Visit this group at https://groups.google.com/group/machinekit

> <https://groups.google.com/group/machinekit>.

> For more options, visit https://groups.google.com/d/optout

> <https://groups.google.com/d/optout>.

>
>
> --
> 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

[Daren Schwenke]

It probably does.  It's just hard to configure headless, without a connection, using connman (which I've never done).

We can come back to that.  It seems to recognize the wilink device fine, so the rest is just mechanics.

In the mean time I've brought up the BBG instead and opened ssh to it.  I'll send the address privately.

> <mailto:machinekit+unsub...@googlegroups.com>.

[Daren Schwenke]

$ cat /etc/dogtag

Machinekit Debian Image 2017-07-26

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ uname -a

Linux beaglebone 4.4.68-ti-rt-r112 #1 SMP PREEMPT RT Sun Jul 23 12:27:13 UTC 2017 armv7l GNU/Linux

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ ./run.py

loading cramps2_cape.bbio... P8_07 pinmux file not found!

WARNING: GPIO pin not exported, cannot set direction or value!

sudo: no askpass program specified, try setting SUDO_ASKPASS

Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P8_07_pinmux/state

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ 

[Charles Steinkuehler]

On 7/28/2017 8:37 AM, Daren Schwenke wrote:
> $ cat /etc/dogtag
> Machinekit Debian Image 2017-07-26
>
> machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ uname
> -a
> Linux beaglebone 4.4.68-ti-rt-r112 #1 SMP PREEMPT RT Sun Jul 23 12:27:13 UTC
> 2017 armv7l GNU/Linux
>
> machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ ./run.py
> loading cramps2_cape.bbio... P8_07 pinmux file not found!
> WARNING: GPIO pin not exported, cannot set direction or value!
> sudo: no askpass program specified, try setting SUDO_ASKPASS
> Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P8_07_pinmux/state
> machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$

It's having problems loading the universal overlay, which isn't
surprising. The overlay should be loaded via U-Boot rather than the
startup script, follow Robert's directions for that (in a previous
email on this thread, or available at the eLinux site).

Is your configuration available somewhere so I can try running the
same thing on a BBB?

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

[Robert Nelson]

For wifi:

we were missing the wl18xx firmware:

https://github.com/RobertCNelson/omap-image-builder/commit/f62b58ff6d82f04e97fcf51521308e401cd1e7f3

for config-pin, you guys call with the "-f" option, which add's

overlay cape-universal
overlay cape-bone-iio
#overlay cape-univ-emmc

https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS/CRAMPS.bbio#L3-L5

let me patch config-pin locally, so that it'll ignore the "overlay" file when:

/bin/grep -c bone_capemgr.uboot_capemgr_enabled=1 /proc/cmdline

so you guys don't have to change anything ;)

[Robert Nelson]

Oh, and you can dump your current kernel/uboot combination with:

sudo /opt/scripts/tools/version.sh

git:/opt/scripts/:[a6e52fdbb7f0d94c04f3973725a85fc4d99a7858]
eeprom:[A335BNLTBBG1BBG217042340]
dogtag:[Machinekit Debian Image 2017-07-26]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
2017.07-00002-g61c3ee0fb5]
kernel:[4.4.68-ti-rt-r112]
nodejs:[v0.10.42]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_emmc=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20170630.1-0rcnee1~jessie+20170719]
WARNING:pkg:[bb-wl18xx-firmware]:[NOT_INSTALLED]
WARNING:pkg:[firmware-ti-connectivity]:[NOT_INSTALLED]

[Robert Nelson]

this should fix config-pin:

https://github.com/beagleboard/bb.org-overlays/commit/40b386724c19bbff3e7c0295d183544814eb4f95

started a *.deb package build for that..

[Charles Steinkuehler]

On 7/28/2017 9:50 AM, Robert Nelson wrote:
>
> this should fix config-pin:
>
> https://github.com/beagleboard/bb.org-overlays/commit/40b386724c19bbff3e7c0295d183544814eb4f95
>
> started a *.deb package build for that..

Thanks Robert!!!

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

[Daren Schwenke]

Thought it was like you said, but here goes:

$ sudo /opt/scripts/tools/version.sh

[sudo] password for machinekit: 

git:/opt/scripts/:[f898b97580b93fab9d71399fd4c6555e77e7bcfc]

eeprom:[A335BNLTBBG1BBG217013823]

dogtag:[Machinekit Debian Image 2017-07-26]

bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2017.07-00002-g61c3ee0fb5]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2016.03-00001-gd12d09f]

kernel:[4.4.68-ti-rt-r112]

nodejs:[v0.10.42]

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]

uboot_overlay_options:[enable_uboot_cape_universal=1]

pkg:[bb-cape-overlays]:[4.4.20170630.1-0rcnee1~jessie+20170719]

WARNING:pkg:[bb-wl18xx-firmware]:[NOT_INSTALLED]

WARNING:pkg:[firmware-ti-connectivity]:[NOT_INSTALLED]

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS

[Charles Steinkuehler]

You should add the missing packages from Robert's recent commit:

https://github.com/RobertCNelson/omap-image-builder/commit/f62b58ff6d82f04e97fcf51521308e401cd1e7f3

sudo apt-get install \
bc \
iw \
rfkill \
bb-wl18xx-firmware \
libgl1-mesa-dri

...which ought to help get WiFi working.

Then do an apt-get update/upgrade to get Robert's new config-pin changes.

With that you ought to get a bit further with loading your configuration.

> --
> 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>.

[Robert Nelson]

On Fri, Jul 28, 2017 at 10:06 AM, Daren Schwenke
<darens...@gmail.com> wrote:
> Thought it was like you said, but here goes:
> $ sudo /opt/scripts/tools/version.sh
> [sudo] password for machinekit:
> git:/opt/scripts/:[f898b97580b93fab9d71399fd4c6555e77e7bcfc]
> eeprom:[A335BNLTBBG1BBG217013823]
> dogtag:[Machinekit Debian Image 2017-07-26]

> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
> 2017.07-00002-g61c3ee0fb5]
> bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2016.03-00001-gd12d09f]

This will also create a problem. Your version u-boot in the eMMC is
too old, so it's going to conflict with u-boot overlays..

sudo dd if=/dev/zero of=/dev/mmcblk1 count=1 seek=1 bs=128k

Will remove the "mlo" file in the eMMC..

> kernel:[4.4.68-ti-rt-r112]
> nodejs:[v0.10.42]
> uboot_overlay_options:[enable_uboot_overlays=1]
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg:[bb-cape-overlays]:[4.4.20170630.1-0rcnee1~jessie+20170719]
> WARNING:pkg:[bb-wl18xx-firmware]:[NOT_INSTALLED]
> WARNING:pkg:[firmware-ti-connectivity]:[NOT_INSTALLED]
> machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS

if you run:

sudo apt update ; sudo apt upgrade

you'll get the config-pin update too. ;)

[Robert Nelson]

looks like the "-f" parameter is broken:

machinekit@beaglebone:~$ config-pin -q P8_07 ; config-pin -q P9_42
P8_07 Mode: default Direction: in Value: 1
P9_42 Mode: default Direction: in Value: 0
machinekit@beaglebone:~$ config-pin -f CRAMPS.bbio
machinekit@beaglebone:~$ config-pin -q P8_07 ; config-pin -q P9_42
P8_07 Mode: default Direction: in Value: 1
P9_42 Mode: default Direction: in Value: 0

machinekit@beaglebone:~$ config-pin P9_42 spics
machinekit@beaglebone:~$ config-pin -q P9_42
P9_42 Mode: spics

Here's the log:

+ AUTOLOAD=0
+ getopts adfhl:q:i: opt
+ CMD=file
+ getopts adfhl:q:i: opt
+ expr 2 - 1
+ shift 1
+ echo_dbg AUTOLOAD=0
+ [ -n ]
+ echo_dbg Args: CRAMPS.bbio
+ [ -n ]
+ readfile CRAMPS.bbio
+ [ ! -r CRAMPS.bbio ]
+ exec
+ read PIN MODE JUNK
+ exit 0


full log:

https://paste.debian.net/978663/

[Daren Schwenke]

The rest was done.  Update, upgrade, packages, reboot.  Result:

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ sudo /opt/scripts/tools/version.sh

git:/opt/scripts/:[f898b97580b93fab9d71399fd4c6555e77e7bcfc]

eeprom:[A335BNLTBBG1BBG217013823]

dogtag:[Machinekit Debian Image 2017-07-26]

bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2017.07-00002-g61c3ee0fb5]

bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2016.03-00001-gd12d09f]

kernel:[4.4.68-ti-rt-r112]

nodejs:[v0.10.42]

uboot_overlay_options:[enable_uboot_overlays=1]

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo]

uboot_overlay_options:[enable_uboot_cape_universal=1]

pkg:[bb-cape-overlays]:[4.4.20170728.0-0rcnee1~jessie+20170728]

pkg:[bb-wl18xx-firmware]:[1.20170727-0rcnee0~jessie+20170727]

pkg:[firmware-ti-connectivity]:[20161130-3]

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ ./run.py 

loading cramps2_cape.bbio... P8_07 pinmux file not found!

WARNING: GPIO pin not exported, cannot set direction or value!

bash: /sys/devices/platform/ocp/ocp*P8_07_pinmux/state: No such file or directory

Cannot write pinmux file: /sys/devices/platform/ocp/ocp*P8_07_pinmux/state

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ sudo dd if=/dev/zero of=/dev/mmcblk1 count=1 seek=1 bs=128k

1+0 records in

1+0 records out

131072 bytes (131 kB) copied, 0.0300359 s, 4.4 MB/s

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ sudo reboot

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ ./run.py

loading cramps2_cape.bbio... done

starting configserver... done

starting linuxcnc... MACHINEKIT - 0.1

Machine configuration directory is '/home/machinekit/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS'

Machine configuration file is 'fabrikator-mini.ini'

Starting Machinekit...

done

io started

halcmd loadusr io started

Traceback (most recent call last):

  File "fabrikator_mini.py", line 20, in <module>

    hardware.init_hardware()

  File "/home/machinekit/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS/cramps.py", line 26, in init_hardware

    prucode=prubin, halname='hpg')

  File "machinekit/rtapi.pyx", line 219, in machinekit.rtapi.RTAPIcommand.loadrt (hal/cython/machinekit/rtapi.c:4636)

RuntimeError: rtapi_loadrt '('hal_pru_generic', 'pru=0', 'num_pwmgens=6', 'num_stepgens=6', 'halname=hpg', 'prucode=/home/machinekit/machinekit/rtlib/xenomai/pru_generic.bin')' failed: Operation not permitted

Shutting down and cleaning up Machinekit...

Cleanup done

Machinekit terminated with an error.  You can find more information in the log:

    /home/machinekit/linuxcnc_debug.txt

and

    /home/machinekit/linuxcnc_print.txt

as well as in the output of the shell command 'dmesg' and in the terminal

stopping configserver... done

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$

[Robert Nelson]

nm that was a brain fart, file was zero size:

machinekit@beaglebone:~$ config-pin -q P8_07 ; config-pin -q P9_42
P8_07 Mode: default Direction: in Value: 1

P9_42 Mode: spics

machinekit@beaglebone:~$ config-pin -f CRAMPS.bbio
machinekit@beaglebone:~$ config-pin -q P8_07 ; config-pin -q P9_42

P8_07 Mode: gpio Direction: in Value: 0
P9_42 Mode: spics

-f works fine when the file is what it actually is...

[Charles Steinkuehler]

On 7/28/2017 10:46 AM, Daren Schwenke wrote:
>
> machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ ./run.py

Can you provide a link to your full configuration?

I'm not sure what the run.py script is doing. It needs to be using
the config-pin utility and not trying to directly manipulate the sysfs
entries (which have moved since 3.8, IIRC).

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

[Robert Nelson]

On Fri, Jul 28, 2017 at 10:50 AM, Charles Steinkuehler
<cha...@steinkuehler.net> wrote:
> On 7/28/2017 10:46 AM, Daren Schwenke wrote:
>>
>> machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ ./run.py
>
> Can you provide a link to your full configuration?
>
> I'm not sure what the run.py script is doing. It needs to be using
> the config-pin utility and not trying to directly manipulate the sysfs
> entries (which have moved since 3.8, IIRC).

i found it here:

https://github.com/machinekit/machinekit/tree/master/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS

and

https://github.com/machinekit/machinekit/blob/master/lib/python/machinekit/launcher.py#L132

it's just calling "config-pin -f <filename>" to setup the pins..

[Robert Nelson]

so it was trying to load the uio firmware.. i bet it needs to call sudo..

> Shutting down and cleaning up Machinekit...
> Cleanup done
> Machinekit terminated with an error. You can find more information in the
> log:
> /home/machinekit/linuxcnc_debug.txt
> and
> /home/machinekit/linuxcnc_print.txt

can we get these?

[Daren Schwenke]

I'm running the included configs.  If you want me to pick another one, let me know.

I had the same problem with this config earlier though, on a working setup.  I tried the MendelMax-CRAMPS version and it worked before though.  Now it doesn't.

I'll try whatever headless config you want.  Just pick.

[Robert Nelson]

Charles, do you remember where the pru firmware call to "load" the firmware is..

one thing i noticed, is the permissions on uio:

machinekit@beaglebone:~$ ls -lha /sys/class/uio/
total 0
drwxr-xr-x 2 root root 0 Jul 28 16:03 .
drwxr-xr-x 55 root root 0 Jul 28 15:32 ..
lrwxrwxrwx 1 root root 0 Jul 28 16:03 uio0 ->
../../devices/platform/ocp/4a300000.pruss/uio/uio0
lrwxrwxrwx 1 root root 0 Jul 28 16:03 uio1 ->
../../devices/platform/ocp/4a300000.pruss/uio/uio1
lrwxrwxrwx 1 root root 0 Jul 28 16:03 uio2 ->
../../devices/platform/ocp/4a300000.pruss/uio/uio2
lrwxrwxrwx 1 root root 0 Jul 28 16:03 uio3 ->
../../devices/platform/ocp/4a300000.pruss/uio/uio3
lrwxrwxrwx 1 root root 0 Jul 28 16:03 uio4 ->
../../devices/platform/ocp/4a300000.pruss/uio/uio4
lrwxrwxrwx 1 root root 0 Jul 28 16:03 uio5 ->
../../devices/platform/ocp/4a300000.pruss/uio/uio5
lrwxrwxrwx 1 root root 0 Jul 28 16:03 uio6 ->
../../devices/platform/ocp/4a300000.pruss/uio/uio6
lrwxrwxrwx 1 root root 0 Jul 28 16:03 uio7 ->
../../devices/platform/ocp/4a300000.pruss/uio/uio7

i'll move them to something like what i did for gpio:

machinekit@beaglebone:~$ ls -lha /sys/class/gpio/
total 0
drwxrwxr-x 2 root gpio 0 Jul 28 15:34 .
drwxr-xr-x 55 root root 0 Jul 28 16:03 ..
-rw-rw---- 1 root gpio 4.0K Jul 28 15:34 export
lrwxrwxrwx 1 root gpio 0 Jul 28 15:34 gpio10 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio10
lrwxrwxrwx 1 root gpio 0 Jul 28 15:34 gpio11 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpio11


where machinekit is part of the gpio group:

[Daren Schwenke]

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ ls

cramps2_cape.bbio  cramps.py   fabrikator-mini.ini  launcher.ini  run.py       tool.tbl

CRAMPS.bbio        cramps.pyc  fabrikator_mini.py   README.md     storage.ini

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ cat /home/machinekit/linuxcnc_debug.txt

Can not find -sec DISPLAY -var INTRO_GRAPHIC -num 1 

5713

  PID TTY      STAT   TIME COMMAND

Stopping realtime threads

Unloading hal components

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ cat /home/machinekit/linuxcnc_print.txt

RUN_IN_PLACE=yes

LINUXCNC_DIR=

LINUXCNC_BIN_DIR=/home/machinekit/machinekit/bin

LINUXCNC_TCL_DIR=/home/machinekit/machinekit/tcl

LINUXCNC_SCRIPT_DIR=

LINUXCNC_RTLIB_DIR=/home/machinekit/machinekit/rtlib

LINUXCNC_CONFIG_DIR=

LINUXCNC_LANG_DIR=/home/machinekit/machinekit/src/objects

INIVAR=/home/machinekit/machinekit/libexec/inivar

HALCMD=halcmd

LINUXCNC_EMCSH=/usr/bin/wish8.6

INIFILE=/home/machinekit/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS/fabrikator-mini.ini

PARAMETER_FILE=pru-stepper.var

TASK=milltask

HALUI=

DISPLAY=mkwrapper

Starting Machinekit server program: linuxcncsvr

Loading Real Time OS, RTAPI, and HAL_LIB modules

Starting Machinekit IO program: io

Killing task linuxcncsvr, PID=5713

Removing HAL_LIB, RTAPI, and Real Time OS modules

Removing NML shared memory segments

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$

[Charles Steinkuehler]

On 7/28/2017 11:07 AM, Robert Nelson wrote:
> On Fri, Jul 28, 2017 at 10:55 AM, Robert Nelson <robert...@gmail.com> wrote:
>>
>> so it was trying to load the uio firmware.. i bet it needs to call sudo..

The real-time code loading the HAL modules (including the PRU driver)
should have root permissions. In the old days (and still with
LinuxCNC if using an RTAI kernel), the HAL components are actually
kernel modules and have to be loaded as root.

> Charles, do you remember where the pru firmware call to "load" the firmware is..

The PRU driver is using the prussdrv library:

https://github.com/machinekit/machinekit/tree/master/src/hal/support/pru

...and does most of it's setup in pru_init():

https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/hal_pru_generic.c#L385

...and setup_pru():

https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/hal_pru_generic.c#L447

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

[Daren Schwenke]

About the only thing I did outside of what you already know was to remove lightdm, as it was restarting continuously and sucking 30% proc when it did.  

I imagine being headless has something to do with it. Might need a check to see if we are headless and prevent lightdm from starting.

[Charles Steinkuehler]

...and the actual firmware load is performed by the call to
prussdrv_exec_program on line 486:

https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/hal_pru_generic.c#L486

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

[Daren Schwenke]

After the dd, it now takes a seriously long time to boot.  

Before it was ~45 seconds till it was back on the network.  Now it takes around 5 minutes.

[Daren Schwenke]

interesting?

[    3.146489] random: udevadm: uninitialized urandom read (16 bytes read, 3 bits of entropy available

)

[  118.238687] PM: Starting manual resume from disk

[  118.238732] PM: Hibernation image partition 179:2 present

[  118.238743] PM: Looking for hibernation image.

[  118.240337] PM: Image not found (code -22)

[  118.240367] PM: Hibernation image not present or could not be loaded.

[  119.965505] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)

[  120.711221] systemd[1]: System time before build time, advancing clock.

[Charles Steinkuehler]

On 7/28/2017 12:59 PM, Daren Schwenke wrote:
> After the dd, it now takes a seriously long time to boot.
> Before it was ~45 seconds till it was back on the network. Now it takes around
> 5 minutes.

I'd suggest reinstalling U-Boot on the eMMC. You can do this by hand,
but the easiest way is probably just to run one of the recent
"flasher" images (assuming you don't care about what's currently on
the eMMC).

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

[Daren Schwenke]

I'll try that.

Loaded up my non-pythonic config for kicks, and I get a similar error to the canned configs:

machinekit@beaglebone:~/Arcus-3D-M2$ ./run.py

loading cramps_cape.bbio... done

installing reset.comp... Compiling realtime reset.c

Linking reset.so

cp reset.so /home/machinekit/machinekit/rtlib/rt-preempt/

done

starting configserver... done

starting linuxcnc... MACHINEKIT - 0.1

Machine configuration directory is '/home/machinekit/Arcus-3D-M2'

Machine configuration file is 'Arcus-3D-M2.ini'

Starting Machinekit...

done

io started

halcmd loadusr io started

Arcus-3D-M2.hal:31: insmod failed, returned -1:

rtapi_app_main(hal_pru_generic): -1 Operation not permitted

See /var/log/linuxcnc.log for more information.

Shutting down and cleaning up Machinekit...

Cleanup done

Machinekit terminated with an error.  You can find more information in the log:

    /home/machinekit/linuxcnc_debug.txt

and

    /home/machinekit/linuxcnc_print.txt

as well as in the output of the shell command 'dmesg' and in the terminal

stopping configserver... done

machinekit@beaglebone:~/Arcus-3D-M2$ 

machinekit@beaglebone:~/Arcus-3D-M2$ cat /home/machinekit/linuxcnc_debug.txt

Can not find -sec DISPLAY -var INTRO_GRAPHIC -num 1 

3716

  PID TTY      STAT   TIME COMMAND

Stopping realtime threads

Unloading hal components

machinekit@beaglebone:~/Arcus-3D-M2$ cat /home/machinekit/linuxcnc_print.txt

RUN_IN_PLACE=yes

LINUXCNC_DIR=

LINUXCNC_BIN_DIR=/home/machinekit/machinekit/bin

LINUXCNC_TCL_DIR=/home/machinekit/machinekit/tcl

LINUXCNC_SCRIPT_DIR=

LINUXCNC_RTLIB_DIR=/home/machinekit/machinekit/rtlib

LINUXCNC_CONFIG_DIR=

LINUXCNC_LANG_DIR=/home/machinekit/machinekit/src/objects

INIVAR=/home/machinekit/machinekit/libexec/inivar

HALCMD=halcmd

LINUXCNC_EMCSH=/usr/bin/wish8.6

INIFILE=/home/machinekit/Arcus-3D-M2/Arcus-3D-M2.ini

PARAMETER_FILE=../pru-stepper.var

TASK=milltask

HALUI=

DISPLAY=mkwrapper

Starting Machinekit server program: linuxcncsvr

Loading Real Time OS, RTAPI, and HAL_LIB modules

Starting Machinekit IO program: io

Killing task linuxcncsvr, PID=3716

Removing HAL_LIB, RTAPI, and Real Time OS modules

Removing NML shared memory segments

machinekit@beaglebone:~/Arcus-3D-M2$ cat /var/log/linuxcnc.log

Jul 28 18:15:37 beaglebone msgd:0: startup pid=3745 flavor=rt-preempt rtlevel=1 usrlevel=1 halsize=524288 shm=Posix cc=gcc 4.9.2  version=unknown

Jul 28 18:15:37 beaglebone msgd:0: ØMQ=4.0.5 czmq=3.0.2 protobuf=2.6.1 atomics=gcc intrinsics    libwebsockets=<no version symbol>

Jul 28 18:15:37 beaglebone msgd:0: configured: sha=86bb58c

Jul 28 18:15:37 beaglebone msgd:0: built:      Jul 28 2017 01:01:30 sha=86bb58c

Jul 28 18:15:37 beaglebone msgd:0: register_stuff: actual hostname as announced by avahi='beaglebone.local'

Jul 28 18:15:37 beaglebone msgd:0: zeroconf: registering: 'Log service on beaglebone.local pid 3745'

Jul 28 18:15:38 beaglebone msgd:0: zeroconf: registered 'Log service on beaglebone.local pid 3745' _machinekit._tcp 49152 TXT "uuid=a42c8c6b-4025-4f83-ba28-dad21114744a" "instance=c15230da-73c0-11e7-8ecb-985dad518a99" "service=log" "dsn=tcp://beaglebone.local:49152"

Jul 28 18:15:38 beaglebone rtapi:0: rtapi_app_main(hal_pru_generic): -1 Operation not permitted

Jul 28 18:15:43 beaglebone rtapi:0: unload: 'tp' not loaded

Jul 28 18:15:43 beaglebone rtapi:0: unload: 'lineardeltakins' not loaded

Jul 28 18:15:43 beaglebone rtapi:0: unload: 'motmod' not loaded

Jul 28 18:15:43 beaglebone rtapi:0: unload: 'hal_bb_gpio' not loaded

Jul 28 18:15:43 beaglebone msgd:0: rtapi_app exit detected - scheduled shutdown

Jul 28 18:15:45 beaglebone msgd:0: msgd shutting down

Jul 28 18:15:45 beaglebone msgd:0: zeroconf: unregistering 'Log service on beaglebone.local pid 3745'

Jul 28 18:15:45 beaglebone msgd:0: log buffer hwm: 0% (0 msgs, 0 bytes out of 524288)

Jul 28 18:15:45 beaglebone msgd:0: normal shutdown - global segment detached

machinekit@beaglebone:~/Arcus-3D-M2$ date

Fri Jul 28 18:19:11 UTC 2017

[Charles Steinkuehler]

On 7/28/2017 1:20 PM, Daren Schwenke wrote:
> I'll try that.
> Loaded up my non-pythonic config for kicks, and I get a similar error to the
> canned configs:

<snip>

> halcmd loadusr io started
> Arcus-3D-M2.hal:31: insmod failed, returned -1:
> rtapi_app_main(hal_pru_generic): -1 Operation not permitted

Just to verify, are you using a package install or a run-in-place
built from source?

If you're building from source, did you run "make setuid" after
running "make"?

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

[Daren Schwenke]

I followed these: http://www.machinekit.io/docs/developing/machinekit-developing/

machinekit@beaglebone:~/machinekit/src$ sudo make setuid

[sudo] password for machinekit: 

make: Entering directory '/home/machinekit/machinekit/src'

test -f ../libexec/pci_read && chown root ../libexec/pci_read && chmod 4750 ../libexec/pci_read || true

test -f ../libexec/pci_write && chown root ../libexec/pci_write && chmod 4750 ../libexec/pci_write || true

test -f ../libexec/rtapi_app_rt-preempt && chown root ../libexec/rtapi_app_rt-preempt && chmod 4750 ../libexec/rtapi_app_rt-preempt || true;

make: Leaving directory '/home/machinekit/machinekit/src'

machinekit@beaglebone:~/machinekit/src$ cd ../../Arcus-3D-M2/

machinekit@beaglebone:~/Arcus-3D-M2$ ./run.py

loading cramps_cape.bbio... done

starting configserver... done

starting linuxcnc... MACHINEKIT - 0.1

Machine configuration directory is '/home/machinekit/Arcus-3D-M2'

Machine configuration file is 'Arcus-3D-M2.ini'

Starting Machinekit...

done

io started

halcmd loadusr io started

Arcus-3D-M2.hal:31: insmod failed, returned -1:

rtapi_app_main(hal_pru_generic): -1 Operation not permitted

See /var/log/linuxcnc.log for more information.

Shutting down and cleaning up Machinekit...

Cleanup done

Machinekit terminated with an error.  You can find more information in the log:

    /home/machinekit/linuxcnc_debug.txt

and

    /home/machinekit/linuxcnc_print.txt

as well as in the output of the shell command 'dmesg' and in the terminal

stopping configserver... done

machinekit@beaglebone:~/Arcus-3D-M2$

[Daren Schwenke]

Well, specifically I did this, which is probably a new combination for the beagle:

debian/configure -pr

./configure --with-platform-beaglebone --with-rt-preempt

[Robert Nelson]

On Fri, Jul 28, 2017 at 12:59 PM, Daren Schwenke
<darens...@gmail.com> wrote:
> After the dd, it now takes a seriously long time to boot.
> Before it was ~45 seconds till it was back on the network. Now it takes
> around 5 minutes.

it's something with teh "RT" patchset in v4.4.x:

root@beaglebone:~# uname -r ; systemd-analyze
4.4.68-ti-rt-r112
Startup finished in 50.682s (kernel) + 1min 16.366s (userspace) = 2min 7.048s

root@beaglebone:~# uname -r ; systemd-analyze
4.4.68-ti-r112
Startup finished in 15.571s (kernel) + 47.007s (userspace) = 1min 2.578s

root@beaglebone:~# uname -r ; systemd-analyze
4.9.39-bone-rt-r6
Startup finished in 33.040s (kernel) + 57.759s (userspace) = 1min 30.799s

root@beaglebone:~# uname -r ; systemd-analyze
4.9.39-bone6
Startup finished in 16.721s (kernel) + 33.363s (userspace) = 50.084s

We could swap from 4.4.68-ti-rt-r112 -> 4.9.39-bone-rt-r6... All the
important bit's are the same..

[Charles Steinkuehler]

On 7/28/2017 1:44 PM, Daren Schwenke wrote:
>
> machinekit@beaglebone:~/Arcus-3D-M2$ ./run.py
> loading cramps_cape.bbio... done
> starting configserver... done
> starting linuxcnc... MACHINEKIT - 0.1
> Machine configuration directory is '/home/machinekit/Arcus-3D-M2'
> Machine configuration file is 'Arcus-3D-M2.ini'
> Starting Machinekit...
> done
> io started
> halcmd loadusr io started
> Arcus-3D-M2.hal:31: insmod failed, returned -1:
> rtapi_app_main(hal_pru_generic): -1 Operation not permitted

This is yet another case of "not very helpful error messages".

I poked around on your system and the problem is you didn't build the
Xeonomai configuration as well as the preemprt-rt, so you don't have
the PRU binary file in your rtlib directory. So the operation you are
not permitted to do is read from a non-existing file!

I installed the machinekit-xenomai package (it will happily co-exist
with a run-in-place source build) and was able to load the
hal_pru_generic driver.

Change the "prucode=..." part of the HAL file you want to use so it
points to the binary file installed as part of the package:

prucode=/usr/lib/linuxcnc/xenomai/pru_generic.bin

...and you should get a bit farther.

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

[Daren Schwenke]

Roger that.  So I just did this:

machinekit@beaglebone:~/machinekit$ debian/configure -prx

debian/control:  copied base template

debian/rules:  copied base template

debian/machinekit.install.in:  copied base template

debian/control:  added POSIX threads package

debian/rules:  enabled posix threads

debian/control:  added RT_PREEMPT threads package

debian/rules:  enabled rt-preempt threads

debian/control:  added Xenomai (userland) threads package with Build-Depends:

    libxenomai-dev

debian/rules:  enabled xenomai threads

debian/control:  Set tcl/tk build deps to version 8.6

debian/control:  add final Build-Depends: list

machinekit@beaglebone:~/machinekit$ sudo mk-build-deps -ir

...

machinekit@beaglebone:~/machinekit/src$ ./autogen.sh

machinekit@beaglebone:~/machinekit/src$ ./configure --with-rt-preempt --with-xenomai --with-platform-beaglebone

...

#   It seems that ./configure completed successfully.                #

#   If things don't work check config.log for errors & warnings      #

machinekit@beaglebone:~/machinekit/src$ make -j 1

[Daren Schwenke]

Ok.  Pointed it directly at your file.  Further:

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ ./run.py

loading cramps2_cape.bbio... done

starting configserver... done

starting linuxcnc... MACHINEKIT - 0.1

Machine configuration directory is '/home/machinekit/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS'

Machine configuration file is 'fabrikator-mini.ini'

Starting Machinekit...

done

io started

halcmd loadusr io started

Traceback (most recent call last):

  File "/home/machinekit/machinekit/bin/hal_temp_bbb", line 198, in <module>

    checkAdcInput(pin)

  File "/home/machinekit/machinekit/bin/hal_temp_bbb", line 156, in checkAdcInput

    pin.filename = tempName[0]

IndexError: list index out of range

Traceback (most recent call last):

  File "fabrikator_mini.py", line 20, in <module>

    hardware.init_hardware()

  File "/home/machinekit/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS/cramps.py", line 41, in init_hardware

    wait_name='temp')

  File "machinekit/hal_loadusr.pyx", line 38, in machinekit.hal.loadusr (hal/cython/machinekit/hal.c:26061)

RuntimeError: hal_temp_bbb exited with return code 1

Shutting down and cleaning up Machinekit...

Cleanup done

Machinekit terminated with an error.  You can find more information in the log:

    /home/machinekit/linuxcnc_debug.txt

and

    /home/machinekit/linuxcnc_print.txt

as well as in the output of the shell command 'dmesg' and in the terminal

stopping configserver... done

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$

[Charles Steinkuehler]

Are you handy with Python?

That's almost certainly a problem with the ADC entries in /sysfs,
which I believe have moved in the 4.x kernels vs. 3.8.13. The current
script is expecting them to be in:

/sys/devices/ocp.*/44e0d000.tscadc/tiadc/iio:device0/

https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps/hal_temp_bbb.py#L154

> cha...@steinkuehler.net <javascript:>

[Daren Schwenke]

found the new path and changed 154 to:

    syspath = '/sys/devices/platform/ocp/44e0d000.tscadc/TI-am335x-adc/iio:device0/'

Works.  Next error:

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ ./run.pyloading cramps2_cape.bbio... done

starting configserver... done

starting linuxcnc... MACHINEKIT - 0.1

Machine configuration directory is '/home/machinekit/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS'

Machine configuration file is 'fabrikator-mini.ini'

Starting Machinekit...

done

io started

halcmd loadusr io started

Traceback (most recent call last):

  File "fabrikator_mini.py", line 34, in <module>

    ve.velocity_extrusion(extruders=numExtruders, thread='servo-thread')

  File "/home/machinekit/machinekit/lib/python/fdm/config/velocity_extrusion.py", line 261, in velocity_extrusion

    velocity_jog(extruders, thread)

  File "/home/machinekit/machinekit/lib/python/fdm/config/velocity_extrusion.py", line 80, in velocity_jog

    reset = rt.newinst('reset', 'reset.ve-jog-trigger')

  File "machinekit/rtapi.pyx", line 265, in machinekit.rtapi.RTAPIcommand.newinst (hal/cython/machinekit/rtapi.c:5541)

RuntimeError: rtapi_newinst '('reset', 'reset.ve-jog-trigger')' failed: Invalid argument

Shutting down and cleaning up Machinekit...

exiting HAL component storage

exiting HAL component temp

Cleanup done

Machinekit terminated with an error.  You can find more information in the log:

    /home/machinekit/linuxcnc_debug.txt

and

    /home/machinekit/linuxcnc_print.txt

as well as in the output of the shell command 'dmesg' and in the terminal

stopping configserver... done

machinekit@beaglebone:~/machinekit/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS$ 

> <mailto:machinekit+unsub...@googlegroups.com>.

[Robert Nelson]

On Fri, Jul 28, 2017 at 3:25 PM, Daren Schwenke <darens...@gmail.com> wrote:
> found the new path and changed 154 to:
> syspath =
> '/sys/devices/platform/ocp/44e0d000.tscadc/TI-am335x-adc/iio:device0/'
> Works. Next error:

another option would be the generic:

/sys/bus/iio/devices/iio:device0/

(it might actually exist on 3.8.13 too..)

[Charles Steinkuehler]

On 7/28/2017 3:25 PM, Daren Schwenke wrote:
> found the new path and changed 154 to:
> syspath =
> '/sys/devices/platform/ocp/44e0d000.tscadc/TI-am335x-adc/iio:device0/'
> Works.

We'll eventually need something that can detect both the 3.8 and 4.x
locations for this file. Feel free to add that if you have time.

> Next error:
<snip>

> File
> "/home/machinekit/machinekit/lib/python/fdm/config/velocity_extrusion.py", line
> 80, in velocity_jog
> reset = rt.newinst('reset', 'reset.ve-jog-trigger')
> File "machinekit/rtapi.pyx", line 265, in
> machinekit.rtapi.RTAPIcommand.newinst (hal/cython/machinekit/rtapi.c:5541)
> RuntimeError: rtapi_newinst '('reset', 'reset.ve-jog-trigger')' failed: Invalid
> argument

Now you're squarely in the middle of the velocity extrusion logic and
python generated HAL configurations, which I'm not particularly
familiar with. AFAIK there's nothing kernel specific about the
velocity extrusion logic, but it's obviously not working.

I'd recommend trying a more traditional configuration that isn't doing
velocity extrusion. I'm most familiar with the CRAMPS.ini config:

https://github.com/machinekit/machinekit/tree/master/configs/ARM/BeagleBone/CRAMPS

...since it started as the config file for my first printer, but you
could try any of the BeagleBone configs that use the universal overlay
(which I think is most of them except for the BeBoPr configs).

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

[Daren Schwenke]

After: Loading cape-bone-iio overlay
(duh)

then Yes, that path is on the old image as well.

[Daren Schwenke]

They don't work so well headless.  :)

[Daren Schwenke]

So I think this is getting really close now.  I'm compiling again so I can remove the dependencies outside of the RIP build I have.

So I'm going to take this and sort the last few thingies here (by removing them) and test it on a real machine.

Then, if it works, I'll compile a list of what had to happen.  Short list:

Robert, your image was missing the wireless firmware files and it doesn't look like it was rebuilt since then.  Could you kick that off?

It also seems we'll need rt-preempt and xenomai at the same time (cause the pru_generic bin was compiled as part of xenomai).  Not sure if the packages currently allow that.
It would be great if machinekoder could take a look at the velocity extrusion related errors, but I have a version where I stripped out reset I believe so I can move forward.

https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps/hal_temp_bbb.py#L154 needs to point to '/sys/bus/iio/devices/iio:device0/', then it works on both 3.8.13 and 4.4

On Wednesday, September 28, 2016 at 6:10:09 AM UTC-4, Unai Antero wrote:

Dear all,

trying to use a SeeedStudio BeagleBone Green Wireless (+ the CRAMPS board) to run machinekit, but without much success...

Tried using the SD image on https://rcn-ee.com/rootfs/bb.org/testing/2016-09-18/machinekit/bone-debian-8.6-machinekit-armhf-2016-09-18-4gb.img.xz , but although it works fine on a Beagle Bone Black, the BB Green Wireless refuses to boot (seems it doesn't like the 3.8 kernel...).

On a second attempt, was able to start from a fresh Debian Jessie on the BeagleBone Green Wireless (that uses the 4.4.9 kernel), installed the 4.4.9-bone-rt-r10 kernel, and installed machinekit-rt-preempt (apt-get install from packages at http://deb.machinekit.io/debian)

Machinekit tries to start the CRAMPS setup, but fails as it expects things to be in /sys/devices/bone_capemgr.*/slots .... and on this kernel, seems things are on /sys/devices/platform/bone_capemgr/slots (among other changes...)

Has anyone been able to run machinekit on the BeagleBone Green Wireless? 

Thanks

[Daren Schwenke]

Something new... seems there is a line length limit I never hit before in effect now.

Arcus-3D-M2.hal:49: Unknown command 'ew0,mult2.ew1,mult2.ew2,mult2.ew3,mult2.ew4,mult2.ew5,mult2.m0'

That's the remainder of a long loadrt mult2 line being chopped off.  I split it into actually being two loadrt mult2 lines and then... 

It starts. 

machinekit@beaglebone:~/Arcus-3D-M2$ ./run.py

loading cramps_cape.bbio... done

starting configserver... done

starting linuxcnc... MACHINEKIT - 0.1

Machine configuration directory is '/home/machinekit/Arcus-3D-M2'

Machine configuration file is 'Arcus-3D-M2.ini'

Starting Machinekit...

done

io started

halcmd loadusr io started

task pid=4589

emcTaskInit: using builtin interpreter

RTAPI is kind of a pig though:

  PID USER      PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND      

 4559 root      20   0   63848  59668  11600 S 45.3 12.0   3:24.15 rtapi:0      

 4577 machine+  20   0   14932   9112   6488 S  4.2  1.8   0:18.59 hal_temp_bbb 

 4589 machine+  20   0   22212  13992  11688 S  3.9  2.8   0:17.85 milltask     

 4616 machine+  20   0    4564   2132   1764 R  1.6  0.4   0:01.26 top          

    4 root      -2   0       0      0      0 S  1.0  0.0   0:11.60 ktimersoftd+ 

    8 root      20   0       0      0      0 S  0.3  0.0   0:02.91 rcu_preempt  

   10 root      20   0       0      0      0 S  0.3  0.0   0:03.29 rcuc/0       

 2589 www-data  20   0  228836   3300   1916 S  0.3  0.7   0:00.72 apache2      

 4554 machine+  20   0   25856   5116   4672 S  0.3  1.0   0:00.48 rtapi_msgd   

 4590 machine+  20   0   81192  30236   8412 S  0.3  6.1   0:14.51 mkwrapper    

 4596 machine+  20   0   72240  30968   8872 S  0.3  6.2   0:01.54 mkwrapper    

Compared to the xenomai version of the same machine:

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND           

 2514 machinek  20   0 13764  12m 9704 S   6.9  2.6   0:07.05 hal_temp_bbb      

 2526 machinek  20   0 21012  19m  14m S   3.0  3.9   0:03.20 milltask          

 2542 machinek  20   0  4208 1244  884 R   1.0  0.2   0:00.81 top               

    3 root      20   0     0    0    0 S   0.7  0.0   0:01.19 ksoftirqd/0       

  775 root      20   0 28740 9112 3668 S   0.3  1.8   0:05.02 Xorg              

 1159 machinek  20   0  5556 2216 1820 S   0.3  0.4   0:00.57 menu-cached       

 1200 machinek  20   0  8912 1404  752 S   0.3  0.3   0:00.15 sshd              

 2016 root      20   0     0    0    0 S   0.3  0.0   0:01.99 kworker/0:0       

 2535 machinek  20   0 54452  14m 4368 S   0.3  2.9   0:00.50 mkwrapper         

    1 root      20   0  4476 2652 1408 S   0.0  0.5   0:01.16 systemd           

    2 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kthreadd          

    5 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/0:0H      

[Robert Nelson]

On Fri, Jul 28, 2017 at 5:40 PM, Daren Schwenke <darens...@gmail.com> wrote:
> So I think this is getting really close now. I'm compiling again so I can
> remove the dependencies outside of the RIP build I have.
> So I'm going to take this and sort the last few thingies here (by removing
> them) and test it on a real machine.
> Then, if it works, I'll compile a list of what had to happen. Short list:
>
> Robert, your image was missing the wireless firmware files and it doesn't
> look like it was rebuilt since then. Could you kick that off?
> It also seems we'll need rt-preempt and xenomai at the same time (cause the
> pru_generic bin was compiled as part of xenomai). Not sure if the packages
> currently allow that.
> It would be great if machinekoder could take a look at the velocity
> extrusion related errors, but I have a version where I stripped out reset I
> believe so I can move forward.
> https://github.com/machinekit/machinekit/blob/master/src/hal/user_comps/hal_temp_bbb.py#L154
> needs to point to '/sys/bus/iio/devices/iio:device0/', then it works on both
> 3.8.13 and 4.4

here you go:

https://rcn-ee.net/rootfs/bb.org/testing/2017-07-28/machinekit/

[Robert Nelson]

btw, side note..

With the cpu resource not really available, would you guys be more
happy with a very basic openbox gui, instead of the big qt5/lxde/etc..

Just enough to click a "machinekit" icon..

[Daren Schwenke]

I'm pretty sure rtapi is not performing as expected here given we have gone up an order of magnitude in processor usage, but running is better than not and these targets are headless anyway.  

I should be able to print something in the morning.

[Daren Schwenke]

I'm not sure what magic sequence of events allowed this to run before, but I can't get RTAPI to start now.

As I was messing about with other stuff and possibly screwed it up, I'm starting fresh with Robert's newly built image and I'll work from there.

[Daren Schwenke]

Everything works, with the caveat of really high processor utilization.  About 80-90% all the time, with rtapi:0 taking about 50% of that.

This makes for a slower user interface even when using remote.

But, that doesn't seem to affect operation as I've printed 2 good looking 1.5 hour parts so far with no issues.

I've only tested on the BBG thus far.  I don't forsee any issues with the BBGW other than configuring it headless is confusing me as it uses connmanctl.

Steps:

Download the image Robert has made for this: https://rcn-ee.net/rootfs/bb.org/testing/2017-07-28/machinekit/bone-debian-8.9-machinekit-armhf-2017-07-28-4gb.img.xz

Login as machinekit:machinekit.

sudo apt-get update

cd /usr/lib/linuxcnc/

# save some files we need from xenomai

sudo tar -cvpf xenomai.tar xenomai/pru*

# remove it.

sudo apt-get remove --purge machinekit-xenomai

# install rt-preempt

sudo apt-get install machinekit-rt-preempt

# put the saved files back

sudo tar -xvf xenomai.tar

# move a couple from preempt to xenomai

sudo cp -p rt-preempt/hal_pru* xenomai/

#now edit /usr/bin/hal_temp_bbb and on line 154 change it so it reads:

#    syspath = '/sys/bus/iio/devices/iio:device0/'

That's it.  Load your config and give it a try.

I noted that the maximum command line length for loadrt has gone down and I needed to split some of my loadrt entries to make them work, but due to a recent patch, you can do that at least.

I also noted that many of the example configs are out dated and explode due to changes in parameters and parameter passing, but that also is not related to rtapi.

Thank you Charles and Robert for your substantial help.

[Daren Schwenke]

One more thing.  You may need to do this to force it to use the uboot version on your SD card instead of the eMMC.

sudo dd if=/dev/zero of=/dev/mmcblk1 count=1 seek=1 bs=128k

[Robert Nelson]

I've submitted a pull request for this adc change:

https://github.com/machinekit/machinekit/pull/1241

[Daren Schwenke]

Tried linux-image-4.9.40-bone-rt-r7.

It's 15% better for processor usage, but still a lot higher than xenomai.

 3735 root      20   0   63524  58884  10816 S 30.4 11.7   0:29.66 rtapi:0             

 3754 machine+  20   0   14608   9260   6644 S  3.3  1.8   0:03.32 hal_temp_bbb        

 3766 machine+  20   0   21892  13808  11512 S  2.9  2.7   0:02.96 milltask            

    1 root      20   0   24748   4568   3540 S  1.3  0.9   0:07.48 systemd             

 1207 root      20   0   15768   3852   3516 S  1.3  0.8   0:01.67 systemd-journal     

 1775 message+  20   0    4868   2644   2156 S  1.3  0.5   0:01.23 dbus-daemon         

 3841 machine+  20   0    4560   2080   1712 R  1.0  0.4   0:00.60 top                 

    4 root      -2   0       0      0      0 S  0.3  0.0   0:00.67 ktimersoftd/0       

   10 root      20   0       0      0      0 S  0.3  0.0   0:00.83 rcuc/0              

 1746 root      20   0   30508   2516   1788 S  0.3  0.5   0:00.35 rsyslogd