She Can't Take Much More, Captain

This has been a tiring week. I'm have two projects which require on site work and shuttling between them is getting to me. One project is a rebuild of an embedded PC for an automated labelling system I helped to develop in 2004. This is a production system so getting them running quite is urgent.

Getting an exact replacement SBC was impossible of course, as it was discontinued a long time ago and none of the distributors has any stock left. The replacement was chosen based on availability as much as for technical compatibility. In 2004, we were forced to use Red Hat Linux 9 because of proprietary drivers for a touch screen which only worked on that distribution. RHL 9 worked about as well as could expected on the replacement SBC, i.e., the kernel crashed as soon as it started!

After discussing it with my customer, we decided to forget RHL 9 and start from scratch. In 2007, I worked on a similar system which used Debian etch, so the OS doesn't really matter and the 2004 application can be recompiled no matter what. This direction has a much better chance of success, but it will still take some time to complete.

Needless to say the end user was not happy when they were given the bad news. They are getting ready to ship the games for a new product line that they recently announced. So yeah, to say that they were not happy, is putting it mildly.

CNC Porn

Here is a cool video of a 5 axis industrial milling machine making a replica of a motor cycle helmet out of single piece of aluminium (aluminum for the North Americans). Presumably the hobbyists haven't reached this level yet. Come on, you can just stick the machine in the garage. I know you want one, don't you? ^_^

The above links leads to a lot more videos which are equally interesting. I can't help but feel that, as impressive the machinery is, it's the software that behind the scenes that's making it look easy.

PCs And Automation

I was helping an automation engineer confirm that the components he had chosen, were suitable for his project. The reason he needed a second opinion was because the controller for the project was a PC, not the usual PLC to which he was accustomed. The components he had chosen were fine so his experience was enough to carry him through, even though he was outside his comfort zone. I wonder if the PC programmer, who doesn't have any experience controlling hardware, will do nearly as well. Depending on whether I get a call to help out or not, I'll have my answer.

This was a reminder of how uncommon my automation experience is. The majority of the automation projects that I've done, used a PC as the controller. Many people might recognise the small form factor SBCs as a PC, but except for the size, it had exactly the same functionality as a regular PC. These projects all had a significant data processing component, which is the main reason to switch to a PC. However, automation people are endeared their PLCs so the manufacturers have come up with many ways to push the data processing onto a PC via a network. Frankly these solutions start to look just as complex and risky as the PC only system.

PLC Programming Dilemma

I was at a customer today fixing a database problem, and they asked if I would help with some PLC programming. They know I can do so it is not a completely of the wall request. Now I need the work so I will probably end up taking the job, but I really dislike PLC programming.

One reason is that most of the programming techniques I take for granted must be thrown out. Take unit testing, for example. You simple can't unit test a PLC program without buying very expensive simulators. Well, if you run big bucks corporation, maybe it doesn't look expensive, but for my customer who is struggling at the other end of the scale, the pricing is out of the question. The problem is that, of all the PLC programmers they might use from time to time, I'm the only one who would actually use the simulator. Even the best PLC programmer I have ever known, had never even heard of unit testing. Testing? Just do it on the robot.

Another reason is that Ladder Diagram (LD) programming sucks. To me, it is just glorified assembly language and who uses assembler for complex systems any more? There are 4 other languages one could use. The graphical language called Structured Function Chart (SFC) is the most interesting. The Structured Text (ST) language looks a lot like Pascal. I've never had the opportunity to use any of them because LD is so entrenched in the automation industry that using LD will never be questioned. It is the risk free choice because you can guarantee that there be someone in the plant who knows LD well enough to tweak a machine. (OK, they might have some trouble with my non-standard programming style, but that's another story.) Fact is, very few maintenance staff will know the other languages.

Finally there is the plethora of different programming interfaces, one from each PLC manufacturer. Sometimes, I think they intentionally go out of their way to make the user interfaces as different from the competitor's as humanly possible. If you use them everyday, I'm sure you get use to it, but for occasional users like me, it is just a pain.

I will stop ranting now. I could go on about this all night. :)