in reply to Re: robotic laser welder
in thread robotic laser welder
The guts of this system is really a motion controller, which has a CPU and poor excuse for a programming environment for control, and a digital signal processor that takes care of motion control. The former is used for monitoring high speed inputs (like the anti-tiedown/anti-reset logic, and the joystick control during setup mode) and the latter puts the laser in the right place at the right time. The Perl programs merely make suggestions to the DSP on what the right place & time may be...
So the architecture is like this:
- The motion controller takes care of positioning and some high-speed input requirements.
- It communicates via Ethernet to a Dell PowerEdge server, running OpenBSD.
- The server runs several Perl programs:
- The main daemon establishes communication with the motion controller, and keeps track of whole bunch of predefined macros for "canned" moves. (I have learned to love regex.) It also does some rudimentary machine control, like watching for parts to be in position, and then running another Perl program, to wit:
- The path generation program calculates the location of the can in space, and generates the motion controller commands to follow that path (and pulse the laser appropriately). It gets its configuration information from a file created by:
- The operator interface program gives the operator the appearance of control, while mostly milking him or her for some setup data, and maximum productivity. This is a Curses application.
- If there had been more time, we had a hand-held serial terminal for the operator. But shipping interfered with production, so it went out with a monitor and a keyboard ;)
Parts of the program are ridiculously slow. The path generator puts out around 500 - 750 lines to STDOUT (slurped up by the main daemon; see Exec Fork Trick for how I did that) and takes about 20 seconds to calculate. I used three cartesian systems (one for the machine as a whole, one for each of the two tools), and a pair of polar systems (because the tools rotate.) There are multiple translations back and forth. (Actually, there are hundreds, just to find the path around the corner radii.) If I had remembered enough trig, I probably could have avoided tons of this, and significantly improved the efficiency of that program.
My original intent was to write the system in C, not Perl. (Yeah, --me on that point alone. I deserve it.) Various production delays brought me to consider Perl, though I had scarsely written more than 100 lines of it. It was still a good idea, and I started by writing everything in Perl for a few weeks before starting this project. (My prototyping on this project was implementing the MP3 Server and building an XMMS Alarm Clock, among other things. Not exactly traditional prototyping methods, but we still managed to get the job out the door.)
The biggest advantage to using Perl was probably the speed of development, even if my inexperience with Perl worked against me. Honestly, I found it much easier to debug and troubleshoot as well, and having such an incredible regular expression engine was valuable.
This application was not a terrifically difficult "real-time" application, though. Had I needed deterministic latencies and preemptive multitasking, I probably would have had to write it in C. I also would not have used OpenBSD -- I'd probably have built a LinuxPLC box instead, and possible even RTLinux or one of the similar projects instead. I'm glad I didn't need to. I like OpenBSD, and I like Perl.
A note on why this source got closed, despite my best arguments. My customer has built machines that went to Taiwan. His company (before he started the company I was working with on this project) took 6 months to build and program one of their machines, and he went to start it up. One month later the customer had trouble with the machine, and he was back for a service call. In that short month, he discovered, they had built a fully-functional duplicate of the machine, and programmed it - without documentation beyond the basics. Given that experience, he's a little shy about releasing the code for a project that is transparently understandable from watching the operation. Only the complexity of the code would prevent a knock-off. (Preventing a potential competitor from reading the code is a delay, not a preventative measure.)
This also gave rise to the introduction of OpenBSD to the application. Aside from the security advantages over Windows, using a UNIX-like operating system in this application was a no-brainer and an excellent choice. This gives us all kinds of potential for remote administration, plus a network gateway to the motion controller. We can do even firmware upgrades across the 'Net. Bonus. (Reminds me of the Cisco VoIP products running Win2k. They're getting infected with the Code Red virus. Hah.)
Well, that's my 4:30 AM overview. Hope it answers the question. In short, this project seriously sold me on the advantages of Perl.