Re: [Emc-developers] Non-X GUI Options
On 01/05/2014 06:06 PM, EBo wrote: No, for a real answer take a look at NanoX/Microwindows (I have not used it, only read about it). Well, maybe. About 3 years ago, with a lot more futzing around than I thought the project deserved, I managed to get Nano-X [1] working on a primitive ARM-based network appliance (the BestBuy Insignia InfoCast 8). A cutdown GNU/Linux with a decent framebuffer driver already existed for this nifty WiFi-equipped touchscreen device which was designed by the legendary Bunny and his fellow Chumby developers. My goal was to make it a LinuxCNC progress-tracker running wherever I happened to be in the house. I buried my project once decent Android tablets became affordable. I used the word working advisedly in the previous paragraph. By the time I gave up, I did have a basic display working but there were tons of loose ends and missing bits in the distro which were driving me crazy. The screen lit up, I could bring up a terminal window, the touchscreen worked. There were all sorts of strange behaviour which left me wondering if I could ever reach my goal. I had trouble finding people who could answer questions. Even had I progressed to a decent GUI (like the original MIT X GUI, for those who ever saw it), anything resembling OpenGL to provide some 3D capability was considered out of scope back when I was working with the code. A lot of water has gone under the bridge since then. Maybe Nano-X is more complete now. Then again, maybe not. There were just 22 messages to the Nano-X mail list in all of 2013. The last news posted to the website I knew (http://microwindows.org) is dated December 2010. I would love to be told I've just been looking in the wrong place and there's lots of new code/messages somewhere else. (Among other things, I've still got that InfoCast, after all!) I'm a dilettante programmer compared to some of you, so it's also possible I just didn't understand how to make the old code perform all its tricks. After reading the previous exchanges, I'm not sure I understand what is meant by GUI in the subject line. Without a list of requirements and desiderata it's hard to know what to propose. Regards, Kent [1] the official name became the Nano-X Window System as a result of a Microsoft challenge akin to the EMC challenge -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Can't compile joints_axes4
On 12/4/2013 3:03 PM, Marius Alksnys wrote: On 12/04/2013 09:27 PM, Sebastian Kuzminsky wrote: the output of the commands in part 2.4 of the document i linked you: cd debian ./configure -a (if installing simulator use ./configure sim instead) cd .. dpkg-checkbuilddeps That assumes you're starting from the root of the git checkout, not from the src/ directory. Yes, I did it right. ./configure -a successfully configured for 'Ubuntu-10.04'-'2.6.32-122-rtai'.. and the result of ./configure --enable-run-in-place is the same: checking for glBegin in -lGL... no configure: error: Required GL library missing. Install it, or specify --disable-python to skip the parts of LinuxCNC that depend on Python FYI, Marius. On my 64-bit Debian system, the symbol glBegin occurs in /usr/lib/x86_64-linux-gnu/libGL.so - /usr/lib/x86_64-linux-gnu/libGL.so.1 - /usr/lib/x86_64-linux-gnu/libGL.so.1.2 (where the first two are symbolic links and the third is the actual library file the chain of symbolic links resolves to and which is tested). This is just what the ./configure test is looking for. YMMV. For example, on my BeagleBoneBlack, the relevant links and file are /usr/lib/arm-linux-gnuebihf/libGL.so etc. Regards, Kent -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Can't compile joints_axes4
On 12/4/2013 3:27 PM, Marius Alksnys wrote: I tried it this way (from the root of the git checkout): git checkout master git pull cd src ./autogen.sh ./configure --enable-run-in-place Same results On 12/04/2013 09:57 PM, Kent A. Reed wrote: Can you configure and make on the master branch? The same test for glBegin in -lGL is performed. Good! The system is behaving the way it should. The ./configure command is telling you the plain and simple truth. It can't find libGL.so (or the actual library file this name resolves to). Kent, I found three similar instances inside/usr/lib/ : /usr/lib/libGL.so /usr/lib/mesa/libGL.so.1 /usr/lib/mesa/libGL.so.1.2 But I am not familiar with these things - what they mean and what to do with them.. Not to worry. If you use the -l option on your ls command you'll get something like lrwxrwxrwx 1 root root 10 Jun 5 11:05 libGL.so - libGL.so.1 lrwxrwxrwx 1 root root 12 Jun 5 11:05 libGL.so.1 - libGL.so.1.2 -rw-r--r-- 1 root root 391928 Jun 5 11:05 libGL.so.1.2 The first two entries are what Unix/Linux calls symbolic links. They are special file entries (note how small they are) whose sole purpose is to link their name to some other file. In this case the first file links to the second and the second links to the third. The third is the actual library file Think of the links as aliases. (For more, Google is your friend). To prove my contention that ./configure is telling you it can't find libGL.so, I renamed my symbolic link /usr/lib/x86_64-linux-gnu/libGL.so to ../xlibGL and tried to configure. Now ./configure complains exactly just as yours does. I changed it back to /usr/lib/x86_linux-gnu/libGL.so and ./configure works again. The same result occurs if I break the chain elsewhere, for example changing the name of the symbolic link ../libGL.so.1 or changing thename of the file ../libGL.so.1.2 So something has corrupted your actual libGL file, or a link in the chain to it, or ./configure isn't looking in the right place for them. I even tried to delete the git checkout folder completely, then followed the instructions http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Installing_LinuxCNC#Getting_the_source_with_git Paragraphs 2.2, 2.5 2.4 does not help either No, deleting and reloading the sources won't make any difference. The problem lies in the content your system directory /usr/lib. Regards, Kent PS - Seb's message just rolled in. He's trying to find out where the system is going to look for your libGL file. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Can't compile joints_axes4
On 12/4/2013 4:10 PM, Marius Alksnys wrote:
dpkg-architecture
DEB_BUILD_ARCH=i386
DEB_BUILD_ARCH_OS=linux
DEB_BUILD_ARCH_CPU=i386
DEB_BUILD_ARCH_BITS=32
DEB_BUILD_ARCH_ENDIAN=little
DEB_BUILD_GNU_CPU=i486
DEB_BUILD_GNU_SYSTEM=linux-gnu
DEB_BUILD_GNU_TYPE=i486-linux-gnu
DEB_HOST_ARCH=i386
DEB_HOST_ARCH_OS=linux
DEB_HOST_ARCH_CPU=i386
DEB_HOST_ARCH_BITS=32
DEB_HOST_ARCH_ENDIAN=little
DEB_HOST_GNU_CPU=i486
DEB_HOST_GNU_SYSTEM=linux-gnu
DEB_HOST_GNU_TYPE=i486-linux-gnu
So I would have expected[1] your libGL.* files to be installed in
/usr/lib/i486-linux-gnu/
but you said you found them in
/usr/lib/
Did you look for other copies ('find /usr/lib -name libGL.*')?
Does /usr/lib/i486-linux-gnu exist on your host?
An experienced Linux hacker would simply (as root) copy the libGL.*
files from /usr/lib to /usr/lib/i486-linux-gnu (creating the directory
if necessary) and see if the problem went away.
A really experienced Linux hacker would want to figure out how your
system got into this state before (potentially) causing further damage.
You say you used to build this branch. What changed?
Regards,
Kent
[1] if I'm wrong you'll hear about it soon enough:-)
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Self-Balancing Robot
On 11/30/2013 10:00 AM, Michael Haberler wrote: Am 30.11.2013 um 15:14 schrieb Charles Steinkuehler char...@steinkuehler.net: On 11/30/2013 7:28 AM, Michael Haberler wrote: Charles, Am 30.11.2013 um 13:12 schrieb Charles Steinkuehler char...@steinkuehler.net: I'm not sure the Balanduino will be available in time, yes, that's my concern too, I need something orderable with code and parts to go now, and without selling the farm to do so your above idea is worth thinking through. It's just that the machines you referred to are too 'CNCish' for what I have in mind; isnt there some 3d-printed self balancing robot..? Thingiverse has a couple: http://www.thingiverse.com/thing:83091 http://www.thingiverse.com/thing:25531 hm, the latter would suggest this board would work, meaning a HAL/I2C driver for its chips is needed: http://www.pololu.com/product/1268 I'll get a few of those -m The first one looks pretty modular, with most of the parts coming from Pololu (so likely purchasable w/o significant time delay). -- Charles Steinkuehler I'm still catching up after a brief hiatus. Like Charles, I would want to build a self-balancer too, both to share in the wringout of Michael's work-to-date in a realistic application and to have something for my grandkids to tinker with. I had thought about self-balancers before. Earlier, I had been looking at a (now ten-month old) posting http://www.freetronics.com/blogs/news/7235638-make-your-own-self-balancing-robot#.Up0iDtJKW6Q based on an MPU6050 IMU (https://www.sparkfun.com/products/11028) but then my life crashed and burned. I won't pretend I've pored over the data sheets for these two units. At a glance, it seems the MPU6050 offers some nice onboard signal processing, but I expect either IMU will work (and both talk I2C) since from all appearances an inverted pendulum self-balancer is just not that hard to implement. I seen mention of 10ms loop times. As an aside, sparkfun has a guide to relevant products they stock: https://www.sparkfun.com/pages/accel_gyro_guide Unfortunately, the only IMU I have on hand is integrated in the controller assembly for my quadracopter - too hard to break it out for experiments. Regards, Kent -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] New test...
Ebo: I replied to your reply (see below) and guess what, my reply didn't go through either. Again, my mail client (Thunderbird) is happy and my gmail account is happy, but I got back neither a receipt nor a bounce message. If this message goes through then it would seem I can start a thread but I can't reply to one. This is strange new behavior for a software chain (Thunderbird local mail client - gmail server - emc2 list server) which has served me well since I created this gmail account 18 months ago. No changes have been made (consciously by me anyway) since I set this up. Regards, Kent Body of message in previous attempt to reply: ---snip--- On 11/6/2013 11:42 AM, EBo wrote: One of the things that always bits me along these lines is that I have 5 different email addresses forwarded into one server. Due to the way emc-developers list is set up you have to make sure that the from address is one that it recognizes. Since my default is a different address, I often have things bounce. Could it be something like that? On Nov 6 2013 9:35 AM, Kent A. Reed wrote: Sorry for the noise, but I just noticed that two messages I sent regarding Gene's kvetch about Rockhopper never showed up on the list (as determined by looking at the Gmane archive) even though my mail client claims they were sent. Later messages to the thread by Andy and John have already shown up in the archive so it's not simply a matter of latency in the archiving process. Regards, Kent Thanks for the thought, EBo, I do sometimes forget which of three email accounts I'm using. In this case, however, something between gmail and the list server ate my first two messages but allowed the third through. All three were identical in terms of the account and toolchain involved and no bounce message was returned by gmail. I remembered after the fact that I still have my emc2-related list-server accounts set to confirm receipt of messages but didn't notice I didn't get receipts for the first two (a Sherlockian clue of the dog that didn't bark in the night). The third message (Subject: test...), to which you replied, got a nearly instantaneous receipt from the list server and was quickly archived to Gmane. Go figure. Regards, Kent ---snip--- -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] beaglebone status [was: UB integration and 2.6 status]
On 11/4/2013 10:30 AM, EBo wrote: What hard real-time ARM kernels have been found suitable for LinuxCNC? Sorry to hear about RT-PREEMPT ARM support... Hard real-time, like beauty, is in the mind of the beholder. Michael named the three real-time kernels the unified-build-candidate-3 branch builds and runs on in x86 systems. As for ARM, I have a Beaglebone Black set up to track and build the unified-build-candidate-3 on Charles' Xenomai-enabled kernel. It passes all 130 tests in runtests. I haven't tried to merge Charles' tree. Regards, Kent -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] UB integration and 2.6 status
On 10/31/2013 5:21 PM, Michael Haberler wrote: Am 31.10.2013 um 21:58 schrieb Kent Reed kentallanr...@gmail.com: Point of information: Issue #2---review and merge new RTOS branch Which branch on the repository is the new RTOS branch? the reference tree and bug tracker is at https://github.com/mhaberler/linuxcnc/tree/unified-build-candidate-3 which I usually sync to git.linuxcnc.org OK, then regarding the Todo-2.6 list item 2. review merge new RTOS branch ... 2. verify that parallel builds work (some of the buildslaves should use 'make -j2' probably) I can say I've successfully built unified-build-candidate-3 on a number of real and virtual hosts provisioned with a number of distros and realtime kernels and with differing numbers of simultaneous make jobs. I can't vouch for all configurations (no Hardy or Lucid on any architecture, for example) and I haven't tried --enable-build-documentation because Jeff's revised docs/src tree hadn't been merged when I last built. Nevertheless, I don't think this item is much of an issue. Still, trust but verify. I'll try to post a table of configurations I've already tested so others can fill in the gaps. I routinely use -j2 on virtual hosts and real hosts. I haven't timed the builds to see if there is any real gain using multiple jobs on a single (virtual) cpu. I don't expect one. There certainly is a gain on real, multicore cpus---I have run -j4 or higher on my quad-core AMD system---but again I haven't timed the builds. Incidentally, don't try make -jspace2, say. A naked -j indicates unlimited number of simultaneous jobs and make is happy to spawn a ton of them. An easy mistake to make late at night. Don't ask me how I know. Regards, Kent -- Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] On building LinuxCNC docs on recent O/Ses
On 10/28/2013 8:40 AM, Jeff Epler wrote: On Sun, Oct 27, 2013 at 03:21:15PM -0500, Jeff Epler wrote: It looks like the :ascii-ids: clears up most of the stuff that the nbsp-killing didn't. There were a few more wrinkles, but now buildbot is chewing on the branch jepler-jessie-doc-build to see whether the changes I made harm doc building on the other architectures. If so, maybe we can put this to bed. I believe I have now fixed doc building for Debian Jessie (and probably Wheezy) in v2.5_branch and master branch. Jeff OK. In the master branch, all the docs now build here on 64-bit Debian Wheezy, Debian Jessie, and Ubuntu Raring. I didn't bother with v2.5_branch. Regards, Kent -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] On building LinuxCNC docs on recent O/Ses
Gentle persons:
Roughly two months ago, there was a brief spat of email traffic about
LinuxCNC documentation not building on stable Debian.
Since the horrific events in my life earlier this year I've lost my zeal
for editing LinuxCNC documentation. On the other hand, I have been
building LinuxCNC on Ubuntu Precise, Ubuntu Raring, Debian Wheezy (e.g.,
stable), and Debian Jessie (e.g., sid) and it keep bugging me that I
couldn't build the docs across the board. They build on Precise but not
on the other three. It's not a critical matter for me since I can always
build them in Lucid or Precise or download them from Linuxcnc.org, but,
like I said, it bugged me.
I spent some time this afternoon and have managed to move the ball
closer to the goal line. I can now build all the English-language pdfs
on all the above-named O/Ses. Building French-language pdfs still fails,
but the information here should help some enterprising person fix that
too, iterating through the different language versions as necessary.
The following is taken from a Debian/Wheezy system working on my pull
today from origin/master on git.linuxcnc.org.
The clue came from the tail-end of the make output:
pdflatex -interaction=batchmode Master_User.tex
pdflatex failed
Master_User.tex:10280: Package utf8x Error: MalformedUTF-8sequence.
Master_User.tex:10280: leading text: G10 L2 P1 X3.
Master_User.tex:10280: Package ucs Error: Unknown Unicode character
65533 = U+FFFD,
Master_User.tex:10280: leading text: G10 L2 P1 X3.
Master_User.tex:10280: Package utf8x Error: Character160appearedalone.
Master_User.tex:10280: leading text: G10 L2 P1 X3.
The last five lines repeat two more times; then there are six
occurrences of the following, similar error:
Master_User.tex:10280: Package utf8x Error: MalformedUTF-8sequence.
Master_User.tex:10280: leading text: G10 L2 P1 X3.5 Y17.
Master_User.tex:10280: Package utf8x Error: Character160appearedalone.
Master_User.tex:10280: leading text: G10 L2 P1 X3.5 Y17.
Finally, we get
A possible reason for transformation failure is invalid DocBook
(as reported by xmllint)
Error: pdflatex compilation failed
I stared at the error lines while the coffee was brewing and realized
they must be complaining about some examples of G-code usage.
I took a look at docs/src/gcode/gcode.txt and sure enough, there are two
G-code example lines which seem to correspond but which looked fine to
my eye (line numbers are not in the source file of course):
654 .G10 L2 Example Line
655 [source,{ngc}]
656
657 G10 L2 P1 X3.5 Y17.2
658
659
660 In the above example the origin of the first coordinate system
661 (the one selected by 'G54') is set to be X=3.5 and Y=17.2.
662 Because only X and Y are specified, the origin point is only moved
in X and Y;
663 the other coordinates are not changed.
664
665 .G10 L2 Example Line
666 [source,{ngc}]
667
668 G10 L2 P1 X0 Y0 Z0 (clear offsets for X,Y Z axes in coordinate
system 1)
669
Funny, though, I didn't get a hit on lines 657 and 668 in this file
grep'ping on 'G10 L2'. Aha! We know what that means. Sure enough, there
are multiple nonbreaking spaces in line 657 and in line 668. The
multiple occurrences account for the repetition in error messages,
although there isn't a one-to-one match with the
MalformedUTF8-sequence messages, presumably due to the way the parser
eats its input.
I edited the file to replace those nonbreaking spaces (vim command :as
reports they are ASCII decimal 160 or hex a0; in UTF-8 they would be
\xc2\xa0) with spaces (ASCII decimal 32 or hex 20) and rebuilt the docs.
Voilà. The make process now chews through all the English-language pdfs
but then breaks on the first French-language document,
Master_Getting_Started_fr.pdf, emitting similar errors. This is true on
Ubuntu Raring, Debian Wheezy, and Debian Jessie.
There are lots more nonbreaking spaces in the documentation source files
(even a few in gcode.txt) which do not cause heartburn for our
toolchain. That says to me it is the occurrence of the nonbreaking
spaces within the particular asciidoc construct used to create example
lines which creates the problem. This should be a sufficient clue for
the proverbial interested student to explore the config and style files
used to build the documentation. Why is it the newer versions of the
tools in the chain which break? Don't know. I've could make an educated
guess but then I'd feel obligated to diddle.
I'm not going to clean up the documentation source files but really, no
extended ASCII characters should exist in them, even if they slip
through. Use the necessary markup.
There may remain problems with other language character sets, of course,
but presumably those would be UTF-8 problems more amenable to solution
through the normal forums devoted to the documentation tools.
Regards,
Kent
PS - For the cognoscenti, here are relevant software versions in the
order Precise / Raring / Wheezy / Jessie
Re: [Emc-developers] PoseMath pass-by-value question
On 10/24/2013 1:23 PM, Robert Ellenberg wrote: Hi All, Many posemath functions (like pmCartCartDot, for example) pass compound data types like PmCartesion and PmPose by value. Is there a specific reason for this design choice? Robert: The posemath library predates LinuxCNC by a number of years. It was written at NIST to support the Realtime Control System (RCS) program and got grandfathered into EMC - EMC2 - LinuxCNC. I expect you've read http://www.isd.mel.nist.gov/projects/rcslib/posemathdoc/PoseMathCpp.htm (note it's link to Karl Murphy's Posemath Examples is broken. Try http://www.isd.mel.nist.gov/projects/rcslib/posemath_examples.html). So far as I know, Fred Proctor is still at NIST. He's the first person I'd ask for the history. When you're thinking of changing the functions, keep in mind that a lot of people out there have certain expectations concerning posemath since they've baked it into a number of projects, not only in LinuxCNC but elsewhere. Several years ago, someone on these lists complained that some of the functions in posemath are stubbed out. Because of a project I was thinking about at the time, I jumped in, confident I could flesh these out. I got cold feet for various reasons including dealing with corner cases, and of course, wondering if my code had to be thread-safe. Keep up the good work! Some of us are following your messages silently but enthusiastically. Regards, Kent -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] PoseMath pass-by-value question
On 10/24/2013 3:19 PM, Robert Ellenberg wrote: That's a good point about the out-of-tree users, though I wonder if it would be better for them to use a standalone libnml version. If there's a lot of pushback from other users, I can make the few call-by-reference changes I need under a different name. I'm too old to be able to say out-of-tree users with a straight face, but I think this is acceptable. The folks who are really divorced from LinuxCNC are probably getting posemath elsewhere anyway (like rcslib from the NIST site). Those doing robotics work who get posemath via their copies of LinuxCNC likely hang out on these lists. If big signposts in the codebase warn users the changes have been made and tell them where find the unaltered version (reference NIST or maybe just reference a particular commit in the git repo) then I think you've done due diligence what with the discussion you started here. To be clear, a total overhaul isn't strictly necessary for the trajectory lookahead stuff, but it would be nice to make everything consistent. I'm a sucker for consistency (and, yes, I know the full quotation)! If you're up to the task then I'd say do it. I, for one, prefer that to adding a few functions with different names and argument protocols. Regards, Kent -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Behavior under heavy CPU load - Revisited
On 8/11/2013 9:46 AM, Michael Haberler wrote: Am 11.08.2013 um 15:19 schrieb Charles Steinkuehler char...@steinkuehler.net: On 8/5/2013 11:29 AM, Charles Steinkuehler wrote: How does LinuxCNC behave under heavy CPU load? ... I am revisiting this issue after experimenting with some alternate user interfaces and a discussion with David Bagby. David indicated he would repeatedly run a familiar gcode program on his shapoko and it would sometimes just sound wrong. I have also tested a variety of interfaces and noticed that if I am running a program in the mini interface and I enable the backplot display, it causes the steppers to dramatically slow down and/or stutter, and change from their 'singing' tones to more of a 'grinding' type noise while the backplot is initially loading. ... ... the backplot hint sounds suspicious. Is there some OpenGL-related code, or feeding of rendering hardware in the kernel which might be less-than-brightly coded? maybe the bug can be observed in latency spikes with glxgears too? I think this an interesting case in itself even if it doesn't prove to be the reason for your bad prints. I didn't try the mini GUI when I was looking at the computational burden imposed on my BBB by LCNC but turning on the backplot in other GUIs certainly kicked up the numbers reported by 'top'. Do you see/hear the effect only while loading the backplot or does it continue as long as the backplot is running? How loaded is the CPU? Is there any swapping going on? What GUI is David running? Has he also observed the behavior you report? Sorry I'm not in a position just now to replicate your results. Regards, Kent -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] installing xenomai
On 7/30/2013 5:38 PM, Michael Haberler wrote: Am 30.07.2013 um 21:34 schrieb Tom Easterday tom-...@bgp.nu: I did the install and rebooted (no RealTek ethernet) but it comes up with a login prompt, no GUI. I put the output of dmesg here: http://pastebin.com/GzQHt4L5 Is there something here that tells me why it isn't launching the GUI? yes: [6.311211] gma500 :00:02.0: Enabling MSI failed! see http://www.xenomai.org/index.php/Configuring_x86_kernels#Message_Signaled_Interrupts_.28MSI_and_MSI-X.29 this obviously fails recognition of the graphics adapter -m See also such pages as https://wiki.ubuntu.com/HardwareSupportComponentsVideoCardsPoulsbo http://www.phoronix.com/scan.php?page=news_itempx=MTMyODA With luck going to a different RTOS will at least get you to a GUI but beware this Intel/PowerVR GM500 graphics is causing fits throughout the Linux world. Regards, Kent -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] devicejs.org | DeviceJS is Javascript for the physical world
On 7/21/2013 2:32 AM, Michael Haberler wrote: interesting idea : http://devicejs.org/ The phrase smoke and mirrors came to mind as I looked at this site, but the information on their WigWag Kickstarter site was actually encouraging. Having lived through successive generations of automation/integration efforts in a sensor-rich environment, I think these guys are on the right track. Only time will tell if it's a track to the future or to the tech scrapheap we oldies like to reminisce about. The most encouraging aspect of this work is its basis in ubiquitous JavaScript. reminisceSome fifteen years ago, while pitching a proposal to management, I prepared a PowerPoint figure of my vision of a building-information InfoBahn. If I were to change a few words it could easily be mistaken for a high-level view of what they are doing. My vision was fatally flawed by its dependence on emerging software technologies that have taken more than a decade to mature and morphed along the way./reminisce By comparison, JavaScript delivers most of what I needed out of the box. I wish them well (someday they may hire my nephew who lives in Austin!) and thanks for the pointer. Regards, Kent -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 'top' and realtime systems?
On 7/16/2013 4:56 AM, Michael Haberler wrote: Kent - some improvements for RT-PREEMPT: Am 14.07.2013 um 15:19 schrieb Kent A. Reed kentallanr...@gmail.com: Gentle persons: Do Xenomai and RT-preempt have the same effect as RTAI does on the usual Linux instrumentation? top for example is blind to the RTAI threads. I know Xenomai places useful data in /proc/xenomai/stat. Do top and ps ignore it? Are there customized versions of these commands which take it into account to give a complete picture of cpu utilization? I've done some minor changes in the rt-preempt rtapi helping thread tracking: Thanks, Michael. Regards, Kent -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] discuss: Why do we have MAN, MDI and AUTO modes.
On 7/15/2013 10:28 AM, John Kasunich wrote: On Mon, Jul 15, 2013, at 03:31 AM, Michael Haberler wrote: Am 15.07.2013 um 05:57 schrieb Chris Morley chrisinnana...@hotmail.com: What if we got rid of 'modes' and relied on interpreter signals to decide if controls work or not. eg. if the interpreter is 'idle' manual controls would be usable on the GUI and/or MDI commands will execute. That is possible, but I would suggest a different approach to mode switching - not at the interpreter level, but a motion primitive: I view MAN vs AUTO/MDI being in effect separate input channels to motion. You can feed either channel with manual motion commands, or interpreter generated - there's no conceptual difference. For the most part this discussion is over my head, but I do want to put my two cents in here. There definitely _is_ a difference between MAN and AUTO/MDI, beyone simply the source of the motion commands. The list of supported commands is also different. Not only over my head but given my lack of experience with commercial CNC machines I kept thinking I just didn't know what every CNC operator knew. John, I think you and I are on the same wavelength. Looking at resources like my copies of the earliest EMC User Handbook I could find (20 Jul 2003), Machinery's Handbook 26ed, and Peter Smid's CNC Programming Handbook, 3rd ed., it would appear that 1) MDI has been with us since the earliest times when CNC machines were fed by paper tape, G-Code was a set of primitives, and MDI was the way for an operator to enter one program instruction at a time to quote Smid, and 2) manual mode was the mode the machine was in when it was not in MDI or Auto and in which the operator could flip switches, turn handwheels, etc., e.g., do things that were outside program control. So what? That was then and this is now. Let's not waste any more time looking backwards. It's sufficient to understand how the existing LinuxCNC works and be able to describe it to users. Looking forward, let's do a sufficient set of Gedanken experiments to be sure we understand what we really want in the next generation LinuxCNC and make it so. Regards, Kent -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] 'top' and realtime systems?
Gentle persons: Do Xenomai and RT-preempt have the same effect as RTAI does on the usual Linux instrumentation? top for example is blind to the RTAI threads. I know Xenomai places useful data in /proc/xenomai/stat. Do top and ps ignore it? Are there customized versions of these commands which take it into account to give a complete picture of cpu utilization? I realize this question is better suited for a Xenomai or RT-preempt list but I'm a stranger there. My web search skills don't seem to be up to the task of finding useful answers this morning. We're driving hellbent for leather toward full-up adoption of these alternatives to RTAI and I think we should know what instrumentation we have available. Regards, Kent -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Licensing Questionaire
On 6/9/2013 10:13 AM, Kenneth Lerman wrote: 4 -- Do you come to it as a free and excellent body of code available for your own use or do you see it as part of what provides their livelihood? 5 -- Should it be protected by strong licensing from those who might attempt to use it without contributing back to the community? Or should it be sown upon the earth freely for anyone to use in any fashion they wish without the hassles of legal contracts? Ken: I read in Steve's message an attempt to demonstrate the diversity of views of developers and users of LinuxCNC by characterizing the opposite ends of several axes (that is 'axis' plural, not to be confused with a kind of weaponry). I really like your idea of posing a questionnaire but I think turning Steve's characterizations into mutually exclusive choices is unfortunate (like the current political climate in the USA, where the only people in the middle of the road are road kill). To use point 4 as an illustration, why can't LinuxCNC be both free and excellent code and also a part of what provides someones livelihood? I don't see the choice. Similarly, in point 5, I don't see the choice between strong licensing and free use, but maybe we're using the word strong in different ways. It seems to me the dilemma we face isn't one of strong vs. weak licensing but one of resolving our oleo mix of licensing on various components, ranging from explicit statements of public domain to claims of copyright with no licensing statement at all. As well, there is a vague notion of assignment to a central LinuxCNC body pretty much across the board. This last means nothing to most of us but I suspect it means everything to certain commercial users, especially those who seek ISO 9000-series certification. Speaking of private use versus commercial use of LinuxCNC, think of successful projects which have dealt with this by creating multiple entities. In the O/S arena, for example, Red Hat Enterprise Linux vs. Fedora vs. CentOS springs to mind. I'm not suggesting that we have to do something like this, only that we could if it became necessary, but not very easily if the licensing issue isn't resolved. Regards, Kent -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Rockhopper revisited
On 6/7/2013 4:09 AM, Gene Heskett wrote: On Friday 07 June 2013 02:10:00 Kent Reed did opine: On Thu, Jun 6, 2013 at 5:01 PM, Gene Heskett ghesk...@wdtv.com wrote: Greetings Guys; Someone mentioned that rockhopper can make .pdf s somehow, and those of coarse can be scaled. Since I now own an HL3170CDW color laser printer, what steps does it take to do this, blowing my lathe .hal file up into at least a 6 page output? _ You can use the ImageMagick suite (available through the Synaptic Package Manager) to create a bunch of image files of the right size out of the original SVG image: convert -crop 594x774 halgraph.svg halgraph-%d.png ... As a matter of curiousity, what is the width and height information in your halgraph.svg file? I suppose if it's big enough, convert could choke. Regards, Kent viewBox=0.00 0.00 3542.00 1505.00 So, convert -crop 594x774 halgraph.svg halgraph-%d.png Then; lpr -PHL3170CDW halgraph-*.png And I got 12 pages too. Hmmm. 3542pt x 1505pt is 49.2in x 20.9in. That's 12 letter-sized sheets. Check. ...But something scaled it down from 72dpi to about 130 so the usable image per page was only 4.65 wide, so I had a lot of lpr has to call some helper function to render the png. Off hand, I don't know what that function is. I chose instead to load and print the images from a graphics viewer so I could have more control over the process. As in so much of Linux, there's more than one way to do that. By the way, convert (really the entire ImageMagick suite) is the proverbial Swiss Army knife. It offers a bazillion options including -gravity with which one can choose from which edges it lays out the cropping tiles. By default, it lays out from the top left to the bottom right, but you can force it to lay out differently. It may sound paradoxical, but I find there's too much yet too little ImageMagick documentation available on-line. Since I no longer have my own sheet/roll-feed wide-format printer/plotter like I did at NIST, I plan to use the local FedEx Office (aka Kinko's) to plot anything really complicated the same way I use them to print huge manuals. I realize local has a different connotation for you but since FedEx now owns the whole enchilada I'm sure you could ship the print job to some shop electronically and have the result shipped back physically. See their website. Scissors and pastepot work grows old in a hurry. ... So, I have something that while a bit fragile, does show what I have carved up in that file. Complex for a machine with two axis's and a servo controlled spindle plus an electrical probe kit for home all use. But if I have any dead ends, they aren't shown because rockhopper ignores wires that aren't connected on both ends. That trash removal could be a disadvantage as that was one of the things I wanted to be able to check quickly. I confronted similar issues when I was visualizing HAL configurations with Graphviz, although I started with the static .hal file instead of the HAL data in working memory. In graphs, there is a fundamental difference between the nodes and the edges connecting them, with a focus on the nodes. I chose to represent signals as edges in Graphviz, so I had to create phantom Graphviz nodes to represent dead ends, else the offending signal disappeared from the graph. I haven't looked closely at the Rockhopper approach to see how they handle dead ends but the information is available to them in the HAL signal table. The situation should be easier for them to deal with than it was for me because they chose to represent signals as Graphviz nodes also (with a different presentation style, of course). A signal with a dead end would be presented as a signal-node box with only one connecting line. In any case, what you are talking about is what the process and piping industry calls free ends analysis which they perform to ensure the integrity of a complicated piping-system design. I'd think it would be much easier to write a script to find single-ended signals than to stare at a drawing of any scale hoping to notice the visual equivalent of the dog that didn't bark in the night (or should that be the sound of one hand clapping?). Glad ImageMagick was useful. As for the missus, our situation continues to degrade. Even with the stairlift I installed in February, it got to be too much getting to/from the upstairs bedroom. Over the last three weeks, I've turned our living room into a mini-nursing home. Hospital bed, Hoyer lift, ramp out the front door, visiting home health care professionals, the whole nine yards. Now I'm trying to find a dependable night-sitter service we can afford so I can get some sleep. Regards, Kent -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level
[Emc-developers] divorcing the HAL graph visualizer from the web server, was Re: Rockhopper revisited
On 6/7/2013 3:37 PM, Peter Jensen wrote: As mentioned, Rockhopper also has a HAL graph visualizer. It would be simple enough to divorce this from the web server, but right now I'll leave that as an exercise for the reader;-) Since Peter's Python coding style is so much better than mine, I'll push this thought forward so others can share the experience:-) 0) get Rockhopper and install supporting packages, notably graphviz and pygraphviz (see http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Rockhopper_Web_Server), but you've already done that, right? 1) have LinuxCNC running and loaded with a HAL configuration (this is necessary so all the .hal files have already been parsed and loaded into memory so Peter's code can access the data needed). 2) in a terminal window, make sure the environment variable PATH includes the path to your LinuxCNC binaries and the environment variable PYTHONPATH includes the path to your LinuxCNC python interface. For example, I have been building run-in-place installations from git pulls in a linuxcnc-dev directory in my home directory, kreed, so this step means PATH=/home/kreed/linuxcnc-dev/bin:other paths and PYTHONPATH=/home/kreed/linuxcnc-dev/lib/python:possibly other paths The easy way to set the environment variables is to source the script provided in the distribution (for run-in-place, that is) of the LinuxCNC you are running. This means invoking . path to LinuxCNC scripts subdirectory/rip-environment where the above is typed dot space and so on. In my case, this means invoking . /home/kreed/linuxcnc-dev/scripts/rip-environment 3) execute the command python path to Rockhopper directory/MakeHALGraph.py name of output svg file So, for example, since I placed the Rockhopper directory in my home directory python /home/kreed/Rockhopper/MakeHALGraph.py fancyschmanzy.svg generates a file fancyschmanzy.svg file in the current working directory from the HAL configuration in my running instance of LinuxCNC. 4) enjoy --- Obviously one doesn't need to use fully qualified file and directory names but I wanted to be error on the side of being pedantic rather than cryptic. Obviously, all this could be turned into a self contained, do-all script, placed on the desktop with a cool Penguin-related icon, etc. To make Peter's script read from .hal files independently of LinuxCNC would take some work. For my own hal2html, which could read from either .hal files or a running LinuxCNC, I write my own naive parser for reasons I explained, but one could be bold and hook into the existing parser in halcmd. To borrow a phrase from Peter, I'll leave that as an exercise for the reader. Finally, I have to say this focus on HAL graphs is detracting from the other very nice pages that Rockhopper presents to the user. The LinuxCNC Configuration Page, for example, is a joy when it comes to examining .ini files. Props. Regards, Kent -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] divorcing the HAL graph visualizer from the web server, was Re: Rockhopper revisited
On 6/7/2013 5:38 PM, Kent A. Reed wrote: Obviously one doesn't need to use fully qualified file and directory names but I wanted to be error on the side of being pedantic rather than cryptic. Obviously, all this could be turned into a self contained, do-all script, placed on the desktop with a cool Penguin-related icon, etc. Oops, I pressed send a tad too soon. Perhaps not so obviously, one can modify the MakeHALGraph.py script to generate the diagram in other formats besides SVG, typically including PostScript, XFIG, FrameMaker graphics, HPGL, PCL, PNG, GIF, DIA (interesting, this last one!). Regards, Kent -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Rockhopper revisited
On 6/7/2013 8:00 PM, Gene Heskett wrote: I have used it several times, and I love the concept. My main problem is that the .svg output, when viewed on a firefox screen has a non adjustable scale that is wy too small to be readable. Actually, SVG has no intrinsic scale. Scalable Vector Graphics means just that. It's your browser which is causing you problems (and Firefox is not alone in not understanding fully how to display and manipulate SVG. Life used to be better when we all had to use Adobe's plugin SVG viewer but Adobe killed that project years ago.). And, if I make the halgragh.svg, then convert it to multiple pages of letter sized paper, I need some sort of control over the scale of the output. The last one I made, 3 hours ago, of the hal file I'm working on for my lathe, was, when converted and clipped to 8.25 x 10.5 pages, totaled 20 pages. If I had some sort of a scale control, I could do that on 4 sheets and still be able to read it just fine. I am inclined to edit the svg file, and divide the viewport by about 3, which should shrink it down to 4 pages if I understand how this works, but there is considerable doubt as to my understanding.:( Well, that's the thing. SVG has no intrinsic scale so Graphviz helpfully adds meta information about what *it* thinks is the right size based on its internal settings. If you don't like the choice made by Graphviz you can fool the downstream tools several ways. First you can edit the width, height, and viewBox parameters in the SVG file as you suggest (be consistent, please). I think that's too much trouble and too error prone. Second you can simply lie to the ImageMagick convert program about the tiles you want it to create. Either way you are changing how much of the full sheet will end up on a single page (tile). Remember we are playing charades anyway. My first instructions skillfully segued past the fact that pixels are not the same as points but we did our computions as if they were. How the png image gets scaled during printing remains under your control. If, for example, I tell convert to -crop 1188x1548 (e.g., twice the width and height values given in my earlier message) it will dutifully place 2x2=4 times as much of the original sheet in each png file compared to before. If you still print the png file as 8.25in x 10.75in (e.g., now 144 pixels per inch), then you'll have reduced the scale of the output by a factor of 2 in each dimension, and the number of pages by a factor of 4 (approximately, depending on details at the edges of the diagram). The other thing is we need a switch to enable a thin, dim, page outline to aid in trimming more accurately, an outline that will show in the printouts to aid us in windy area's, about 1 pixel wide. Great idea. I think it might even be done with ImageMagick. Could be either full box outline (if you use scissors) or just printer's crosses at the corners (if you use a paper cutter). Give me a night to think about it. Graphviz and hence MakeHALGraph.py know nothing about this stuff. Thirdly, it needs a switch so it does draw the stuff thats there, but disconnected. That would be handy for both troubleshooting and garbage cleanup in the .hal code. Well, I happened to run the axis_mm configuration through MakeHALGraph.py this afternoon and the resulting diagram *does* show single-ended signals (Xacc, Yacc, and Zacc, for example, each of which has a source but no sink). In earlier messages, you talked about dead ends, which I think is covered by what I just described. Now you are saying stuff that's there but disconnected which I could take to mean something different Please clarify. Regards, Kent -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] contributing to LinuxCNC documentation
On 6/5/2013 6:50 AM, John Thornton wrote: Well the 3rd possibility and the preferred way (short of you getting commit rights) so you get proper credit/blame is for you to prepare a git patch and e-mail it to me. And that works too, at least in the short term. I think John Morris' musing deserve careful consideration (what's not to like about a drive-by commit?). Addressing them helps not just me but lots of others. Regards, Kent -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] exploring the LinuxCNC 'burden' on my BeagleBone Black
Gentle persons: My interest has been tweaked by several remarks made about performance on the BeagleBone Black. I've started a page (https://sites.google.com/site/manisbutareed/beaglebone-black-linuxcnc) and to kick it off posted some gross characterizations of the burden imposed by various LinuxCNC GUIs and use of SSH/X11 Forwarding. This has been a little something to keep me busy in the wee hours Regards, Kent PS - I'm not a fan of the comment mechanism so it is disabled on my site. Emails to me or the list will do. -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] exploring the LinuxCNC 'burden' on my BeagleBone Black
On 6/6/2013 3:24 PM, Sebastian Kuzminsky wrote: On 6/6/13 13:19 , Kent A. Reed wrote: My interest has been tweaked by several remarks made about performance on the BeagleBone Black. I've started a page (https://sites.google.com/site/manisbutareed/beaglebone-black-linuxcnc) and to kick it off posted some gross characterizations of the burden imposed by various LinuxCNC GUIs and use of SSH/X11 Forwarding. This has been a little something to keep me busy in the wee hours Regards, Kent PS - I'm not a fan of the comment mechanism so it is disabled on my site. Emails to me or the list will do. It's interesting that ssh for the X forwarding is a big chunk of your CPU utilization. Have you tried switching ssh form the default 3des cipher to blowfish? It's much faster. There's more to come in the details that I haven't posted yet. Despite blowfish and arcfour both being faster---it must be true, I read it on the Internet---they don't substantially aid here. The issue may be clouded by the ARM chip which I suspect isn't tweaked the way many x86 chips are, and the algorithms in the OpenSSH routines, which I suspect may have been tweaked for x86. There were differences to be sure, just no home runs. The ciphers I forced my SSH client to select using the -c option were -c (default) aes128-ctr -c arcfour256 -c arcfour128 -c arcfour -c blowfish-cbc I also ran throughput tests between the hosts, using 'dd' to generate very large files of zeros in memory (to avoid benchmarking the file system) on the BBB and piping them through ssh to one of the x86 hosts. Haven't had time to post the numbers. I did not see any significant advantage to using compression (-C option), either. That's a technique often used in WAN communcations, whereas my hosts are communicating over a single LAN segment. Regards, Kent -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] exploring the LinuxCNC 'burden' on my BeagleBone Black
On 6/6/2013 5:15 PM, Michael Haberler wrote: very interesting writeup! very much in line with my observations I have so far run with a remote X display directly (i.e. without ssh tunneling) by setting DISPLAY on the bb and enabling connect on the X server, so no sshd overhead but more involved startup Because X11 Forwarding works so reliably, is so easy to set up, and is so the right thing to do for people who worry* about network security, I just use it automatically. This is my first situation where its performance became an issue. For those who want to run in what I called naked X11 mode, there's a bit of magic needed if you are running your XServer on Ubuntu. Not only do you need to allow it to accept X connections, typically by invoking 'xhost XClient hostname/IP' or 'xhost +' if you are lazy, but you also have to set it to allow connection via TCP. Ubuntu (well, actually Gnome) makes this unaccountably hard in its attempt to do everything for you. The traditional setting in /etc/X11/xinit/xserverrc is overruled by a setting in gdm.schemas. You can prove this by changing xserverrc to allow TCP (eg., delete '-nolisten tcp' from the invocation) and restart gdm. Run 'ps ax' and note that X started with the 'nolisten tcp' option despite you just told it not to. In Ubuntu 10.04LTS, at least, this tweak works: In /etc/gdm/gdm.schemas, change 'true' to 'false' in the following stanza schema keysecurity/DisallowTCP/key signatureb/signature defaultfalse/default --- here I've already changed 'true' to 'false' /schema Save and restart gdm using, for example, 'sudo service gdm restart'. also interesting to note - the core parts (milltask and the interpreter embedded therein, plus rtapi_app and usercomps) use negligable CPU compared to GUIs For all my runs with the AXIS GUI, milltask was number two on the hit parade, consuming roughly 28 percent of CPU time and 3.1 percent of memory. With the other GUIs it was always less than 5 percent of CPU, more typically 2-3 percent, as were hal_manualtoolc and halui across the board. I looked at every task down to 'top' which always consumed about 1 percent of CPU and 0.3 percent of memory. I was tired and only took the time in this first cut to report on the two that most concerned me. Details later, maybe. Regards, Kent * you can't work with computers at NIST for three decades and not be such. We wore belts and suspenders, so to speak. Public perception was a huge issue. By act of Congress, NIST plays a major role in computer security research, testing, and standards in the US, culminating in the Federal Information Processing Standards (FIPS). It just would not do for any of us to be caught with our own pants down...and don't think the Internet blackhats don't try. Our firewalls were/are under constant assault and we were constantly lecturing our staff about social engineering practices. Sometimes dumb luck carries the day. We were one of the few major sites to sidestep the infamous Morris worm back in 1988 but only because our principal mail server was running on VAX/VMS and not Unix. Sometimes not everyone gets the memo. Sometime in the 90s, we got hit right between the eyes by a vulnerability in Sun Solaris because we had Suns running on an experimental ATM (asynchronous transfer mode, not a cash machine) network connecting us by optical fiber to several universities. The ATM network bypassed the firewall. The Suns involved were all supposed to be in a DMZ, but dualhoming with the regular network was not unheard of. Naturally, security audits got more draconian. Designing, building, and maintaining an electronic condom is tough business. -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] contributing to LinuxCNC documentation
Ok, so Michael has thrown down the gauntlet: Now please stop the damn 'thank you' thing, and contribute something. Circumstances prevent me from contributing much in the way of code but y'all know I have a passion for decent documentation. I have made a number of contributions to the Wiki and to the distributed LinuxCNC documentation. The process I used last year to contribute to the docs was horribly inefficient. I would first find problems, then document them as to source file, line, and the change to be made. Then I'd fire off emails to John Thornton who would fire up his trusty editor and, file by file, line by line, first locate what I was talking about, and then make the corrections he agreed with (which he mostly did; thanks, John). Frankly, I'd rather just edit the document source files and be done with it. It's something I can do at odd moments during the day as I see problems in the pdf/html results. I see two possibilities for doing this in an organized way: 1) create my own public git repository, edit and post files to it after pulling from the central repository, and announce their availability to y'all. It would then be up to 'someone' to pull them and merge them in the central repository. or 2) get push privilege to the central repository. It would be super if git allowed for restriction of push privilege to the ./docs subset, since that's all I need/want, but I'm not aware that it does. And the answer is...? Regards, Kent -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Tests
On 5/31/2013 5:49 AM, andy pugh wrote: On 31 May 2013 01:52, andy pugh bodge...@gmail.com wrote: So I disabled it. Is there any way to see what the problem was? Now that it isn't 2am: Can anyone else with a recent pull of master re-enable that test and see if it passes for them? I am a bit stumped on how to fix this properly when it always passes for me on my system, and I can't see what the issue is on the buildbot system. Andy: I just pulled and built master on Ubuntu 10.04LTS. tests/mux failed with the usual test run exited with 1. Maybe I'll get a little time later to see what's happening internally. Regards, Kent -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Tests
On 5/31/2013 9:29 AM, andy pugh wrote: On 31 May 2013 13:38, Kent A. Reed kentallanr...@gmail.com wrote: tests/mux failed with the usual test run exited with 1. Maybe I'll get a little time later to see what's happening internally. if you look in the tests/mux directory there should be a file left in there called result which ought to match the similar file called expected My bad. I have just had my own 2AM experience. Last night I started LinuxCNC on this machine from a remote host and by this morning I'd forgotten it was still running. The exited with 1 message was a cryptic way of telling me this. I just ran the mux test again and it still fails, this time with the message you anticipated, namely result differs from expected. I'll email you the result and stderr files privately. Regards, Kent -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Tests
On 5/31/2013 11:29 AM, Sebastian Kuzminsky wrote: On 5/31/13 09:02 , andy pugh wrote: On 31 May 2013 15:54, Sebastian Kuzminsky s...@highlab.com wrote: If you follow the link you'll see a list of the steps the builder did, Actually, what I see in my lunch break is: Based on your corporate access policies, this web site ( http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1041 ) has been blocked because it has been determined by Web Reputation Filters to be a security threat to your computer or the corporate network. This web site has been associated with malware/spyware. Threat Type: othermalware Threat Reason: Domain reported and verified as serving malware. IP addresses are not typically used as legitimate web hosts. If you have questions, please contact your corporate network administrator and provide the codes shown below. Curses! My plot to infiltrate the linuxcnc community in order to serve othermalware to the developers has been foiled by your ever vigilant corporate network administrator! FYI: the DNS record sez buildbot.linuxcnc.org - emc2-buildbot.highlab.com - highlab.com - 174.29.73.105 and this IP address is on at least two blacklists according to the online source I just checked. Whether it is a condemnation of this specific address or of all addresses within some block of addresses isn't stated. Andy, I wonder if your Corporate condom prevents you from using tricks like a secure proxy or an anonymizer site to access the buildbot, not that you should have to work so hard just to look at the results. Regards, Kent -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] releases branching
On 5/24/2013 12:46 PM, Sebastian Kuzminsky wrote: I've certainly been assuming that we'll stay with Ubuntu, and that we'll target basically what we're currently building on the buildbot: Hardy sim rtai, Lucid sim rtai, Precise sim, plus any new rtos options we merge. Since Lucid Desktop, Hardy Desktop, and Hardy Server have all reached end-of-life, I think the users deserve some discussion on the implications of basing their CNC systems on these releases. Even with the EOL issue, I think they should be given at least a high-level overview of the implications of using older vs newer kernels and distributions. As much as I would like to volunteer to write the first draft I'm currently my wife's 24/7 care provider and I just don't see it happening. ... There are a bunch of minor janitor-level tasks I hope to get into 2.6: ... * automatic asciidoc math rendering Along those lines, I was thinking a while ago about how to streamline the documentation process by using a workflow in which the PDF files are generated and then HTML files are generated from the PDF files instead of the bifurcated workflow we have now (ref. my page http://wiki.linuxcnc.org/cgi-bin/wiki.pl?BeyondWikiToo, which I admit may be out of date by now). I'm working from memory here but some of the disadvantages I saw to the current approach are: 1. maintenance of the two uses of asciidoc including disparate stylesheets and processing options. 2. subtle but obvious visual differences between the results in the two formats. 3. the difficulty of presenting mathematics in both formats from the common AsciiDoc source (which may become a moot point with your work). 4. there is a natual one-to-one correspondence between a logical document and its resulting PDF file but an unnatural one-to-many correspondence between it and its resulting XHTML files and supporting files (stylesheets, javascript, image files,etc.). It seems to me HTML5 plus emergence of the open-source pdf2htmlEX package make it possible to consider an alternative workflow. In this workflow, a LinuxCNC document would be rendered in PDF format as before and then the resulting PDF file would be postprocessed by pdf2htmlEX to render the same document in HTML5 format. Some advantages to this alternative workflow are 1. a one-to-one correspondence between a logical document and its HTML5 file just as with PDF 2. tighter visual correspondence between the two renderings with less effort 3. no separate processing of mathematical content (again, perhaps a moot point if you succeed, but still without requiring the separate image files in HTML5). Of course, every silver cloud may contain a dark lining. Some potential disadvantages of the alternative workflow are 1. HTML5-capable browsers are required to view the HTML format. Fortunately, browser developers are being driven by big market forces to broaden their implementations of HTML5 rendering. 2. It's always possible AsciiDoc + some stylesheets may may generate PDF constructs which pdf2htmlEX (or whatever is chosen) can't process. I haven't noticed a problem in trial processing of the major LinuxCNC PDF documents but that doesn't mean none will arise. 3. It introduces yet one more dependency on the work of others. So far, the pdf2htmlEX effort seems quite strong but that doesn't mean it can't die in various ways. 4. the resulting HTML5 files can be big, bigger certainly than their corresponding PDF files, but I consider a single big file a huge advantage over the many small files we have now. 5. There may be some issues with typeface collections (I haven't gotten there yet) To put some meat on the bones of this proposal, I naively (e.g., with no options or tricks) postprocessed the five LinuxCNC 2.5 PDF documents available on the Wiki. At a glance, they looked good for a first effort. Then my wife's medical condition fell precipitously and I've had no time to do a detailed analysis and post my results. I'll try to get them up on my Google Site along with these thoughts and more RSN. This approach may come too late for V2.6 but I hope it or something like it becomes standard in the future. Regards, Kent -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] manpages was: Hitatchi WJ200 Inverter Driver (using comp)
On 5/20/2013 10:20 PM, Sebastian Kuzminsky wrote: On 05/20/2013 07:50 PM, Curtis Dutton wrote: Ok I have the driver pretty much completed and it has been working well for a week now. It can now take command line arguments to control the modbus serial connection parameters. Great! Now I'd like to add a manpage for the driver and any other documentation where appropriate. I need some guidance on what documentation to add and where to add it. A manpage is a good place to start. Be warned that manpages are written in the completely awful 1960-era troff language. I suggest finding a simple manpage (in docs/man in the source tree) and modifying it to describe your driver, instead of trying to write one from scratch. Andy already gave the straightforward answer for docs related to linuxCNC comps, but as a reminder to others, if one does have to generate manpages from scratch for some reason, then one should consider using the txt2man script (available via the Synaptic Package Manager in Ubuntu). It does a decent job without forcing one to learn the intricacies of the troff/groff/etc. markup language. As an aside, troff emerged in the 1970s; I was a neophyte researcher then and I remember colleagues at UChicago and Argonne National Lab struggling to install Unix from the Bell Labs tapes just so they could use the Unix/Editor/Troff pipeline to publish documents. completely awful is a relative term which I would be just as likely to apply to that paragon of WYSIWIG editing, Microsoft Word.:-) Regards, Kent -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] on the subject of governance
A modest suggestion: There are lots of governance models out there. Rather than try to invent one, choose an open source project (or more than one if you have several in mind) which best matches your vision for the size, scope, and impact of our LinuxCNC project and see how its governance model could be applied. Two useful resources: a web site on open source projects, which includes this page - http://www.oss-watch.ac.uk/resources/governanceModels a book about producing open source software - http://producingoss.com/en/index.html (I take note of the fact that the author believes his book is getting stale in the face of 8 years of progress and is seeking kickstarter funding to update it for a second edition) A concern: As a physicist I tend to think in terms of orders of magnitudes so let me throw out the following quantities (my engineering dad would call these SWAGs) Number of LinuxCNC developers: something on the order of 10**1 Number of LinuxCNC discussants (both lists plus forum): something on the order of 10**2 Number of LinuxCNC installations (the ballot on the website): something on the order of 10**3 I hypothesize that making LinuxCNC more attractive to a broader base---notably but not just the Maker Movement---could cause the number of active LinuxCNC developers to increase by a factor of 10 and each of the other two numbers to increase by at least a factor of 100. Do you believe our current governance and communication models will stand up to the pressure? Regards, Kent -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Wear Offsets (was lathe-style tool patch)
On 5/17/2013 10:20 AM, andy pugh wrote: On 17 May 2013 08:05, Chris Morley chrisinnana...@hotmail.com wrote: If I was doing a clean sheet Gcode dialect I think I would choose multiple geometry and wear offsets per tool, but that gets to be a lot of entries in the tool table. 100 tools x 10 geo offsets + 100 tools x 10 wear offsets is 2000 entries. (arbitrary example) It is potentially a lot more than that, as each individual offset might be in 6 different axes. Some form of sparse data structure is probably needed. I'm thinking of a 'virtual' tool number that the program would call say tool 1 then the control would use one of a number of actual tools - all preset to cut identical. They wouldn't need to be preset, they could have individual offsets. The trick is to separate Tool-ID and T-number. You can also imagine having multiple carousels for different jobs, with some tools duplicated between carousels. max force - The maximum force use while cutting - one could set the control to change tools if max force is too high. Hmm, another thing to add to the list. (There probably needs to not be a list. Tool-table entries should be integrator-configurable.) This is starting to sound like the ISO STEP-NC project (http://en.wikipedia.org/wiki/STEP-NC) which produced ISO 10303-238, Application protocol: Application interpreted model for computerized numerical controllers and the concomitant ISO 13399 Cutting tool data representation and exchange (http://en.wikipedia.org/wiki/ISO_13399). Don't expect the ISO documentation to be easy to obtain or to read once obtained. I believe my old friends at Step Tools, Inc., have some useful material online (http://www.steptools.com/products/stepncmachine/). Lists and tables are not very satisfying data structures. Chris's first example reminds me of the problem that relational database normalization was intended to solve when it was introduced forty years ago. If a relational database approach isn't acceptable, how about an object-oriented database approach instead? Regards, Kent -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Wear Offsets (was lathe-style tool patch)
On 5/17/2013 12:51 PM, EBo wrote: On May 17 2013 10:47 AM, andy pugh wrote: On 17 May 2013 17:27, Kent A. Reed kentallanr...@gmail.com wrote: If a relational database approach isn't acceptable, how about an object-oriented database approach instead? Why wouldn't it be? Snooping around the source tree last night I found: http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=blob;f=src/emc/toolstore/sql/schema-simple.sql;h=21c04238eb6e7ae917a8049cc3555337fb0aeb1b;hb=HEAD to maybe state it a different way, is a relational database approach the best design model? Are there other design (like object oriented) from which we can leverage utility? Thanks, EBo, that's what I intended to say. I've been away from this kind of work long enough to have forgotten to be explicit about information modeling vs information-system implementation. Regards, Kent -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] STEP-NC (was Wear Offsets (was lathe-style tool patch))
On 5/17/2013 1:46 PM, EBo wrote: Glad I could give you a gafaugh (or how ever it is spell it). I meant g-code - STEP-NC. Since there is source for a demonstration parser using ISO 14649, that might be a fruitful path and what I had in mind when I made my comment. I just do not know enough about ISO 14649 to know if it is feasible. Aha. I don't know enough either, but let me quote from the STEP-NC DLL Programming Guide I found on the StepTools site (http://www.steptools.com/support/stepnc_docs/stepncdll/index.html). [That APT is invoked in a modern-era document might tweak Dave Engvall's interest as well.] ---begin quote--- 2.0 APT Object 2.1 Concept The APT object is used to create AP-238 files from APT data. APT is a legacy language from the 1950’s that defines tool path geometries. In the beginning it was used in a similar way to FORTRAN except it created machine tool programs rather than computer programs. In recent years CAM systems have replaced APT systems but many CAM systems still write APT data so it is the most widely available common denominator for tool path information. APT is the most important but not the only source of data for the DLL. There are functions to read several flavors of RS274D/ISO 6983 files, for example, see the ImportHass, ImportSiemens and ImportFanuc functions, and there are functions to read STEP files to define the geometries and tolerances of the workpiece, stock, fixtures and cutting tools, for example see the Workpiece and Rawpiece functions. The legacy APT programming language is state driven. Each time a new tool path is created the current feed, speed and other quantities are added to that tool path as necessary. The APT object has been written for APT parsers so it is also state driven. Hence, at any time there is a current workpiece, workplan, workingstep, feed, speed and so on (see the GetCurrent functions). STEP-NC is NOT state driven. The APT object takes the state driven commands of APT and converts them into a graph of STEP-NC objects where every quality of every object is explicitly attached to that object. Only the APT object has a state model in the STEP-NC DLL. The other objects use navigation models in which a given argument is used as the starting point to find other objects. It can be argued that another version of the APT object should be written for more modern applications that is not state driven. The process object contains some of the required functionality. ---end quote--- This doesn't indicate how much work is required to salt the DLL so an imported RS274D (aka G-Gode) file becomes a valid and useful STEP-NC file but the second paragraph of the quote seems to indicate the transformation you have in mind can be done. Perhaps more is said elsewhere in the guide. And I learned to spell it guffaw but the Oxford English Dictionary shows a variety of spellings stretching back to 1720 so no points deducted:-) Regards, Kent -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Wear Offsets (was lathe-style tool patch)
On 5/17/2013 2:05 PM, Michael Haberler wrote: that said, what I am convinced is needed is proper design work on a relational_model_ for the tool miniworld (tools, offsets, spindles, magazines, wear, holders and whatever came up over the years) ... As for an OODB approach - I never understood what that is so I cant comment, but it surely doesnt get us around the legwork designing a bulletproof data model My bad for saying RDB and OODB as a shorthand for the conceptual models and methodologies that back the design of RDBs and OODBs. I could not agree more strongly with the need for proper design. Speaking in database-ese, the availability of two different data models (relational vs O-O) means one might choose slightly different approaches to that design even at the conceptual schema level but certainly will choose differently at the logical schema level (ANSI/SPARC defined the three-schema approach back in 1975). This does not remove the need to state clearly the purpose of the database and to gather and massage end-user requirements. I think we are assuming we've agreed the purpose of the database and I'm sure that many of Chris Morley's emails contain end-user requirements which need to be captured. Regards, Kent -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] lathe style toolchange patch
On 5/16/2013 1:08 AM, Chris Morley wrote: At this point I really start to wonder how often G10 L10 P10001 is used in current lathe Gcode and start to consider other alternatives such as P01 for geometry, P0101 for wear etc. - It really makes it easier if the geometry offsets are under the plain tool number In a followup, Andy Pugh wrote: I think discussing this in the context of existing G-code is clearer than discussing it in the context of any future compatibility-switches. I don't know squat about the commands and parameters which are being discussed---I'm trying to learn them from this discussion---but from my experience in technical committees, I have to reiterate Andy's desire to focus. Too often, I saw folks jump on a horse and ride off in all directions as my Grandmother used to say. Out of ignorance, I ask - what existing G-code? Are we talking about legacy G-code for specific parts or MOPs (machine operations) on hand in a machine shop that has now added a LinuxCNC machine to the mix? G-code as it would be emitted from specific postprocessors on specific CAM systems? What's the scope of the problem? The notion of compatibility-switches is intriguing; I missed it if it has already been discussed. The primary use case as I see it is of a LinuxCNC shop taking on a job where G-code files have been delivered from elsewhere and in name your favorite vendor-specific format. Am I correct that the choices would be either to remap the code or to use a compatibility-switch to affect the behavior of the LinuxCNC interpreter? As an aside, I assume most G-code files are not well documented internally as to source of the code and intended target of the code. Are there any 'file'-like programs out there that parse a G-code file and make guesses as to its flavor? Inquiring minds want to know. Regards, Kent -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC week at MPM/SFI
On 5/16/2013 7:15 AM, andy pugh wrote: It seems a little more readily walkable to/from MPM than does the Candlewood. (Though I understand that being a pedestrian is illegal in the US:-) It might seem like that but some of us stubbornly walk as much as we can. I purposely chose a townhouse close enough to NIST that I could walk to/from work most days. It was good for getting the braincells working in the morning and for getting work-related stress out of my system before I reached home. Now that I'm retired and not getting in much walking because of the daily challenge of my wife's declining health, my weight seems to be rising linearly with time. Sigh. Growing old is not for sissies. Just be prepared for stupid drivers. As a broad characterization, most drivers don't pay attention to zebra crossings Regards, Kent -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] lathe style toolchange patch
On 5/16/2013 9:00 AM, andy pugh wrote: On 16 May 2013 13:37, Kent A. Reed kentallanr...@gmail.com wrote: Out of ignorance, I ask - what existing G-code? Are we talking about I meant G-code as understood by LinuxCNC today. ie, where a tool change is M6 T3 G43 H4 not T0304. Ah, yes. I went a bridge too far, as usual. Regards, Kent -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Some initial BBB GPIO code
On 5/8/2013 10:34 AM, Ian McMahon wrote: I started with Michaels's BBW work here: http://static.mah.priv.at/public/beaglebone/ The BBW 3.2 kernel won't work on the BBB, so I had to build a kernel. Here's a working 3.8.10 kernel for BBB: kernel-3.8.10-vanilla.tgz It's a vanilla kernel; there's no xenomai for 3.8 yet, so you're not going to get proper realtime yet. Procedure: ... Great instructions, Ian. Coincidentally, Michael and I had recently discussed the kernel problem. Based on his conjecture that a system just as you describe would be useful, I modified and tested an installed StarterKit to include both Michael's 3.2.21-xenomai+ kernel and the 3.8.10-bone15 kernel that I had built from Robert Nelson's BBB page at http://eewiki.net/display/linuxonarm/BeagleBone+Black, which I expect is nominally the same as your vanilla 3.8.10 kernel. I then wrote a U-Boot 'script' which detects whether it is executing on a BBW or a BBB and boots accordingly. Result, from the same uSD card, one can boot into a realtime LinuxCNC system on a BBW or a non-realtime LinuxCNC system on a BBB. I expect Michael will modify his StarterKit accordingly. Michael suggested I try to add a kernel-selection menu to my script, which I'm doing now. As currently envisioned, it would require BBB users to obtain a 3.3v TTL-to-USB cable to be able to use the menu but for now that seems a moot problem since at the moment the BBB user can boot only the 3.8 kernel. On the other hand, it would allow a BBW user to boot into either kernel. I did some more poking at the BBB/3.2.21-xenomai+ booting problem and Michael found some info about problems with the 3.2 Xenomai patches. Discretion being the better part of valor, it would seem we should wait for the 3.8 Xenomai patches before we go realtime on the BBB. As for building the LinuxCNC simulator, I didn't attempt it on the BBB. Apart from the time it takes, does the build succeed using a 4GB uSD card? IIRC, there's less than 400MB left in the rootfs partition after installing the StarterKit. To others just tuning in, my only intellectual contribution here is the new script. Regards, Kent -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Woo hoo, possible alternative to U-Boot for the ARM boards
Gentle persons: Don't know why I missed it before, but I just stumbled across the barebox project (www.barebox.org). It claims to combine the best of U-Boot with the Tao of Linux. barebox is a bootloader that initializes hardware and boots Linux and perhaps other operating systems or bare metal code on a variety of processors. It was initially derived from U-Boot and preserves many of its features, so users familiar with U-Boot should become productive with barebox relatively quickly. However, as the barebox developers are highly addicted to the Linux kernel, its coding style and code quality, we try to stick as closely as possible to the methodologies and techniques developed in Linux. In addition, we have a strong background in POSIX, so you'll find several good old Unix traditions implemented in barebox as well. Of special interest to me is the statement [I]n contrast to U-Boot, barebox doesn't misuse the environment for scripting. If you start the bootloader, it gives you a shell and something that looks like a filesystem. It's exactly that misuse of the environment that makes U-Boot tricky to use. I hope to steal some minutes today to test whether the most recent release supports the BBW and BBB properly. If it works, it will give us a natural environment for constructing boot menus and who knows what else. In practice, powering up a BBW/BBB would proceed from the first-stage ROM code to second- and third-stage boot code contained in whatever barebox uses in place of the U-Boot MLO/u-boot.img and then to the barebox shell. Looking at their download directory, the barebox (always in lowercase) project has been pushing out releases pretty regularly since Christmas 2009 so there's some reason to be optimistic it will continue. Regards, Kent -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Proctor and Shackleford paper on jitter; was Re: LinuxCNC version for Debian Wheezy ?
On 5/7/2013 5:53 AM, andy pugh wrote: This models a linear dependency of delta-torque to delta-time, which seems like it should break down at some point. Absolutely, just as the small-angle analysis of a pendulum begins to break down as the angle increases beyond 30deg-45deg, say. Fred and Will were just trying to estimate the size of the effect. --- On 5/7/2013 12:50 AM, Michael Haberler wrote: Note this does_not_ address the (IMO more interesting) question how latency impacts 'path tracking quality' of a real and complete motion/pid etc servo setup; that would be worth a separate attempt, probably more based on control theory than measurements plus some verification I share your desire. Not knowing how the work would proceed, I thought a bit instead about how it would end. A full minute later I decided I also don't know how one would devise a quality metric which would be useful to prospective CNC system buyers/integrators. We constantly run into these problems in devising rating schemes for equipment. Consider vehicle fuel economy ratings. In the USA the EPA three-number scheme (city mileage/highway mileage/combined) is constantly attacked as hopelessly simplistic yet the next step up in sophistication seems to be hopelessly complicated to non-technical people. I participated peripherally in similar endless arguments during the 1980s concerning rating schemes for such mundane items as HVAC equipment, solar-energy collectors, and the like. I'm hoping that work proceeds along the lines that Michael has indicated and some wisdom emerges out of the thicket of results. Regards, Kent -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Proctor and Shackleford paper on jitter; was Re: LinuxCNC version for Debian Wheezy ?
On 5/7/2013 12:23 PM, Jon Elson wrote: I have a VAGUE recollection that Mariss Freimanis may have written about this in his whitepapers about stepper performance. It might be worth a quick search on his website at Geckodrives. He has certainly done a LOT of testing of steppers. Jon, that's the other work I had alluded to. I can't find anything but his stepper motor basics at the moment. It occurs to me I may be remembering a long-ish discourse by Mariss on one of the CNC-related forums some years ago. If I find a good reference I'll post it if you don't beat me to it. Regards, Kent -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?
On 5/6/2013 8:13 AM, Charles Steinkuehler wrote: Yes, but if you've got a Mesa card, you don't gain that much on an x86 platform. Unless you're really pushing your servo rate, rtai and xenomai are IMHO really only necessary on x86 if you're trying to do software stepgen. But make sure you test your board, latency numbers for rt_preempt can vary a*LOT* based on BIOS settings and your particular hardware (since for rt_preempt to work well, the driver code needs to be written to work well under SMP). and, just prior, Ebo wrote: There are people poking at RT-PREEMPT, and depending on your exact setup getting very good results. Like others have said, RTAI and Xenomai get better latencies and will probably always do so because of technical reasons of their implementation. That being said, if the rt-preempt latencies is good enough for your application I personally go for that -- rt-preempt is now part of the stock kernel and there is a variant which is now supposed to provide hard real-time. Anyway, them's my thoughts on the matter. and, just prior to that, Michael wrote: Yes, RTAI and Xenomai have significantly better latency behaviour than RT-PREEMPT. I think this is relevant mostly for software stepgen setups The question of what is good enough has intrigued me since I first started reading LinuxCNC nee EMC2 documentation. For many years we have had essentially only one quantitative criterion. IIRC correctly it shows up several places but this particular quote comes from the Latency-Test page on the Wiki: If the numbers are 100 uS or more (100,000 nanoseconds), then the PC is not a good candidate for software stepping. Numbers over 1 millisecond (1,000,000 nanoseconds) mean the PC is not a good candidate for LinuxCNC, regardless of whether you use software stepping or not. Is this still the best we can do for guidance to prospective users? I realize that details matter so it's difficult to get very specific about what is good enough for your application but I keep hoping we could say more. For that matter, we could say more about the impact of high jitter. Currently, we say only : ...your maximum step rate might be a bit disappointing If I thought I had the knowledge I would write more about the impact myself, but I don't and I haven't. MIchael and I briefly discussed the subject a year ago in the context of stepper drives and I realized after considerable Internet searching that little useful information is available (one limited calculation by Proctor et al and some postings by Mariss) so maybe it's just too hard a subject? As a practical matter, we haven't collected much latency/jitter data for the Xenomai and RT-PREEMPT kernels on different CPU-motherboard-BIOS combinations. It feels like it is time to start gathering such data in new tables on the Latency-test page on the Wiki. If I get time later today (and if the Wiki is more responsive than it was yesterday), I'll copy in my Xenomai results for several systems and Charles' RT-PREEMPT results for several other systems which have been posted elsewhere. Maybe the presence of new tables will embolden others to contribute their results. Regards, Kent PS - if new material on this subject already has been added to the LCNC documentation please point it out. My blind spots are widening with age. -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] LinuxCNC version for Debian Wheezy ?
On 5/6/2013 9:16 AM, Lars Segerlund wrote: check the data on osadl.org ... with RT-Preempt you should be able to get worstcase jitters of less than 50 us ... or you have a 'bad' system / bad drivers. With a 'good' RT-Preempt system you get 20 us as worstcase. osadl is good since they are really hammering the systems while measuring. / regards, Lars Segerlund. Lars: I'm not looking to open a discussion about the definition of jitter and the appropriate methodology for measuring it (we've had some of those in the past on this list, and some of us are quite familiar with OSADL). What I'm looking for is better guidance to our CNC users, most of whom find the details about latency as understandable as details about the fuel-injection algorithm used in their car's computer. What we have seen in the time I've been reading the emc2- lists amounts to constant schoolyard taunting, my latency is better than your latency. Look how excited we get when the latest Atom board yields 1us lower or higher jitter results than another. If the better guidance includes pointing to the OSADL as another source of data (along with suggestions on how to interpret those data) so much the better for the folks who wish to use RT-PREEMPT enabled kernels (and my thanks to those on this list who have been making it possible for the average user to even consider using them). Regards, Kent -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Proctor and Shackleford paper on jitter; was Re: LinuxCNC version for Debian Wheezy ?
On 5/6/2013 5:00 PM, EBo wrote: does anyone remember the paper that was posted to the group that measured the loss in torque as a function of speed and jitter? That might give us a more principled start to develop guidelines. As a note, when you get anywhere close to the jitter threshold the apparent acceleration/deceleration is greater than what the motor can handle. hope that helps. Ebo: You may be thinking of this 2001 SPIE paper: Frederick M. Proctor and William P. Shackleford, Real-time Operating System Timing Jitter and its Impact on Motor Control, Proceedings of the SPIE Sensors and Controls for Intelligent Manufacturing II, Vol. 4563, pp. 10-16, October 28, 2001. Nevermind the SPIE paywall. NIST provides a pdf copy at http://www.nist.gov/customcf/get_pdf.cfm?pub_id=824455 This is the work I alluded to in my earlier email. Regards, Kent -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] What's up with the Wiki?
It is taking the Wiki a v-e-r-y long time to return pages at the moment. Response time for the Forum seems a tad long; the website, almost normal. Regards, Kent -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] The arm excrement has I believe, intersected with the air mover
On 5/5/2013 10:04 AM, Gene Heskett wrote: Guys Gals; There was a post that made it to one of the lkml related lists I am on this morning that I would liken to calling Linus out for a duel. Calling specific attention to his knowledge of x86 stuff being a huge hindrance in the arm world, specifically his insistence that devices belong in a 'device tree'. I think some of the points it brings up might be helpful in terms of our being able to use these devices in a stable manner. So I will fwd that post to this list shortly. Cheers, Gene Gene: I think it a mistake to take a knife to a gun fight. This is a battle that is raging across Linux-land, not just in the debian-arm list. It is inaccurate to claim it is Linus's fault that we don't have a clean approach. There was lots of muttering among the leads in Linux-ARM development about how badly we were managing things pre-device tree, well before Linus's celebrated rant. It's unfortunate that people pick and choose the lists on which they post their opinions so as to look wise and prescient with little opposition, but we see the same behavior in politics as well. To quote an old line, we live in interesting times. Regards, Kent -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] introduction
On 5/2/2013 6:21 PM, Ian McMahon wrote: Hi folks, I've been talking with Michael Haberler on IRC about getting involved with hal development for BeagleBoard Black, and I wanted to quickly introduce myself. I've been working with linuxcnc as a user for about four years now; just completed my fourth machine, and I love the product. I'm a professional developer by trade, Sr. Technical Architect for Turner Broadcasting System in Atlanta, GA, working on CNN, sports properties such as NCAA March Madness Live, and much more. I'm a hobbyist machinist, as well as an experimental aviation enthusiast and pilot building an RV-7. My C skills will require a bit of dusting off, as I have mostly been working in Java and functional languages these last many years, but I hope to be able to come up to speed and be useful! Thanks, Ian McMahon Hi, Ian. Just dive in:-) Regards, Kent -- Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Musings re LCNC and Beaglebone White vs. Black
On 4/28/2013 8:26 AM, Charles Steinkuehler wrote: On 4/27/2013 7:23 PM, David Bagby wrote: snip I think you're trying to make things too complicated. I'm 99% sure the existing BBW SD image will run as-is on the BBB, 3.2 kernel and all, it just won't know about the new hardware (like the HDMI output). I'll know for sure soon...Mouser says my BBB order has shipped. I was hoping to test this theory last night but I didn't get to it. Maybe later today...or maybe you'll get your order first :-) I notice the BBB which I received yesterday is rev A5A, which http://circuitco.com/support/index.php?title=BeagleBoneBlack claims is the production version. On the other hand, the System Reference Manual (Rev. A52, April 11, 2013) available from the same site says Rev. A5B is the initial production release. The phrase bleeding edge comes to mind. Regards, Kent -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] heads up on fast network I/O : netmap
On 4/17/2013 12:37 PM, Michael Haberler wrote: ... I stumbled over this: http://info.iet.unipi.it/~luigi/netmap/ this is suggested reading for anybody interested in the field; if the performance and ease of build (some drivers) hold up to the promise, this could potentially do away with the need for special-purpose stacks by brute force/speed of a much more general solution if the promise holds up: With netmap, it takes as little as 60-65 clock cycles to move one packet between the user program and the wire. As an example, a single core running at 900 MHz can generate the 14.8 Mpps that saturate a 10 GigE interface. Yeow. Hotter than a pistol and lives in user space. What a great find! Regards, Kent -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] pmMatRpyConvert
On 4/12/2013 8:22 AM, andy pugh wrote: Someone on the forum seems to have spotted something odd in pmMatRpyConvert http://www.linuxcnc.org/index.php/english/forum/30-cnc-machines/26392-the-study-of-arithmetic#32609 At best it seems like there is redundant code. Don't have my fingers on the right reference (yet) and my brain is rusty but I expect the seemingly odd coding is protection against the usual problems representing mathematical functions in binary arithmetic. Don't be too quick to suspect redundant code. Then again, trust but verify! If I get a chance later today I'll look for something I can pass to these guys on the forum. Regards, Kent -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Overview: the unified binary branch
On 4/9/2013 3:12 AM, Michael Haberler wrote: The new RTOS builds are close to producing packages as Seb has thankfully updated the buildbot to run RT-PREEMPT and Xenomai kernels, so it is time to turn what's coming next building on this work, and that is the unified binary build. The code for that is mostly done, what remains is adapting the build procedure to support several targets in one go. However, as an early branch is now winding through the buildbot too it might make sense to get everybody on the same page on what it provides, and how it is done. The goal of this work is: make linuxcnc build for any supported kernel or thread flavor in one go, and have all that support in a single package; the actual type of threading used is a startup option (subject to limitations of the running kernel, and what platforms it was built for). This is exciting news. My thanks and tip of the hat to the small team of developers who have suffered through the frustrating details to make this happen. In every field I've worked in, infrastructure projects like this one were always a hard sell because most folks were most interested in the superstructure---the applications and their interfaces---and naturally so. It is always easier in retrospect to appreciate the importance of a sound foundation or rue the lack of one. Good on ya, mates. Regards, Kent -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Fw: SourceForge project upgrades start April 22
On 4/5/2013 3:44 PM, Matt Shaver wrote: Will this cause us any problems? Everything I read about this is long on announcement and short on details I can use. :) Thanks, Matt Reading over the Allura features list, http://sourceforge.net/p/allura/wiki/Features/, I don't see significant problems nor amazing new capability. - Allura offers feature tracking rethought from the ground up and fire-polished during the development of Allura. How much more useful it would be for us than the existing SourgeForge Trackers remains to be seen. I didn't notice any statement about possible impact of the release of Allure on the continued support of the existing trackers. - Allura offers threaded-discussion forums which look, superficially at least, like the linuxcnc forums. The announcement does not say what will happen to SourceForge maillists. Even if it doesn't have to, perhaps the emc-developers email list could migrate to a Allura threaded-discussion forum? - Allura offers a wiki for documentation development. Now isn't that special? - Allura offers a code repository that supports git, mercurial, and subversion (but only old svn repositories, they say in the FAQ) and supports browser-based code browsing. We already have these features in our repository. Would we consider migrating it to Allura hosted on SourceForge? - Allura is written in Python. It must be the Right Stuff :-) Perhaps the biggest attraction lies in the consolidation of these features into one code package which one could easily configure and and run either on SourceForge hardware or other hardware and keep (I assume) the same data same interfaces, and same look-and-feel. Regards, Kent -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] New ARM/FPGA Platform
On 3/27/2013 2:52 AM, Michael Haberler wrote: I'm entertaining ideas here - it would not be good if the price for using such devices would be a collection of special-purpose hacks per-platform and per-device. But of course that is just what the pick-an-IP-from-column-A and one from column-B, and ..., approach in the ARM world is doing to the entire smart-devices industry :-( The curmudgeon in me worries we're trying to out-ski an avalanche. Exhilarating for as long as it's still behind you; crushing once it catches up. I'm glad you're thinking ahead (and like the ring buffer as supporting infrastructure). Regards, Kent -- Own the Future-Intelreg; Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] New BeagleBone
On 3/17/2013 10:08 AM, Charles Steinkuehler wrote: For those following along on LinuxCNC ARM development, there's a new version of the BeagleBone coming out soon: http://beagleboard.org/unzipped More and faster memory, on-board flash, built-in HDMI, and a lower (but not yet announced) price. It's curious how the current microelectronic economy works. First, they get under the price of the BeagleBoard by nearly 40 percent by throwing out features to create the BeagleBone. Then they add back features to the BeagleBone and reduce the price some more. Clearly, the RPi sales numbers have affected these guys (neither side claims to be in it for the money but obviously both crave the street cred). For 30 years we had the relative stability of the PC as the target application to focus the evolution of x86 CPUs and their surrounding technology (notably, the interfaces). In the past 5 years, it's been the laptop/notebook/HTPC market that has focused their evolution (and the interfaces have suffered). The evolution of ARM has been much more diffuse. Smartphones and embedded applications certainly became a big factor, but the rapid evolution of SBCs like Beagles, RPis, and all the others look like attempts to find a sweetspot without a shared definition of a target market (interfaces? what interfaces? here's some gpio bits to twiddle.). These are exciting times for tech junkies like me who accumulate one of everything, but the turbulent situation must give heartburn for those trying to realize a stable product. Can't wait to see the product itself and not just the teaser announcement of a product. Regards, Kent -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] Implementation of LCNC Copyright and licensing terms
Gentle persons: I've spent every waking moment of the last two weeks by my wife's side after a massive infection put her into septic shock. Those of you who know me know this isn't a play for sympathy (and please, please, please, let's not fill this channel with responses to the news) but an explanation for why I've been uncharacteristically silent during this lively discussion of copyright and licensing. Some may recall I tried unsuccessfully to start such a discussion twice, first in January 2012, and then again in August 2012. I think I failed because I was coming from the perspective of an editor (gack) rather than an implementer (yay). - (aside) In response to various messages about what the different licenses mean and what the legal ramifications are, I have recently discovered that O'Reilly*, as part of its Open Book Project, has made freely available the book Open Source and Free Software Licensing by Andrew M. St. Laurent, August 2004. One can download the individual chapters as pdf files from http://oreilly.com/openbook/osfreesoft/book/index.html The chapters are: Chapter 1: Open Source Licensing, Contract, and Copyright Law Chapter 2: The MIT, BSD, Apache, and Academic Free Licenses Chapter 3: The GPL, LGPL, and Mozilla Licenses Chapter 4: Qt, Artistic, and Creative Commons Licenses Chapter 5: Non-Open Source Licenses Chapter 6: Legal Impacts of Open Source and Free Software Licensing Chapter 7: Software Development Using Open Source and Free Software Licenses Note well Chapters 1, 6 7 which get beyond textual analysis of the individual licenses. I haven't read it all yet but the parts I have were easy to read and very good. It may not be as good as having an intellectual-property rights lawyer in your pocket but it's as close as I can get for free. - Back to my implementation theme. The recent comment about getting LCNC included in major distributions brings this one home for me. I don't have a dog in the fight over choosing licenses, but I think we should do a better job than before in our implementation of the choice(s) we make. 1) There are hundreds of source-code files in the LCNC distribution. I won't repeat my year-old messages about the disparities in the style and content of their copyright and licensing statements. I know I sound like that school teacher you most detested but it seems to me an important step is to impose a common style. Of course, the content may differ depending on the source of the code but the provenance, copyright, and licensing should be as clear as we can make it. This seems especially important if we contemplate making the lower layers of LCNC visible in their own right. I looked at samples from the Linux kernel and found they vary more than I expected. I suppose this reflects its decades of code development starting with the archetypal Thunderdome developer, Mr. Rules? There are no rules Linus Torvalds. Some files had surprisingly minimal statements, but they all have a statement. I looked at samples from GNU software and, unsurprisingly, found them more uniformly documented. I don't want to emulate Richard Stallman but I do think we would benefit from more uniformity. 2) I've momentarily lost it, but there was an interesting CONTRIBUTING file alongside the usual COPYING file in somebody's project which spells out the expectation/obligation of contributors to abide by the overarching licensing statement of the project. I think inclusion of such a file could only help the LCNC project. I'll try to find it again. 3) I think the documentation should prominently display a statement of the software copyright and licensing statement (and philosophy) up front. A recent email exchange on our lists was an example of the confusion created by having only the documentation copyright and licensing statement plainly visible. Try searching either the wiki or the website on licensing. The resulting hits are mostly about documentation. There is the ambiguous statement GPL licensing terms have been applied to the derived code which appears in discussion of how LCNC/EMC2 differ from the NIST code. I know the history of the development of LCNC. I don't want to rehash why things are the way they are now. I just want to see them get better as we move forward. Regards, Kent *I still think O'Reilly is villainous in its treatment of authors (see, e.g., recent hacker news traffic), but this Open Book is genuinely useful. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] xenomai on an Intel Atom motherboard- latency-test results
On 3/3/2013 12:44 PM, Dan Falck wrote: Michael Haberler has guided me through installing xenomai on a computer I have here and I wanted to post my results from the latency-test. Intel Desktop Board D94GCLF2D (purchased from Newegg several years ago). Dan: I also have this Intel board (Atom 330-based) and a later ASUS AT5NM10-I (Atom D510-based). I fell by the wayside a while back in my Xenomai testing and never got past my Intel P4 and AMD Athlon II cpus. Now that you've posted your Atom numbers, I feel inspired to catch up. We'll see if I can replicate your results. It seems to me things are stabilizing to the point where the Xenomai builds need no longer be considered experimental. IMHO, we should consider posting Xenomai metrics to the Wiki for easier comparison. I believe we should create a second Latency Test Results table (and label the two tables appropriately) rather than mix and match RTAI and Xenomai results within a single table, but that's just me. If no one has set it up by the time I get my boards set up (Note to self: get a bigger desk) and run the tests, I'll create the new table myself. Regards, Kent -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] xenomai on an Intel Atom motherboard- latency-test results
On 3/3/2013 2:56 PM, Tom Easterday wrote: On Mar 3, 2013, at 1:40 PM, Kent A. Reed kentallanr...@gmail.com wrote: It seems to me things are stabilizing to the point where the Xenomai builds need no longer be considered experimental. IMHO, we should consider posting Xenomai metrics to the Wiki for easier comparison. This reminds me Is there a roadmap document anywhere that shows what we can expect for upcoming/future releases? For example, questions I have are... Will 2.6.0 be on 10.04 or 12.04 or both? Will new rt kernel options be incorporated? Tom Great questions, Tom. Inquiring minds want to know. I could tell you what I *wish* such a roadmap document would say, but I'm not one who can tell what it *will* say. Regards, Kent -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Porting miniEMC2 web interface
On 2/28/2013 4:54 AM, Michael Haberler wrote: Hi GP, Sergey - I've tried it out on Lucid - I am impressed! Since you're wildly productive with integration, please fill me in on the bigger picture: how does this relate to your other projects? - Raspberry http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Miniemc2webinterface - http://code.google.com/p/rt-8p8c - http://code.google.com/p/picnc/ I think that is a great start for a Web-based UI which can eventually run on a mainstream branch! I'll still have to try this on the Raspberry, but I see the emcweb server has less of a CPU impact than Axis so it looks like a good fit for smaller boards which lack the punch to run more demanding UI's on it - Michael I'll second Michael's remarks. I didn't get around to trying out your code until after you got it cleanly integrated with latest source https://github.com/kinsamanka/linuxcnc-mirror/tree/emcweb so I went with that. I pulled and built LinuxCNC + emcweb a few minutes ago on Ubuntu 10.04LTS. No problem except: is it just me or is this branch missing the ./www/index.html file? Once I copied this file over from the svn repository emcweb started serving Sergey's clever, not to mention attractive, control panel as expected. For those who haven't played with http servers, it's worth noting that, as built from this branch, emcweb is serving on port 8080 rather than port 80, so one must browse to http://host:8080 Regards, Kent -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Unifying error message reporting in LinuxCNC
On 2/26/2013 5:00 PM, Chris Radek wrote: I guess I just want us to consider what problem we are solving for the user before we decide on an architecture. I saw a lot of obviously syslog! and I didn't understand why we were jumping right to there, because it didn't seem to me that it solves any of our primary problems. I realize we are coming at this with opposite approaches - that's good! Michael's original message said - all messages shall be reported through a single channel, including its reporting level, and preferrably its origin too - setting a message reporting level shall apply to all elements in a uniform way I think this is an admirable set of requirements in itself, especially but not exclusively for the more distributed systems we are imagining. It addresses channels and messages in them, not destinations. Pretty general stuff. Certainly syslog is one possible destination for messages (based on reporting level, say) but it isn't not the only one. Perhaps as important as asking what problem does this architecture solve, Chris, it is important to ask what usage pattern would this architecture exclude? Regards, Kent -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] 12.04-2 vs my lappy
On 2/19/2013 11:05 AM, Gene Heskett wrote: Greetings; I was advised that John Morris's new stuff was running on a 12.04 LTS install, where as a test install on 10.04-4 on my lappy wouldn't boot, the new kernel panic's about .6 seconds in, can't mount sda1 as /boot (or root, I didn't take a pix) I also had to do the sailors hornpipe on the left shift + ctl in order to get a grub screen at all. Gene: I suppose it's a bit late in the day to ask if you first tried a LiveCD/LiveUSB version :-) Details about your laptop may not help but I always ask. My personal experience has been that newer releases of Ubuntu (and most every other distro as well) are more likely to work out of the box on my laptops than older ones. If I recall correctly, this isn't the first time you've complained...er...commented about IPV6. I am at a loss. Yes, recent distros enable IPV6 by default but the distros just work for me on my home IPV4 network. It's not Ubuntu 12.04, but at the moment I'm running Linux Mint 13 on a Toshiba Netbook NB305 with Michael Haberler's 3.2.21-xenomai+ kernel. IIRC I had tested Ubuntu 12.04 on it at some point. Ethernet and WiFi interfaces work without my fingers leaving my hands. The only notable problems I have are 1) Linux doesn't wake up properly after I've closed and opened the cover and 2) battery performance is still terrible compared to performance with MS Windows. I think I can fix 1) if I just dig around the Internet, but 2) is a continuing challenge for the Linux-on-laptop community. Regards, Kent -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Xenomai latency spikes: feedback from Xenomai mailing list
On 2/13/2013 6:08 AM, Michael Haberler wrote: Am 13.02.2013 um 11:37 schrieb andy pugh: On 13 February 2013 10:15, Michael Haberler mai...@mah.priv.at wrote: http://www.xenomai.org/pipermail/xenomai/2013-February/027675.html This sounds familiar, there is a similar situation with RTAI: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?RealTime and the cpu hog near the bottom. Mick just observed that the nohlt idle=poll boot option does in fact improve latency figures significantly It might well be the case that the same option does have an impact with RTAI, too It's worth a try - I just dont have 'laggy' hardware at my hands here - Michael After a bit more searching, I guess you are aware of that as exactly the same name for it is being used on the Xenomai page. -- atp As I've been telling Michael in a side channel, my latency test results from late last fall with an AMD Athlon II X4-640 cpu on a ASUS M488T-M motherboard do not show the same behavior being reported for this newer AMD cpu and whatever motherboard. Back then, I ran Michael's x686 xenomai kernel with a variety of configurations - various cpus isolated or not, various combinations of servo and base threads on different cpus, various combinations of cpu-hog runs. (see https://sites.google.com/site/manisbutareed/linuxcnc-2-5/xenomai-user-threads) Latencies were always within a factor of 2x to 4x of my best RTAI numbers for the same hardware. The only latency buster I encountered was peeking at the xenomai stats. Executing cat /proc/xenomai/stat would reliably blow up the base thread in particular (jumps 250us or more). I am overwhelmed by my home healthcare-provider chores and have not been able to catch up to the latest wisdom and repeat my testing accordingly. I do have one new data point that didn't cost me a lot of time to generate: I rebooted the same system with the additional kernel boot parameters nohlt idle=poll A quick 'n dirty latency-test showed similar jitter to what I had seen before. Maybe they are a tad better, but I have no time now to be quantitative. For the record, cat /proc/xenomai/stat still blows up the latency numbers. Regards, Kent -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Xenomai latency spikes: feedback from Xenomai mailing list : the reference
On 2/13/2013 10:28 PM, Tom Easterday wrote: I spent the day playing with this on the Intel Atom D2700MUD. I rebuilt the system using the rtos-integration-preview3-merged-into-master branch. I rebuilt it for another reason (stupid graphics fubar) and figured I would try this branch for the heck of it. Neither no-halt nor idle=poll had any effect (good or bad) on the system as far as I could tell in the short testing intervals I did today (5 minutes or so generally). I played with Hyperthreading, which definitely needs to stay off on my system, and isolcpus which helps latency some (I think) but really makes the machine slow for doing anything else other than Linuxcnc - but that's the point isn't it? In general I am seeing between 15,000-22,000 but I will let the machine run over night or a weekend soon for more concrete numbers. If I run update-grub, whether I have made a change to grub or not, the number shoots up to over 170,000. Obviously this isn't something one would do while using Linuxcnc, like Kent's messing in the /proc area, and shows you should keep your mitts out of where they don't belong. :-) Tom On Feb 13, 2013, at 2:29 PM, sam sokolik sa...@empirescreen.com wrote: For this system (amd) the only thing that seems to make a difference is the idle=poll (no-halt seems to have no effect) I go from 200+us latency to 7us top. sam Regarding the AMD Athlon II X4-640 system I've mentioned several times, I got a few moments to try a restricted set of combinations. Just first impressions. --- Some trivia: Still Michael's i686 3.2.21-xenomai+ kernel from late last fall on a Ubuntu 10.04LTS system. Always isolcpus=3 (e.g., the last one reported by the bios) Five-minute latency tests with both 25us base-period, 1ms servo-period threads running on isolated cpu 3. No special attempt was to torture the system. Just random browsing. cpu hog means the one-line script from the Wiki. us means microsecond --- Results: case 1. no other boot parameters, no cpu hog servo jitter 6us / base jitter 9.5us --- case 2. no other boot parameters, 1 cpu hog running servo jitter 5.9us / base jitter 6.2us --- case 3. no-hlt and idle=poll, no cpu hog servo jitter 4.0us / base jitter 5.0us [avg of 3 runs] servo jitter 2.8us / base jitter 3.3us [a later single run; gives a sense of the variability] --- case 4. no-hlt and idle=poll, 1 cpu hog running servo jitter 3.2us / base jitter 5.1us [I believe this is an anomalous result caused by me playing with the sensors/ksensors packages. Forgot to go back and check. Sorry.] --- case 5. nohlt and idle=poll, no cpu hog servo jitter 2.5us / 3.1us --- case 6. nohlt and idle=poll, 1 cpu hog running no test --- case 7. only idle=poll, no cpu hog servo jitter 2.7us / base jitter 3.4us --- case 8. only idle=poll, 1 cpu hog running essentially same as case 7 within some tenths of a microsecond. - Comments: 1. My jitter is so low with this CPU/motherboard combination that none of this matters practically:-) 2. I recorded jitters to tenths of a microsecond but all indications are that I can get 1-2us variability without doing much of anything. 3. Like Tom and Sam, I don't see a strong dependence on either no-hlt or nohlt 4. Even at these low latencies, idle=poll has a beneficial effect and appears to make the cpu-hog approach irrelevant (not exactly new news...) 5. Reported temperature rises nearly 20degC with the extra boot parameters and a cheap house-brand heatsink/fan. Caveat: could be worse than this. The lm-sensors package and the ksensors package both report some temperature I don't believe is the CPU itself; at least the number they show is nearly 10degC lower than the one I see if I quickly reboot and look at the readings in the BIOS. Sigh. - Regards, Kent -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Future directions of LinuxCNC development, and RTAPI restructuring tutorial
On 2/6/2013 6:25 AM, John Morris wrote: On 02/04/2013 08:43 AM, Michael Haberler wrote: ...well in fact that's what John is doing for RTAPI, with the intent to arrive at a universal build that supports RTAI, Xenomai, RT_PREEMPT and sim 'automagically'; that's not part of the current merge candidate-in-the-waiting though the design and flow stands, and I think it's another incremental change - basically linking RTAPI though support libraries for RT OS x,y or z, that is replaced by loading a .so module - the same stunt Jeff does with the interpreter; since Jeff's change wasnt noticed widely, we hope this one doesnt either. And every HAL module uses a similar method, so that's all safe ground. Hi fellas, It's my own fault that the first opinion expressed on the list of the RTAPI restructuring is one of suspicion. I got a bit carried away for just 'cleanups', and didn't broadcast purpose, progress or pointers to information. Doubt should be the natural reaction to an end result of a patch with 3000 additions and 7000 subtractions to a critical piece of code. Following is a bit of a deep dive into what the RTAPI 'cleanups' are about in this email. Apologies for the great length, but I implore anyone both suspicious of the RTAPI work and also influential in setting the direction of LinuxCNC's development to at least scan through so it gets a fair shake. ... If you've made it this far, I'm admirous of your high pain threshold and also grateful for taking the work seriously. Hopefully the main concerns about what the changes are and their overall impact on the code base have been addressed. Please ask questions about anything still unclear, and I promise a short answer. Yes, John, I made it this far. I liked your explanation so much I've made it more accessible by copying it over to the Wiki as a subsection RTAPI Cleanup and Restructuring under LinuxCNC Development for want of a better place in the Wiki structure. I did a smidge of editorial work, like eliding the self-deprecation, which of course you can put back if you want. I tip my hat to you for all the work, thinking as well as doing, that went into this. Regards, Kent -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Future directions of LinuxCNC development, was custom EDM configuration questions
Gentle persons: I started to read an EDM discussion and discovered a future-directions discussion of LinuxCNC development hiding inside:-) The discussion is lovely and I hope it will grow. I just wish it had a better thread name so others would recognize it for what it is, hence the change in subject line. Regards, Kent -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] A Lazy Programmer's Solution to the BeagleBone Netboot Lockup Problem
Gentle persons:
I won't repeat here Bas's analysis of the problem we're having with the
BeagleBone/Ubuntu system.
Here is my minimalist solution which requires no new programming, just a
change in several configuration parameters. Please bear with the longish
message. Because of an abrupt turn of events at home, I'm on my way out
the door and I don't know when I'll next get a chance to put out this
information. Someone else may have to deal with the Wiki page if this
approach is found to work generally.
1. The uDev.txt Michael posted is like most I found on the net. It
results in DHCP services being invoked twice. First, U-Boot asks for
parameters it needs for, e.g., tftpboot. Then, while initializing, the
Linux kernel itself uses DHCP services to provision its ip parameter
set. This redundancy is harmless but consider...
if we eliminate that second invocation and instead explicitly pass the
full set of ip parameters in the bootargs then the LinuxCNC system boots
and stays up just fine. Yes, dhclient is still invoked early on but by
then the clock is set and the lease times are valid, at least in testing
on my system.
For example, from the U-Boot command line, the following works (I keep
most of Michael's parameters to maintain verisimilitude. Note though
there is an environment variable console already set properly by
U-Boot, so I used it.). I've added comments parenthetically (... ).
# setenv autoload no
(...I don't have time to demonstrate an alternative to turning off the
autoload feature)
# dhcp
(...provision some environment variables needed by tftp)
# tftp
(...the kernel is loaded to the default loadaddr)
# setenv bootargs console=${console} noinitrd rw debug --no-log
root=/dev/nfs nfsroot=my nfs server
ip:/var/lib/tftpboot/rootfs-xenomai ip=my BB ip:my server ip:my
gateway ip:my netmask:my hostname:eth0:off
(... substitute real strings for all items; the nfsroot string is
necessary because we're not letting the kernel obtain that information
via ip=dhcp)
# bootz
(...U-Boot passes control to the kernel at the default loadaddr; the
kernel initializes and mounts the root filesystem from the server)
and away we go.
2. So how do we do this in a uEnv.txt script? In various places in the
source code, U-Boot groks the following environment variables
ipaddr---our device's IP address
serverip---the IP address of the TFTP server
gatewayip---not strictly needed if everything is reachable on the
local subnet
netmask---the usual
hostname---not strictly needed if you set hostname in /etc/hostname
but I like the flexibility
bootfile---the name of the kernel that the TFTP server is going to
pass, relative to the (to pass to the TFTP server)
rootpath---the fully qualified root file system path to pass to the
NFS server
Most of you have probably discovered that, after invoking dhcp or tftp,
some of these environment variables have been provisioned from the dhcp
reply. However, in my system the hosthame and rootpath variables have not.
Yet in the U-Boot README we find the statement (note - for the purpose
of my discussion here, bootp and dhcp are equivalent commands; also,
rarpboot is not included in the BeagleBone executable)
The following environment variables may be used and automatically
updated by the network boot commands (bootp and rarpboot),
depending the information provided by your boot server:
bootfile- see above
dnsip- IP address of your Domain Name Server
dnsip2- IP address of your secondary Domain Name Server
gatewayip- IP address of the Gateway (Router) to use
hostname- Target hostname
ipaddr- see above
netmask- Subnet Mask
rootpath- Pathname of the root filesystem on the NFS server
serverip- see above
So what's up with that?
3. It turns out my ISP DHCP server is perfectly happy to dish out all
the necessary parameters including those I defined as options in my
dhcpd.conf.
Indeed, running dhcpdump confirms that my server is telling the kernel
everything needed when it exercises the ip=dhcp boot argument, but it's
not telling U-Boot. Why? Because U-Boot is explicitly telling the DHCP
server it wants only certain parameters and the server obliges (look at
the DHCPREQUEST and DHCPREPLY exchanges via dhcpdump).
So here we have the perfect stand off. U-Boot can use the needed
parameters if it gets them and will parse them if sent, but they aren't
sent because it doesn't ask for them.
4. It turns out the ISC DHCP server has a configuration parameter
available that can force the return of stipulated options whether they
are asked for or not. Here's the description from dhcpd-options(5)
option dhcp-parameter-request-list uint16;
This option, when sent by the client, specifies which options the client
wishes the server to return. Normally, in the ISC DHCP client, this is
done using the request statement. If this option is not specified by the
client, the DHCP
Re: [Emc-developers] [Xenomai] new RTOS status: Scheduler (?) lockup on ARM - SUMMARY
On 1/22/2013 9:01 AM, Charles Steinkuehler wrote: On 1/22/2013 6:06 AM, Bas Laarhoven wrote: A final solution hasn't been found yet: I prefer a workaround without changing the dhclient or some other standard program. I think it would suffice to acquire a new lease right after the time-step has been made. This has to be done without giving up the previous lease (that has expired because of the time-step), because that would cause the system to freeze again. Suggestions on how to do this are welcome. I can't spend much more time on this issue this week. Perhaps shutting down the dhcp client once the boot is finished, deleting the leases file, and restarting would work? If it works, it could be implemented as a very late init script. I don't have time to test at the moment, as I'm heading out of town. Well, manually this technique seemed to work for me, at least when I restarted dhclient from the command line. I'm uncertain where one would inject a very late init script to ensure it will be proof against all the other processes that are lurking in Ubuntu and its brethren (I've read complaints in the Blogosphere that network manager, to cite one example, may restart dhclient if it notices it is not running). Perhaps none of them pertain to our stripped-down system. Obviously, I'm not above using this approach but I can't help feeling it amounts to putting lipstick on the pig I described in my earlier message to Bas:-) The tricky part of what Bas describes is that bit about without giving up the previous lease. It isn't clear to me that the current documentation describes exactly the current software is doing, so I don't have a suggestion yet, but I'm confident this approach can be made to work too. I'm trying to work some different tricks as well but I'll be out of touch for a bit too to deal with family health matters. Regards, Kent -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] BeagleBone DHCP Crashes
On 1/21/2013 12:11 AM, EBo wrote: It sounds like this condition should be checked for in the scripts and/or code -- there are a number of conditions where stale files can be left around (although one would hope that this would be taken care of on bootup). Ebo: I added stanzas to /etc/rc.local that check for the existence of the leases files and delete them if present (I don't like blind deletes; this way I can include a log message if the file exists). However, Bas' most recent message may lead to a different fix. Regards, Kent -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] BeagleBone DHCP Crashes
On 1/21/2013 9:28 AM, Kent A. Reed wrote: On 1/21/2013 12:11 AM, EBo wrote: It sounds like this condition should be checked for in the scripts and/or code -- there are a number of conditions where stale files can be left around (although one would hope that this would be taken care of on bootup). Ebo: I added stanzas to /etc/rc.local that check for the existence of the leases files and delete them if present (I don't like blind deletes; this way I can include a log message if the file exists). However, Bas' most recent message may lead to a different fix. Oh, please, shoot me now. This is one of those answers that is short, neat, and wrong. The offending lease file gets created after rc.local runs. Regards, Kent -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] BeagleBone DHCP Crashes - WORKAROUND please test !
On 1/21/2013 6:18 AM, Bas Laarhoven wrote: On 20-1-2013 18:31, Charles Steinkuehler wrote: On 1/19/2013 8:57 AM, Charles Steinkuehler wrote: I've setup Michael Haberler's network booting of my BeagleBone, and I seem to be having the same network crashing on DHCP lease renewal issue others have seen. Has anyone identified and resolved the issue, or just worked around it? Update: Given the way the system behaved, I suspected an issue with dhcp lease renewal, which appears to be the case. ... Could everyone who's experiencing the lockup / freeze / hang try the following workaround: The Ubuntu filesystem has a ntpdate file in /etc/network/if-up.d. Move this file (temporarily) to another place and reboot the system. This should solve the lockup. The system is now running with the wrong RTC setting, but dhcp is acting properly. (At least at my place!) Theory: The bone is booting without correct RTC setting, so the time is in the past 1970, 2000 or something like that. This can be found in the /var/lib/dhcp/*leases* file. Bas: You're right, of course. You'd think I would have looked at the contents of the leases file. In a freshly booted system, the relevant timestamps are 2000/01/01. Regards, Kent -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] BeagleBone DHCP Crashes
On 1/20/2013 12:31 PM, Charles Steinkuehler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/19/2013 8:57 AM, Charles Steinkuehler wrote: I've setup Michael Haberler's network booting of my BeagleBone, and I seem to be having the same network crashing on DHCP lease renewal issue others have seen. Has anyone identified and resolved the issue, or just worked around it? Update: Given the way the system behaved, I suspected an issue with dhcp lease renewal, which appears to be the case. I created a new SD card with Michael's TFTP/NFS boot partition, but with the rootfs on a second partition (unused by default). Once the system network booted, I logged in via ssh and started a simple while loop (running 'uptime' every 5 seconds). In the USB/serial console, I mounted the SD card rootfs and chrooted to it. Neat trick, Charles. Wish I'd thought of it! After a bit more than 4 minutes, the network went down, taking my ssh console with it. The chroot was still alive, and showed that eth0 no longer had an IP address. Manually assigning an IP address to eth0 restored full functionality, even the ssh terminal came back alive, although it 'skipped' several of the 5-second intervals when it was blocked waiting for the network. Slick. I suspect this may be an Ubuntu issue, but regardless it does not appear to be a fundamental problem with the ARM kernel or the 'Bone. I have not yet tried to debug the lease renewal problem. First I'll probably see if a Debian install behaves the same way. If so, I'll likely try to get to the bottom of the problem. If not, I'll chalk it up to those wacky Ubuntu folks, and go back to Debian (or work-around the issue by running off the SD card if I need to stick with Ubuntu). Alas, the only other build I have tried was based on Ubuntu Qantal---not exactly a different code base. Those wacky Ubuntu folks...well...yeah...but I prefer to say those wacky Linux guys. Every distribution contains questionable code. And please disregard what I said last night about getting around the problem by using NFS rather than TFTP to load the kernel. I must have accidentally rebooted a different configuration. (Note to self: stop trying to be productive after midnight!) I hate adding to the world supply of red herrings. Sorry. Regards, Kent -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] BeagleBone DHCP Crashes
On 1/20/2013 6:21 PM, Charles Steinkuehler wrote: ... I was able to get a working system by deleting all existing lease files in /var/lib/dhcp/ and by forcing broadcast responses from the dhcp server (put always-broadcast on; in the BeagleBone host declaration). Further testing showed simply deleting the existing leases from /var/lib/dhcp/ seems to work as well, but I thought I had tested this prior to adding the always-broadcast flag to the host stanza and found it still failed (I really should take better notes). There could also have been some issues related to leases on the dhcp server, which I didn't try to flush. Anyway, if you have run into this issue, see if deleting the exiting lease file(s) fixes things up. I am currently running *WITHOUT* the always-broadcast flag, and don't seem to be having problems. Yes, Charles, deleting the lease files seems sufficient here too. A configuration that had been reliably locking up in 2-1/2 minutes is still up after 15m. Thanks. I could have sworn that I tested this hypothesis weeks ago, having been sensitized to the existence of the lease files by the inadvertent inclusion of such in Michael's initial distribution. Convinced that the problem must lie elsewhere, I jumped on my horse and rode off in all directions. Like you say, I really should take better notes. Regards, Kent -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] BeagleBone DHCP Crashes
On 1/19/2013 2:46 PM, Kent A. Reed wrote: On 1/19/2013 9:57 AM, Charles Steinkuehler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've setup Michael Haberler's network booting of my BeagleBone, and I seem to be having the same network crashing on DHCP lease renewal issue others have seen. Has anyone identified and resolved the issue, or just worked around it? It looks like Kent Reed had this problem, but has switched to using a rootfs on the SD card. I didn't see an actual solution in the archives. I'm sorry you fell in the same hole, Charles, but I'm relieved I'm not the only guy in it! I haven't finished gathering data (got distracted by the BeagleBoard-xM comments yesterday, including yours, and pulled mine out of a project to see if I can boot and run LinuxCNC as built by Michael). Anal-retentive tester that I am, so far I've tried various combinations of: 1) U-Boot IP provisioning: either setting the relevant environment variables explicitly or setting them via DHCP (U-Boot command dhcp with autoload=no) 2) kernel loading: either from the microSD card or via TFTP (U-Boot command tftp with autoload=no) 3) kernel IP provisioning: either setting the relevant boot parameters explicitly or setting them via DHCP (boot parameter: ip=dhcp) 4) rootfs mounting: either from the microSD card or via NFS So far, it seems that I can succeed with a number of combinations---many with rootfs mounted via NFS---but not with 1=dhcp, 2=ftfp, 3=dhcp, 4=nfs (e.g., the very combination that Michael described on his Wiki page) and I can cheat death with this last one by greatly increasing the lease time. I think this combination being an issue is a good clue but I haven't noodled through what it means. YMMV :-) Gentle persons: I neglected to include yet another variable. As Bas pointed out in the other thread ([Emc-developers] new RTOS status: Scheduler (?) lockup on ARM) one can also load the kernel via NFS rather than TFTP. This means my item 2 should have three options, namely, from microSD, via TFTP, or via NFS. A few minutes ago, I restarted my BeagleBone with 1=dhcp, 2=nfs, 3=dhcp, 4=nfs, and then started LinuxCNC with the same test as before, simulated 3-axis mill processing 3D_Chips.ngc. Unlike the nearly identical configuration with 2=tftp, which reliably locked up after a few minutes*, this configuration is still running 20 minutes later. I'll leave it running while I try to get some sleep. Assuming it's still running when I get up, I'll rerun the original configuration to confirm it's still failing...if it doesn't fail, then I'm really going to start tearing my hair! Regards. Kent *actually about 2.5 minutes which happens to be 1/2 of the lease-expiration time I set in dhcpd.conf. Since I know that many dhcp clients by default start looking for renewals on their leases at this 50-percent point, I'm suspicious that some related is causing my lockups. And, no, Michael, I don't have your stale leases hanging around. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] new RTOS status: Scheduler (?) lockup on ARM
On 1/17/2013 2:59 AM, Bas Laarhoven wrote: I think that running linuxcnc is mandatory for the lockup. After a dozen runs, it looks like I can reproduce the lockup with 100% certainty within one hour. Using the JTAG interface to attach a debugger to the Bone, I've found that once stalled the kernel is still running. It looks like it won't schedule properly and almost all time is spent in the cpu_idle thread. The kernel with extra diagnostics produces these messages: [ 3480.386342] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 3480.395913] INFO: task axis:799 blocked for more than 120 seconds. [ 3480.406643] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 3600.408670] INFO: task hal_manualtoolc:788 blocked for more than 120 seconds. Hi, Bas. Like Michael I haven't been running LinuxCNC continuously but I'm doing it now to see if I can reproduce your lockup on my BeagleBone. I'm using a Rev. A6 BeagleBone powered solely through the microUSB port (I've tried unsuccessfully to induce power problems; there's a 2a supply in the drawer if I need it) I'm running off Michael's updated root filesystem. Both the vmlinuz-3.2.21-xenomai+ kernel and the rootfs are loaded from the microSD card (e.g., TFTP and NFS were not used to bring up the system and DHCP was used only to provision the kernel ip settings, not the U-Boot settings). [1] I'm talking to the BeagleBone via ssh -X over my LAN so I don't have to futz with DISPLAY and permissions settings. [2] Since the microUSB port is connected I'm logged in over the serial port and running 'top' to see how I'm doing. So far, I've had LinuxCNC up for more than an hour with the 3-axis mill simulator running in Axis, repeatedly executing and reopening the 3d_chips.ngc file within Axis. Granted I haven't automated this; every time I notice the simulator has finished the G-Code I manually reopen and execute the file. Nevertheless, the processes Axis, milltask, hal_manualtoolc, and halui remain loaded, active, and the big cpu consumers according to 'top'. As an aside, so is sshd, which is consuming 25 percent (yikes) of CPU as long as it's updating the backplot. So, to help me understand better what you are seeing, could you please add some detail to your report? -What rev board (ok, so I think this an unlikely problem, but at some point you said you've been working with your BeagleBone for months so I wonder what's different between yours and mine)? -are you running a simulator or are you exercising some PRUSS code or what? -what do you mean by running LinuxCNC? Does LinuxCNC have to be actively running a program without interruption for the fault to occur or does it fault when run the way I did my own test? Finally, with respect to your next email message, how universal is your statement that TI ...decided not to support the PRUSS anymore. Does this refer to the TI documentation and software situation or does it mean TI has decided they can't make money developing SoCs with PRUSS and, hence, the current AM335x series is the end of the road? I could get depressed:-( Regards, Kent PS - I promise I'll update Michael's wiki page concerning items [1] and [2] -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] new RTOS status
On 1/16/2013 9:15 AM, Michael Haberler wrote: a short update: There's a lot of really good news here, folks. My thanks and a tip of the hat to Michael, John, Charles, and everyone else who has contributed. I doubt most of us can appreciate how much work has been done to get us to this point. The devil's in the details as they say. linuxcnc development branches: ... John and me are working to produce a single 'userland threads' build which supports all of the mentioned styles, and activates them based on autodetection of the underlying kernel (default) or explicity through a startup option. This should make it significantly easier for the build process, and also for trying different kernels with the same configuration (reboot, but no rebuild required). This is terrific. I've futzed with various schemes to keep separate builds available on the same machine and it's a real nuisance. ... x86 kernels: from the 'it doesnt boot on my machine' perspective it seems we're through the worst with this kernel: http://static.mah.priv.at/public/xenomai-debs/linux-image-3.2.21-xenomai+_0.4_i386.deb . However, John is working with the folks on the Xenomai list to produce debian-style and other 'universal' kernels which likely will be based on a later vanilla kernel (3.5.x). Since these will likely see more exposure than my initial attempt I would rather bet on that option. There is also talk about forward-porting the ipipe patch to 3.8 so with that route it seems to me the 'kernel too old' problem will go away. John probably can give a better picture here. Fortunately, all your kernels have booted on my machines without any problems not of my own making. I'm glad to hear the worst is over for others. I'm also relieved to hear the ipipe folks are still breathing. from the latency perspective, I must say the results are still confusing - we have Sam's AMD results which are disappointing, and we have other reports like memleak's which really shine on an AMD (different base version though). We have no figures from the efforts on the Xenomai list yet, but that shouldnt be too long. Also memleak has access to my git kernel repo and I am looking forward to having a build which can be reviewed on other platforms as well. So here it's more about consistent results, rather than instability. In fact I havent seen a kernel oops or crash with the 3.2.21 based kernels in quite a while. Sam's results were so different from my own that I keep thinking there's something obvious we're missing here. Time will tell. I need to repeat my tests using the latest version. ARM work: Several people have been able to get the Beaglebone ubuntu/xenomai setup working as outlined here: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?BeagleboneDevsetup I have updated the kernel and rootfs image a few days ago so the kernel includes ext2/3/4 support compiled in, which should take care of two failure reports I got. Again that xenomai kernel is based on 3.2.21; it works very stable for me but there have been several reports of 'sudden stops'. The BB is a bit sensitive to power fluctuations but it might be more than that. As for that kernel, it works, but it is based on a branch which will see no further development. It supports most of the stuff needed to development; there might be some patches coming from more active BB users than me. I'm not convinced it is solely a power supply issue, at least not in my case, but more usage should shed light on any underlying problems. I'd be happy to be proven wrong. Charles has done some great work for a high-speed stepgen on the Beaglebone, and a few folks have reproduced that, but I leave the fanfare to Charles here;) That's your cue, Charles; time to appear through the curtain before the drum roll stops :-) I have done no further work on the Raspberry, I do not consider that platform particularly useful to base work on. Yep. For me, the RPi ranks right up there with Arduinos as fun but ultimately dissatisfying. I'm using mine for spur-of-the-moment projects. RTAI note: I was pointed to this thread recently, which is interesting to read for several reasons: https://mail.rtai.org/pipermail/rtai/2012-December/thread.html Git repository for RTAI It does mention a Ubuntu 12.04 RTAI kernel (Shahbaz Youssefi shabbyx at gmail.com Tue Dec 18 11:09:41 CET 2012) - it might be worth following that up, maybe this is an option to get the current builds out of the 10.04 end-of-support-life situation. I would appreciate if somebody more RTAI-aware than me would pick that up. It also touches on the issue how the source repository and collaboration model touches upon a project's success, and that's an interesting read. It looks like the nature of open source communities changes due to for instance the github model, making it easier for the casual contributor, which is a sore spot with the linuxcnc
Re: [Emc-developers] Beaglebone/Xenomai LinuxCNC starter kit
[Oops - I responded to Joachim and forgot about the list. This is a resend.] On 1/3/2013 3:42 PM, Joachim Franek wrote: I have also observed the crashes after about 5min. But after several reboots I was able to run the cnc demo programm from sim/axis/axis_mm. Hi, Joachim. I'm the KAR. I've traced my crashes to the way my BeagleBone and DHCP server are interacting. I'm not sure yet what the root cause is but I am sure it's not in Michael's LinuxCNC/Xenomai/Ubuntu system since the same occurs when I network-boot a Ubuntu Quantal system from the same server. It does not happen when I boot /load everything directly from microSD card. When you say after several reboots do you mean your crashes go away? I never saw that. My systems reliably die at about 4 minutes (I just run 'top', wait for the lockup, and read the last recorded time) and I can get a different lifetime by changing the default client-lease time in the DHCP server. Having a lease expire should not make a client lock up. Like I said, I'm not sure what the root cause is yet. Welcome to the ARMband. Regards, Kent -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] BeagleBone PRU Update
On 12/25/2012 8:14 PM, Charles Steinkuehler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Happy Holidays! Now that the hm2_pci driver works in user-space, and the Christmas turkey is cooked (and eaten!), I've managed to absorb enough details to write some code for the BeagleBone PRU and perform some initial timing tests. As things stand now, I expect to be able to implement a general-purpose PRU solution that can implement step/dir, up/down, pwm (or delta-sigma modulation), and anything else anyone wants to code up for all available PRU pins (14 PRU0 pins available on the 'bone) that can run with a cycle time of around 5 uS or less (ie: 5000 nS base period with virtually zero latency jitter, in LinuxCNC software stepgen terms). Even better, if you simplify the task, fold common channel control values together (step length, dir setup/hold, etc), and keep state data in registers, I think it should be possible to implement a 3D printer (or generic 4-axis CNC + 2 PWM) in a 1 uS thread. And there are still dedicated hardware timers and encoder inputs available as well! Of course, the proof is in the pudding, so keep an eye out on Michael Haberler's git repo...I'll commit code there once it does something useful. Oh, and Michael: Thanks for the PRU tools! The debugger may be limited, but it's *WAY* better than nothing! - -- Charles Steinkuehler Charles: I'm surprised not to see responses already but maybe everyone else has been as preoccupied as I have been. A BeagleBone arrived here on Monday so I'm all set to sample your tasty pudding :-) My 12-year old grandson's favorite word for things that impress him is epic. I think what you have outlined is epic. If it turns out it's possible only to deliver half as much performance it would be semi-epic, which is still awesome in my book!. Regards, Kent -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] my thanks
Gentle persons: Now that we have survived the great non-event of 2012, the end of the Mayan Calendar (something the descendents of the Mayans claim is totally misrepresented by us European descendents) and see the sun still comes up... Now that we have once again survived the Winter Solstice and see that the sun is again almost imperceptibly rising earlier and setting later ... I want to express my thanks to all of you who continue to make LinuxCNC better. I won't try to name you for fear of leaving someone out inadvertently. You know who you are:-) I look forward to more changes, additions, and all around fun in 2013. Regards, Kent -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] trying out Mesanet PCI cards with userland thread builds
On 12/17/2012 6:21 PM, Charles Steinkuehler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/17/2012 3:22 PM, Anders Wallin wrote: - pull this branch: http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/usermode-pci known-to-work configs are: 5i20.ini and 5i25.ini I can preliminarily confirm that git checkout 9a20569656795474cb95a0177a517f7f11da05b7 (not the latest git commit, since it messes with the build) works with a 6i68 + 3x20-1.0 hardware combo and the configs: hm2-stepper/3x20-small hm2-servo/3x20-small I am testing on 12.04LTS, 3.2.21-xenomai+, and a threads=xenomai-user build. Excellent news! So the tested hardware now includes the 5i25, 5i20, and 3x20, and all should run under either xenomai or rt-preempt. The latest code (that builds runs for me but not for Anders) is a restructuring that allows compiling of kernel-mode drivers for PCI with very minor changes the code (essentially replacing any linux/blah.h includes with RTAPI_INC_BLAH_H). With luck, there should be a grand unified version with my usermode-pci changes, John Morris' significant code cleanups, and Michael Halberer's unified real-time architecture available Real Soon Now! Then it's on to crafting a software stepgen program for the Beagle Bone's PRUs. You guys rock! We've come a long distance since the tentative emails a remarkably short time ago. I tip my hat to you all. Regards, Kent -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Spindle speed display, green progress bar type
On 12/13/2012 11:24 AM, Gene Heskett wrote: On Thursday 13 December 2012 11:01:49 Charles Steinkuehler did opine: On 12/13/2012 8:28 AM, Gene Heskett wrote: ... Looks like the section numbers changed. Try section 31.5 Spindle Soft Start in the Hardware Examples section. The example HAL setup has a spindle-ready net which may be what you're looking for. Still not there, but I found some stuff in section 33 that could be mined for such details I think. But the pdf viewer firefox is using now is the shittiest font handler I've witness in 30 years of computin. It says it will use acroread, but that is NOT what I'm, staring at. That thing should be taken out back and shot. Repeatedly. Its totally wierdsvill, I went to see if I could print just that section, and the page numbers were 245-247 that I wanted to print, but were 19-20-21 in the print menu, the first time I ran that, second time they were 1-8. We have an infestation of snilmerg in whatever pdf rendered firefox is using. Now go get the printout see if the font kerning is as fouled on paper as it is in video. Answer? YES! example: l oadrt pwmge n out put_type=0 So, I guess I learn to read swahili. Anyway, thanks, I finally found it. Cheers, Gene Gene: It's hard to know what you have on your hands but from the 'acroread' hint I infer that you installed Adobe's Acrobat Reader at some point. On my vanilla-Ubuntu 10.04LTS system, the HTML version of this section comes up cleanly in Firefox and the PDF version opens cleanly in the external Document Viewer application that Firefox opens. The typefaces don't display exactly the same but I expect they differ because of the different paths taken through the docs build-chain for the two types of output and not because of the viewing apps. Oh, yeah, I'm looking at the docs at http://www.linuxcnc.org/docs/2.5/ Regards, Kent -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] naming/docs: hal_xxxx drivers?
On 12/7/2012 6:49 AM, John Thornton wrote: In any case I doubt a newbee can find a man page with both hands... much less know to look for a man page. Now THAT'S dismissive :-) Seriously, though, I have cognitive issues with our man page system. Even seasoned users might miss that man abs - returns a description of the family of Linux functions which compute the absolute value of an integer man 9 abs - returns a description of the HAL abs component or man axis - returns a description of the LinuxCNC Axis GUI man 9 axis - returns a description of the HAL motion component just to cite two examples I recently ran across. As well, do even seasoned users understand the annotation at the top of the LinuxCNC man pages, such as ...(3rtapi) and ...(3hal)? These suggest specific man-page directories but actually denote pages from LinuxCNC projects that are placed in the general man3 directory. Yet this convention wasn't applied to many (most?) of our man pages...AXIS(1), for example. Several times, I have thought we need a better documentation roadmap for users, one that is accessible from the keyboard as well as the HTML/PDF/Wiki pages, but I freely confess I haven't tried to make one. I remember looking at the man-page generation process long ago when I was trying to help with the transition to asciidoc for 2.5 but I'm too fuzzy-headed this morning to remember if I took good notes :-( Regards, Kent -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] naming/docs: hal_xxxx drivers?
On 12/7/2012 11:08 AM, Sebastian Kuzminsky wrote: I've lived with man pages for decades, and our man pages seem well organized to me. I think that's my point, actually. It's commonly accepted among the folks who study such things that it takes roughly 6 to 10 years to become truly expert in something, by which time even the most byzantine organization makes sense. I'm just suggesting we could make it less byzantine to those who are machine users and integrators rather than Unix/Linux gurus. The recent exchanges triggered an old business memory. Since I'm not feeling motivated enough to do something about it (I've already got a verrry long to-do list) I'll say no more. Regards, Kent -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] latency histogram comp
On 12/5/2012 7:55 PM, Dewey Garrett wrote: Here is a simple comp named lhisto.comp to show a histogram for latency values in 1,2,5 bin sizes over 4 decades: http://www.panix.com/~dgarrett/stuff/lhisto.comp This is great, Dewey. Thanks. I'm glad I decided to put off my own effort until tomorrow. Now I don't have to do it at all! I think this is called lazy programming. Regards, Kent -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] latency histogram comp
On 12/6/2012 9:15 AM, EBo wrote: ... From that I can see that there is a small group of outliers at ±20us. From this information we might be able to look at the traces to see what is happening around those events and cleaning up some of the latency. I hear one of the previous posters about my latency is better than yours thing, but these plots (and possible statistical analysis) tells me how good my setup is and points me where to look for possible other latency gains. Those outliers were always there of course and could be seen with a little wasted time staring at latency-test and latencyplot, but the histogram approach demonstrates the value of pictures. I was the mine is better than yours poster so I have to quibble with the but these plots That was exactly my point to Gene. Focus on understanding and on improving the performance, not on the absolute numbers. Thanks guys for providing this functionality. Yup. They get my tip of the hat. Regards, Kent PS - thanks everyone for not mentioning the mistake in my offhanded remark to Gene about reducing the sizes of the captured-sample files by reducing the precision of the sample. I was like Wile E Coyote (a Warner Brothers cartoon character for those who don't know). I got up a head of steam and ran off a cliff but didn't know it until I looked down. Sorry. Fortunately, Dewey, et al. have made it a moot point. -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] outliers [was: latency histogram comp]
On 12/6/2012 3:38 PM, EBo wrote: On Dec 6 2012 12:27 PM, Anders Wallin wrote: Is the ±20us always happening during the startup? If so, we can probably work around this. If it is periodic, or happens much later, then it points to a real issue. On my machine the few events at +/- 20us do not occur immediately on startup, but rather randomly after a short while. For these initial tests I was recording about 100k jitter values, so for a 1ms thread it means I ran the logger for about 100 seconds. OK. I would say it is real then, and not a startup issue. Good to know... EBo -- Be careful not to generalize too much. My somewhat limited experience is that every combination of (motherboard)+(bios)+(cpu)+(specific-rt-mechanism) is capable of exhibiting qualitatively different behavior. Whether it actually does is, to me, a matter of test, not conjecture. That's why I've tried to set up and test a number of different combinations as time permits. Several times you and others have talked about connecting the outlier events to other goings-on by comparing time-stamps with system logs. Has anyone actually tried an experiment to do that? Regards, Kent -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] formal analysis [was: xenomai + linuxcnc on 12.04LTS]
On 12/5/2012 4:16 AM, EBo wrote: On Dec 4 2012 9:06 AM, Kent A. Reed wrote: ... If one is satisfied that the internal, latency-test approach provides a reasonable metric, then it would be dead-simple to take latency-test/latencyplot a step further, bin the results, and derive interesting measures from it. Like latency-test, one could provide a running tally of key measures or like the OSADL does for its RT-Preempt, one could draw histograms and analyze exhaustively on demand. I'm not a statistician, but have been involved with some wicked cool statistical analysis projects in the distant past. I wonder if there is anyone in the group who knows how to use R well enough to help design and set up a study to tease out various things like outliers, the spectral density, ... I am not sure what all, but that would be a formal way to get at what you are talking about. The nice thing is that R might already have the nasty bits like sapa, quantspec, spectralGP, or possibly BaSAR. I'm not realistically going to have the time to delve into this, but thought I would throw out the idea... EBo -- I love exploratory data analysis. Over the years it proved invaluable first in my degree work (I owe my degree to it) and later in my professional research. Fancy analysis---and R would be a great tool---can come later, but always start with plots to get a feel for the problem at hand. I'm shooting for a histogram plot by this weekend. Regards, Kent -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] formal analysis [was: xenomai + linuxcnc on 12.04LTS]
On 12/5/2012 2:38 PM, Gene Heskett wrote: On Wednesday 05 December 2012 14:33:01 EBo did opine: On Dec 5 2012 9:03 AM, Kent A. Reed wrote: On 12/5/2012 4:16 AM, EBo wrote: On Dec 4 2012 9:06 AM, Kent A. Reed wrote: ... If one is satisfied that the internal, latency-test approach provides a reasonable metric, then it would be dead-simple to take latency-test/latencyplot a step further, bin the results, and derive interesting measures from it. Like latency-test, one could provide a running tally of key measures or like the OSADL does for its RT-Preempt, one could draw histograms and analyze exhaustively on demand. I'm not a statistician, but have been involved with some wicked cool statistical analysis projects in the distant past. I wonder if ... EBo -- I love exploratory data analysis. Over the years it proved invaluable first in my degree work (I owe my degree to it) and later in my professional research. Fancy analysis---and R would be a great tool---can come later, but always start with plots to get a feel for the problem at hand. I'm shooting for a histogram plot by this weekend. That data would be easier to collect if latencyloop could keep a log, hint hint. My b.max is now at 18 microseconds, s.max is about 15, but the averages are in the 5 range. 31xxx runtime now. I'm already on it, Gene. There's surprisingly little to be done. As a side benefit (I hope), I decided the Wiki could do with a discussion of How LatencyTest works. Its mixture of shell script, dynamically created temp files, hal configuration, and pyvcp, not to mention hal itself, may be opaque to some folk. Stay tuned for a page branched off from the existing LatencyTest page. While I'm at it, let me say out loud what some of us have been whispering. There's no reason for us to get so fixated on these jitter numbers (and it's really the jitter we're interested in). They make interesting reading---like Consumer Reports rating numbers---but once they are good enough to run a particular machine it makes no sense to wrap one's self around the axle over them. It seems sometimes we just want to get into a typical playground argument...mine's better than yours, nyah, nyah, nyah :-) The techniques we're discussing here are intended more for understanding better what's going on in the bowels of the various cpu/bios/rt kernel combinations and figuring out what, if anything, can be done about it. My problem is I can never know enough (used to drive my bosses crazy) so new diagnostic tools always get my attention. Of course, a 25us base thread will generate nearly 14GB of data in a 24-hour period just capturing the current period-to-period difference in nanoseconds as a 32-bit integer, and a 1ms servo thread another 350MB. These aren't huge files by today's multimedia standards, but one has to be aware. I'm talking latencytest defaults here. Everything is already adjustable in the current latencytest script and one could reduce the file sizes dramatically by reducing the precision. Regards, Kent -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
[Emc-developers] aside: experience
On 12/4/2012 5:41 AM, Michael Haberler wrote: So much for the value of re-applying past experiences;) Fortunately, human beings have the capacity both to remember the past (ala George Santayana) and to imagine the future can be different. Or as my grandmother (sorry, she was the font of all wisdom for me) would say, live and learn :-) This is an interesting adventure. Regards, Kent -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] xenomai + linuxcnc on 12.04LTS
On 12/4/2012 2:47 AM, Anders Wallin wrote: I'm trying to place your 30us latency number in context. What motherboard/bios/cpu? This is a new Intel DH61AG mini-ITX motheboard with an Intel Core i3 2120T 2.6 GHz LGA1155 CPU. It has 4G of ram and a 60G SSD disk. On specs alone, this sounds like a sweet combination. I easily could have chosen it for myself. I feel like we are alchemists---if you prefer, Tom Edison---trying every possible combination in our search for the solution. The recent explorations of Michael, Charles, John, Bas, and others of alternative realtime frameworks are fantastic but a proper science hasn't yet emerged. Engineering without underlying scientific principles is really tough but sometimes one is forced to it. With HyperThreading turned off from the BIOS, and specifying isolcpus=1 in grub I seem to get around 14us mostly, but still the occasional 30us latency. The latency-histograms Michael had measured would really tell the whole story as I feel the 30 or 35us occasional spikes are quite rare. Any other BIOS/xenomai/linuxcnc tuning that I should try? For my In addition to latency-test there is a script called latencyplot that possibly could give some insight. I have spent time staring at the rolling plot trying to discern regularities in the jitter (like when I suspect a BIOS and SMI are doing some fancy footwork). I had conjectured on emc-users about how one might go about making an external pulse-train analyzer which, like Michael's digital logic analyzer, would be able to generate histograms but over a longer time scale. If one is satisfied that the internal, latency-test approach provides a reasonable metric, then it would be dead-simple to take latency-test/latencyplot a step further, bin the results, and derive interesting measures from it. Like latency-test, one could provide a running tally of key measures or like the OSADL does for its RT-Preempt, one could draw histograms and analyze exhaustively on demand. application a 1ms thread will be enough, so I can probably live with 35us, but it would be interesting to see if 15us is attainable easily. cpus, real and/or virtual). I recently reported latency measurements for a variety of configurations on my Quad-core AMD Athlon II box ( https://sites.google.com/site/manisbutareed/linuxcnc-2-5/xenomai-user-threads ). nice page, more of that please :) As I said before collecting this kind of data automatically into a web-browsable database would be nice. Thanks. I have some other boards and RT-approaches to try but your remark about automation is exactly on target. After kvetching privately to Michael about the tedium of testing all possible combinations (I feel like one of Skinner's pigeons pecking obsessively at the keys) I got to thinking about this too. Fiddling with BIOS options is probably out of scope for automation, but everything else could be done programmatically. I've been idly sketching out what to try on my next board. Regards, Kent -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] on the ARM builds
On 12/3/2012 12:51 AM, EBo wrote: On Dec 2 2012 10:26 PM, Kent A. Reed wrote: ... Curiously, Plan 9 (the OS from ATT, not the movie from Ed Wood!) has recently been reemerging in the Internet consciousness. I don't think Plan 9 is the answer, but the outside-the-box thinking that went into its design is a model for the thinking I believe could emerge in LinuxCNC too as we see new opportunities in the ARM world. In diversity there is strength. Kent, I am curious what else you have seen regarding Plan 9. You may not know, but the Plan 9 files system protocol has been in the main kernel tree for some time, and various other bits and bobs are being slowly ported from Plan 9 to Linux. I will have to check into to if the user defined name spaces have been ported yet -- those are useful. If you are interested in looking robotics using 9p take a look at Styx-on-a-Brick. BEo -- I apologize if I misled (usual excuse...I was tired). I admire the Plan 9 project-eers for daring to suggest that Unix is not the holy grail and exploring new paradigms that preserve much of the goodness of Unix. They invented Unix; they should know. I see that as metaphor for how I hope we proceed with LinuxCNC. On the other hand, I wasn't proposing Plan 9 as a concrete solution for us. (Nor do I consider its lack of market share to be a strike against it.) Thanks for the pointer to Styx-on-a-Brick. Fun stuff. My original message was triggered by seeing a hackaday item about someone porting Plan 9 to his RPi. I forget where else I saw Plan 9 mentioned recently too. Finally, who is this guy BEo and what has he done with our friend EBo? Regards, Kent -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] xenomai + linuxcnc on 12.04LTS
Quoting from the exchange between Michael Haberler and Anders Wallin: AW sudo update-initramfs -c -k 3.2.21-xenomai+ (I am not sure this is required or done by dpkg) MAH at least the 10.04 dpkg fails to do that for me, maybe this is some option I am missing; but dpkg and friends are in such deplorable shape in 10.04 that I prefer not to look into the issue - they are too old to even compile 3.x kernels. AW sudo update-grub In 10.04LTS, the update-initramfs step fails (don't ask me why; as Michael says, dpkg and friends are in deplorable shape in 10.04) and hence the update-grub step fails too because it finds an incomplete set of boot files. Both steps must be done manually after the fact. However, thanks to the stable of virtual machines I keep on standby for just this sort of testing, I can confirm that, performing the same steps with Michael's .deb files in 12.04LTS, dpkg succeeds not only at the update-initramfs step (watch the scrolling messages in the terminal window or look for the resulting file /boot/initrd.img-3.2.21-xenomai+) but also at the update-grub step (again, watch the scrolling messages in the terminal window), so I needed to perform neither step manually in 12.04LTS. AW By looking at the output of ./configure I installed the following packages. I don't know if this set is minimal or optimal, but at least configure and the build seems to complete. Packages: build-essential autoconf libpth-dev libglib2.0-dev libgtk2.0-dev tcl-dev tk-dev bwidget libreadline-dev python-tk python-dev libgl1-mesa-dev libglu1-mesa-dev libxmu-dev MAH I would think you can achieve this a tad easier by: $ cd debian $ ./configure sim successfully configured for 'sim-Ubuntu-12.04'-'sim'.. $ cd .. $ dpkg-checkbuilddeps dpkg-checkbuilddeps: Unmet build dependencies: dvipng texlive-extra-utils texlive-latex-recommended texlive-fonts-recommended ghostscript imagemagick texlive-lang-french texlive-lang-german texlive-lang-spanish texlive-lang-polish texlive-font-utils asciidoc (= 8.5) source-highlight dblatex (= 0.2.12) xsltproc groff libgnomeprintui2.2-dev texlive-lang-cyrillic note the 'configure sim' part is just to make the debian directory happy, this is not adapted yet to be in sync with src/configure (and I would appreciate help on that) (those missing dependencies above I can live with until I --enable-build-documentation) Actually, Anders, now that I've checked on a pristine virtual machine, I see your list of packages is missing three libraries: libxaw7-dev, without which xemc won't run, according to the warning; libgnomeprinting-2.2-dev, without which one can't print from classicladder, again according to the warning; and libncurses-dev, without which I infer keystick won't work (does anything else use ncurses?). Watch the warnings scroll in the ./configure output. Of course, dpkg-checkbuilddeps will also list these missing packages, but I find it hard to notice a few non-docs-related files in a big list; besides, this approach offers no statement of what requires the missing packages. Obviously, LinuxCNC builds without these libraries; it just won't be able to do the three things I mention. FWIW I would consider this rtos work more important for a linuxcnc 2.6 release than the redis work that just seems to break the build and cause problems on 12.04/12.10. Errm. Let's review the bidding here. In a pristine virtual 12.04LTS host, I just built Michael's experimental LinuxCNC 2.5 based on his threads=xenomai-user configuration and his custom kernel. I then rebooted this host to the regular kernel, pulled the latest from the master branch on git.linuxcnc.org, and built a LinuxCNC 2.6.0~pre simulator. Neither build broke. In the first case redis isn't present, as Michael has already explained, but in the second case redis certainly is present. Where in the build are you running into trouble with redis on a 12.04LTS machine? I'd like to be able to contribute to debugging the problem so we can keep the ball moving forward, but I have nothing to go on. Regards, Kent -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] on the ARM builds
On 12/2/2012 11:22 PM, Michael Haberler wrote: just noting where we are on various ARM builds - ARM really because it is the only non-x86 platform I'm looking into and so I have nothing contribute otherwise And a very nice note it is, Michael. There's more factual meat in it than I have found on entire websites. Thanks. Skipping down... 5) Is the result usable? If you're pegging hopes to connect screen and keyboard to any of the current boards, be able to fire up Axis and determine it is as fast as the current PC/RTAI option: you are likely in for a bad surprise. Both Sergey and I found that the current code maxes out the main CPU to the extent that maybe 10, 20% CPU are left and that isnt good news. Note we both havent seriosly looked into profiling and removing any glaring bottelnecks; this is still to be verified. From my perspective, it is still early days. Sure, it would be great if eliminating a bottleneck or two turns out to be all we need to do, but I'm not holding my breath. Curiously, Plan 9 (the OS from ATT, not the movie from Ed Wood!) has recently been reemerging in the Internet consciousness. I don't think Plan 9 is the answer, but the outside-the-box thinking that went into its design is a model for the thinking I believe could emerge in LinuxCNC too as we see new opportunities in the ARM world. In diversity there is strength. Regards, Kent -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] xenomai + linuxcnc on 12.04LTS
On 12/2/2012 11:27 PM, Michael Haberler wrote in response to me: KAR ... Neither build broke. In the first case redis isn't present, as Michael has already explained, but in the second case redis certainly is present. Where in the build are you running into trouble with redis on a 12.04LTS machine? I'd like to be able to contribute to debugging the problem so we can keep the ball moving forward, but I have nothing to go on. MAH I just pushed a fix to the redis Submakefile in master an hour ago which I hope fixes the issue. There was an issue, but for reasons I dont fully understand it hid from me quite well. I just checked my local directory and git log includes your commit so indeed you may have fixed the issue. It's late but tomorrow I'll try rolling back the commit and rebuilding. Regards, Kent -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] proof of concept: HAL module/driver for Beaglebone/ARM335x PRU realtime coprocessor
On 11/30/2012 8:51 AM, Yishin Li wrote: On Fri, Nov 30, 2012 at 9:25 PM, Kent A. Reed kentallanr...@gmail.comwrote: On 11/29/2012 9:42 PM, Yishin Li wrote: Yocto might be useful for cross building. I've tried to cross build yocto for x86. It also supports BeagleBone. I don't have experience with Angstrom yet. -Yishin After Andy brought Yocto to our attention earlier this year, I quickly got it (version 6 at the time) running on an x86 Ubuntu system with the original BeagleBoard BSP (Board Support package to those unfamiliar with Yocto). When you say also suppports BeagleBone do you mean the Texas Instruments ARM Cortex-A8 development board (Beagleboard) https://www.yoctoproject.org/download/texas-instruments-arm-cortex-a8-development-board-beagleboard BSP or is there a specific BeagleBone BSP floating around? Honestly, I don't know enough to know if this really matters but the fact that we're working with the PRUs as well as the ARM core makes me wonder. Regards, Kent Per the Working with meta-ti, there's beaglebone.conf in the meta-ti BSP. https://wiki.yoctoproject.org/wiki/images/b/b3/Meta-ti.pdf Yishin Thanks, Yishin. Not having had the time to read all the Yocto documentation, notably the BSP Developer's Guide, I don't know whether a BSP gets down to nitty-gritty details of the board and passes compiler flags etc to the toolchain accordingly or if it merely makes it easy to wrap all the software resources in one blanket. My FINO (First-in, Never-out) stack contains many reading assignments like this one :) Joking aside, I have accumulated some limited-resource ARM boards and appliances for which I'd like to create custom BSPs and for which there are no member-sponsors in the Yocto Project doing the work for me. It's a nonstarter to build anything complicated, certainly not a kernel, directly on these boards; the CPU power and RAM size are just too limiting even if NFS gives access to adequate storage. When I had just one device, OpenEmbedded/BitBake worked well enough but once I started playing with more devices I felt like a one-armed wallpaper-hanger as I tried to manage the proliferation of directories and builds. I like that the Yocto Project came into being to deal with exactly this kind of problem. Regards, Kent -- Keep yourself connected to Go Parallel: TUNE You got it built. Now make it sing. Tune shows you how. http://goparallel.sourceforge.net ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] PCI Progress
On 11/21/2012 8:09 AM, Charles Steinkuehler wrote: I don't mind. I would have sent to the dev list in the first place, but I'm still figuring out what should/shouldn't be posted to the list. Oh, please! The reason you can't figure it out is we have no rulesjust a sense that this is where folks who care about the insides of LinuxCNC hang out. I'd rather get told to move the discussion somewhere else than not have the discussion at all. Regards, Kent -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Gladevcp+HAL standalone applications on Raspberry Pi: works
On 11/20/2012 11:40 AM, Anders Wallin wrote: Good news! I've ordered a Pi (Farnell re-directs to a local distributor), but the delivery-time seems to be 3 weeks right now(?) Good luck with that! Some six months ago I ordered an original (256MB) Series-B RPi from Allied Electronics here in the USA. It went out-of-stock there even as I was pressing the commit button. Two months later, I happened to catch Newark (now tied together with Farnell) showing them in stock and snagged one before they also depleted their stock on hand. Since that time everyone over here has been showing this same 3-week lead time. I suppose that means there is a container full of 512MB boards somewhere on the high seas. It seems that the SPI interface will be most useful for high-speed IO. If I understood correctly the Pi supports only two separate chips on the SPI-bus, but on IRC PCW mentioned that SPI is possible on the GPIO-pins also? For a servo-controlled machine I guess a microcontroller and/or FPGA on the SPI bus could read encoders, output PWM, and do IO. One would then need a HAL-driver that is capable of communicating the relevant data over SPI every servo period (1ms or so). Do you think this HAL2SPI driver will be easy or hard to write? What about stepper-machines? Is it enough to communicate a stepper velocity over SPI to dedicated step-generation hardware? I'm not a driver guy. I'm hoping that technical need or just good old-fashioned curiosity is motivating other folks to git er done RSN (Real Soon Now). In addition to cnc use I'm also interested in stand-alone operation with a touch-screen, for example this one (HDMI display, USB touchscreen): http://www.lilliputuk.com/monitors/open-frame/of701-2/ Something that boots directly into a Touchy-like custom UI-panel and can set/watch/plot/etc. HAL-signals would be really nice. This goal doesn't seem out of reach. I started on a similar project based on hacking an ARM-based Insignia (house brand of the BestBuy chain here in the USA) Infocast 7 touchscreen internet appliance. I seemed to be making progress, but it was strictly as a satellite Touchy talking via ethernet to a LinuxCNC machine. Family health problems have slowed me down considerably. Regards, Kent PS - Have you seen the Eaton HMi VU Operator Interface (http://www.alliedelec.com/lp/121120eaton/?utm_source=productutm_medium=emailutm_campaign=121120_product). It's too pricey for my blood but interesting in that it is basically an encapsulation of many of the features we talk about. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
Re: [Emc-developers] Preview: LinuxCNC 2.5 single codebase - supports RTAI, RT_PREEMPT, Xenomai-kernel, Xenomai-User, Simulator
On 11/14/2012 2:19 AM, John Morris wrote: While sitting around waiting for the umpteenth time for the Xenomai kernel to build, this time with Michael's config just to help narrow things down, I compiled up LinuxCNC xenomai-user. Latency-test works. And on the same kernel that, combined with xenomai-kernel, hangs! 64-bit uniprocessor running several glxgears (why's that the test we always use?), loading up Firefox with a buggy load of saved tabs, compiling that same xenomai kernel and spinning shapes around in FreeCAD, latency-test reported 7ms/6ms jitter. Sorry, John, I lost the bubble. What CPU/motherboard/etc was this? As for the silly glxgears test, I think the original intent was to use it as a quick exercise of the X/OpenGL/driver path and perhaps as a benchmark of the graphics performance if the path works (although graphics guys are quick to tell us it isn't a benchmark). For latency testing purposes, it might help smoke out problems with the graphics subsystem---some drivers and some chips grab hold of DMA for example. Obviously, we've not thought our way through anything resembling a proper test suite. Regards, Kent -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
