Re: preferred version of EMC

Terry:

> it may sound bad, but once the user understands
> the limitations of rtlinux and what to look for
> the entire system, hardware, linux, rtlinux, and
> emc can be made to work reliably and be stable.

No. That sounds great.

> hardware selection is probably the least understood
> item. there is alot of hardware out there that has
> bugs in the chipsets. these normally do not bother
> linux since most are understood to some extent. it
> is when rtlinux comes into play and takes over the
> interrupts that things get a bit strange/odd/unstable.
>
> to some degree this also applies to the cards
> that are placed in the computer. some cards have
> buggy hardware also, video cards are famous for
> their buggy bios, and "undocumented" features.

Give up the details. Does some sort of reliability matrix for common
hardware exist? Any support for choosing known stable hardware?
Particularly for the common denominator hardware, i.e. chipset combos
and video boards?

>
> linux is solid. the latest kernel in the 2.0.x series
> is 2.0.38. it is stable but will not support the newer
> hardware. the latest kernel in the 2.2.x series is
> 2.2.17. the latest development kernel is linux-2.4.0-test10.
> depending on the hardware a person has will guide which
> kernel they will need to use.

ok, this is what I need. Give it up EMC boy :)

> emc-0.9-25.tar.gz (sept 25th, 2000) release works rather
> well with linux-2.2.17, and rtlinux-2.2. i have some
> patches for rtlinux-2.2 which i need to get into
> emc sourceforge.net cvs.

What is "sourceforge.net cvs" ? Dunno the meaning.

> the bottomline is to test, test, test, and test again.
> before using the system to do any real "chip" making
> put the entire system through "it's paces". pound on
> it. run emc/sim.run, have the cd-player playing your
> favourite cd, surf the web, play a graphic intense
> game, etc. think of ways to load the machine down in
> such a way to force interrupts on every card, hard drive,
> cd-rom/dvd/cd-rom burner. watch to see if the system
> "hangs". find or generate complex g-code programs and
> run emc/sim.run. have the backplot program running.
> if you have more than one computer and a network
> ftp entire harddrives to another machine. (and yes,
> i do do that.) nfs mount filesytems from the other
> machine copy files to it, diff the files, erase the
> files, copy them back. the goal is to find if/where
> the problems are, and they will not be found unless
> the entire system is pounded on.

I plan to protect the EMC environment by dedicating the machine to
control only. I won't risk the interaction of additional processor
tasks. I'm attempting to install EMC, which has proved to be
difficult, because I believed it was a capable, well designed, FREE,
and proven system, in some release combinations. I continue to bore
the List, attempting to extract exactly which combination of releases
and upgrades I need to employ to build the most stable installation
that I can. All the while admitting that I am hobbled by a complete
lack of Linux experience.

>
> after all the testing, begin small, and watch the
> machine being controlled and the system like a hawk.
>
> the number one rule to follow at all times:
> is the machine being controlled and the computer
> system (hardware, linux, rtlinux, emc, etc) operating
> in a safe, reliable fashion so that the risk of personal
> injury is reduced to minimal levels?
>
> if the answer is no, go back to test, test, test,
> and test again.

Acknowledged.

>
> if the answer is yes, keep the system at the level
> and think of ways to improve the level of safety.

Thanks,
Ron