Malte, it is up there. http://blog.machinekit.io/
I have hopefully proof read it properly and corrected any spelling etc.
Let me know if there are any howlers.
Thanks for your contribution
On 07/02/19 14:52, Charles Steinkuehler wrote:
I can still get in. I removed you from the user list and sent you a
new invitation to the same gmail address.
Hopefully that will fix it.
On 2/7/2019 3:32 AM, [email protected] wrote:
Hi Malte
Unfortunately, I seem unable to log into the machinekit blog any more.
Seems to have something to do with being required to use a Google+
account
originally and now those are defunct.
The login recognises my normal google log in but not that I am a
member of that
blog.
Hopefully someone else who still has access will be able to help.
If not we shall have to transfer all the blogs elsewhere
AFAIR the blog.machinekit.io is just a redirection to the blogger page
regards
On 05/02/19 07:16, [email protected] wrote:
Hi Malte
Thanks for that it looks comprehensive.
I'll leave a couple of days for 'peer reviews by people who
actually know
about the BBB,
in case they have an input.
Then I will 'cut and paste' with a suitable header etc into the
machinekit blog
(If I can remember how :-))
regards
On 2/4/2019 7:54 PM, Malte Schmidt wrote:
Dear all,
first of all I would like to say a big THANK YOU to all the
contributors of
machinekit and linuxcnc. I do really value the effort you all put
into this !
When setting up my machine I realized that, while all needed
information was
available somewhere, the information was somewhat scattered
around and it
took some time to figure out what was relevant and what was not.
I therefore collected some notes and thought about posting this
somewhere
(blog) to help others. I have some background in Linux and
Linuxcnc (PC) as
user and did therefore not note down line for line but rather
tried to
capture the overall process of getting machinekit to work on a BBB.
My notes are below and I wonder if this would be good content for
the
machinekit blog. If yes, how can I post this there?
BR,
Malte
This document was written in December 2018/Januar 2019
The challenge:
Automate a lathe with 2 steppers, limit switches
Allow for manual turning using encoder input for x, z
Provide glass scales input for manual turning (this may be
considered
gold plating but my initial plan was to use this lathe in CNC or
manual mode)
Obviously have spindle feedback and control the lathe motor
Ideally controlled via touchscreen.
My leanings:
I considered the following approaches:
With the amount of inputs required a
- parallel port solution would only be feasible if multiple
parallel
ports are used. -> decided against it
- MESA card solution requires two cards -> expensive,
decided against it
- A beagle bone based solution with GPIO and PRUs -> my
tentatively
selected approach. Downside of this is the poor graphic performance
Linux on the Beagle Bone Black:
Three different options exist for Realtime in the Linux Kernel
- RTAI
- RT_PREEMPT
- Xenomai
All are patches to the vanilla Linux kernel.
- RTAI is old and seems to be superseded by...
- RT_PREEMPT which will be adapted by main Linux kernel
- Xenomai is commercial
My takeaway is that RT_PREEMPT would be ideal but Xenomai is
a possible
option.
Two different Debian Linux distributions have been considered:
- Strech
- Jessie
To get a Debian distribution and one of the realtime kernels
on the
beagle board three approaches have been explored:
1) Putting it toggelter by hand
(https://machinekoder.com/machinekit-debian-stretch-beaglebone-black/)
2) Getting Strech + RT_PREEMPT from eLinux
(http://www.machinekit.io/docs/getting-started/machinekit-images/
and
https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29_Machinekit)
3) Getting Jessie + Xenomai from eLinux (see links above)
Findings
- Current RT_PREEMPT + Strech combinations 1) and 2) above
have long boot
times of 2-4 minutes.
- The blog post in 1) is a good read in any case to perform
some steps to
get the system up to date and further improve boot times
Flashing
- I was not able to flash using the procedures described in
most online
places. I booted from SD and than used the approach outlined
(https://stackoverflow.com/questions/33930747/how-to-flash-beaglebone-black-emmc-with-debian-8-2-image)
cd /opt/scripts/tools/eMMC/
sudo ./init-eMMC-flasher-v3.sh
I'm currently using Jessie and Preempt_RT because I'm lazy.
There is some
background here on the boot time issue which will hopefully be
resolved in
the future:
https://groups.google.com/forum/#!topic/machinekit/sOWj5I7fVpo
Cape support
- No commercially available cape was suitable to be used
with my
requirements. So I decided to go with a Sparkfun prototype cape
and wire up
things from there.
The name of the board coded in the EEPROM will tell which
device tree
overlay file to load. The device tree overlay file declares the
pins we can
use with this cape.
(cf
https://github.com/jbdatko/eeprom_tutorial/blob/master/eeprom.md)
With different Linux versions different approaches exist how
this is
achieved.
Linux 3.8 / Xenomai + Jessie uses capemanager
Linux 4.4 / Preempt_RT + Strech uses U-boot overlays
Most resources in the internet are about capemanager.
We need two things for loading the cape during boot:
-- EEPROM
-- Device Tree overlay file
- The easiest way to get through this is using existing
device tree
overlay files.
(https://github.com/cdsteinkuehler/beaglebone-universal-io)
- This means that the eeprom needs to be coded such that
those are loaded.
Use https://github.com/picoflamingo/BBCape_EEPROM to write
e.g.
cape-universal in both the board name and revision field (I don't
know which
field is actually used)
- For the Sparkfun Prototype cape it may be good to know
that the
sparkfun prototype cape addr is 0x57
Checking if cape is recognized
capemanager:
- Check that the cape is recognized (e.g.
http://azkeller.com/blog/?p=62)
U-Boot overlays
- Check that cat /proc/cmdline shows overlay file handed
over to kernel
- Also worth to note:
https://groups.google.com/forum/#!topic/machinekit/SF9xA8sdpB0 and
http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/
My board stopped booting from eMMC at this point when the cape
was
connected. It's unclear why
Machinekit setups
Get this tool:
https://github.com/machinekoder/BBIOConfig/releases
(bbioconfig_v1.1-7_windows_x86.zip)
https://github.com/machinekoder/BBIOConfig
To create a BBIO file that actually contains the pins and
settings you
intend to use
Get and modify run.py from one of the different
configurations (e.g. from
https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/Fabrikator-Mini-CRAMPS/run.py)
I created a "standard" Axis UI configuration (i.e. the
selection that
comes up when starting machinekit) and copied the .ini file from
there. I
also copied GUI related stuff (postgui.hal and xml files)
I used the cramps hal file as starting point for my specific
stuff:
https://github.com/machinekit/machinekit/blob/master/configs/ARM/BeagleBone/CRAMPS/CRAMPS.hal
My takeaways
- Make sure to understand the constraints:
- Pin usage and dependencies are error prone. The same
output may be
routed to different pins
- You can use only one PRU (machinekit driver restriction)
Adding hardware inputs and outputs to my custom cape
A fairly straightforward thing. I used HW-399 Optocoupler
Modules to
isolate all inputs. They are based on a TLP-281 chip. All powered
from the
beagle board.
The outputs are generated by a 4 channel (BiDirectional -
although this
is not used) logic level converter module. There are integrated
and discrete
solutions for this on the market.
I used a discrete version here to provide the required
current (afaik
<15mAh) for the optocouplers in the stepper drivers. The
integrted drivers
available in the market are not as capable in this regard.
Overall 16 inputs and 4 outputs are generated this way.
The hardware design is not as nice but good enough for me. I
mounted the
logic lvel converter and one optocoupler on the proto cape.
The other parts are mounted on 3D printed holder together
with the BBB
The "real" User interface
As stated in the beginning it was clear that the BBB would
not deliver a
good graphics performance and I looked into different options how
to deal
with this
a) Axis with remote X server
This was too slow. And also not did not meet the desire to
use a
touchscreen. I also did not see a way to work around this.
b) QtQuickVCP with Cetus or a to be developed UI (for touch)
This seems to be somwhat work in progress. The UI
responsiveness was good
but there were two things that I considered as downsides. The
main thing was that
the UI requires a number of user interactions to actually
load. The
developement effort for a touch UI was another downside.
c) Machinetalk with Browser based UI (WebVCP)
This would have been a possible option to work around the
different user
interactions with QtQuickVCP. But I did not get this to work within
reasonable time
The development effort was also clearly a downside here
d) Touchy
Touchy delivered a reasonable graphics performance when
using this with a
remote X server. I therefore investigated this further and
realized that this
is actually
fast enough with X running on the BBB itself. I assume this
is because
touchy will not create a preview. Since I'm running a lathe which
is 2D only
this is actually good enough.
My learnings:
- Touchy is what I will be evaluate / use further. If my
requirements
would have included a working preview I would have continued with
QtQuickVCP.
X Display system + touchsceen.
- I'm using a waveshare 7" touchsceen. My first attempts to
get this to
work failed (touch was not working).
It started to work after I installed lxdm but likely this
was because
some tools got installed in this process. I did not figure out
the details here.
Autologin
follow these steps to automaically log to the terminal:
https://unix.stackexchange.com/questions/401759/automatically-login-on-debian-9-2-1-command-line
and add startx [run.py] to your .bashrc
--
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 [email protected]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit 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 [email protected]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit 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 [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
