- Bdi4emc-help - lists.ourproject.org

Re: Bdi4emc-help Digest, Vol 2, Issue 4
by Kent A. Reed 10 Jan '06

10 Jan '06

Paul wrote: >Message: 1 >Date: Sat, 7 Jan 2006 09:29:30 +0000 >From: Paul <bdi-emc(a)ntlworld.com> >Subject: [Bdi4emc-help] BDI-4.38 package list >To: "Help and advice for BDI-4 users." > <bdi4emc-help(a)lists.ourproject.org> >Cc: Abdul R Rafiq <arafiq(a)vitalsystem.com> >Message-ID: <200601070929.31054.bdi-emc(a)ntlworld.com> >Content-Type: text/plain; charset="us-ascii" > > >Hi Folks > >Updated the wiki with a new page listing *ALL* the packages on the BDI-4.38 CD >at http://ourproject.org/moin/Package_list - Note: Although both the kernel >and rtai sources are included, they are not needed for compilation of emc or >any other third party kernel modules (see the Nvidia page for details). > > Over the next few months, I'd like to see discussion on package candidates >for the BDI-4.40 release, perhaps even debate on what to drop to free up >space.. > > >Regards, Paul. > > > Thanks, Paul. Recall my mindset that the BDI is all about EMC1/2 and making chips fly. The first packages I would vote 'off the island' are those related to document preparation. These include packages such as and related to aspell, dictionary-common, kdict, kghostview, koffice, kword, gs, etc. Regards, Kent

1 0

BDI-4.38 package list
by Paul 07 Jan '06

07 Jan '06

Hi Folks Updated the wiki with a new page listing *ALL* the packages on the BDI-4.38 CD at http://ourproject.org/moin/Package_list - Note: Although both the kernel and rtai sources are included, they are not needed for compilation of emc or any other third party kernel modules (see the Nvidia page for details). Over the next few months, I'd like to see discussion on package candidates for the BDI-4.40 release, perhaps even debate on what to drop to free up space.. Regards, Paul. -- From the Klingon book of C: Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM.

1 0

Re: BDI suggestions
by Kent A. Reed 03 Jan '06

03 Jan '06

So then Gene wrote: >On Thursday 29 December 2005 15:21, Kent A. Reed wrote: > > > <yada yada yada> > >Following up on this train of thought, rather than provide the srcs, >provide instead a script that will download a known stable version of >a script to build emc or emc2, which probably is not the current >cvs/svn. That way, if a given snapshot builds and runs, then the repo >is frozen long enough to fine-tune the script, the script is added to >the wiki, and then the repo is opened up again, what, a day down the >log? > > Sure. That's why including source was way down my list. >>5) provide a running copy of EMC/EMC2 "out of the box." >> >> > >Nice for absolute gnubies, but really, by the time someone comes >looking for emc, can we not assume they know the basics of building an >app? The script itself should be able to handle the dependencies. > > > I was thinking more of the folks who'd like to invest the minimum effort required to take EMC for a test drive. Maybe the BDI-Live is still the answer for them., or maybe just exercising the different user interfaces in a scripted test harness would suffice. I'm old enough to have learned to drive when only stick-shift cars were used by the testers. I was all hands and feet, so to speak. With experience, complicated things, like hand signalling, downshifting, braking, and turning became easy. I think the combination of Linux, EMC, controller hardware, and the machine tool itself presents similar challenges even for folks who have either software or hardware experience but not both. It's comforting to know that major parts of the system already work. Judging from the questions I've seen posted to some of the cnc-oriented groups and to cnczone, I don't believe we'll ever go wrong by assuming the least. I'll bet most parties get interested in EMC because they want to drive a machine tool and not because they're Linux-heads looking for a cool application, so there's no basis for assessment of their computer skills. >Or am I chasing rabbits and barking barking at the moon here? > > > So what's wrong with that? Surely you've noticed the smile on the hound's face! >>Item 1 is the most important for me because I made up my mind early >>on that I don't want to get tangled up in the real-time kernel >>issues and debates. >> >> > >Neither do I, generally speaking, although this box is always running >the latest kernel from Linus that will run on this box, currently >2.6.15-rc7. Does that place me a cut above the average emc user? I >doubt it... > > I do doubt it. I've seen lots of experienced Linux users never upgrade the kernel that came with their distro even when they religiously run up2date or its equivalent. There's an unspoken fear that they'll screw up the works if they start playing with the kernel. In the old days, this was a realistic fear. These days, the upgrade tools are so well integrated and automated that it seems like a no-brainer to override the default setting not to upgrade the kernel. >>As for editors, I had no problem coping with your solution when I >>installed my BDI. I just downloaded and installed the editor I >>wanted. Between me, my staff, and various visiting professors and >>students, we've tried them all on my systems at work. I never met an >>editor I couldn't complain about :-) >> >> > >Neither did I, which I guess is the reason I tend to stick with what I >know on linux, vim. Or occasionally gvim. I'd like to see the last >version of CygnusEd that was published for the amiga ported to linux, >that was to me, the ideal editor of all editors. The vi/emacs debate >would be noise I could cheerfully tune out were this to happen. >Unforch, a quick check with google fails to even find it for sale to >run on an amiga today. Sad state of affairs indeed. > > > Well, I wrote but then deleted a long section in my first reply that argued for inclusion of a vi-compatible editor because of its "greatest common denominator" status over the decades I've played with various Unices and Linux. It's hard to teach an old dog new tricks! If you're a true Amiga fan, why not install "Amiga Forever" on your Linux box to emulate the Amiga OS so you can run CygnusEd :-) I never got into the Amiga fan club but I've got a colleague at work who still hasn't gotten over the forced retirement of his Amiga video toaster. >>Just my 2 cents worth. I am already on record as being completely >>satisfied with the effortless install of BDI-4.30 on several >>different cpu/motherboard combinations so all this is in the nature >>of counting how many angels can dance on the head of a pin. >> >> > >Humm, now thats a question I never felt it was our lot to know the >answer thereto. :-) > > That's what makes the argument so much fun. Nobody can ever win. Regards, Kent

3 3

Re: subversion etc.
by Kent A. Reed 01 Jan '06

01 Jan '06

So then Paul replied: > >Hi Kent & Gene > >On Thursday 29 December 2005 20:21, Kent A. Reed wrote: > > >>At least on paper, subversion looks great. If Source Forge is going to >>migrate to it from CVS, then it sounds like your hand will be forced >>soon enough. >> >> > >If the EMC developers decide to switch to subversion, I fear they will be >shooting themselves in the collective foot. Quite a few users and developers >are running RH-7.x systems, and there are a considerable number of RH-6.x >installations to boot. Whilst there are subversion.rpm packages available for >RH-7.x, you have to go digging for them. For the many running RH-6.x boxes, I >suspect the situation will be much worse. > > > "Gee,' I thought, "even Cygwin offers subversion, so how hard can this be?" Then I did some digging at sourceforge and elsewhere and decided you are right. Yikes. I'm in agreement with Gene, though. I wouldn't want to let an older RH system near the Internet. I guess the folk who do are using firewalls and NAT, etc., and hoping that between that and the lesser status of Linux vis-a-vis Windows, hackerwise, they'll achieve "security through obscurity." My experience at work, where we have something on the order of 10000 computers and pretty good resident packet-police, suggests this approach isn't good enough, but everyone has to do the cost/benefit analysis for their own situation. Maybe I lean too heavily toward security because I've had too much experience cleaning infected machines. >I've not done any significant work with the old EMC tree for the best part of >two years now. Most of my efforts have been in a branch of emc2 - The EMC >version found on the BDI-4 disk is the result. Although both head and bdi-4 >branches share much code in common, most of the user space code is identical, >as are core parts of the RT modules, the bdi-4 branch does not use the HAL >layer. Think of the BDI-4 build as a staging platform for the time when >(if ?) emc2 becomes stable enough for widespread use. Although from what I >hear, emc3 may be just round the corner. > > > And the payoff for me is that you've already done this so I don't have to, just as you've already worked out the details for merging the RTAI with the Debian distribution. One of life's lessons for me has been to stop saying immediately "I can do that" and start asking "who's done it" so I don't have to. When I made my comment, I wasn't thinking about the different branches, only about EMC vs EMC2 as nominally fixed vs. still evolving applications. I confess it isn't clear to me what achieving a stable EMC2 would mean for the BDI. Do you mean you could retire all EMC1-specific code and build EMC2 strictly from the sourceforge head branch, and/or something else? I really like the people who are developing EMC, but your last two sentences in the above quote worry me. I've been involved in a number of major IT standards developments where core developers could not resist starting a new version before the ink was dry on the current version's release candidate (futureware is always more fun than presentware). As long as the EMC developers continue to use their evolving product to make chips fly, this probably will be ok, but if they let the perfect become the enemy of the good, it could end badly. The marginalization of the perfect ISO/OSI communications protocols by the wart-covered TCP/IP protocols is a good example of what I mean. Regards, Kent

2 1

kernel source
by David Szakovits 30 Dec '05

30 Dec '05

the bdi-4.38 install went well for me, except networking. in the past i have used the NFORCE drivers from nvidia to get the network card to work. i have downloaded the latest files from nvidia, but the when i run the NFORCE install script, it complains that it does not have a precompiled driver for my (BDI) kernel and that it cannot find the kernel source so it can compile. i cant find the kernel source either! i presume i will need to use anonymous cvs to download the kernel. but i am not sure where this is hosted (and what module to specify). i am stuck for the moment, can anyone point me in the right direction.

3 3

Install Help please
by Arthur Butler 30 Dec '05

30 Dec '05

Hi. Thank you for working on these programs. Unfortunately I'm having trouble installing the BDI 4.30 version. I'm not a complete newby, have used Redhat, and now Debian on other PC's. I've checked the md5sum of the iso downloaded, and of the CD itself. I've turned "detect virus by trend" off in the bios, and am using LBA mode for the 40G hard drive, and reburnt the CDRW to a CDR just incase, all as suggested in the FAQ. The install starts fine, all packages are then installed, but when the screen saying "post install config" or something pops up it crashes. The PC I'm trying to install on is a 500MHz AMD K6II processor, with 128MB RAM. I think there was a problem with BDI on K6 processors, but think newer versions of BDI are OK. I'm trying to use LVM too, with my own partitioning scheme, based on that I've used on my desktop PC. I'm trying the graphical install since there's a problem with text installations mentioned in one of the docs. I've been testing the memory and hard drive incase they could be faulty, but haven't found a problem with 13 hours of memtest86+ and full drive scan using badblocks destructive test. I'm just setting an "automatic" install running incase that works. I like lvm though, so it'd be a shame to loose that. If I can get it installed I could then set up lvm on another drive and move the install.... I've looked at the install.log and install.log.syslog files by booting the PC using Knoppix, the first lists 475 packages, the second lists user creation commands, which I think must have failed since I don't have any user directories created under /home. Well, the "automatic" install works a little better, at least it boots, but the user account I created doesn't exist, so I cannot do a graphical login-root is blocked. Logging into a command prompt I've looked again at the log files. install.log this time has the list of packages installed, then those available which weren't installed, then says: Changing configs on 23-12-2005 User name not found - anaconda bug ? root login not allowed by kdm etc.... I'm wondering about trying either a minimal install with lvm, or running the upgrade script on the partially working version. Anyway, I wonder if you might be able to investigate this further for me? I can supply any other details/files you need. I'd like to try emc out-and this has unfortunately been a fraustrating start! Happy Christmas, Arthur

2 2

Re: BDI-4.38 suggestions
by Kent A. Reed 30 Dec '05

30 Dec '05

Paul, et al. [<gently ribbing on> What? 4.38? Already?</>] At least on paper, subversion looks great. If Source Forge is going to migrate to it from CVS, then it sounds like your hand will be forced soon enough. I lean toward Gene's suggestion that you postpone including it until it's needed for updating EMC2 from Source Forge, but you know better what including it now or later entails. The recent discussion of features to be included or excluded suggests to me that you have some conflicting requirements for the BDI from your clientele. In descending order of priority, my desiderata are (writing EMC/EMC2 as if they were one animal, which of course they aren't): 1) painlessly install a Linux with real-time extensions on which EMC/EMC2 will run 2) provide the resources to update/maintain this real-time Linux, preferably directly via the internet, but indirectly through a transfer of packages via CD or flash drive is acceptable if it can be managed easily 3) provide an environment in which I can build a running copy of EMC/EMC2 from source. 4) provide the source code for a stable version of EMC/EMC2. 5) provide a running copy of EMC/EMC2 "out of the box." Item 1 is the most important for me because I made up my mind early on that I don't want to get tangled up in the real-time kernel issues and debates. Item 2 is next most important because there are always updates and patches to the kernel and surrounding modules and libraries coming down the pike. In principle, my EMC host will never be exposed directly to the Internet but it is exposed to the other hosts inside my firewall and I like all my hosts to be secure just-in-case. Item 3 is next most important because it means I can build an running copy of EMC/EMC2 from source that might be provided with the BDI or that I download / update from Source Forge. Obviously this requirement is more important for EMC2 than for EMC since, quoting from the Wiki, the latter is "...the old stable version and no major improvement will be done here." In any case, I believe you should provide an environment that can build the same executables you might choose to distribute. This is the essence of the open-source movement. Items 4 and 5 are at the bottom of the list because I can download and build a running copy of EMC/EMC2 myself if the system satisfies items 1, 2, and 3. It would be nice to be able to exercise EMC/EMC2 immediately, as I did when I first got hold of BDI-Live a year ago, but I don't mind having to build it before I run it, so I ranked the provision of source code above the provision of executables, and it is included only because then I could build a first working version even if the Source Forge servers were temporarily unreachable or the EMC/EMC2 source code on the servers were temporarily corrupted, both of which have been known to happen. Based on my list, you can dump anything from the CD that doesn't directly support building and running EMC/EMC2. If this gets sticky because of the requirements of others (as you put it, "The inclusion of subversion in the BDI-4 builds is primarily for the people that use BDI-4 for non-EMC development."), then you could push all the EMC/EMC2 stuff to a second "application" CD and still meet my needs. Indeed, you could simply leave off all the EMC/EMC2 stuff and still meet my irreducible need. Like Gene, I consider all my open-source software and practically everything else to be just an Ethernet cable away. The other end of that cable is either a cable modem at home or the equivalent of a T3 service at work, so I don't flinch from downloading what I need (I downloaded BDI-4.30 at home without any difficulty and from an overseas server to boot). Whether or not it all fits on a single CD isn't so terribly important any more, since we're not trying to run from it, executing an unattended install from it doesn't seem to be a requirement, the discs are cheap, and recording them no longer takes all afternoon. From my prespective, a network install of everything from a remote server would be fine (but, oh, what a headache for the poor guy providing the network servers). After all, we're basically doing that now when we install or update EMC/EMC2 from Source Forge. As for editors, I had no problem coping with your solution when I installed my BDI. I just downloaded and installed the editor I wanted. Between me, my staff, and various visiting professors and students, we've tried them all on my systems at work. I never met an editor I couldn't complain about :-) Just my 2 cents worth. I am already on record as being completely satisfied with the effortless install of BDI-4.30 on several different cpu/motherboard combinations so all this is in the nature of counting how many angels can dance on the head of a pin. Regards, Kent

3 3

problem with BDI 4.3 and ppmc
by beaufait＠mchsi.com 29 Dec '05

29 Dec '05

We are working on a Bostimatic using the PPMC card set We are running BDI 4.30 We have everyting connected, ran the ppmc diagnostics and everything works fine When we run EMC we have all the DIO working, ESTOP, MachineON, Limits, Etc. we have tested the encoders by moving them by hand and they work in EMC and display the right movements When we try to move an axis EMC errors off with a follow error. We have checked and there is no voltage being sent out of the DAC card from EMC. It works fine with the PPMC diagnostics. Just noting with EMC. Anyone running EMC BDI 4.3 with PPMC.

3 3

BDI-4.38 released.
by Paul 29 Dec '05

29 Dec '05

Early christmas present - BDI-4.38 is up for testing at: http://www.cncgear.com/EMC/BDI/ http://mirrors.neuron.com/emc-bdi/ Noteable changes include: * A new set kernel of kernel packages built against the up coming RTA-3.3 release. * The mini GUI has had a new editor module built in, along with a few bug fixes in the background. * Axis, the python based GUI has been rebuilt from a recent source tarball. * Several base packages have been updated from Debian-Security. If you already have a recent BDI-4 install, all the updated packages are available with apt-get. There is no need to do a complete fresh install ! Regards, Paul.

1 0

BDI-4.38 suggestions
by Paul 27 Dec '05

27 Dec '05

Hi folks Working on a few minor issues related to the kernel packages, in particular, the need to have to mess around with the kernel-source tree before compiling any modules - An upgrade on the main build system has resulted in a shiny new set of key packages. The rtai-dev and kernel-headers packages are the only prerequisites for compiling kernel modules now. The change in the way kernel packages are produced has introduced a name change (kernel-image-2.6.12.6-magma is now linux-image-2.6.12.6-rtai) along with an increase in size for linux-headers-2.6.12.6-rtai (up by 1.4M). This is offset by dropping kernel-kbuild (355K). Mumblings from other quarters would suggest the addition of subversion to be useful, however, this adds another 1.4M to the final ISO. Along with the increase in size of the kernel packages, I'm at 630M for the ISO.. Question: Is subversion worth the additional space, should something be dropped in it's favour, or should I forget about reserving space for emc2 ? Regards, Paul. -- From the Klingon book of C: Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM.

2 3