Monday, October 30, 2017

DE0-NANO-Soc Stretch image

There is now a Debian Stretch based Machinekit SD card image for the DE0-NANO-Soc.

It contains the new machinekit code which uses the new czmq4 API, so the RIP build is fully updateable from the main Machinekit repo.

The image is not extensively tested, but runs the mksocfpga sim fine, so should not have any issues with hardware.

The image is in compressed .xz format, expanding to 5GB approx.
It is heavier than previously, but does contain all the tools and libraries
necessary to rebuild Machinekit in situ and do some development.

There is a .bmap file with it to allow copying to card using bmaptool.

Files are located at:
http://deb.machinekit.io/uploads/de0-nano/debian-9.2-console-armhf-2017-10-29

You will need to write to at least a  8GB card and expand the fs
That will allow room for a swapfile, which is essential for rebuilding the RIP
using -j2, or else you will run out of memory compiling the C++ elements,
because g++ is particularly memory hungry in later versions.

Wednesday, February 15, 2017

Multicore merged into Machinekit

This is to advise users, that a major merge has occurred in the Machinekit repo.

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.

What is multicore?
This talk from 2015 gives the full details.
https://plus.google.com/events/cvhj9r8m2gh0v0kj7ccme36hlpo

What do you need to do?

With 3 particular exceptions, nothing at all, the aim has been to make it backwardly compatible,
so all your configs should work as before.

Please report any problems via the tracker at https://github.com/machinekit/machinekit/issues/1123

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.

Exceptions

  • The primary exception is for anyone using the DE0-NANO-Soc or Zynq as a Mesa 5i25 replacement
Improvements to the hm2_soc_ol driver now make use of a different string argument handling mechanism.

In practice, this simply means editing your hal file driver instantiation line from
newinst [HOSTMOT2](DRIVER) [HOSTMOT2]DEVNAME config=[HOSTMOT2](CONFIG)
to
newinst [HOSTMOT2](DRIVER) [HOSTMOT2]DEVNAME -- config=[HOSTMOT2](CONFIG)

The 2 dashes route the config string to the driver via a safer mechanism.
Any integer instanceparams such as 'debug=1' are passed as previously, so remain to the left side of the delimiter

If interested, this gives more details
https://github.com/machinekit/machinekit-multicore/issues/20

The binary SD card image for the DE0-NANO-Soc has been updated with a new
pull of Machinekit, containing Multicore available from
http://deb.machinekit.io/uploads/de0-nano/debian-8.5-console-armhf-2017-02-14/


  •  The multicore concept relies upon atomic operations in the C11++ standard and newer
These are supported sufficiently in gcc 4.7.2 and above in x86, which means the code will build under Wheezy with backports installed


Originally there were problems building for wheezy-armhf.
This was because all embedded toolchains have effectively deprecated gcc-4.7.

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.

Charles battled this for several days and has now sorted it and armhf packages for Wheezy are being built.

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.
All support will end in 2018.



  • 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.)
An API change sees
hal_ring_detach(char *name, ringbuffer_t *rb)
become
hal_ring_detach(ringbuffer_t *rb)

Thursday, January 12, 2017

Beta 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.
This talk from 2015 gives the full details.
https://plus.google.com/events/cvhj9r8m2gh0v0kj7ccme36hlpo

Volunteers are wanted to do the initial backward compatibility testing.
95% of existing configurations should work unchanged.
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.

After testing for any problems in backward compatibility, it is intended to merge with the main machinekit repo.
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.

Testers need to be able to build and run RIP builds,
        (http://www.machinekit.io/docs/developing/developing/ )
set debugging levels
        ( http://www.machinekit.io/docs/config/ini_config/#sub:EMC-section  - DEBUG=7 is normally sufficient)
and provide comprehensive logs of any errors
        (copy of relevant section of /var/log/linuxcnc.log, copy of dmesg for segfaults etc. and stderr output to terminal)
plus access to complete configs that produce them.
        (preferably via a github repo)

Testing across as wide a range of computers and machines as possible is crucial.

The repo is here http://github.com/machinekit/machinekit-multicore.git

If you are able to test;
from a terminal session
clone it
        (git clone http://github.com/machinekit/machinekit-multicore.git)
build it locally
        (cd machinekit-multicore/src && autogen.sh && configure (insert any platform specific switches) && make -j$(nproc) && sudo make setuid)
then set the env
        ( cd ../ && . ./scripts/rip-environment )
run your existing configs.
         (machinekit   ---- then select your config)

Results, bugs queries etc should be addressed to < https://github.com/machinekit/machinekit-multicore/issues/10 >


Sunday, November 20, 2016

DE0-Nano-Soc update on SD card Images

In my last entry I mentioned problems with the new SD card image and my use of a previous image.

This has now been resolved.

There was what equated to a typo in the device name specified in the .ini file for the sample configuration.
(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)
Thus anything based upon the sample, as mine was, did not work.

The image build system is in the process of being regenerated, once some other glitches are straightened out.

There is now an image with the repo as of 14/02/2017 here
http://deb.machinekit.io/uploads/de0-nano/debian-8.5-console-armhf-2017-02-14/
It includes the multicore code, with the updated hm2_soc_ol driver and
it has a 512MB swap partition, which makes it easier to rebuild and use both cores without running out of memory.

In my last entry, I also advocated the use of gparted to extend the rootfs partition to use the available SD card space.

Having twice had failures using gparted to do just this with SD cards recently, I have hit upon a successful command line strategy.

The images consist of a 1M uboot partition and an approx 3.6G rootfs partition.
If we use the designations on my desktop (which has a lot of other disks), they
are
/dev/sdf1 uboot
/dev/sdf2 rootfs

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.
Then we need to fix up the file system and expand it to the new partition size.

# check it is as you expect                                                                              
$ fdisk -l /dev/sdf                                                                                                
                                                                                                                         
$ umount /dev/sdf2                                                                                             
                                                                                                                         
$ fdisk /dev/sdf                                                                                                    
                                                                                                                         
# command d to delete partition                                                                     
                                                                                                                         
# select partition 2                                                                                          
                                                                                                                         
# w to write to disc                                                                                         
                                                                                                                         
$ fdisk /dev/sdf                                                                                                    
                                                                                                                         
# n to add, primary partition, same start sector as before, select full size    
                                                                                                                         
# w to write to disc                                                                                         
                                                                                                                         
# now fix the file system                                                                                 
$ e2fsck -f -y /dev/sdf2                                                                                        
                                                                                                                         
# resize the filesystem                                                                                     
$ resize2fs /dev/sdf2                                                                                           


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.

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

$ fdisk /dev/sdf

# n add primary partition number 3 use full size

# w to write to disc

$ mkswap /dev/sdf3

$ echo "UUID=<output-from-mkswap-here> none swap sw 0 0" >> /etc/fstab

Helps greatly if you are actually rebuilding machinekit in-situ.

Or you can use the swapfile method detailed in Michael's gist .
https://gist.github.com/mhaberler/89a813dc70688e35d8848e8e467a1337 
Cat skinning methods are plentiful 😼
 

Friday, November 18, 2016

DE0-Nano_Soc and the DB25 interface board - real world testing

You 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


http://blog.machinekit.io/2016/04/altera-soc-running-machinekit-with.html

In the next stage, Charles designed a DB25 connected interface board, with pin-outs matching the P2 and P3 headers on a 5i25.


https://oshpark.com/shared_projects/ZSjsiCUd

I finally got hold of one of these interface boards, courtesy of the surface mount component soldering skills of Bas de Bruijn.

There was a comparatively simple way for me to test its capabilities.
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.

I simply needed to unplug the DB25 lead from the 5i25 to 7i76 and connect instead to the interface board P2.
I was utilising an encoder on the 5i25 second header, so I connected this to the interface board P3.


  • First steps.

I already had a SD card image built by Michael Haberler to run the board and program the FPGA.

( These images are now deprecated, use:
http://deb.machinekit.io/uploads/de0-nano/debian-8.5-console-armhf-2017-02-14/ )

You will need package bmap-tools to write this to SD and verify.

Then use gparted to expand the second (rootfs) partition to the full size of the remaining space on the card.
You could also create a swap partition if space allows, then edit /etc/fstab to use this.

  • Setting up the image
Quite uniquely, the NIC does not have a preset MAC code and one has to be set
Michaels gist deals with how to do this, via a UART connection into something like CuteCom.
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.

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

At the second boot you will get a terminal prompt,
default user is machinekit, password machinekit

Do a sudo apt-get update and install any extra packages you require, 
but do NOT apt-get upgrade 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.

  • Running 
(This section assumes familiarity with 5i25 configs.)

The only changes I needed to make to my config for the mill were at the top of the ini and hal files
INI:

[HOSTMOT2]
DRIVER=hm2_soc_ol
BOARD=de0n
CONFIG="firmware=socfpga/dtbo/DE0_Nano_SoC_DB25.7I76_7I76_7I76_7I76.dtbo num_encoders=2 num_stepgens=4"


HAL:

loadrt trivkins
loadrt tp
loadrt [EMCMOT]EMCMOT servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[TRAJ]AXES  tp=tp kins=trivkins
loadrt hostmot2 debug_idrom=1 debug_modules=1

loadrt [HOSTMOT2](DRIVER) config=[HOSTMOT2](CONFIG)


NB. if you copy & paste from the sample config, note that tp=tp kins=trivkins is commented out in that config

The eagle eyed amongst you may have spotted that I specified encoders=2 in the config line

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 encoder.01 can be accessed from that.

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. 


It really was as simple as that.

I ssh'd into the Nano from another computer, using X forwarding
(ie. ssh -X machinekit@192.168.1.XX
entered the /home/machinekit/machinekit directory which houses the pre-built RIP build.

Invoke `machinekit`, select the relevant config and it worked seamlessly, just as it had before.

This is a major achievement by Charles Steinkuehler, Michael Haberler, Michael Brown and Devin Hughes in particular.

Much kudos to them all. 

Monday, September 12, 2016

Introducing a blog about Machinekit, 3D printing, QtQuickVcp and more

Hello Machinekit community,
I recently started a new blog about Machinekit, 3D printing, QtQuickVcp and more (probably tech related) - machinekoder.com. My intention is to write a new article at least once a week.
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.
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.
Four blog posts are already waiting for you on http://machinekoder.com

Greetings,
Alex Rössler (Machine Koder)

Sunday, June 5, 2016

ANNOUNCE: Machinekit Europe meeting

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

Please feel free to join us - share your plans, exchange experience, and help shape the future of Machinekit!

The agenda is not yet fixed. However, so far following ideas have been collected:

  • Frederic will present his Emco 120 + Intelys C3000 retrofits and demonstrate the XHC-HB04 pendant + DIY lathe control panel.
  • Alex will give a hands-on Machinekit workshop, including HAL and remote user interfaces with QtQuickVcp (help appreciated).
  • Bas will show a ROS configuration for the Matilda robot arm and talk about how the connection with Machinekit works.


... and anything you would want to bring up/contribute to! Please propose talks, bring your hardware and share your Machinekit experience.

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.

More details about hotels, transportation and agenda are available in
this TitanPad: https://titanpad.com/SVIvrCTDyl

Alex Bas Frederic Clement