MrGreg
Posts: 66
Joined: Sun Jun 10, 2012 7:25 pm

rtstepperemc CNC for RPI

Wed Dec 05, 2012 12:03 am

Found this recently

http://www.ecklersoft.com/

Looks like it could provide a basic CNC solution for the Pi without the need for a realtime kernel.
4 stepper axis and three input lines

Briefly it is a usb dongle device with a PIC microcontroller doing the realtime thing with a cut down version of EMC2 - linuxcnc running on the pi providing the brains and a graphical front end.

Managed to get the rtstepperemc - tkmini software to compile on the pi and run the gui. So far so good. On the basis of that bit seemingly working I have ordered hardware to evaluate and test, I'll post back progress when I get the opportunity to try it out with some real steppers.

Note this post is a follow on from here
http://www.raspberrypi.org/phpBB3/viewt ... =63&t=9490

To try out the rtstepperemc software to have a play and tinker about:

Brief "How To" to get rtstepperemc to compile on Raspian October 2012 ( perhaps not the best or right way, but it seems to work - !)

Download the most recent source release from here
http://www.ecklersoft.com/download.shtml

Run an update to ensure you have got the latest versions

You will need these installed

libncurses5-dev

tcl

tcl-dev

tcl8.5-dev

libusb-dev

Then unzip the source release into your home dir

Then, go to the task dir in the rtstepperemc. xxx dir
there should be a file called tclext.cc
open it with a text editor Eg Leafpad
Find the line

#include <tcl.h>

and change it to

#include <tcl8.5/tcl.h>

rtstepper should now successfully compile

You will have to type in tkmini into the "Run" command from the main menu on the GUI or from a terminal to get it to go. Currently there is no menu entry for it

There is a deal of info on the ecklersoft site at the top of this post.

I'm rather short of "quality time" at the mo so it might be a few weeks before I get to test it with real hardware.

MrGreg
Posts: 66
Joined: Sun Jun 10, 2012 7:25 pm

Re: rtstepperemc CNC for RPI

Sun Jan 06, 2013 1:47 am

OK
I think I have this device working fairly well with the Pi !

Built an Ecklersoft reference design dongle with pre programmed PIC device from Ecklersoft.
Did a series of comprehensive bench test evaluations with drivers and various steppers.

As best I can tell the realtime moves are executing correctly from the Gcode. There is some dead time delay between moves while the Pi is calculating the next move. The Pi is obviously limited by its cpu capability, so the total execution time is proportional to the settings applied to the tkmini & dongle, the level of overclock you are happy to apply to the Pi, and how the software is compiled. This will determine the amount of dead time, and therefore the total execution time.

I will fill in detail and limitations and a digestible description of how to get it all working and some optimization ref info, hopefully in the next few days.

Happy new year

Hakase
Posts: 6
Joined: Tue Sep 04, 2012 4:38 pm

Re: rtstepperemc CNC for RPI

Mon Jan 07, 2013 7:44 am

Did you run those tests with stock or overclocked RPI?

MrGreg
Posts: 66
Joined: Sun Jun 10, 2012 7:25 pm

Re: rtstepperemc CNC for RPI

Mon Jan 07, 2013 8:40 pm

Here follows from my notes a fairly comprehensive evaluation report

Ecklersoft CNC Dongle Evaluation-1


Bench test evaluation only, to determine functional suitability for use with “Raspberry Pi” ARM computer.

Ecklersoft dongle PIC device (Ref design on pcb with 0.1 pin header)
Drivers: Pololu 4988
Stepper motors: Various, including nema 14

Gcode: chip.nc From Ecklersoft website
Rtstepper.ini: Default version or modified as indicated

Benchmarking against various ‘086 machines: chip.nc & default .ini
Times accuracy less than +/- 1min

Pentium D820 2.8GHz Ubuntu Ecklersoft binary.
23mins execution time

Centrino 1.6GHz Win XP Ecklersoft binary
23mins execution time

Pentium 3 800MHz Ubuntu Ecklersoft binary
26mins execution time

Initial test run with RPi with modest overclock @ 800MHz
1hr 15mins execution time (chip.nc & default .ini)
1hr 3mins execution time compiled with vfp

Second test RPi @ 800MHz
Rtstepper.ini mods: INPUT_SCALE = 500 , CYCLE_TIME = 10
56mins execution time
48mins execution time compiled with vfp

Third test RPi @ 900MHz
Rtstepper.ini mods: INPUT_SCALE = 500 , CYCLE_TIME = 0.2 (default)
57mins execution time
56mins execution time compiled with vfp

Fourth test RPi @ 900MHz
Rtstepper.ini mods: INPUT_SCALE = 500 , CYCLE_TIME = 10
45mins execution time
44mins execution time compiled with vfp

Observations:
22 – 23mins is about the shortest mechanical execution time, thus the figures above are mechanical execution and software execution time combined or start to finish time.
Reducing INPUT_SCALE (steps per unit length) and increasing CYCLE_TIME (polling interval and DRO - GUI display time) gives significant improvement to execution time.
Overclocking the RPi also offers an improvement, although overclocking in general is not a good thing to do to a cpu. 900MHz is about as much as the RPi can be expected to do without significant risk to reliability given the cpu was running at 100% most of the time.
500 steps per inch (25mm) is about the minimum expected resolution for an average user.

Comments:
The evaluation was limited to a basic capability study to assess whether the RPi could run the software & hardware and drive stepper motors as described by Ecklersoft for use with an ‘086 class computer.
Within the limitations of the evaluation, the RPi seems to run the software and accompanying hardware successfully, all be it rather slowly. There is quite a delay between each successive line of Gcode while the RPi is calculating the next line prior to execution through the hardware. This a reflection on the total execution time, not the apparent “realtime” stepper sequences.

I feel, (currently just my opinion) that there is significant scope for improvements possibly including speed of execution by truncating the trajectory calculations and an improved or alternative to the current GUI and possibly including options to the DRO display to 3 decimal places (Imperial – inch) or 2 decimal places (Metric) or less.

Initially the Rpi was run and tested with no overclock. The tkmini interface and accompanying software was consuming about 20 – 30% at idle with no dongle attached. With dongle attached, 70 – 80% cpu without doing any cnc processing. This left little usable headroom, so all tests were performed at 800 and 900MHz. I expect it would run without overclock but somewhat more slowly.

Software compliations

The first compliations were with a modified tclext file to include tcl8.5. The second compliations used a modified ./configure command. The third compliations returned to a modified tclext file and a modified Makefile to include the vfp (fpu capability) options.

Note:
At the time of compilation (Early Jan 2013) the Raspian FAQ advisory said
Here


http://www.raspbian.org/RaspbianFAQ#Wha ... an_code.3F


The compiler tools included in the Raspbian repository are, by default, pre-configured to produce code compatible with Raspbian. However, if you are looking to port compiler tools over to Raspbian, the settings required for most GNU tools are as follows:
• -march=armv6
• -mfpu=vfp
• -mfloat-abi=hard
These settings produce code with armv6 specific instructions, vector floating point instructions and specify the ARM EABI where floating point values are to be passed in floating point registers. Additional information can be found in the Debian hard float documents.



Whilst we were using compiler tools from Raspian, we didn’t know what “compatible” really meant. So we went ahead and included the vfp options in the compilation anyway with an apparent positive outcome.

Comments Re VFP
Compiling with VFP gives a modest to significant improvement at 800MHz, but little apparent improvement at 900MHz. Suspect / speculate that sustained cpu at 100% is causing thermal shutdown of overclock negating any further usefull reduction in execution time.

Special thanks to Toby Davies for his software skills.

Mr Greg 7th Jan 2013


I will follow through with other bits and bobs later.

User avatar
gordon@drogon.net
Posts: 2020
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
Contact: Website

Re: rtstepperemc CNC for RPI

Mon Jan 07, 2013 11:10 pm

Browsing this out of idle curiosuty, however I was heavilly involved with CNC stuff some 25-30 years ago and back then we had controllers that used really slow (by todays standard!) microprocessors, and not much else, so I'm really surprised to read that there is latency between the Pi calculating the next move and pondering overclocking to make it faster. Certianly I had no issues with the robotics I was doing on a BBC Micro (not CNC, but very similar and controlling stepper motors, although I did have a dedicated own-design 6502 board to do the actual motor control)

What am I missing?

-Gordon
--
Gordons projects: https://projects.drogon.net/

ksangeelee
Posts: 192
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
Contact: Website

Re: rtstepperemc CNC for RPI

Mon Jan 07, 2013 11:35 pm

Well done for getting this far! I couldn't figure out from your description if the test were being driven from your cut-down version of LinuxCNC, or if the rtstepper code with the dongle is capable of accepting the g-code directly.

If from LinuxCNC, did you try with the Axis GUI's preview pane disabled (can't remember if that's in the View menu or the Machine menu), and if so did it make a noticeable difference to the processing time?

MrGreg
Posts: 66
Joined: Sun Jun 10, 2012 7:25 pm

Re: rtstepperemc CNC for RPI

Tue Jan 08, 2013 12:38 am

Everything was done with the rtstepperemc software from Ecklersoft, and /or compiled from sourcecode from Ecklersoft download area.
I'll write up a HowTo, or rather What-We-Did re the final test & compile with fpu - vfp stuff shortly

Serac
Posts: 124
Joined: Wed Jul 18, 2012 2:49 pm

Re: rtstepperemc CNC for RPI

Sun Jan 27, 2013 5:59 pm

Looked over the rtstepperemc code a couple of months back - There is scope to improve things and remove some of the bottlenecks. Without resorting to low level coding, you could try using (re)nice to bump up the priority of the core executable.

MrGreg
Posts: 66
Joined: Sun Jun 10, 2012 7:25 pm

Re: rtstepperemc CNC for RPI

Sun Jan 27, 2013 10:28 pm

Re my earlier report - evaluation
I have largely ruled out any problems with the overclock running out of steam.
However, various updates to Raspbian Oct 2012 seem to have slowed the total execution time a bit between test runs.
Raspbian Dec 2012 has had a significant impact on the total execution time. Slowed things up quite a bit.

Raspbian Oct 2012
Using the default rtstepper.ini and chip.nc and compiling with vfp options we came in at circa 1hr 3m (+/- a couple of mins)

Raspbian Dec Dec 2012
As above but now coming in at 1hr 25m ish

So, until Raspbian development reaches a steady and stable state it is difficult to tell whats going on.

@ Serac
I also had the notion of "nice" ing it up a bit, but thought that would best left as a cherry on top or an action of last resort, depending on your viewpoint. If you do have any ideas about how to speed things up at a coding level, then do please share. I am aware of at least one code developer who has taken an interest in this. I am also aware of the existence of a command line interface within linuxcnc/EMC2. Perhaps that would be a potential way forward?
Your thoughts?

As this product is open source software with closed source firmware/hardware, I am hoping that Ecklersoft will a lead role in assisting with the software development.
So, would be users, go and pester Ecklersoft and urge some development and info to make it Pi friendly !
Here
http://www.ecklersoft.com/

Finally courtesy of Ecklersoft a ./config command to compile with the dependencies as per OP and including the fpu/vfp options for RPi

Code: Select all

./configure --prefix=/usr CFLAGS="-g -O2 -march=armv6 -mfpu=vfp -mfloat-abi=hard -I/usr/include/tcl8.5" CXXFLAGS="-g -O2 -march=armv6 -mfpu=vfp -mfloat-abi=hard -I/usr/include/tcl8.5"
I have tested this out and it seems to work OK

Serac
Posts: 124
Joined: Wed Jul 18, 2012 2:49 pm

Re: rtstepperemc CNC for RPI

Mon Jan 28, 2013 12:10 am

MrGreg wrote:So, until Raspbian development reaches a steady and stable state it is difficult to tell whats going on.

If you do have any ideas about how to speed things up at a coding level, then do please share. I am aware of at least one code developer who has taken an interest in this. I am also aware of the existence of a command line interface within linuxcnc/EMC2. Perhaps that would be a potential way forward?
I'm waiting for the BCM2708 support to hit the mainline kernel tree - Some of it is already in the 3.8-arm tree, so may be we will se it hit 3.10.x -stable. Will performance improve at that point, probably a little if any. Firmware changes will have a bigger impact on performance, but as this is the one area that no one (outside of Broadcom) can see, we can't do anything about it.

Source code changes would be aimed at reducing the cruft and excess data that is copied from one point to another and make greater use of pointers - e.g. struct foo={a,bc,bar,0,0,7}; func_call(&foo); instead of func_call(a,b,c,bar,0,0,7); That said, the guy has done some stirling work in cleaning up much of the code.

There is (or was) an ncurses based interface which shouldn't be too difficult to plug in to rtstepperemc, but Eckler's clause on contributions puts me off. (Something along the lines of "all contributions will be copyright of ecklersoft"), can't find it on his website at the moment... That and GPLv2.0 only is getting too restrictive nowadays.

MrGreg
Posts: 66
Joined: Sun Jun 10, 2012 7:25 pm

Re: rtstepperemc CNC for RPI

Mon Jan 28, 2013 11:34 pm

Hmmm
but Eckler's clause on contributions puts me off. (Something along the lines of "all contributions will be copyright of ecklersoft"), can't find it on his website at the moment... That and GPLv2.0 only is getting too restrictive nowadays.
Can't say I have seen this, Guess we will have to see if Ecklersoft clarifies their position on the matter.

There is a good deal of interest in getting a CNC solution for the RPi. This thread on the linuxcnc forum is currently running at 31000 views.

http://www.linuxcnc.org/index.php/germa ... ?start=102

I am skeptical about the future of linuxcnc as such on the RPi, but it does indicate the level of interest and direction.

I am rather thinly spread as far as doing much more legwork specifically on the Ecklersoft dongle & current software, but believe as a concept, is prob the best way to go, (that is RPi + microcontroller)

For the time being, just have to wait and see what Ecklersoft and the code development community come up with?

Serac
Posts: 124
Joined: Wed Jul 18, 2012 2:49 pm

Re: rtstepperemc CNC for RPI

Tue Feb 05, 2013 1:44 pm

MrGreg wrote:I am skeptical about the future of linuxcnc as such on the RPi, but it does indicate the level of interest and direction.

I am rather thinly spread as far as doing much more legwork specifically on the Ecklersoft dongle & current software, but believe as a concept, is prob the best way to go, (that is RPi + microcontroller)
Like you, I am also skeptical about the future of linuxcnc, and not just on a Pi. The growth in the number of clones running on Arduino and PC/Macs certainly shows that there is an interest in a simple, easy to use package. Having spent some time working with Xenomai+3.2.27, it is more than capable of running a real time application such as a CNC control. Generating the stepper motor pulses via GPIO is possible but maximum speed will always be mediocre at best. The obvious solution is to offload the task on to a microcontroller or fpga.

Anyone seen this Xenomai-3.5.7 patch floating around that is purportedly working on a Pi ?

Had a quick go at compiling rtstepperemc - Epic fail due to it not picking up the correct path for tcl.h
Missing the Makefile.am and have zero desire to poke around a Makefile.in.

MrGreg
Posts: 66
Joined: Sun Jun 10, 2012 7:25 pm

Re: rtstepperemc CNC for RPI

Tue Feb 05, 2013 10:39 pm

It "should" compile and run as far as it can (Won't run gcode without a dongle)
using the ./configure script I posted up earlier and the dependencies installed, again for completeness

libncurses5-dev

tcl8.5-dev

libusb-dev

The tcl.h issue is resolved by tcl8.5-dev and the include tcl8.5 in the ./config script.

I have modified versions Makefile & tclext.cc which will do the same job, but more faffing about if anyone interested

Re xenomai I am only aware of this... earlier version

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?NewRTInstall

I would also be interested in info on later versions if anyone has tried them

Return to “Automation, sensing and robotics”