Hi

Being an electrical engineer with some electromechanical experience; I can tell you that what you're trying to build cannot be built without some knowledge and experience in this field.

Simple research on the net alone will really take a LONG time for you to get right. You really need help from someone who has extensive experience in PLC programming, automation and control systems perhaps.

Good Luck

Hey, I like your "can do" attitude! Something to do with being a Kiwi? Great country, great people -- just a little on the cold side for me.

You've got a steep learning curve ahead of you but why not if you want to do it and have the determination?

PLCs are the old way of doing such control but PCs are way more versatile.

Good luck!

EDIT: PC stability will be really important for this so Slackware is a good choice even if it's harder to learn at the beginning. For production, it will be worth the extra price of reliable, good quality hardware -- perhaps with hardware redundancy in hot-pluggable PSUs, disks etc. and a conditioned power supply if you have big motors starting up hard.

Here's a few links to start:

http://www.orchestracontrol.com/

http://orca-robotics.sourceforge.net/

http://dros.org/

http://www.ros.org/wiki/

Do you have knowledge of the existing PLC code? Is it your aim to replace the role of the PLC with an embedded system? Do you have some sense of what kind of IO controller you will be using? What is your motivation for doing this? Is the Linux system intended to perform the role of IO control only, or also as an operator interface? Why have you chosen Linux, a priori (ie. there may be a real-time requirment for such an application)?
--- rod.

Unless you program get used to having goals of maybe learning bash, shell scripting and otherwise being a fluent Linux user. Without programming knowledge the learning curve is steep.


1. Setting up your proprietary O.S for a dual boot computer. (Unless you have a Linux expert at your side it is not feesable to have it as your solitary O.S for a year or so).
2. Learning to navigate on your new O.S with the use of menus.
3. Learning how to use your package manager and install the programs that allow the basic functionality of your proprietary O.S but with out the shackles and chains.
4. Learning the basics of using Bash and the purpose of having a built in interpreter. I'm still foggy on the latter part.
5. Going to another planet and learning how to install non native programs on your particular system. Expect to use the same amount of resources on learning the Makefile and AutoTools as you have on your ENTIRE education.(Not much distinction is made between Make being a program its self and it also being data for the Make program which is ridiculous).
6. Understanding the basics of programming in a particular language.(This one is covered pretty well).
7. LEARNING HOW TO USE YOUR COMPILER. I'm currently at this step.
8. Trying to find simple and basic programs to learn how all the parts fit together.
9. Writing your own program.
10. Learning how to install your own program using the package manager.


Windows Xp home sucks. XP pro is respectable but is not the internet machine that Linux is. When I help people with XP home, I can't get used to how ridiculous it is.

Comments by annotation above.

While I agree the learning curve can be steep, it is definitely doable by a person of reasonable intelligence. No programming eperience is necessary. Period.

I switched from XP pro about 2 years ago and never looked back (I keep a small XP partition on my desktop for gaming, which I hardly ever do). The extent of my programming experience is limited to very simple BASIC in the '80s (I had forgotten most of this way before I made the switch), and simple ladder logic PLC programming on allen-bradley and koyo PLCs (I had to figure out how to program an ancient GE fanuc PLC once using a microcassette recorder for data up/download *shudders*; I think I mentally blocked this, I hardly remember it )

Knowing some programming may put you ahead in the game, but a lack thereof will not doom you to losing. Shell scripting is not that hard to grasp, once you get used to the command line.

Learning how to install and use an operating system comes in stages. For me, when I started with Linux in 1995, before I did so I spent a fair amount of time, first reading a variety of opinions on what was available and what worked well at that time. In 1995, I already had about thirteen years of experience installing, configuring, managing, administering, and programming on UNIX systems, plus I had already used a lot of GNU programs that had been written up until that time, so I had the advantage of knowing the utilities once the system was installed. What I did not know at that time was how to install the software properly.

It turned out that if I were simply installing the software on an empty system, it became a series of "Enter" responses to most screen prompts, taking defaults unless there was a good reason to do otherwise. In my case, I bought my first home computer in 1995 and for the sake of knowledge and background, I wanted to run both Windows and Linux, so I could later tell people about "dual booting", and later, multi-booting. The books that I was able to acquire spoke only of working with Windows 3.1 and Linux, so I was careful to order a system with Windows 3.1.1, which had "Windows for Workgroups". Later, once I knew it worked, I got Windows 85, which came out in August of that same year.

The software I chose was Slackware, and I learned about it by purchasing a book that Patrick Volkerding himself co-authored with two other writers. They explained how to create boot and root floppy disks way back then, and in effect, how to bootstrap load the system. Things are MUCH EASIER than that now.

I also had to contend with the fact that my video card was not supported with the old software from the book that I was using. It turned out, however, that there were drivers available for my video card, so I got them from another machine, put them on a floppy or two and loaded them.

I did a lot of research. It was installing and configuring the system I wanted to make sure that I understood, and it was a good thing I did that, because back in 1995 things were not always clean and automatic, especially with graphics cards and network configuration. It helps to either know the basics about such things or at least know where to find quick answers if you need them.

Regarding physical controllers of one type or another, whether mechanical controllers or electronic controllers, I am not an expert in them, so my comments are certainly not definitive. Consider, however, that the number of operations a typical controller can do are fairly limited - we are not likely to see hundreds, much less thousands, of core operations, though I suppose the number of possibilities, based on the parameters that are variable could add up. The main thing would be to learn the control language, the core set of operations and the intended results.

Doing all of this could be a daunting task, but breaking it down, one by one, may not be as difficult as you might think. The difficulty is simply that there is a lot to learn. The biggest challenge, then, is to learn what things are necessary to acquire and learn, figure out how to pare out the details that you do not need to know so that you can focus on the key things.

Something tells me that ultimately you will want some kind of either real-time or embedded system. The Linux kernel is flexible enough that there are special purpose real-time and embedded systems based entirely on Linux. My thought would be to gain some basic Linux familiarity by fooling around with a few reasonably easy to use systems, then gravitate to what you will need to eventually create and solve your solution. A Live CD based system will give you a gentle introduction to Linux, which will not be an all bad thing. You may ultimately want to use one for every day, general purpose use anyway. If you want to dive in heads first, where you pretty much HAVE to learn something, or else it just won't work, then something like a Slackware, or even Arch Linux, could be the kind of baptism that would force you to have the discipline to read and learn.

As you learn about the simple basics of a Linux system, somewhat concurrently you may want to start researching control systems and what kind of system software they work with. That could ultimately dictate a lot about what your choice will be, unless you choose to program the thing 100% yourself at a rather low level.

I hope this gives you some ideas about what you will need to research and learn. Reading and studying first, and asking questions when what you've read either is unclear or you want to confirm what you think you have learned, and try stuff out, being willing to make errors, are excellent ways to gain practical learning. Enjoy the ride. It will take a lot of work to get good at this. It will be very satisfying, assuming that you pursue this to a successful conclusion.

Sound like it beyond just modifying the machine, sounds like a redesign of the machine. You need to hire a electrical engineer and a programmer.

Check out the package robot-player. It's in the Debian repositories.

use a high end linux distro (one with all the bells and whistles)

look here ----> http://www.hexwax.com/Products/USB-FileSys/default.aspx

it is a pic micro that is coded to behave like a flash drive (it shows up as a USB memory stick, and the PICMICRO is controlled by reading/writing files to the flash device, just like the /PROC directory in linux.
the pic micro can now be interfaced to the motors and sensors on the machine) where there are plenty of control boards that can do this.
there are plenty of consultants on the internet and I am sure there are some in your local area, but I have struggled for years using windows to control hardware and it is shit, LINUX is the choice of all serious embedded designers... even my toshiba flat screen tv has a gnu license stored in the help menu cos it has linux in it.

graham

Thanks for a considered and interesting post

Definitely the system will have to be real time but what are the decisive advantages of embedded? What about using a standard PC as both the operator console (displaying relevant metrics) and as the controller itself? A standard PC compared would be (slightly/significantly?) more likely to lose connection than an embedded system but real time systems with their remote sensors and controllers have to be designed for that anyway -- and to "fail safe" on loss of connection.

Cassette tape was better, but entering the bootloader via toggle switches was not my idea of a good time.

1 members found this post helpful.

Advice for learning Linux: go down to your favorite large bookstore and purchase the latest copy of the Ubuntu Linux Bible, Fedora Linux Bible, or some similar book. Not only will it come with an installation DVD, but the book itself will contain enough info to get you started with Linux. The idea here is to get a very recent book so that the included distro is still being supported

1 members found this post helpful.