Friday, September 19, 2008
(Quick) status update
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.
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.
Friday, February 23, 2007
3D view
Thursday, February 15, 2007
Current TODO list
- 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.
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.
Sunday, February 04, 2007
erDoc
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.
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.
Saturday, January 20, 2007
Docs.
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.
Monday, December 25, 2006
Pf tracing results
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.
Thursday, December 14, 2006
...and the second binary release
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.
