It's been a couple of weeks since I've run VisiLogic - that's a bit unusual for me lately, since I generally don't go a day without doing something or other on a Unitronics system. The reason is that I've been spending my time on two of the nation's newest mobile HDTV production trucks, installing control systems which combine an embedded Linux computer with networked frames of Mitsubishi PLCs and a cross-platform PC GUI written in Perl/Tk.
Working as a controls systems integrator has its benefits - a fair amount of travel, exposure to lots of different industries, the ability to pick up the occasional cool story - when I meet someone new, one of the most common questions I hear is "Controls Engineer, huh? How'd you get that job?" The answer I give is, I admit, a bit cryptic: "I was a Television Engineer for ABC Networks in New York." That leads into its own story, which I'll try not to make too boring (and I'll bring it back to Unitronics territory at the end):
You've all seen a TV Camera with a red light on the front, right? Well, did you ever stop to think how that red light knows when to turn on? Back in 1985, our engineering group at ABC was presented with a problem - we were installing a new little TV studio which would allow us to feed different programming and commercials to different sections of the nationwide ABC network. This meant that for the first time, more than one studio could be "On The Air" to network at once, and the red lights on dozens of cameras and hundreds of TV monitors would need to react accordingly. (Today, that's one _small_ truck worth of gear...)
The technology we used to turn those red lights on was bank after bank of slide-matrix switches - all set up by hand for each show, and all physically wired to the various devices, which all had to have compatible voltage levels (or have frames of interposing relays). Our quick calculation of the number of those switches required to get the red lights to do what we now needed them to do pointed out that the matrix switches would take up all the room we had reserved for the actual TV monitors, plus another rack or two. Time to look for another answer, as finding a bigger room wasn't an option.
One of our engineers happened to be looking through a trade magazine and saw a new device from Mitsubishi - a "Programmable Logic Controller", or "PLC". It could have hundreds of inputs, and hundreds of outputs, and had a CPU which could read in the inputs and control the outputs. This would allow us to replace seven or eight racks full of matrix switches with a frame which could mount under a console, and be controlled by that new thing which I was one of the department experts on - a "Personal Computer" (this was just before that mainframe company got into the PC business.) We could also save patterns to floppy disk and load them back up, saving many hours of setting up and checking out the tally light configurations.
Well, the software turned out to be much more of a project than we had envisioned, since we were trying to emulate a matrix switch with tens of thousands of crosspoints - more crosspoints than the controller had memory to store. I tried saving a compressed matrix pattern as data tables in the controller's memory, only to find that it took so long to scan the data tables that the red lights would only update every few seconds - far too slow for the precise timing of television production. The eventual method I used was to reverse-engineer the language used to program the Mitsubishi controller, and have the personal computer software write its own PLC program and download it to the controller - something the manufacturer didn't support, and wasn't sure would even work. But work it certainly did - that system was the first of a whole series of PLC installations at ABC networks, and PLCs were deemed by the engineering department to be the most reliable equipment in the entire plant.
Eventually I moved over to work for the distributor we had bought the controllers from, and who had helped us get un-released components and untranslated documentation via air cargo from Japan in order to make a PLC do something that was considered impossible. That distributor was Howman Controls, and twenty plus years later, I still work here, and we still do some off-the-wall projects, and we still make Tally systems for the broadcast industry using Mitsubishi controllers.
However, this latest installation has got me thinking - what if I were to use a V570 system instead? Although the PLC frames don't currently have any operator interface device at all, if we used a Unitronics I could provide a diagnostic display allowing for easier installation, testing and troubleshooting. TV trucks take an amazing pounding as they drive around from venue to venue, and it's not unusual for interconnecting wiring to fail, or connectors to become dislodged - having a readily accessible display would be a great feature, and given the difference in pricing between the two PLCs, it's essentially a free feature.
PLC to PLC networking is also a built-in on the V570, so that would now be standard instead of an extra-cost item. The faster processor and native data-table handling bypasses the need for the reverse-engineered PLC programming trickery I've used in the past, and the availability of ethernet and RS-422 communications would let the Unitronics communicate with the various routing, control, and display devices on the truck, potentially giving smaller installations the same power as our current Linux/PLC hybrid top-of-the-line systems. I can see there's going to be quite a bit of R&D work in my future...