Linux CNC

[uMinded]

THIS IS A VERY PRELIMINARY BUILD

I have managed to compile LinuxCNC-v2.5 on my olinuxino. I am running headless as I am on a micro so all of the GUI tests failed and about 33 other did as well but the HAL layer is working and as this is the heart of LinuxCNC I think its a win.


NOTE:
This is all done on my Embeded Debian ARMEL RootFS: POSTED HERE
Our unofficial Olinuxino Wiki


TODO:
1) Figure out how to compile Driver modules for LinuxCNC without requilding the entire package.
2) The first step is we need to write a HAL driver to access the sun5i_gpio's. I recommend using src/hal/drivers/hal_gpio.c as the base as that is the Rasberry Pi driver and its GPIO is nearly the same as ours.


== Compile Xenomai Kernel ==
I will post another thread on this when I have time. For now follow Xenomai for A13 - A10.
The latest patch is at Crubille's site
That thread also has a breakdown on compiling the userspace programs.


== Dependencies ===
Must haves:

Code Select Expand


apt-get install --no-install-recommends \
build-essential gettext autoconf \
libpth-dev libncurses5-dev tcl8.5-dev \
tk8.5-dev bwidget blt libxaw7-dev \
libreadline6-dev libgl1-mesa-swx11 \
libglu1-mesa-dev libgl1-mesa-dev \
libgtk2.0-dev yapps2-runtime libtk-img \
python python-dev python-support \
python-tk python-lxml python-xlib \
python-gtkglext1 python-configobj \
python-glade2 python-numpy \
python-imaging python-imaging-tk \
libboost-python-dev libudev-dev


Also needs:

Code Select Expand


apt-get install --no-install-recommends \
sudo xauth bc git



=== Get LinuxCNC ===

Code Select Expand


git clone git://git.mah.priv.at/emc2-dev.git linuxcnc-rtos
cd linuxcnc-rtos
git checkout rtos-integration-preview3



=== Modify LinuxCNC ===
src/rtapi/arm_bitops.h:

Code Select Expand


#elif defined(__arm__)

#include "arm_bitops.h"

#define typecheck(a,b)
#define raw_local_irq_save(a)
#define trace_hardirqs_off()
#define raw_irqs_disabled_flags(flags)
#define trace_hardirqs_on()

#define local_irq_save(flags)                           \
        do {                                            \
                typecheck(unsigned long, flags);        \
                raw_local_irq_save(flags);              \
                trace_hardirqs_off();                   \
        } while (0)

#define local_irq_restore(flags)                        \
        do {                                            \
                typecheck(unsigned long, flags);        \
                if (raw_irqs_disabled_flags(flags)) {   \
                        raw_local_irq_restore(flags);   \
                        trace_hardirqs_off();           \
                } else {                                \
                        trace_hardirqs_on();            \
                        raw_local_irq_restore(flags);   \
                }                                       \
        } while (0)


#define _atomic_spin_lock_irqsave(l,f) do { local_irq_save(f); } while (0)
#define _atomic_spin_unlock_irqrestore(l,f) do { local_irq_restore(f); } while (0)

static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
{return(0);}
static inline int test_and_clear_bit(int nr, volatile unsigned long *addr)
{return(0);}

#else // out of architectures
#error The header file <asm/bitops.h> is not usable and rtapi does not yet have support for your CPU
#endif // (defined(MODULE) && !defined(BUILD_SYS_USER_DSO))
#endif // defined(USE_GCC_ATOMIC_OPS)
#endif // RTAPI_BITOPS_H



=== Compile LinuxCNC ===
Now during compile you will see a lot of warning about compiling against kernel headers. This is generally frowned upon when distributing software but since we are building from source on an already customized kernel then their is no harm.

Code Select Expand


cd src
sh autogen.sh
./configure
make
sudo make setuid



=== Running LinuxCNC ===
I can only run commands as root, my user is in the xenomai group but I get complaints from xenomai.

Code Select Expand


sudo adduser <yourlogin> xenomai
sudo adduser <yourlogin> kmem
// If xenomai complains then use root for now
su
source ./scripts/rip-environment
halrun
// You now have a halcmd: prompt



=== Hal Test ===
At Halcmd: prompt

Code Select Expand


loadrt siggen
show comp
show pin
show param
show funct
loadrt threads name1=test-thread period1=1000000
show thread
addf siggen.0.update test-thread
show thread
start
show pin
show pin
stop
exit


[uMinded]

I have written a preliminary driver for the A13's GPIO. It has no features at all and hard codes GP09 (the green LED) as an output. This however has allowed me to set up the HAL stepgen and actually toggle the bit.

src/hal/drivers/sun5i_gpio.c

To get it to compile you need to modify the following makefiles:
src/makefile.inc.in:211:CONFIG_SUN5I_GPIO=m
src/Makefile:804:obj-$(CONFIG_HAL_GPIO) += sun5i_gpio.o
src/Makefile:805:sun5i_gpio-objs := hal/drivers/sun5i_gpio.o
src/Makefile:1060:../rtlib/sun5i_gpio$(MODULE_EXT): $(addprefix objects/rt,$(sun5i_gpio-objs))

To test out the functionality make sure nothing else is using PG09 like the new LED module and do:

Code Select Expand


loadrt threads name1=fast fp1=0 period1=50000 name2=slow period2=1000000
loadrt stepgen step_type=0 ctrl_type=v
loadrt sun5i_gpio
loadrt siggen
addf sun5i_gpio.write fast
addf stepgen.make-pulses fast
addf siggen.0.update slow
addf stepgen.update-freq slow
net blinky stepgen.0.dir => sun5i_gpio.pin-09-out
net velocity siggen.0.cosine => stepgen.0.velocity-cmd
setp stepgen.0.enable 1

start


The theoretical speed of the best pulse train with my setup is 50kHz but that is with nothing optimized. I am taking a break from code for a while as the pay job is piling up but here is what needs to be done:

TODO:
- Data structure large enough to hold all possible GPIO
- Data configuration string the same size of the data one. -1 to diable, 0 for input, 1 for output. Ideally this is a text file so when we do loadrt its customizable without re-compiling.
- A data masking structure so we do not touch the bits configured as -1 as this would muck up connected hardware
- In the read and write functions we need to parse the massive data structure and set/read the appropriate bits.

- My original attempt was to create a 9x32 array so that read/write would be a simple matter of writel() & mask nine times in each function but the hal_addf() was being belligerent and hopefully someone who understands pointers better can get it to work.

[ehj666]

That is way cool. I got sidetracked this week by something called paid for work.:-) I hope to get back on it this week. I am still having trouble getting the xenomai utilities running.

I am however running xfce4 on my Oli, so am wondering if the python, etc. errors will go away.

Good work.

[otto_pjm]

Guys,

I'm not sure if you are tracking this, but I thought it might be helpful to unite efforts. I believe this is using the same RPi GPIO code, you are discussing as a starting point. The thread goes on from here talking about strategies to implement GPIO using DMA. I understand a bit of the theory, but none of how this would be implemented.

http://linuxcnc.org/index.php/english/forum/18-computer/20514-emc2-running-on-raspberry-pi?start=130

Sorry if you are already tracking this.

Pete

[olimex]

using DMA is OK for large blocks of data, but I doubt for the purpose of GPIO 1 word of data it will have any benefit in opposite I think the setup etc of DMA to transfer just 1 word of data will make the DMA approach much slower than /dev/mem direct write

[JohnS]

True but I think it's really intended for thousands of (pairs of, in the case of step/dir) bits per DMA.

DMA will have various latency/jitter/etc issues but they can hopefully be much smaller than those of Linux.

John

[awallin]

Great work!
Has there been any progress on this since March?

Could you run latency-test and report what numbers you get?
The standard latency-test requires X+GUI, but you could easily cook up something text-based in HAL. See for example:
http://www.anderswallin.net/2012/12/latency-histogram/

I would be very interested in using SPI from HAL (for writing/reading to/from DAC/ADC chips).
Can anyone comment on how hard it would be to write a HAL SPI-driver?

Anders

[otto_pjm]

Not to highjack the thread to RPi, but,

You can look here for an update of LinuxCNC on the RPi.
http://www.linuxcnc.org/index.php/english/forum/18-computer/20514-emc2-running-on-raspberry-pi?start=170
It's development is stalled, but the DMA approach shows promise. The driver was not complete enough to allow me to tune it for the drivers I have, but I had it running my CNC router for a few days.The RPi version ran X windows OK, I used the lxde windows manager, but I don't believe the latency test was ported with the RPi code.

In theory the DMA approach would work with other ARM systems, I don't know how much porting it would take, and I'm not sure if the "using the onboard PWM module" used is RPi specific. The driver was based on the GPIO code for PWM here, which is RPi specific code
http://pythonhosted.org/RPIO/pwm_py.html

Sorry for the confusing update, but maybe it will spur some development.

Pete

[BJFreeman]

here is another curve.
use eagle by cadsoft
and pcb-gcode
the spool the results to your CNC

[apollo]

Hi
I followed uMinded instructions, but I could not run EMC2, Xenomai wok fine as I can execute  Latency test
I'm using kernel 3.4.12 with xeno patch from the wi-ki (uploaded by TELE) cross-compiled with gcc 4.6 gnueabihf (ubuntu 12.04)
Xenomai tools compiled with gcc 4.6 hard float
Linuxcnc does compile shautogen.sh => ok
./configure =>ok
Make => ok
Make setuid => got problem with Directory missing then did I create them manually
When I run Halrun there's errors msgs :
..../scripts/halrun :line34:halcmd:command not found
..../scripts/halrun :line39:halcmd:command not found
..../scripts/halrun :line40:halcmd:command not found
..../scripts/realtime:line190:rtapi-app :command not found
I tried with the option => ./configure --with-threads=xenomai-user but still same error :/
Please what I'm doing wrong ?, I searched for a week now and I couldn't find anything
Thanks in advance