gcode development

(Quick) status update

2008-09-19T17:13:00.000-07:00

There has been no updates for quite a while now, so let's take a look at what's happening.

In the core functionality of MyNC, not much has changed. It's still a limited version of 5-axis wire EDM. I'm looking forward to implementing support for milling, but that's not at the top of my TODO list, since I've got no real-world application for it in the near future, and, most importantly, no one else interested in it has showed up so far.

Right now, I'm working on a parser for C++ to become able to write static source code checks. I was surprised to find that there's no decent general-purpose parser out there, so maybe this project has some moment. Writing one is no easy task, it's going to take quite a while. To me, it's like a vacation from MyNC development.

Just before that, I've upgraded MyNC communication middleware layer (myrelay) to support automatic code generation from IDL. The compiler is called 'relic'. It's different from other IDL compilers in that with myrelay+relic one can have a completely custom wire protocol while still having quite a lot of code generated automatically. And the simplicity, of course. MyConf update is on its way.

I had to switch several workstations lately, and at some point I've become tired of random problems with setting up development environment for MyNC and stuff. So I've invested some time in preparing a portable development framework. One can simply download it, unpack it, and then get right to work. It's called "Sovereign", the project's page is at http://sgn.sourceforge.net . The description is all there. In short, it just works.

I have also spent some time playing with GNU Modula-2 compiler to see if the older CNC system could be ported to Linux. And the answer is that yes, it could be ported, but who cares.

What else... Ah, yes, I've completed my diploma thesis and graduated from the university. So if you have any problems with information security these days, you know the number.

Some words on linux-rti-pf (home-grown patch for hard real-time in Linux). Two major things happened.

The first one is that the patch has bit-rotted to the state where porting it to the latest kernel version means an almost complete rewrite. The only major update I did so far (transition from 2.6.5 to 2.6.19) was mostly about rewriting from scratch too, and it took me about two weeks of (hard) work. I expect the next update, if one happens, to require a similar amount of time. The good news is that there's now a bunch of helpful virtualization hooks in the kernel, the bad news is that it looks like any externally maintained patch is going to bit-rot real quick anyway.

The second one is that I've found that I had no sensible idea of memory barriers at the time I was actively hacking on the patch. This means that in its current form it's not adequate for SMP, and that's just what I experienced while testing it (which included using the -rti kernel for my everyday work). It basically hanged somewhat twice a month on my dual-core machine, and worked just fine with SMP disabled. But now there's no doubt that I have all the necessary expertise to write a correct patch for SMP (fingers crossed).

Well, that's it for now. It's not like I'm spending 100% of my spare time on MyNC these days. It's time to get a life after the graduation, you know :) Good luck, and stay tuned.

3D view

2007-02-23T17:44:00.000-08:00

Current TODO list

2007-02-15T16:07:00.000-08:00

Implement plane switching to support milling (in progress)

3D view (OpenGL, also in progress)

Move path discretization code into the kernel, support in-program fast feeds, pauses. I deferred this till "later times", and now this seems to be the right decision: the implementation I had in mind before looks flawed to me now.

Support EMC's rs274ngc interpreter (some initial adoption has been done already). This interpreter is a nice option, but in its current form it is not suitable for 4-axis wire EDM, so the current interpreter is not going away.

Hope to finish this before it gets warm and dry. Then, if all goes well, another real-world testing session will follow, during which probing support is to be added.

Future plans and thoughts include more compatibility with EMC: become compatible with HAL, and make -mync real-time kernels an option for RTAPI. I've investigated into it recently, and it looks perfectly possible.

erDoc

2007-02-04T17:58:00.000-08:00

Besides passing the final university exams and working on my diploma project, I've almost finished
writing the "erDoc" documentation extractor for MyNC. It is already usable, so I have began to write actual documentation, incrementally adding new features to erDoc as they become relevant. The major ones already implemented are: cross-referencing of types between different libraries, inheritance tracking, tracking of namespaces ('using' keyword honored too). I'm planning to spend some time documenting the code already written. It's better to do it now, before I forget all the details.

Docs.

2007-01-20T15:33:00.000-08:00

I'm working on source-code documentation extractor (codename "erdoc"). A bit of Perl, some XSLT, XML at your taste... The goal is to write some API docs to make mync libraries more useful.

Pf tracing results

2006-12-25T06:33:00.003-08:00

Pf.gaunlet is now able to make plots of "intervals" and "speed". "An interval" is the count of CPU cycles between two consequent interrupt events. "Speed" is determined as (1 / interval), it is plotted with blue color, while "intervals" are plotted with brown.

On the first screenshot you can see a plot that was made for all interrupt events in the system. The noise at the left is the result of my system being a samba file server, somebody was downloading a movie at the moment. A bit of idle time follows, and then another download had began according to smbstatus output. Bold crossing lines are the result of local APIC timer and i8253 PIT timer being set for almost the same frequency, with a slight difference due to different clock sources of these timers.

The second plot is for a real-time interrupt only. I was performing fast manual movements at that time. The plot shows linear speed increasing (constant acceleration). At the top speed (5Khz frequency in this case) some noise is noticeable, that's how "2.6.19-mync" kernel performs. The worst-case interrupt latency seems to be around 25 microseconds, which is a usual limit for PC hardware.

...and the second binary release

2006-12-14T15:37:00.000-08:00

The first livecd release contained a pair of unfortunate bugs causing rare system hangs on speed changes and terminal crashes. I've fixed those. And when booted from the livecd, the GUI feels noticably slower than under my Ubuntu installation. This has to be addressed as well.

First binary release

2006-12-12T18:56:00.000-08:00

Compiling and deploying MyNC system is not an obvious task, but it is not hard either. I think that a project like MyNC should be distributed in two forms: source code tarballs and LiveCD images, plus SVN repository for developers. LiveCD that I've prepared seems to work, I've tested it on several computers already and everything went fine except on my old system with Matrox G400 video adapter: X.org refuses to work with it. Problems with the kernel have been holding me for almost two weeks: instantly I've discovered that my last modifications were working only on systems with IO-APIC, so I've decided to upgrade to the newest kernel version and have reworked the patch. The result is now available through sf.net file release system. And this is the first time I disclose the patch, here it is: http://mync.sourceforge.net/kernel.html

Working on a LiveCD and a minimal distribution

2006-11-26T06:45:00.000-08:00

I'm currently building a custom distribution for running MyNC from CDs and for installing it onto small flash cards. The main purpose is demonstration. I've chosen Linux From Scratch (linuxfromscratch.org) to begin with. Compiling modular Xorg now...

Ready

2006-11-18T16:42:00.000-08:00

It's all in SVN. A few tasks should still be done but they are disintegrated and thus do not form one major challenge any more. I've found myself testing and fixing things, so the core system is here with us. Started to think what to place at the website.

gncedit

2006-09-03T13:16:00.000-07:00

NC editor is ready, it's back in a better shape. The editor is now a GPart and the text editing widget with undo/redo support is now actually a separate widget class. MyNC is now on the last turn before the announcement. The only packages left are myncbd-* ones, and they are already getting hot.

MyConf is back

2006-08-26T09:12:00.000-07:00

MyConf is MyNC's state management subsystem. It is similar to GConf of the GNOME project, but is more lightweight and is meant to meet the requirements of a soft-realtime system. MyConf includes a server which stores name/value pairs in a tree structure and keeps it synchronized with its XML representation on the disk. There is a well-defined grelay interface so that one can perform operations on the server remotely, and a C++ client library that allows to write MyConf clients in C++. The main feature is the subscription mechanism: clients can subscribe to certain options and receive notifications when those options change. I've just finished porting MyConf to GRelay. Here you can see a picture of MyConfUI.Control widget in action.

Had fun with AVL trees

2006-08-20T02:23:00.000-07:00

Balanced trees are required for several tasks in MyNC. I've just written a graphics tool to debug them in three incarnations: for the kernel, for grelay and for mycpp. Fresh MyCpp::AvlTree code seems to work. Here's a screenshot of what is available at https://svn.sourceforge.net/svnroot/mync/trunk/mync-gtree.

Oh, and yes, I've registered MyNC at sf.net and have already imported several modules into SVN. The rest is due soon.

Performance in action

2006-06-07T17:10:00.000-07:00

Yesterday I've written the first combat plugin for performance.gauntlet called PfLatencyPlugin. It finds the longest interval between local APIC timer's interrupts on CPU 0 and draws a horizontal green line covering that interval. The most natural test was to try to determine the cause of the worst latency case that I know to date which is latency introduced by nVidia's graphics driver. And an instant success followed! I've prepared a screen composition to illustrate the process. The cause of the delay is x86's wbinvd instruction.

There's a recent discussion on the topic here: http://www.nvnews.net/vbulletin/showthread.php?t=67430

I'm going to try to overcome this in a way similar to the one proposed by Bernhard: to prefill the cache with a necessary lot of data to make it synchronized with the main memory so that wbinvd would not take long to complete.

Equidistant task solved

2006-06-06T01:48:00.000-07:00

I've mentioned equidistant correction plans here. It was implemented last summer. The correction is done at the program description level in terms of lines and curves. Tunable corner cases and transitions, instant configurability over myconf, works fine. Here is a shot of it.

Performance tuning

2006-06-05T12:13:00.000-07:00

I've just put a bit of love into Performance. Here is the screenshot of performance.gauntlet. I take the trace with the following commands:

echo 1 > /proc/performance/enable
# Do something special
echo 0 > /proc/performance/enable
cp /proc/performance/trace ./
gauntlet trace

Copying from proc is required because gauntlet mmaps the file and procfs doesn't support mmap. I'm looking forward to some better way of accessing trace data that would allow direct mmap without copying.

Then gauntlet window appears where the trace is displayed in a timeline horizontally and can be moved and zoomed. A thick yellow marker line follows mouse pointer and in a text field at the bottom there is a list of events covered by the marker. It's quite convinient. The only thing left is to add some heuristics to determine bad high-latency places and to highlight them.

Long live GRelay

2006-06-04T15:03:00.000-07:00

Last winter I tried to prepare packages for the first public MyNC distribution. I soon realized that privately-patched OmniORB was a killing dependency: it builds enormously long, it is uncertain how to distribute IDL's properly, and I've failed to write Makfile.am that I would be satisfied with. CORBA took its evil hands too deep into my code and turned simple things into complicated beasts. So I've decided to throw CORBA away from MyNC and replace it with something home-grown. The new middleware is called GRelay, it's simple, features straightforward design, textual protocol (direct GRelay shell scripting? - yes) and lacks any kind of IDL and IDL compiler. MyNC porting to GRelay is not finished yet but I've already tested GRelay in a file-server called "filewar" written as a student hometask. It's a bit boring to write client and server stubs for GRelay objects manually but overall simplicity worths it and MyNC interfaces are quite compact anyway.

On the way to 1.0

2006-06-04T14:46:00.000-07:00

First, the project now has a stable name: "MyNC" which stants for "My Numerical Control" - quite simple, really.
Debugging a real-time patch for SMP Linux 2.6 is pain. It looks like I've just finally assembled something stable called linux-2.6.16.19-rti-pf. It doesn't show great timings yet, I know it can perform better, but this is the only stable version so far. In the version string "-rti" stands for "Real-Time Interrupts" and "-pf" stands for "PerFormance", a tracing toolkit somewhat similar to Linux Trace Toolkit. The main purpose of Performance is to catch real-time-consuming critical sections to get rid of interrupt latency. -rti-pf is not critically important though, MyNC can easily be ported to any real-time environment like RTAI (or even lower-level ADEOS) and L4/Linux. I even considered the possibility of running MyNC on MINIX 3, but lack of threading support in MINIX blocks the effort.

Real-work test

2005-08-14T12:25:00.000-07:00

I can proudly say that gcode has been tested on real hardware with real stepper motors and a pencil instead of a real wire EDM process. Steppers are running, the form and trajectory speed looks fine, no one micron escapes on fast moves.
Now I'm working on some modifications that include a re-worked real-time kernel patch that uses local APIC and its timer, so I suspect to reduce interrupt latency about 10 more times: it is 50 microseconds at the moment and I read a report about analogous work done by Bernhard Kuhn and he claimed 5 microseconds latency. That looks likely as in such case there are no system bus and PCI transactions.
I'm also going to rearchitect the lowest-level gcode module (a kernel module) to make it more flexible, so that other hardware configurations could be easily supported as well. Today this turns out to be a priority because it turns out that it is not so easy to successfully pop up with a wire EDM CNC software today :) I need a universal software machine controller to keep interest in the project, so I'm thinking hard on how it should be implemented.

Current state record

2005-06-09T15:57:00.000-07:00

gcode has reached certain degree of maturity

The following is the list of ready-to-work modules:

real-time 2.6.5-ds Linux kernel patch
ncb-kernel for the most low-level work
ncb-user as the Numeric Control Block high-level part
core library, contains program translation and path calculation logics
grlib graphics rendering library
gcode-conf configuration server and client interfaces
omniORB-4.0.3-ds patch and gcode.crio library, mainly for managing multiple robust CORBA connections
graphical control terminal

The most recent addition is unified system state support: all parts of gcode installation now have real-time information about current ncb-kernel state (which defines the state of the whole system).
Just before state handling work precise instrument marker rendering had been written. Elliptic forms are honored, and instrument's position is being displayed in a precise sub-pixel manner. My own sub-pixel ellipse drawing algorithm worths separate description :). This allows to debug future equidistant correction code.

TODO list includes extending terminal to control new ncb-kernel's manual movement capabilities, adding back-link support to ncb-kernel (should be quite straightforward as ncb-kernel was designed with this in mind), adding advanced path handling algorithms to the core library (e.g. equidistant paths).

This all is planned for my spare time, which my life currently consists of :) Education and spare time. I'm a happy man, really.

It's all about gcode

2005-01-01T11:19:00.002-08:00

'gcode' is a piece of software that I am currently working on. It is a PC-CNC system. CNC stands for Computer Numerical Control - a set of tools to drive manufacturing processes with a personal computer. gcode is based on Linux, it inlcudes a patched Linux kernel, a Numerical Control Block (NCB) software and a control terminal. I'll explain it later as an exersize in English, and in Russian some descriptive documentation is already available, but it is still a subject to publish.

Nobody but me worked on gcode for more than a year and this blog marks a step when I begin to prepare to share it. Of course, before "the great sharing" happens, gcode has to be taught to do something really useful and I want it to be documented a bit, so that you could at least understand how it works and what the main idea is. I'd also like to mention that although gcode is a real beast at the moment, things may change so that it'll fail. Really, I don't worry too much about it: I've learned a lot from its development and thats sufficient to me. But giving up on gcode is not not more likely than escaping from the university. And the last is very unlikely, so I belive that the 'gcode' game will go on (and on, and on).

Really, never mind if nobody reads this. Writing stuff helps to organise personal thoughts, anyway. And I'm going to post here in English (will try to do my best), so that more people could benefit from this blog.