tag:blogger.com,1999:blog-7217396662251743552024-03-13T07:03:24.223-05:00Machinekit Blogcdsteinkuehlerhttp://www.blogger.com/profile/12028187486525768375noreply@blogger.comBlogger89125tag:blogger.com,1999:blog-721739666225174355.post-76773143100152665492019-02-07T08:54:00.000-06:002019-02-07T09:01:41.865-06:00Using Machinekit on the BBB - a hands on log of how I did it, by Malte Scmidt<div>
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.</div>
<div>
</div>
<div>
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. </div>
<div>
<br /></div>
<div>
BR,</div>
<div>
Malte</div>
<div>
<br /></div>
<div>
<div>
(This document was written in December 2018/January 2019)</div>
<div>
<br /></div>
<div>
<b>The challenge:</b></div>
<div>
Automate a lathe with 2 steppers, limit switches</div>
<div>
Allow for manual turning using encoder input for x, z</div>
<div>
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)</div>
<div>
Obviously have spindle feedback and control the lathe motor</div>
<div>
Ideally controlled via touchscreen.</div>
<div>
<br /></div>
<div>
<b>My leanings:</b></div>
<div>
<br /></div>
<div>
I considered the following approaches:</div>
<div>
With the amount of inputs required a </div>
<div>
- parallel port solution would only be feasible if multiple parallel ports are used. -> decided against it</div>
<div>
- MESA card solution requires two cards -> expensive, decided against it</div>
<div>
- A beagle bone based solution with GPIO and PRUs -> my
tentatively selected approach. Downside of this is the poor graphic
performance</div>
<div>
<br /></div>
<div>
<b>Linux on the Beagle Bone Black:</b></div>
<div>
Three different options exist for Realtime in the Linux Kernel</div>
<div>
- RTAI</div>
<div>
- RT_PREEMPT</div>
<div>
- Xenomai</div>
<div>
<br /></div>
<div>
All are patches to the vanilla Linux kernel. </div>
<div>
- RTAI is old and seems to be superseded by...</div>
<div>
- RT_PREEMPT which will be adapted by main Linux kernel</div>
<div>
- Xenomai is commercial</div>
<div>
<br /></div>
<div>
<i>My takeaway</i> is that RT_PREEMPT would be ideal but Xenomai is a possible option.</div>
<div>
</div>
<div>
Two different Debian Linux distributions have been considered:</div>
<div>
- Stretch</div>
<div>
- Jessie</div>
<div>
<br /></div>
<div>
To get a Debian distribution and one of the realtime kernels on the beagle board three approaches have been explored:</div>
<div>
1) Putting it together by hand (https://machinekoder.com/machinekit-debian-stretch-beaglebone-black/)</div>
<div>
2) Getting Stretch + 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)</div>
<div>
3) Getting Jessie + Xenomai from eLinux (see links above)</div>
<div>
<br /></div>
<div>
<b>Findings</b></div>
<div>
- Current RT_PREEMPT + Stretch combinations 1) and 2) above have long boot times of 2-4 minutes.</div>
<div>
- 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</div>
<div>
</div>
<div>
<b>Flashing</b></div>
<div>
- 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)</div>
<div>
cd /opt/scripts/tools/eMMC/</div>
<div>
sudo ./init-eMMC-flasher-v3.sh</div>
<div>
<br /></div>
<div>
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:</div>
<div>
https://groups.google.com/forum/#!topic/machinekit/sOWj5I7fVpo</div>
<div>
</div>
<div>
<b>Cape support</b></div>
<div>
- 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.</div>
<div>
</div>
<div>
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.</div>
<div>
(cf https://github.com/jbdatko/eeprom_tutorial/blob/master/eeprom.md)</div>
<div>
</div>
<div>
With different Linux versions different approaches exist how this is achieved.</div>
<div>
Linux 3.8 / Xenomai + Jessie uses cape-manager</div>
<div>
Linux 4.4 / Preempt_RT + Stretch uses U-boot overlays</div>
<div>
<br /></div>
<div>
Most resources in the internet are about capemanager.</div>
<div>
</div>
<div>
We need two things for loading the cape during boot:</div>
<div>
-- EEPROM</div>
<div>
-- Device Tree overlay file</div>
<div>
<br /></div>
<div>
- The easiest way to get through this is using existing device tree
overlay files.
(https://github.com/cdsteinkuehler/beaglebone-universal-io)</div>
<div>
- This means that the eeprom needs to be coded such that those are loaded. </div>
<div>
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)</div>
<div>
</div>
<div>
- For the Sparkfun Prototype cape it may be good to know that the sparkfun prototype cape addr is 0x57</div>
<div>
</div>
<div>
Checking if cape is recognized </div>
<div>
capemanager:</div>
<div>
- Check that the cape is recognized (e.g. http://azkeller.com/blog/?p=62)</div>
<div>
U-Boot overlays</div>
<div>
- Check that cat /proc/cmdline shows overlay file handed over to kernel</div>
<div>
</div>
<div>
- 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/</div>
<div>
</div>
<div>
</div>
<div>
My board stopped booting from eMMC at this point when the cape was connected. It's unclear why </div>
<div>
<br /></div>
<div>
<br /></div>
<div>
<b>Machinekit setups</b></div>
<div>
Get this tool: https://github.com/machinekoder/BBIOConfig/releases
(bbioconfig_v1.1-7_windows_x86.zip)
https://github.com/machinekoder/BBIOConfig</div>
<div>
To create a BBIO file that actually contains the pins and settings you intend to use</div>
<div>
</div>
<div>
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)</div>
<div>
</div>
<div>
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)</div>
<div>
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</div>
<div>
<br /></div>
<div>
<b> </b><i>My takeaways</i></div>
<div>
- Make sure to understand the constraints:</div>
<div>
- Pin usage and dependencies are error prone. The same output may be routed to different pins</div>
<div>
- You can use only one PRU (machinekit driver restriction)</div>
<div>
</div>
<div>
</div>
<div>
Adding hardware inputs and outputs to my custom cape</div>
<div>
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.</div>
<div>
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.</div>
<div>
I used a discrete version here to provide the
required current (afaik <15mAh) for the optocouplers in the stepper
drivers. The integrated drivers available in the market are not as
capable in this regard.</div>
<div>
<br /></div>
<div>
Overall 16 inputs and 4 outputs are generated this way.</div>
<div>
</div>
<div>
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.</div>
<div>
The other parts are mounted on 3D printed holder together with the BBB</div>
<div>
</div>
<div>
<b>The "real" User interface</b></div>
<div>
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</div>
<div>
<br /></div>
<div>
a) Axis with remote X server</div>
<div>
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.</div>
<div>
<br /></div>
<div>
b) QtQuickVCP with Cetus or a to be developed UI (for touch)</div>
<div>
This seems to be somewhat work in progress. The UI responsiveness was
good but there were two things that I considered as downsides. The main
thing was that</div>
<div>
the UI requires a number of user interactions to actually load. The development effort for a touch UI was another downside.</div>
<div>
</div>
<div>
c) Machinetalk with Browser based UI (WebVCP)</div>
<div>
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</div>
<div>
The development effort was also clearly a downside here</div>
<div>
</div>
<div>
d) Touchy</div>
<div>
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.</div>
<div>
</div>
<div>
<i>My learnings:</i></div>
<div>
- Touchy is what I will be evaluate / use further. If my requirements
would have included a working preview I would have continued with
QtQuickVCP.</div>
<div>
<br /></div>
<div>
<b>X Display system + touchsceen.</b></div>
<div>
- I'm using a waveshare 7" touchsceen. My first attempts to get this to work failed (touch was not working). </div>
<div>
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.</div>
<div>
</div>
<div>
<b>Autologin</b></div>
<div>
follow these steps to automatically log to the terminal:
https://unix.stackexchange.com/questions/401759/automatically-login-on-debian-9-2-1-command-line</div>
<div>
and add startx [run.py] to your .bashrc</div>
</div>
<div>
<br /></div>
ArcEyehttp://www.blogger.com/profile/17491874941914997104noreply@blogger.com3tag:blogger.com,1999:blog-721739666225174355.post-53072029279807933652017-10-30T04:35:00.000-05:002017-10-30T04:35:33.046-05:00DE0-NANO-Soc Stretch imageThere is now a Debian Stretch based Machinekit SD card image for the DE0-NANO-Soc.<br />
<br />
It contains the new machinekit code which uses the new czmq4 API, so the RIP build is fully updateable from the main Machinekit repo.<br />
<br />
The image is not extensively tested, but runs the mksocfpga sim fine, so should not have any issues with hardware. <br />
<br />
The image is in compressed .xz format, expanding to 5GB approx.<br />
It is heavier than previously, but does contain all the tools and libraries<br />
necessary to rebuild Machinekit in situ and do some development.<br />
<br />
There is a .bmap file with it to allow copying to card using bmaptool.<br />
<br />
Files are located at:<br />
http://deb.machinekit.io/uploads/de0-nano/debian-9.2-console-armhf-2017-10-29<br />
<br />
You will need to write to at least a 8GB card and expand the fs<br />
That will allow room for a swapfile, which is essential for rebuilding the RIP<br />
using -j2, or else you will run out of memory compiling the C++ elements,<br />
because g++ is particularly memory hungry in later versions.Unknownnoreply@blogger.com5tag:blogger.com,1999:blog-721739666225174355.post-53519611562855972132017-02-15T05:52:00.000-06:002017-02-15T05:52:45.413-06:00Multicore merged into MachinekitThis is to advise users, that a major merge has occurred in the
Machinekit repo.<br />
<br />
The work christened 'multicore', has been finalised and tested for
the last few months and as of 3rd Feb 2017 is now part of Machinekit.<br />
<br />
What is multicore?<br />
This talk from 2015 gives the full details. <br />
<a class="moz-txt-link-freetext" href="https://plus.google.com/events/cvhj9r8m2gh0v0kj7ccme36hlpo">https://plus.google.com/events/cvhj9r8m2gh0v0kj7ccme36hlpo</a>
<br />
<br />
What do you need to do?<br />
<br />
With 3 particular exceptions, <b>nothing at all</b>, the aim has
been to make it backwardly compatible,<br />
so all your configs should work as before.<br />
<br />
Please report any problems via the tracker at <a class="moz-txt-link-freetext" href="https://github.com/machinekit/machinekit/issues/1123">https://github.com/machinekit/machinekit/issues/1123</a><br />
<br />
Once any teething problems are sorted, the capabilities and
enhancements available within the code, will be rolled out, documented and advised for any users wishing to
make use of them.<br />
<br />
<u>Exceptions </u><br />
<br />
<ul>
<li>The primary exception is for anyone using the DE0-NANO-Soc or
Zynq as a Mesa 5i25 replacement</li>
</ul>
Improvements to the <i>hm2_soc_ol</i> driver now make use of a
different string argument handling mechanism.<br />
<br />
In practice, this simply means editing your hal file driver
instantiation line from<br />
<i>newinst [HOSTMOT2](DRIVER) [HOSTMOT2]DEVNAME
config=[HOSTMOT2](CONFIG)</i><br />
to<br />
<i>newinst [HOSTMOT2](DRIVER) [HOSTMOT2]DEVNAME <b>--</b>
config=[HOSTMOT2](CONFIG)</i><br />
<br />
The 2 dashes route the config string to the driver via a safer
mechanism.<br />
Any integer instanceparams such as 'debug=1' are passed as
previously, so remain to the left side of the delimiter<br />
<br />
If interested, this gives more details<br />
<a class="moz-txt-link-freetext" href="https://github.com/machinekit/machinekit-multicore/issues/20">https://github.com/machinekit/machinekit-multicore/issues/20</a><br />
<br />
The binary SD card image for the DE0-NANO-Soc has been updated with a new<br />
pull of Machinekit, containing Multicore available from<br />
<a href="http://deb.machinekit.io/uploads/de0-nano/debian-8.5-console-armhf-2017-02-14/">http://deb.machinekit.io/uploads/de0-nano/debian-8.5-console-armhf-2017-02-14/</a> <br />
<br />
<br />
<ul>
<li> The multicore concept relies upon atomic operations in the
C11++ standard and newer</li>
</ul>
These are supported sufficiently in gcc 4.7.2 and above in x86,
which means the code will build under Wheezy with backports
installed<br />
<br />
<br />
Originally there were problems building for wheezy-armhf.<br />
This was because all embedded toolchains have effectively deprecated gcc-4.7.<br />
<br />
Builds had to be done on gcc-4.9 but ABI peculiarities meant that even linking with 4.9 left an unmet dependency that shouldn't have really been there.<br />
<br />
Charles battled this for several days and has now sorted it and armhf packages for Wheezy are being built.<br />
<br />Users are however encouraged to upgrade from Wheezy, which is almost 'end
of life' and no longer receiving new backports from Debian in any
case.<br />
All support will end in 2018.<br />
<br />
<br />
<br />
<ul>
<li>Something that will only affect users who have written their
own C components which use ringbuffers. (We have no idea if
there are any out there.)<br />
</li>
</ul>
An API change sees <br />
<i><big><code>hal_ring_detach(char *name, ringbuffer_t *rb)</code></big></i><br />
become<br />
<i><big><code>hal_ring_detach(ringbuffer_t *rb)</code></big></i><br />
<br />
Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-721739666225174355.post-15758984992693971372017-01-12T06:29:00.000-06:002017-01-12T08:03:38.886-06:00Beta Test volunteers wanted.For a while there has been a parallel repo on github that
incorporates the multicore capabilities developed by Michael Haberler and Mick Grant a couple of years ago into the
main machinekit repo.<br />
This talk from 2015 gives the full details.<br />
<a class="moz-txt-link-freetext" href="https://plus.google.com/events/cvhj9r8m2gh0v0kj7ccme36hlpo">https://plus.google.com/events/cvhj9r8m2gh0v0kj7ccme36hlpo</a><br />
<br />
Volunteers are wanted to do the initial backward compatibility
testing. <br />
95% of existing configurations should work unchanged.<br />
A few specialised configs that use ring buffers and some other
components will require minor API syntax changes, which can be advised on a case by case basis.<br />
<br />
After testing for any problems in backward compatibility, it is
intended to merge with the main machinekit repo.<br />
Thereafter the features of multicore can be tested and rolled out,
without any impact upon the majority of the user base, who can just carry on as before.<br />
<br />
Testers need to be able to build and run RIP builds, <br />
(<a class="moz-txt-link-freetext" href="http://www.machinekit.io/docs/developing/developing/">http://www.machinekit.io/docs/developing/developing/</a> )<br />
set debugging levels <br />
(
<a class="moz-txt-link-freetext" href="http://www.machinekit.io/docs/config/ini_config/#sub:EMC-section">http://www.machinekit.io/docs/config/ini_config/#sub:EMC-section</a> -
DEBUG=7 is normally sufficient)<br />
and provide comprehensive logs of any errors <br />
(copy of relevant section of /var/log/linuxcnc.log, copy of
dmesg for segfaults etc. and stderr output to terminal)<br />
plus access to complete configs that produce them.
<br />
(preferably via a github repo)<br />
<br />
Testing across as wide a range of computers and machines as possible
is crucial.<br />
<br />
The repo is here <a class="moz-txt-link-freetext" href="http://github.com/machinekit/machinekit-multicore.git">http://github.com/machinekit/machinekit-multicore.git</a><br />
<br />
If you are able to test; <br />
from a terminal session<br />
clone it <br />
(git clone
<a class="moz-txt-link-freetext" href="http://github.com/machinekit/machinekit-multicore.git">http://github.com/machinekit/machinekit-multicore.git</a>)<br />
build it locally <br />
(cd machinekit-multicore/src && autogen.sh
&& configure (insert any platform specific switches)
&& make -j$(nproc) && sudo make setuid)<br />
then set the env<br />
( cd ../ && . ./scripts/rip-environment )<br />
run your existing configs.<br />
(machinekit ---- then select your config)<br />
<br />
Results, bugs queries etc should be addressed to <a class="moz-txt-link-rfc2396E" href="https://github.com/machinekit/machinekit-multicore/issues/10"><
https://github.com/machinekit/machinekit-multicore/issues/10 ></a><br />
<br />
<br />Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-721739666225174355.post-10233828434693710512016-11-20T04:45:00.000-06:002017-02-14T11:38:18.898-06:00DE0-Nano-Soc update on SD card ImagesIn my last entry I mentioned problems with the new SD card image and my use of a previous image.<br />
<br />
This has now been resolved.<br />
<br />
There was what equated to a typo in the device name specified in the .ini file for the sample configuration.<br />
(I say 'equated', because the name was deliberate, but when it was deprecated in favour of a common one across Altera and Zynq platforms, the sample config was not updated)<br />
Thus anything based upon the sample, as mine was, did not work. <br />
<br />
The image build system is in the process of being regenerated, once some other glitches are straightened out.<br />
<br />
There is now an image with the repo as of 14/02/2017 here<br />
<a href="http://deb.machinekit.io/uploads/de0-nano/debian-8.5-console-armhf-2017-02-14/">http://deb.machinekit.io/uploads/de0-nano/debian-8.5-console-armhf-2017-02-14/</a><br />
It includes the multicore code, with the updated hm2_soc_ol driver and <br />
it has a 512MB swap partition, which makes it easier to rebuild and use both cores without running out of memory. <br />
<br />
In my last entry, I also advocated the use of <span style="color: blue;">gparted <span style="color: #666666;">to extend the rootfs partition to use the available SD card space.</span></span><br />
<br />
<span style="color: #666666;">Having twice had failures using gparted to do just this with SD cards recently, I have hit upon a successful command line strategy.</span><br />
<br />
<span style="color: #666666;">The images consist of a 1M uboot partition and an approx 3.6G rootfs partition.</span><br />
<span style="color: #666666;">If we use the designations on my desktop (which has a lot of other disks), they</span><br />
<span style="color: #666666;">are</span><br />
<span style="color: #666666;">/dev/sdf1 uboot</span><br />
<span style="color: #666666;">/dev/sdf2 rootfs</span><br />
<br />
<span style="color: #666666;">Because there are no partitions after /dev/sdf2, it is possible to delete the partition, then create a new one starting at exactly the same sector, but encompassing the whole SD card.</span><br />
<span style="color: #666666;">Then we need to fix up the file system and expand it to the new partition size.</span><br />
<span style="color: #666666;"><br /></span>
<span style="color: #666666;"><span style="background-color: #eeeeee;"><span style="color: blue;"><span style="background-color: white;"># check it is as you expect <br />$ fdisk -l /dev/sdf <br /> <br />$ umount /dev/sdf2 <br /> <br />$ fdisk /dev/sdf <br /> <br /># command d to delete partition <br /> <br /># select partition 2 <br /> <br /># w to write to disc <br /> <br />$ fdisk /dev/sdf <br /> <br /># n to add, primary partition, same start sector as before, select full size <br /> <br /># w to write to disc <br /> <br /># now fix the file system <br />$ e2fsck -f -y /dev/sdf2 <br /> <br /># resize the filesystem <br />$ resize2fs /dev/sdf2 </span></span></span></span><br />
<br />
<span style="color: #666666;">Usual caveats apply, back up any data etc. but works fine for me with a card that gparted just hung for 10 mins and produced an error with.</span><br />
<br />
<span style="color: #666666;">If you create the rootfs partition slightly smaller than full disk size, you can go back into fdisk and create a 3rd partition, then format that as swap and enter it into the /etc/fstab file.</span><br />
<span style="color: #666666;">eg.</span><br />
<br />
<span style="color: blue;"><span style="color: blue;"><span style="color: blue;"><span style="color: blue;"><span style="color: #666666;">$ fdisk /dev/sdf</span></span></span></span></span><br />
<span style="color: blue;"><span style="color: blue;"><span style="color: blue;"><br /></span></span></span>
<span style="color: blue;"><span style="color: blue;"><span style="color: blue;"><span style="color: blue;"><span style="color: #666666;"># n add primary partition number 3 use full size</span></span></span></span></span><br />
<span style="color: blue;"><span style="color: blue;"><span style="color: blue;"><br /></span></span></span>
<span style="color: blue;"><span style="color: blue;"><span style="color: blue;"><span style="color: blue;"><span style="color: #666666;"># w to write to disc</span></span></span></span></span><br />
<span style="color: blue;"><span style="color: blue;"><span style="color: blue;"><br /></span></span></span>
<span style="color: blue;"><span style="color: blue;"><span style="color: blue;"><span style="color: blue;"><span style="color: #666666;">$ mkswap /dev/sdf3</span></span></span></span></span><br />
<span style="color: blue;"><span style="color: blue;"><span style="color: blue;"><br /></span></span></span>
<span style="color: blue;"><span style="color: blue;"><span style="color: blue;"><span style="color: blue;"><span style="color: #666666;">$ echo "UUID=<output-from-mkswap-here> none swap sw 0 0" >> /etc/fstab</span></span></span></span></span><br />
<span style="color: #666666;"><br /></span>
<span style="color: #666666;">Helps greatly if you are actually rebuilding machinekit in-situ.</span><br />
<br />
<span style="color: #666666;">Or you can use the swapfile method detailed in Michael's gist .</span><br />
<pre><a href="https://gist.github.com/mhaberler/89a813dc70688e35d8848e8e467a1337">https://gist.github.com/mhaberler/89a813dc70688e35d8848e8e467a1337</a> </pre>
<span style="color: #999999;"><span style="color: #666666;">Cat skinning methods are plentiful đŒ</span> </span><br />
<span style="color: #666666;"> </span> Unknownnoreply@blogger.com0tag:blogger.com,1999:blog-721739666225174355.post-5161092251050363152016-11-18T04:18:00.003-06:002017-02-15T05:34:24.682-06:00DE0-Nano_Soc and the DB25 interface board - real world testingYou will recall, that a while back, Charles Steinkuehler announced
the completion of the initial work to get the DE0-Nano board running
with machinekit and FPGA programmed to act as a Mesa 5i25 replacement<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.terasic.com.tw/attachment/archive/941/image/image_76_thumb.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="284" src="https://www.terasic.com.tw/attachment/archive/941/image/image_76_thumb.jpg" width="320" /></a></div>
<br />
<a href="http://blog.machinekit.io/2016/04/altera-soc-running-machinekit-with.html">http://blog.machinekit.io/2016/04/altera-soc-running-machinekit-with.html</a><br />
<br />
In the next stage, Charles designed a DB25 connected interface board, with pin-outs matching the P2 and P3 headers on a 5i25.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://644db4de3505c40a0444-327723bce298e3ff5813fb42baeefbaa.ssl.cf1.rackcdn.com/c602742f337b6f61784028595f0f76f9.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://644db4de3505c40a0444-327723bce298e3ff5813fb42baeefbaa.ssl.cf1.rackcdn.com/c602742f337b6f61784028595f0f76f9.png" /></a></div>
<br />
<a href="https://oshpark.com/shared_projects/ZSjsiCUd">https://oshpark.com/shared_projects/ZSjsiCUd</a><br />
<br />
I finally got hold of one of these interface boards, courtesy of the surface mount component soldering skills of Bas de Bruijn.<br />
<br />
There was a comparatively simple way for me to test its capabilities.<br />
I
already had a turret knee-mill in my workshop, that I had converted to
Machinekit and which utilised a 5i25 and 7i76 Mesa combo.<br />
<br />
I simply needed to unplug the DB25 lead from the 5i25 to 7i76 and connect instead to the interface board P2.<br />
I was utilising an encoder on the 5i25 second header, so I connected this to the interface board P3. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://3.bp.blogspot.com/-H5NbNc2h0Hk/WC7KQzTalYI/AAAAAAAAAA8/2rt8tKBuXEgEAKMkpzvJlCuEvjgerdN0wCLcB/s1600/DSCN2826.JPG" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://3.bp.blogspot.com/-H5NbNc2h0Hk/WC7KQzTalYI/AAAAAAAAAA8/2rt8tKBuXEgEAKMkpzvJlCuEvjgerdN0wCLcB/s320/DSCN2826.JPG" width="240" /></a></div>
<br />
<ul>
<li>First steps.</li>
</ul>
<br />
I already had a SD card image built by Michael Haberler to run the board and program the FPGA.<br />
<br />
( These images are now deprecated, use:<br />
<a href="http://deb.machinekit.io/uploads/de0-nano/debian-8.5-console-armhf-2017-02-14/">http://deb.machinekit.io/uploads/de0-nano/debian-8.5-console-armhf-2017-02-14/</a> )<br />
<br />
You will need package <i>bmap-tools</i> to write this to SD and verify.<br />
<br />
Then use <i>gparted</i> to expand the second (rootfs) partition to the full size of the remaining space on the card.<br />
You could also create a swap partition if space allows, then edit /etc/fstab to use this.<br />
<br />
<ul>
<li>Setting up the image</li>
</ul>
Quite uniquely, the NIC does not have a preset MAC code and one has to be set<br />
Michaels gist deals with how to do this, via a UART connection into something like CuteCom.<br />
You
need to enter any keystroke whilst in the first stage of boot, set the
environment to include the MAC address and then trigger a reboot. <br />
<br />
<blockquote class="tr_bq">
<pre><code>=> env default -a
## Resetting to default environment
=> setenv ethaddr ba:d0:4a:9c:4e:ce
=> saveenv
Saving Environment to MMC...
Writing to MMC(0)... done
=> reset</code></pre>
</blockquote>
<br />
At the second boot you will get a terminal prompt,<br />
default user is <span style="color: red;">machinekit</span>, password <span style="color: red;">machinekit</span><br />
<br />
<span style="color: red;"><span style="color: black;">Do a <i>sudo apt-get update</i></span> <span style="color: black;">and install any extra packages you require, </span></span><br />
<span style="color: red;"><span style="color: black;">but do NOT <i>apt-get upgrade </i>if
you are using this image, because there is a later one, and upgrading
will overwrite its components and I could not get that one to work.</span></span><br />
<br />
<ul>
<li><span style="color: red;"><span style="color: black;">Running </span></span> </li>
</ul>
(This section assumes familiarity with 5i25 configs.)<br />
<br />
The only changes I needed to make to my config for the mill were at the top of the ini and hal files<br />
INI:<br />
<br />
<span style="color: magenta;"><span style="font-size: x-small;">[HOSTMOT2]<br />
DRIVER=hm2_soc_ol<br />
BOARD=de0n<br />
CONFIG="firmware=socfpga/dtbo/DE0_Nano_SoC_DB25.7I76_7I76_7I76_7I76.dtbo
num_encoders=2 num_stepgens=4"</span></span> <br />
<br />
HAL:<br />
<br />
<span style="font-size: xx-small;"><span style="color: magenta;"><span style="font-size: x-small;">loadrt trivkins<br />
loadrt tp<br />
loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD
num_joints=[TRAJ]AXES tp=tp kins=trivkins<br />
loadrt hostmot2 debug_idrom=1 debug_modules=1</span></span><br />
<span style="color: magenta;"><span style="font-size: x-small;">loadrt [HOSTMOT2](DRIVER) config=[HOSTMOT2](CONFIG)</span></span></span><br />
<br />
<span style="font-size: small;"><span style="color: blue;"><span style="color: black;">NB.</span> <span style="color: orange;">if you copy & paste from the sample config, note that tp=tp
kins=trivkins is commented out in that config</span></span><br />
<br />
The eagle eyed amongst you may have spotted that I specified
<i>encoders=2</i> in the config line<br />
<br />
Each header on the 5i25 and thus the Nano, only has 4 stepgens and 1
encoder, what this does is effectively enable the second DB25 header
output socket on Charles's interface board (equivalent to the header P2 on the 5i25) and the
<i>encoder.01</i> can be accessed from that.<br />
<br />
I use the second encoder solely for a hardware pendant MPG on this
mill, all the IO for the switches etc on that pendant go onto the
7i76 and are dealt with on the primary header. </span><br />
<br />
<span style="font-size: small;">It really was as simple as that.</span><br />
<br />
<span style="font-size: small;">I ssh'd into the Nano from another computer, using X forwarding</span><br />
<span style="font-size: small;">(ie. <i>ssh -X machinekit@192.168.1.XX</i>) </span><br />
<span style="font-size: small;">entered the /home/machinekit/machinekit directory which houses the pre-built RIP build.</span><br />
<br />
<span style="font-size: small;">Invoke `machinekit`, select the relevant config and it worked seamlessly, just as it had before.</span><br />
<br />
<span style="font-size: small;">This is a major achievement by </span><span style="font-size: small;">Charles Steinkuehler, Michael
Haberler, Michael Brown and Devin Hughes in particular.</span><br />
<br />
<span style="font-size: small;">Much kudos to them all. </span> Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-721739666225174355.post-6949379827369662412016-09-12T00:52:00.000-05:002016-09-12T00:52:30.443-05:00Introducing a blog about Machinekit, 3D printing, QtQuickVcp and more<div class="markdown-here-wrapper" data-md-url="https://www.blogger.com/blogger.g?blogID=721739666225174355#editor/target=post;postID=694937982736966241" markdown-here-wrapper-content-modified="true">
<div style="margin: 0px 0px 1.2em !important;">
Hello Machinekit community,</div>
<div style="margin: 0px 0px 1.2em !important;">
I recently started a new blog about Machinekit, 3D printing, QtQuickVcp and more (probably tech related) - <a href="http://machinekoder.com/">machinekoder.com</a>. My intention is to write a new article at least once a week.</div>
<div style="margin: 0px 0px 1.2em !important;">
Since I would like this blog to be a useful resource for any Machinekit interested person, I would very much appreciate if you propose topics that interest you most.</div>
<div style="margin: 0px 0px 1.2em !important;">
I think there is some interest in basic Machinekit getting started tutorials. Of course, I will try to merge things back to the main Machinekit docs if they prove useful.</div>
<div style="margin: 0px 0px 1.2em !important;">
Four blog posts are already waiting for you on <a href="http://machinekoder.com/">http://machinekoder.com</a></div>
<div style="margin: 0px 0px 1.2em !important;">
</div>
<ul>
<li><a href="http://machinekoder.com/?p=82">Mini 3D Printer from HobbyKing running with CRAMPS Board and Machinekit</a></li>
<li><a href="http://machinekoder.com/?p=67">Machinekit on the C.H.I.P. 9$ computer</a></li>
<li><a href="http://machinekoder.com/?p=33">Controlling TP-Link HS100/110 Smart Plugs with Machinekit</a></li>
<li><a href="http://machinekoder.com/?p=9">Machinekit and Cura</a></li>
</ul>
<br />
<div style="margin: 0px 0px 1.2em !important;">
Greetings,<br />Alex Rössler (Machine Koder)</div>
<div style="font-size: 0em; height: 0; margin: 0; max-height: 0; max-width: 0; overflow: hidden; padding: 0; width: 0;" title="MDH:PHA+SGVsbG8gTWFjaGluZWtpdCBjb21tdW5pdHksPC9wPjxwPjxicj48L3A+PHA+SSBmaW5hbGx5
IGZvdW5kIHRoZSBtb3RpdmF0aW9uIGFuZCBpbnNwaXJhdGlvbiB0byBzdGFydCBhIG5ldyBibG9n
IGFib3V0PC9wPjxwPk1hY2hpbmVraXQsIDNEIHByaW50aW5nLCBRdFF1aWNrVmNwIGFuZCBtb3Jl
IChwcm9iYWJseSB0ZWNoIHJlbGF0ZWQpIC08L3A+PHA+W21hY2hpbmVrb2Rlci5jb21dKGh0dHA6
Ly9tYWNoaW5la29kZXIuY29tKS4gTXkgaW50ZW50aW9uIGlzIHRvIHdyaXRlIGEgbmV3IGFydGlj
bGUgYXQgbGVhc3Qgb25jZTwvcD48cD5hIHdlZWsuIFNpbmNlIEkgd291bGQgbGlrZSB0aGlzIGJs
b2cgdG8gYmUgYSB1c2VmdWwgcmVzb3VyY2UgZm9yIGFueTwvcD48cD5NYWNoaW5la2l0IGludGVy
ZXN0ZWQgcGVyc29uLCBJIHdvdWxkIHZlcnkgbXVjaCBhcHByZWNpYXRlIGlmIHlvdTwvcD48cD5w
cm9wb3NlIHRvcGljcyB0aGF0IGludGVyZXN0IHlvdSBtb3N0LjwvcD48cD48YnI+PC9wPjxwPkkg
dGhpbmsgdGhlcmUgaXMgc29tZSBpbnRlcmVzdCBpbiBiYXNpYyBNYWNoaW5la2l0IGdldHRpbmcg
c3RhcnRlZDwvcD48cD50dXRvcmlhbHMuIE9mIGNvdXJzZSwgSSB3aWxsIHRyeSB0byBtZXJnZSB0
aGluZ3MgYmFjayB0byB0aGUgbWFpbiBNYWNoaW5la2l0PC9wPjxwPmRvY3MgaWYgdGhleSBwcm92
ZSB1c2VmdWwuPC9wPjxwPjxicj48L3A+PHA+Rm91ciBibG9nIHBvc3RzIGFyZSBhbHJlYWR5IHdh
aXRpbmcgZm9yIHlvdSBvbiBbaHR0cDovL21hY2hpbmVrb2Rlci5jb21dKGh0dHA6Ly9tYWNoaW5l
a29kZXIuY29tKTwvcD48cD48YnI+PC9wPjxwPkdyZWV0aW5ncyw8L3A+PHA+QWxleCBSw7Zzc2xl
ciAoTWFjaGluZSA8ZyBjbGFzcz0iZ3JfIGdyXzEyNCBnci1hbGVydCBncl9zcGVsbCBncl9ydW5f
YW5pbSBDb250ZXh0dWFsU3BlbGxpbmcgaW5zLWRlbCBtdWx0aVJlcGxhY2UiIGlkPSIxMjQiIGRh
dGEtZ3ItaWQ9IjEyNCI+S29kZXI8L2c+KTwvcD4=">
â</div>
</div>
Alexander R.http://www.blogger.com/profile/07713050639129933949noreply@blogger.com1tag:blogger.com,1999:blog-721739666225174355.post-75349413465193916692016-06-05T06:10:00.002-05:002016-06-05T06:10:46.205-05:00ANNOUNCE: Machinekit Europe meetingWe are pleased to invite anyone interested to the first Machinekit meeting in Europe, taking place on July 2nd and 3rd at the Electrolab Hackerspace in Paris/Nanterre, France.<br />
<br />
Please feel free to join us - share your plans, exchange experience, and help shape the future of Machinekit!<br />
<br />
The agenda is not yet fixed. However, so far following ideas have been collected:<br />
<br />
<ul>
<li>Frederic will present his Emco 120 + Intelys C3000 retrofits and demonstrate the XHC-HB04 pendant + DIY lathe control panel.</li>
<li>Alex will give a hands-on Machinekit workshop, including HAL and remote user interfaces with QtQuickVcp (help appreciated).</li>
<li>Bas will show a ROS configuration for the Matilda robot arm and talk about how the connection with Machinekit works.</li>
</ul>
<br />
<br />
... and anything you would want to bring up/contribute to! Please propose talks, bring your hardware and share your Machinekit experience.<br />
<br />
More venue and agenda details will be posted shortly, so watch for details, and speak up if you're planning to attend. So far, most folks are arriving sometime Friday and leaving Sunday evening.<br />
<br />
More details about hotels, transportation and agenda are available in<br />
this TitanPad: <a href="https://titanpad.com/SVIvrCTDyl">https://titanpad.com/SVIvrCTDyl</a><br />
<br />
Alex Bas Frederic ClementAlexander R.http://www.blogger.com/profile/07713050639129933949noreply@blogger.com0tag:blogger.com,1999:blog-721739666225174355.post-48608322462091217682016-05-31T08:38:00.002-05:002016-05-31T08:38:52.588-05:00Machinekit documentation goes on-lineWe are very pleased to announce that the existing machinekit-docs repository is now rendered automatically in html on the www.machinekit.io website.<br />
<br />
It was an intense 3 weeks of brain storming, document conversion and creation, struggling with a Jekyll rendering engines, within a docker container, within a Jenkins project deployment server, but now the worst is over and the docs are out there.<br />
<br />
Michael Haberler deserves the Order of the Duct Tape 1st Class, for managing to get the whole thing stuck together! <br />
<br />
The overriding aim of the work, was to have the whole process be automatically regenerative, any edit to the base repo documents being quickly reflected in the rendered site, no human intervention required, after a pull request is merged.<br />
<br />
Currently this takes as little as 2 minutes!<br />
<br />
A secondary objective was to make editing and adding to existing documents and contributing new documents as easy as possible.<br />
Only if the user base get actively involved in the documentation, will it transform into the information portal everyone wants.<br />
<br />
Features:<br />
<br />
A site wide search engine, powered by Google.<br />
Already very useful and will expand with time as indexing requests propagate.<br />
<br />
An 'Edit this page' link.<br />
This considerably lowers the bar to contribution, requiring only that the user has a GitHub account and user name, to allow them to edit docs and submit the edit as a Pull Request directly via a temporary branch reference.<br />
<br />
A SandBox page.<br />
This is for any kind of Machinekit connected contribution.<br />
It could be a HowTo on using a particular board with Machinekit,<br />
a blog type project progress report on a particular machine build,<br />
anything whatsoever.<br />
<br />
The document can be created by the same 'Edit this page' link and will be visible in the SandBox from the outset, whilst the maintainers consider how best to incorporate it into the document base.<br />
<br />
There is still more work to be done, but already we can see a 100% improvement.<br />
<br />
Please get involved and contribute your knowledge for all to benefit from. <br />
<br />
Mick, Bas and Michael.<br />
<br />
<br />Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-721739666225174355.post-68281527972287595932016-04-21T08:12:00.001-05:002016-04-21T08:12:56.331-05:00Necitec CNC Cape<div class="separator" style="clear: both; text-align: center;">
<a href="https://1.bp.blogspot.com/-iMcAjEV0hKY/VxjHbr83f7I/AAAAAAAACLY/ursQWxzT4ioqWnZlbs1MiqnejhINxwsFwCKgB/s1600/Necitec.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="231" src="https://1.bp.blogspot.com/-iMcAjEV0hKY/VxjHbr83f7I/AAAAAAAACLY/ursQWxzT4ioqWnZlbs1MiqnejhINxwsFwCKgB/s320/Necitec.JPG" width="320" /></a></div>
<br />
Necitec has a <a href="https://www.kickstarter.com/projects/necitec/up-to-4-axis-beaglebone-black-based-cnc-control">kickstarter</a> going for their new CNC cape, which supports 16 isolated inputs and buffered outputs for 4 step/dir drivers and 8 additional signals. Along with the cape, you also get a uSD card for the BeagleBone with Machinekit pre-installed, sample configurations, and a setup program for adapting system parameters.cdsteinkuehlerhttp://www.blogger.com/profile/12028187486525768375noreply@blogger.com2tag:blogger.com,1999:blog-721739666225174355.post-7988863661304297952016-04-13T07:50:00.000-05:002016-04-13T09:08:06.011-05:00Altera SoC running Machinekit with hostmot2 firmware<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.terasic.com.tw/attachment/archive/941/image/image_76_thumb.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://www.terasic.com.tw/attachment/archive/941/image/image_76_thumb.jpg" height="284" width="320" /></a></div>
Thanks to the tireless efforts of Michael Brown and others, the open-source hostmot2 firmware from <a href="http://mesanet.com/">Mesa Electronics</a> has been ported to the Altera SoC family and can be controlled with Machinekit running on the ARM core(s) using a Debian OS image. The <a href="http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=941">DE0-Nano</a> development board from Terasic was the first board supported, but the <a href="http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=165&No=836">DE1-SoC</a> and <a href="http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&No=816">SoCKit </a>boards also work.<br />
<br />
The hardware design files can be found in Michael's <a href="https://github.com/the-snowwhite/mksocfpga">mksocfpga GitHub repo</a>, and <a href="https://github.com/cdsteinkuehler/mksocfpga/blob/master/HW/README.BuildSystem.txt">instructions for creating a build machine VM</a> are available for those who do not already have an Altera Quartus development system setup.<br />
<br />
The OS is essentially stock Debian Jessie, but custom kernels, dtb files, and boot loaders are required for the various boards. Michael is working on build scripts to create full OS images, and the goal is to get builds integrated into RCN's excellent image build infrastructure, so updated images would be automatically built and released every few weeks.<br />
<br />
If you want to start testing with any of the SoC platforms, subscribe to the <a href="https://github.com/machinekit/machinekit/issues">Machinekit issues tracker</a>, and ask any questions on the <a href="https://groups.google.com/forum/#!forum/machinekit">Machinekit Google group</a>.cdsteinkuehlerhttp://www.blogger.com/profile/12028187486525768375noreply@blogger.com0tag:blogger.com,1999:blog-721739666225174355.post-46881117653352551792016-03-08T20:13:00.000-06:002016-03-08T20:13:18.548-06:00Furaday BeagleBone CapeMarius Alksnys and Robotise.lt have a new cape available for the BeagleBone, <a href="http://www.robotise.lt/hardware-for-beaglebone/8-furaday-cape-1.html">the Furaday</a>.<br />
<br />
This is the first commercially available cape that directly supports isolated I/O, encoders, and servo amplifiers. If you need something to work with traditional servos or quadrature encoders, this may be the cape you want.cdsteinkuehlerhttp://www.blogger.com/profile/12028187486525768375noreply@blogger.com0tag:blogger.com,1999:blog-721739666225174355.post-48708991084638967152015-11-16T08:38:00.000-06:002015-11-16T08:47:57.598-06:00Summary of open discussion at the Nov 2015 Machinekit MeetupOn friday afternoon and sunday morning we held open discussions about a range of themes, and formed an opinion on how to proceed with the project. I started out with a recap of the original goals, as it helps focusing on the road ahead:<br />
<br />
<h3>
Goal of the Machinekit Project</h3>
The core goal was and still is to make the HAL/realtime stack usable as a component of a larger project, and enable remote operation on a wide range of platforms (the "realtime appliance" idea), including new remote UI techniques.<br />
<br />
The existing CNC stack will continue to work, on top of the separated HAL stack, and should generally run existing configurations as is (or with trivial modifications).<br />
<br />
<h3>
Direction of the Machinekit project</h3>
To summarize the key changes of direction - we agreed the best course of action to be:<br />
<br />
<ul>
<li>split the project <i>horizontally</i> into packages (and eventually separate git repositories): a CNC stack, the HAL/realtime stack, and the machinetalk support package for remote clients. The CNC package will depend on the HAL/RT and machinetalk packages.<br />This is the key change: making the HAL stack reusable by other projects.</li>
<li><a href="http://blog.machinekit.io/2015/11/and-winner-is-rt-preempt.html">end support for the - essentially unused - RTAI and Xenomai-kernel flavor</a>s - this is required to simplify the build process and dependencies, and ease the previous step.</li>
</ul>
<div>
To understand what led up to this - here are the items discussed as I recollect them (with some personal observations added in):</div>
<div>
<br /></div>
<h3>
Topics discussed</h3>
<b>Code size:</b> the machinekit repository is a huge monolithic "blob". It contains everything from very low-level stuff to UI's (many of them deprecated), plus the whole CNC and realtime stacks. The amount of code is staggering - comparable in code size to mysql3 or roughly three times the Emacs editor source code, with a developer base diameter which is a fraction of comparable projects.<br />
<br />
<b>Build complexity:</b> Having everything - used or not - in one blob adds several dimensions of complexity: different RT kernels, various user interfaces, and the ongoing transition of replacing the middleware stack. This has resulted in a staggering number of prerequisite packages, which are very hard to get right, as the mailing list and tracker shows. The RTAI kernel threads build has added to that by making it very hard to use more standard tools like <a href="https://cmake.org/">cmake</a>, causing us to limp along with the legacy build scripts.<br />
<br />
<b>Reuse in other projects:</b> The HAL/realtime stack is one-of-a-kind and would be a great building block for other projects, like ROS, where it could be used as a 'realtime playout' and hardware interaction vehicle. And that part is actually rather small compared to the whole repository. But fact is: the unmanageable code size, build dependencies and build system make it extremely hard to adopt the realtime stack in a separate project - the complexity involved essentially precludes this, and this is why it did not happen. As things stand, adopting the realtime stack into another project is very unlikely to happen. So our priority must be to jettison complexity and simplify things wherever we can.<br />
<br />
<b>Different rates of change:</b> Most of the development around Machinekit has been in the HAL/realtime and machinetalk areas, and the UI development based thereon. But I think the major changes are in place or readying, and things are stabilizing overall. The actual CNC stack ontop so far has seen only minor changes. While the CNC stack will eventually be migrated to machinetalk, we are only part of the way into this work.<br />
<br />
<b>Tentative machinekit "stable branch"</b>: There have been suggestions to fork off a stable branch, focusing more on a versioned release rather than rapid development. This certainly makes sense for folks desiring to run off a less volatile code base, and the C4 process does encourage that. But it is important to note that this actually adds to the problems listed above while solving none of them - the "blob", the build complexity, external dependency, reusability: that all stays where it is, and would be managed in separate branches, spreading resources even thinner.<br />
<br />
<b>Talking to Machinekit remotely</b>: Both Alex and Bob have presented remote API's into Machinekit (Python and node.js), and remote clients will need to make use of the machinetalk stack to some extent - but certainly not the whole repository: requiring to build Machinekit on a remote client just for this part defeats the very purpose of going remote, which is to simplify things on the remote client rather than incur a build on a possibly separate platform. This suggests spinning out the required parts of machinetalk into a package which can be build separately (and more easily on target), and end managing protobuf as git subtree as we do now. We created the basic capability to use Machinekit remotely - we now need to wrap it such that this can be used by mere mortals.<br />
<br />
<h3>
Random bits and loose ends</h3>
<div>
<ul>
<li>We will be maintaining a build server, CI builds (likely separate from package builds), and package repos for all currently supported architectures. </li>
<li>I was surprised in the very strong interest in remote both remote operations, and actual use of the new remote UI's. Some of this comes from the new capabilities, and some from the relative freedom of licensing when creating a remote Machinekit UI.</li>
<li>The installation counts are significant and much higher than I thought - around 1400 distinct SD image downloads, and several hundred package users.</li>
<li>the resulting HAL/realtime package will have external package dependencies which are a fraction of the current list - making it much easier to reuse in other projects. </li>
<li>The current HAL revision under way suggests using a vehicle for inline API documentation (possibly doxygen or asciidoc-based as the zeroMQ project uses it)</li>
</ul>
</div>
<div>
<h3>
Plans for a Machinekit Foundation</h3>
<div>
An open source project on github only goes so far. At times it makes sense to have a bit more formal structure, and a legal entity at hand - for improved professional standing, but also as an endpoint for corporate or consortia memberships like EtherCAT or i-ROS. There is no intent to create any superstructure over the Machinekit project per se - rather a utility to be used when appropriate.<br />
<br />
One of the obvious purposes of such an entity could be to hold the domain name ownerships of the project (I currently hold these at my private expense), which will remove another dependency on a single person. I'd be happy to transfer ownership eventually. Same thing could go say for hosting contracts - non-profits also get usually better rates than individuals.</div>
<div>
<br /></div>
<div>
The role model we considered is the <a href="http://www.osrfoundation.org/">Open Source Robotics Foundation</a>, a not-for-profit organization under American law. It turned out that setting up such an entity can be done with moderate financial and recurring paperwork exposure. The majority felt this would be a useful step to take, and we will strive to have this entity setup before our next meetup.</div>
</div>
Anonymoushttp://www.blogger.com/profile/11450108660120427100noreply@blogger.com4tag:blogger.com,1999:blog-721739666225174355.post-81194366777931732372015-11-15T07:21:00.001-06:002015-11-15T07:21:27.611-06:00And the winner is: RT-PREEMPT<div class="p1">
<span class="s1"></span>Many might remember that one of the key contributions of the <i>unified build</i> branch of LinuxCNC - which eventually turned into Machinekit - was providing support to multiple realtime kernels. At the time, LinuxCNC only could make use of <a href="https://www.rtai.org/">RTAI</a>, distributing a well-aged version thereof.<br />
<br />
RTAI still yields the best latency figures. But that comes at a huge cost: having application code run in-kernel is not only unsafe at any speed, but fraught with an enormous build complexity, kernel version dependency and recurring maintenance chores. And that has not changed - as well as the restriction that RTAI runs on Intel architectures only. Moreover, the future of the RTAI project has become clouded as it has always been a bit of a one-man show lacking a healthy community around it to take over just in case.<br />
<br />
The alternatives supported by Machinekit are <a href="http://xenomai.org/">Xenomai</a> and <a href="https://rt.wiki.kernel.org/index.php/Main_Page">RT-PREEMPT</a>.<br />
<br />
Xenomai shares some history with RTAI - both are hypervisor kernels: the idea is to have a minimal, RT-capable scheduler and interrupt handler underneath the actual Linux kernel. RT threads use this hypervisor to achieve better timing than possible with a vanilla Linux kernel. Other than RTAI - where RT applications need to run in-kernel as modules similar to device drivers, Xenomai supports a threading model which almost looks like normal Posix threads - except that only rather restricted use of the Linux API can be made from such a thread. Xenomai does support a wide range of architectures, which is why it is the mainstay of running Machinekit on ARM platforms. Again this comes at a cost: Xenomai still requires a rather intrusive kernel patch and is available for a limited range of underlying Linux kernel versions. And given the fact that many embedded manufacturers choose to use a rather specific, sometimes outdated kernel version and sometimes do not upstream their patches into the Torvalds mainline Linux kernel, the chances for getting a working Xenomai kernel for such platforms is pretty low. That is the main reason for both RTAI and Xenomai kernels being "well aged" on most platforms.<br />
<br />
The third alternative is RT-PREEMPT - a set of patches to the standard Linux kernel to improve it's timing behavior, but without introducing a separate API, or a hypervisor. This project has been over a decade in the making, and at times there were doubts if it would make it into Linux mainline kernel. Initially being substantially higher latency than the hypervisor breed, over the last year or so huge progress has been made in terms of performance delivered on Intel platforms in particular, but also on ARM platforms: I recently tried an RT-PREEMPT kernel on a Raspberry-2 and it delivers slightly better latency than Xenomai on the Beaglebone, so it's getting pretty close.<br />
<br />
In the past, the argument for minimum latency has been its usefulness for software-based step generation and quadrature encoders - the actual servo cycle computations do not need that low latency. But fact is - the PC's parallel port is an extinct piece of hardware (and even then RT-PREEMPT can deliver reasonable software step rates). Plus, inexpensive FPGA hardware can deliver higher performance if needed.<br />
<br />
Picking one among the above choices needs to made by all users of realtime applications, not just us. Some funding for RT work has come from the financial industry for high-frequency trading in the past, and the automotive industry has a healthy interest as well, demonstrated for instance by the participation in the <a href="https://www.osadl.org/RTLWS-2015-Graz-Austria.rtlws17-graz-2015.0.html">Linux Realtime Workshop conference series</a>. This revolves mostly around the autonomous driving theme.<br />
<br />
There was some real good news recently: the <a href="http://www.marketwatch.com/story/the-linux-foundation-announces-project-to-advance-real-time-linux-2015-10-05">Linux Foundation announced that it will adopt the RT-PREEMPT project with the goal of bringing it into the mainline kernel</a> (note list of sponsors!). This assures the funding of the remaining work, and IMO it is reasonable to expect that in a few years - probably more than one, but certainly less than five - obtaining a RT-PREEMPT kernel will be just a build option of the mainline kernel. Already now building kernels is much, much simpler than any of the other options - and once that effort goes mainline and manufacturers actually support that kernel, it will be much simpler to obtain RT kernels for any platform, not just a few select ones.<br />
<br />
Is interesting to note that the <a href="https://xenomai.org/introducing-xenomai-3/">Xenomai3 effort</a> provides a common API over both the hypervisor-style and RT-PREEMPT kernels. Since Xenomai seems to enjoy a healthy industrial user base, it is important to offer a migration path to its users towards what - probably not only I - consider the winner of the RT kernels competition.<br />
<br />
These developments have some far-reaching implications for the Machinekit project, some of which were discussed at the recent meetup. Among those are:<br />
<br />
<br />
<ul>
<li>the performance edge provided by RTAI has become so small that it is by far outweighed by the enormous build complexity it entails for Machinekit. We have therefore decided to <b>end support for RTAI</b>.</li>
<li>With RT-PREEMPT very likely to go mainline, it is likely efforts are made by hardware vendors to support this rather than other options, meaning both range of supported hardware will widen, as well as functionality and performance improvements to show up here first. It will take a while until this "sinks in" with all involved, but the direction is clear.</li>
<li>For the time being we'll retain the Xenomai2 builds; while Xenomai2 is in maintenance mode already, we do have stable kernels around which perform great. And the build process is easy and robust. But there is not much point in a Xenomai3 port to just run RT-PREEMPT underneath - the rt-preempt flavor already does that. Any Xenomai3 hypervisor flavor needs to be weighed against the performance edge it has over RT-PREEMPT, and it looks like this edge is shrinking.</li>
<li>Ending support for kernel-threads enables removing the absurdly complex <a href="https://github.com/machinekit/machinekit/issues/336">legacy build system</a> by more mainstream tools like <a href="https://cmake.org/">cmake</a>.</li>
<li>using userland threads exclusively opens new options: so far HAL realtime code was restricted to C, as C++ is not supported for kernel modules. This has both potential for simplifying HAL itself, as well as making it easier to integrate with C++-based systems like <a href="http://www.ros.org/">ROS</a> and <a href="http://www.orocos.org/">Orocos</a>, or bringing in <a href="https://personal.traclabs.com/~pbeeson/publications/b2hd-Beeson-humanoids-15.html">improved solutions to old problems</a>.</li>
</ul>
<br />
<br />
<br /></div>
Anonymoushttp://www.blogger.com/profile/11450108660120427100noreply@blogger.com6tag:blogger.com,1999:blog-721739666225174355.post-16122668007318989072015-11-10T11:33:00.001-06:002015-11-10T12:56:41.777-06:00Machinekit meetup - summary of talks<div class="p1">
</div>
<br />
<br />
<span style="color: #666666; font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><span style="line-height: 12.32px;">Here's a list of all talks held at the meetup, including links to recorded video and slides:</span></span><br />
<ul>
<li><span style="background-color: white; color: #666666; font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif; line-height: 12.32px;">Bob van der Linden, </span><b style="background-color: white; color: #666666; font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif; line-height: 12.32px;">node.js-machinetalk</b><span style="background-color: white; color: #666666; font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif; line-height: 12.32px;">, an upcoming node.js - based remote API into the machinekit CNC and HAL stacks (</span><a href="http://bobvanderlinden.github.io/node-machinetalk-presentation/#1" style="background-color: white; font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif; line-height: 12.32px;">slides</a><span style="background-color: white; color: #666666; font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif; line-height: 12.32px;">)</span></li>
</ul>
<ul>
<li><span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><span style="background-color: white; line-height: 12.32px;"><span style="color: #666666;">A</span></span><span style="background-color: white; color: #404040; line-height: 16.5455px;">lexander Rössler, </span><span style="background-color: white; color: #666666; line-height: 12.32px;"><b>python-machinetalk</b>, on a Python-based remote API </span><span style="background-color: white; color: #666666; line-height: 12.32px;">into the machinekit CNC and HAL stacks (<a href="https://plus.google.com/events/ca9dg65qajhnqcig93pg9it5c24">video</a> <a href="https://github.com/strahlex/slides">slides</a>)</span></span></li>
</ul>
<ul>
<li><span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"> Charles Steinkuehler, <b>Platform Options for Machinekit: Current and Future</b>, review and outlook on "what is cooking in the hardware space", (<a href="https://plus.google.com/events/cul6pvbcpklk35jguij77phba8s?hl=en">video</a>)</span></li>
</ul>
<ul>
<li><span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><span class="s1">Charles Steinkuehler, </span><b>The need and use of multicore HAL</b> (<a href="https://plus.google.com/events/c930h723csiebehkfdrkcgbpnpk">video</a> <a href="https://github.com/cdsteinkuehler/Presentations">slides</a>)</span></li>
</ul>
<ul>
<li><span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><span class="s1">Michael Haberler & Mick Grant, <b>HAL âmultiKoreâ: making HAL safe & fast for multicore platforms</b> -</span><span style="background-color: white; color: #666666; line-height: 12.32px;"> about enabling safe use of multiple core processors for realtime tasks (<a href="https://plus.google.com/events/cvhj9r8m2gh0v0kj7ccme36hlpo">video</a> <a href="http://static.mah.priv.at/public/hal-mkore.pdf">slides</a>)</span></span></li>
</ul>
<ul>
<li><span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><span style="background-color: white; color: #666666; line-height: 12.32px;">Bas de Brujin, </span><b style="color: #666666; line-height: 12.32px;">Update on CANopen driver for HAL</b><span style="background-color: white; color: #666666; line-height: 12.32px;"> (</span><a href="https://plus.google.com/events/ctfd8iou5rmivuhqci0rptpufb4" style="line-height: 12.32px;">video</a><span style="background-color: white; color: #666666; line-height: 12.32px;"> <a href="https://github.com/luminize/canopen-machinekit/blob/master/Machinekit%20meetup%202015%20-%20machinekit%20and%20canopen.pdf">slides</a>)</span></span></li>
</ul>
<ul>
<li><span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><span style="background-color: white; color: #262626;">Jon Elson, PicoSystems, </span><span class="s1"><span style="background-color: white; color: #262626;"><b>Comments on the success of making CRAMPS boards and retrofit of 1996 photoplotter with a Beagle Bone</b> (<a href="https://plus.google.com/events/cu1uvijej9uafpfepnndp2cvbao">video</a>)</span></span></span></li>
</ul>
<ul>
<li><span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif;"><span style="background-color: white; color: #404040; line-height: 16.5455px;">Alexander Rössler, </span><b style="background-color: white; color: #404040; line-height: 16.5455px;">Building Qt5 UI's with the MachinekitSDK</b><span style="background-color: white; color: #404040; line-height: 16.5455px;">, covering creating user interfaces in the MachineSDK Vagrant VM and future possibilities of the MachinekitSDK (</span><a href="https://plus.google.com/u/0/events/cjaspd7cutbridu9t5771mrr830%EF%BB%BF" style="background-color: white; line-height: 16.5455px;">video</a><span style="background-color: white; color: #404040; line-height: 16.5455px;"> </span><a href="https://github.com/strahlex/slides" style="background-color: white; line-height: 16.5455px;">slides</a><span style="background-color: white; color: #404040; line-height: 16.5455px;">)</span></span></li>
</ul>
<br />
<br />
<br />
<br />
<div class="p2">
<span style="font-family: "helvetica neue" , "arial" , "helvetica" , sans-serif; font-size: x-small;"><span class="s1"></span></span></div>
<br />
<div>
</div>
Anonymoushttp://www.blogger.com/profile/11450108660120427100noreply@blogger.com0tag:blogger.com,1999:blog-721739666225174355.post-84282198964914280422015-10-04T09:34:00.004-05:002015-10-04T09:34:45.538-05:00ANNOUNCE: Machinekit Meetup<h3 wrap="">
Nov 6-8/2015, Madison WI </h3>
We are please to invite anyone interested to the second "real world" Machinekit meeting, taking place on November 6/8 at the Tormach facility in Madison, Wisconsin (USA). Please feel free to join us - share your plans, exchange experience, and help shape the future of Machinekit!
<br />
<br />
Rough agenda so far:
<br />
<ul>
<li>Charles will talk on "Platform Options for Machinekit: Current and Future", covering the upcoming newer ARM & ARM+FPGA options besides the existing armhf/x86/amd64 options</li>
<li>Alex will talk on "Building Qt5 UI's with the MachinekitSDK"</li>
<li>I will present on HALmk ("HAL-MultiKore") - about enabling safe use of multiple core processors for realtime tasks, and the future of kernels for machinekit</li>
</ul>
Other topics we could think of
<br />
<ul>
<li>firming up plans and procedures for a machinekit stable branch</li>
<li>status reports from the nodejs-machinetalk and python-machinetalk projects (remote API's)</li>
</ul>
.. and anything you would want to bring up/contribute to!<br />
<br />
More venue and agenda details will be posted shortly, so watch for
details, and speak up if you're planning to attend. So far most folks
are arriving sometime Friday and leaving sometime Sunday.
<br />
<br />
Charles, John, Alex, Michael, Bas
<br />
<br />
<br />
<br />
<br />
<br />
cdsteinkuehlerhttp://www.blogger.com/profile/12028187486525768375noreply@blogger.com1tag:blogger.com,1999:blog-721739666225174355.post-89681645056530066362015-06-24T10:18:00.000-05:002015-06-24T10:18:44.234-05:00Denford Novamill Conversion<div class="separator" style="clear: both; text-align: center;">
<a href="http://www.rs-online.com/designspark/electronics/eng/blog/upgrading-a-cnc-milling-machine-part-1"><img alt="http://www.rs-online.com/designspark/electronics/eng/blog/upgrading-a-cnc-milling-machine-part-1" border="0" src="http://www.rs-online.com/designspark/assets/ds-assets/uploads/images/5559b10f3ca842ab91477c580ab56371DSC_2029CNCMill-Original.jpg" height="213" width="320" /></a></div>
Designspark user stuartChilds has a multi-part blog entry documenting the conversion of a Denford Novamill with a non-working controller to using a BeagleBone Black running Machinekit with a <a href="http://blog.machinekit.io/p/hardware-capes.html#PBX-BB">Probotix cape</a> and Gecko stepper drivers. <a href="http://www.rs-online.com/designspark/electronics/eng/blog/upgrading-a-cnc-milling-machine-part-1">Part 1</a> covers the mechanical and wiring changes, while <a href="http://www.rs-online.com/designspark/electronics/eng/blog/upgrading-a-cnc-milling-machine-part-2">part 2</a> details software integration and configuration. Upcoming posts will cover the spindle drive, CAD/CAM, and "making chips".cdsteinkuehlerhttp://www.blogger.com/profile/12028187486525768375noreply@blogger.com0tag:blogger.com,1999:blog-721739666225174355.post-13305963079422170212015-03-31T11:43:00.001-05:002015-03-31T11:43:07.252-05:00Machinekit To Aid With Heart Research<div class="p1">
<span class="s1">Recently I was contacted by a Professor Andreas Lueger of Medical University of Graz, Austria, Dept. of Internal Medicine, probing me with some rather intricate questions on Machinekit. Andreas is head of the emergency room there, helipad on the roof and all. So if you drive recklessly around here, you stand a chance for a helicopter ride and being stitched up by Andreas and his team, but that is certainly not âmotion controlâ as we know it. That made me curious, and I visited Andreas to probe what he is up to:</span></div>
<br />
<div class="p2">
<span class="s1"></span><br /></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://2.bp.blogspot.com/-asTHdKP0ap0/VRm4JlYgXbI/AAAAAAAAAJ8/gFgKdOu-Fj8/s1600/andreas.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://2.bp.blogspot.com/-asTHdKP0ap0/VRm4JlYgXbI/AAAAAAAAAJ8/gFgKdOu-Fj8/s1600/andreas.png" height="145" width="200" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">
<span style="font-size: 12.8000001907349px;">Andreas in business attire, as found in his professional habitat</span></td></tr>
</tbody></table>
<div class="p1">
<span class="s1">Beyond stitching up patients, Andreas is deeply involved in heart research - <a href="http://static.mah.priv.at/web/Projekt_Andreas_Vers_2b.pdf">investigating atrial fibrillation, a precursor of heart attacks</a>. And that is some very geeky project - for his research, he develops the electronics based on a <a href="http://en.wikipedia.org/wiki/TI_MSP430">TI MSP430</a>, as well as the software for his own Wifi-enabled pacemakers - a whole new meaning of âembeddedâ for me. Andreas brought down current consumption to a couple of hundred nanoampĂ©res, and does solder the parts under his own stereo microscope:</span></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-RMNF8MQHmxM/VRm5S5-5eyI/AAAAAAAAAKQ/U_r4kJ-9uys/s1600/pacemaker.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-RMNF8MQHmxM/VRm5S5-5eyI/AAAAAAAAAKQ/U_r4kJ-9uys/s1600/pacemaker.png" /></a></div>
<div class="separator" style="clear: both; text-align: left;">
<br /></div>
<div class="p1">
<span class="s1">What can I say? at last an MD who talks our language! And when I visited him, he had a bug report for Machinekit, including a screenshot from his oscilloscope. I was impressed.</span></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p2">
</div>
<div class="p1">
<span class="s1">Now that pacemaker certainly is not running Machinekit, so where do we come in? Well, in the next iteration of the project, Andreas plans to integrate acceleration sensors in the setup, to measure actual mechanical performance of heart muscles. And for manufacturing these sensor attachments Andreas is designing a custom CNC machine with <a href="http://www.freecadweb.org/">FreeCAD</a>:</span></div>
<div class="p1">
<span class="s1"><br /></span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-vr1Ty_VUtqA/VRm4JfTCsII/AAAAAAAAAJ4/JHn_or2Wzck/s1600/CNC%2BWorkbensch.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-vr1Ty_VUtqA/VRm4JfTCsII/AAAAAAAAAJ4/JHn_or2Wzck/s1600/CNC%2BWorkbensch.jpg" height="299" width="320" /></a></div>
<div class="p1">
<span class="s1"><br /></span></div>
<div class="p1">
<span class="s1">
</span></div>
<div class="p1">
<span class="s1">Now weâre talking.. that machine will run Machinekit! Here comes the twist: Andreas plans to use <a href="http://www.trinamic.com/">Trinamic</a> <a href="http://www.trinamic.com/products/pandrives/pandrives-stepper/pd-1160?psk=+PD57-2-1160-TMCL">servo stepper motors</a>. Those are very smart motors with an embedded controller and power stages attached; among other features, these motors can detect and report a stall, and autonomously compensate for lost steps:</span></div>
<div class="p1">
<span class="s1"><br /></span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-Ti_7lmHckfM/VRm6cc1ZVBI/AAAAAAAAAKY/MAgaHbixa-U/s1600/192874_LB_00_FB.EPS_1000.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-Ti_7lmHckfM/VRm6cc1ZVBI/AAAAAAAAAKY/MAgaHbixa-U/s1600/192874_LB_00_FB.EPS_1000.jpg" height="200" width="200" /></a></div>
<div class="p1">
<span class="s1">Trinamic motors can be controlled through various methods: Step/Direction pins, RS232, RS485, USB, and CANbus. Now out of these options, <a href="http://en.wikipedia.org/wiki/CAN_bus">CANbus</a> is the most interesting one because it operates on a much higher level than the other options; the motor can report back (heartbeat, stall, position, velocity etc). Itâs really a much more intelligent motor subsystem than we usually use in Machinekit, like servos or stepgens.</span></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p1">
<span class="s1">I found all this terribly geeky, and beyond that also valuable for the project overall: if we investigate and collectively learn how to integrate CANbus, we open up Machinekit to literally thousands of peripherals with a professional bus system - as opposed to homegrown methods like hooking up an Arduino over RS232 or USB. The Beaglebone's <a href="http://www.ti.com/product/am3359">TI3359 chip</a> comes with two CAN devices on board - add <a href="http://www.microchip.com/wwwproducts/Devices.aspx?product=MCP2562">MCP2562 bus drivers</a> and you are done; or use <a href="http://www.logicsupply.com/eu-en/components/beaglebone/capes/cbb-serial/">an appropriate cape</a>. For other platforms, <a href="http://www.vscom.de/pci-2can.htm">PCI cards</a> and <a href="http://www.fischl.de/usbtin/">USB adapters</a> do the trick.</span></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p1">
<span class="s1">CANbus peripherals come in many shapes and forms - like <a href="http://www.icub.org/images/brochures/iCub_controllers_flyer_web.pdf">this controller</a> used by Claudio Lorini with support for the <a href="http://zedboard.org/">zedboard</a> which he recently merged into machinekit; but also more mundane devices like your car's windshield wipers and power windows: y</span>es - your car is a one extensive CANbus installation (provided your car was built in the current millennium). And if you research that topic, you will find thereâs a whole âcar CANbusâ hacking scene out there, using Arduinos and whatnot to tap into their carâs CANbus, <a href="https://www.youtube.com/watch?v=PbA_bOO2mMw">like this example</a>. </div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="p1">
<span class="s1">Where does this leave us? I have decided to support Andreas with this project, and while it is not absolutely certain the Trinamics will work as motion units as planned, it will be a very interesting expedition. And along the journey, Machinekit will learn to support CANbus peripherals.</span></div>
<div class="p2">
<span class="s1"></span><br /></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="p1">
<span class="s1">And that exciting story is the background why you saw references to CANbus in my recent postings to the Machinekit list!</span></div>
<div class="p1">
<span class="s1"><br /></span></div>
<div class="p1">
<span class="s1"><br /></span></div>
<div class="p1">
<span class="s1"><br /></span></div>
<div class="p1">
<span class="s1"><br /></span></div>
Anonymoushttp://www.blogger.com/profile/11450108660120427100noreply@blogger.com14tag:blogger.com,1999:blog-721739666225174355.post-55530142660990049542015-03-14T07:21:00.000-05:002015-03-14T07:21:13.501-05:00Machinekit Running on Odroid C1<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-aSKjFk5Qdas/VQQl2-1-LDI/AAAAAAAABqQ/AukpQ9tW0lg/s1600/OdroidC1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-aSKjFk5Qdas/VQQl2-1-LDI/AAAAAAAABqQ/AukpQ9tW0lg/s1600/OdroidC1.jpg" height="243" width="320" /></a></div>
Machinekit already runs on x86 machines, the BeagleBone, and the Raspberry Pi. Now GP Orcullo <a href="https://groups.google.com/d/msg/machinekit/a-HPcaKnxEY/F8eGmAmqFnQJ">reports he has Machinekit running on the Odroid C1</a> using rt-preempt. There are no hardware drivers yet, but it shouldn't take long to port GPIO access and get some motors moving. If you're interested, there's a link to a bootable Debian Wheezy image <a href="https://groups.google.com/d/msg/machinekit/a-HPcaKnxEY/F8eGmAmqFnQJ">in the Machinekit list post</a>.<br />
<br />
I'm anxiously waiting for boards based around all the new Big/Little parts coming out, which combine Cortex-A cores for good OS performance and Cortex-M parts for real-time tasks. Then there's the BeagleBoard X15 coming out soon with Big/Little + DSPs + PRUs! Exciting times in the ARM world!cdsteinkuehlerhttp://www.blogger.com/profile/12028187486525768375noreply@blogger.com1tag:blogger.com,1999:blog-721739666225174355.post-79544867717955048532015-03-10T13:01:00.000-05:002015-03-10T13:01:02.720-05:00IoT Vienna Presentation<div class="separator" style="clear: both; text-align: center;">
<iframe width="320" height="266" class="YOUTUBE-iframe-video" data-thumbnail-src="https://ytimg.googleusercontent.com/vi/VPaaXHBu7gE/0.jpg" src="http://www.youtube.com/embed/VPaaXHBu7gE?feature=player_embedded" frameborder="0" allowfullscreen></iframe></div>
Alexander Rössler recently gave a presentation on Machinekit and Machinetalk at the IoT Vienna Talks March 2015. If you're interested in the new remote user interfaces and distributed HAL capabilities, take a look!cdsteinkuehlerhttp://www.blogger.com/profile/12028187486525768375noreply@blogger.com0tag:blogger.com,1999:blog-721739666225174355.post-39097581862779451472015-02-27T16:36:00.001-06:002015-02-27T16:36:49.847-06:002015 Midwest RepRap Festival Coming Up<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-4nvMSXxdpxk/VPDrHghN1rI/AAAAAAAABg8/U2MmAEncnyM/s1600/IMGP0777.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-4nvMSXxdpxk/VPDrHghN1rI/AAAAAAAABg8/U2MmAEncnyM/s1600/IMGP0777.JPG" height="240" width="320" /></a></div>
The Machinekit vinyl stickers for the <a href="http://midwestreprapfest.org/">2015 Midwest RepRep Festival </a>hosted by <a href="http://seemecnc.com/">SeeMeCNC</a> arrived recently. I'll be handing out stickers and showing off various 3D printers running Machinekit soon in Goshen, IN.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-dUcrxE2JoXw/VPDtZsSukTI/AAAAAAAABhM/1VgzO6NpWG4/s1600/Beagle.RostockMax.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-dUcrxE2JoXw/VPDtZsSukTI/AAAAAAAABhM/1VgzO6NpWG4/s1600/Beagle.RostockMax.jpg" height="240" width="320" /></a></div>
Jason Kridner (of BeagleBoard.org) will also be there showing off his BeagleStock1, a SeeMeCNC Rostock Max v2 driven by <span class="_58cl">âȘMachinekit running on a BeagleBone Black.</span> <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<img border="0" src="http://2.bp.blogspot.com/-0rIu2w_VpZo/VPDxAwwv4SI/AAAAAAAABhc/3ebPaKwng8M/s1600/IMGP0785.JPG" height="240" width="320" /></div>
There will even be some complete BeagleBone and Machinekit powered electronics kits (BBB + CRAMPS + DRV8832) for your 3D printer or mini-mill being given away as door prizes! <br />
<br />
<br />
If you're anywhere near the Midwest (or have some spare frequent flyer miles) and are interested in 3D printing, the MRRF is something you won't want to miss! <br /><span class="_58cl"> </span><a class="_58cn" data-ft="{"tn":"*N","type":104}" href="https://www.facebook.com/hashtag/machinekit?source=feed_text&story_id=10152694373876659"><span class="_58cm"><br /></span></a><br />
<br />cdsteinkuehlerhttp://www.blogger.com/profile/12028187486525768375noreply@blogger.com0tag:blogger.com,1999:blog-721739666225174355.post-17780429758687189772015-02-21T17:15:00.000-06:002015-02-21T17:15:17.714-06:00Loadable Trajectory ModulesMichael Haberler has recently succeeded in separating the trajectory planner from the motion controller and made it a new <a href="https://github.com/machinekit/machinekit/issues/476#issuecomment-75374209">HAL vtable module</a>. While the details quickly get into technical programming issues, this seemingly esoteric feature actually means big changes are possible with higher level configurations.<br />
<br />
The new vtable modules allows HAL components, kinematics modules, and now the trajectory planner to be loaded and instantiated dynamically. That means you no longer need to know ahead of time how many of a particular component your HAL file needs, and you can do things like load more than one kinematics module or trajectory planner.<br />
<br />
What good is that, you ask? Well, the ability to dynamically load modules means you can craft modular HAL files without jumping through hoops to add up all the modules before you load anything. One HAL file might instantiate three PID loops for XYZ motion, and another included HAL file might add two more PIDs for temperature control. Even better, since you can use Python to work with HAL, you could have a Python program setup a complete HAL configuration based on a few parameters with a library of subroutines to craft basic modules like a servo driven axis, a stepper driven axis, a temperature control loop, etc.<br />
<br />
As for being able to dynamically load things like the trajectory planner and kinematics modules, that means you can now essentially have more than one "machine" running in the same HAL space. This provides an advanced way to handle things like tool changers and is helpful anywhere you need more than one control system. Perhaps you have a pick-and-place machine that includes a separate mechanism to place finished PCBs on a conveyer and load a new blank PCB. Maybe your robot arm also has a gimbal mounted camera you want to control independently. There are lots of times having more than one trajectory planner and kinematics module available is very helpful once you go beyond the world of traditional CNC machine tool applications.cdsteinkuehlerhttp://www.blogger.com/profile/12028187486525768375noreply@blogger.com0tag:blogger.com,1999:blog-721739666225174355.post-42232859647539764372015-01-21T16:02:00.000-06:002015-01-21T16:02:09.374-06:00New BeagleBone Images Avaialble<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-Xlh1zcM9dcc/VMAfQgxL-7I/AAAAAAAABdM/WtRJpELsi_I/s1600/machinekit_background_16x9.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-Xlh1zcM9dcc/VMAfQgxL-7I/AAAAAAAABdM/WtRJpELsi_I/s1600/machinekit_background_16x9.png" height="180" width="320" /></a></div>
Thanks to the tireless efforts of Robert C. Nelson, Machinekit uSD images for the BeagleBone are now part of the regular Debian image build cycle. The <a href="http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#BBW.2FBBB_.28All_Revs.29_Machinekit">first image is available now</a>, with updates expected about every two weeks.<br />
<br />
I will update my <a href="http://blog.machinekit.io/p/machinekit_16.html">Machinekit page</a> as soon as I get a chance, but for now just follow along with any of the BeagleBone getting started guides to put the xz compressed image onto a uSD card. Once you're running the image, you can easily perform updates using the standard Debian package management tools.<br />
<br />
Many thanks to Robert for building the images (and the required Xenomai kernel), everyone working on the Machinekit project for the packages, and to all of you who use these tools to drive your machines.<br />
<br />cdsteinkuehlerhttp://www.blogger.com/profile/12028187486525768375noreply@blogger.com0tag:blogger.com,1999:blog-721739666225174355.post-63565838002090166362015-01-19T12:28:00.000-06:002015-01-19T12:28:06.109-06:003D Printing With MachinekitWhile it is possible to 3D print with a "traditional" CNC controller like Mach3, LinuxCNC, or Machinekit, there are a lot of small problems that get in the way. There is a lot of ongoing work in the Machinekit project to make this process much easier.<br />
<br />
Alexander Rössler has been working on gcode remapping and a standard set of signal names that will reduce the amount of gcode post-processing required and improve print quality (migrating "queue-busting" custom M1xx codes for setting things like heater temperatures and fan speed to inline analog output values that keep the hot-end moving).<br />
<br />
Bas de Bruijn has been reworking the documentation files and build scripts, allowing documentation to exist in a separate (and easier for non-programmers to modify) repository. Very soon you should see online documentation built automatically just like the buildbot packages for the executable files.<br />
<br />
Jean-Paul Moniz has been working on getting some of the fancier bed-probing and auto-calibration features common in Arduino firmware working on Machinekit. I (Charles Steinkuehler) helped this effort slightly by exporting some homing settings to HAL that previously required a shutdown and restart of the linuxcnc application to change (traditional machine tools don't need to change their homing details very often).<br />
<br />
In addition, work is continuing with remote interfaces, velocity based extrusion, simplifying the example HAL files, and other changes to help make Machinekit more accessible for new users looking for a solution with more "upside" than an AVR or Cortex M4. Machinekit scales from systems like the BeagleBone and Raspberry-Pi to multi-core x86 systems with custom FPGA hardware interfaces.<br />
<br />
I'm sure I missed several folks who've reported progress on the mailing list, but it's not intentional. There's just so much happening with Machinekit already this year it's hard to keep track of it all!<br />
<br />
Remember, the best way to keep up to date is to monitor the <a href="https://groups.google.com/forum/#!forum/machinekit">Machinekit Google group</a>. Drop in and say hi!cdsteinkuehlerhttp://www.blogger.com/profile/12028187486525768375noreply@blogger.com2tag:blogger.com,1999:blog-721739666225174355.post-80108479709680901132014-12-22T17:44:00.002-06:002014-12-22T17:44:54.108-06:00Holiday PackagesIt's time for holiday packages! Not the kind you put under the tree, but the packages you install on your Linux OS to provide new programs and features.<br />
<br />Thanks to the incredibly awesome Robert Nelson, just about everything needed to install and run Machinekit is now available in the default BeagleBone Debian package repositories. This includes a few things back-ported from Jessie to Wheezy, some things that need to be built directly from source, and even a 3.14 Xenomai real-time kernel! The actual Machinekit packages (and the buildbot infrastructure that builds them) remain on the private repository generously provided by John Morris at DovetailAutomata.com.<br />
<br />
<b>MANY</b> thanks to Robert for this great work, which frees up the Machinekit developers to keep improving things.<br />
<br />
If you haven't worked with a package based Machinekit install yet, I suggest you try it out. Using packages makes it much easier to stay current with updates and enhancements. Instructions for <a href="http://www.machinekit.io/docs/packages-debian/">installing Machinekit from packages</a> can be found on the Machinekit website. Packages are available for the BeagleBone (arm7), Raspberry Pi (arm6), and generic PCs (i686/amd64). For real-time operation, you'll also need an appropriate real-time kernel (PREEMPT_RT, Xenomai, and RTAI are currently supported).cdsteinkuehlerhttp://www.blogger.com/profile/12028187486525768375noreply@blogger.com0