The shoe on the other foot......
Disclaimer: This posting is from the Marketing Manager responsible for the Steeplechase VLC, Think & Do software products and other Automation solutions from Phoenix Contact. Phoenix Contact purchased Entivity, Inc (and the Steeplechase VLC and Think & Do software products) to create a USA based software resource with products and control software applications based on PC based technologies.
Obviously, it looks suspect that my first posting on this forum is to respond to a criticism of one of our software products. However, I thought the members here might appreciate a candid response of these observations from inside our company. I have attempted to be as honest and “non-salesy” as possible in my comments. Phoenix Contact is currently investing heavily in both Steeplechase VLC and Think & Do. We are committed to providing software solutions that exceed our customers expectations. The only way we will do this is by hearing both the good and the bad experiences from those using our products. As such, I welcome any feedback, comments, questions or recommendations about future functionalities that we might provide with our software and automation products.
Magicsmoke, Paully’s5.0 and alanMICS - Thanks for your business. Please let me (or your local Phoenix Contact salesperson/distributor or tech support) know if we can ever be of any assistance.
And Magicsmoke, I can definitely recommend you attend our training class in Ann Arbor, MI. (I typically say pick a warm month, but being in MN you're likely used to the cold) We do have a lot of product training for general products in our facilities in Harrisburg and Houston (and at regional seminars), but we only do the main training for VLC/T&D in Ann Arbor. The main reason for this is that it is where the developers are located. Some of them have been with Steeplechase since the very beginning over a decade ago, and are still located there. I tend to think having them in the same facility, and at the occasional access of the training department while teaching a customer training, says something positive about the very open dialogues we hope to maintain with our customers, from the training room, to tech support and over to the guys writing the source code of the next generation product in the room next door. (That is something that definitely not all software companies can say anymore……)
Tim - You make some interesting observations. In response to your points:
1. Obsolescence. The motion cards we used in these systems were obsolete a year after we bought them. Since it's a 12-axis system, it's not so simple to replace them with anything else. We treat them like they were made of platinum - or maybe plutonium.
Steeplechase was one of the original PC-based controls company. At that time, the company was an independent software company with no hardware affiliations. The whole concept of PC-based control and open automation was to integrate “best in class” of hardware and software to create control solutions that were either not possible or were too cost prohibitive with PLC architecture. As such, Steeplechase created drivers that would communicate with the hardware of various 3rd party vendors. Hardware obsolescence is a problem in both the PC-based control world as well as the PLC world. However, because improvements and changes in PC hardware typically occur several orders of magnitude faster than in PLC hardware, obsolescence of 3rd party hardware also takes place much faster. This is something that is out the control of an independent software company.
Now that the Steeplechase VLC product is part of Phoenix Contact, we are and will continue to provide more complete Phoenix Contact solutions.
Our experience in the open automation world is that 'the component with the most mystery always gets the blame' and the component with the most mystery is always the software.
2. Software incompatibilities. Never, ever, EVER upgrade the OS the machine shipped with. When these were on our network, security "fixes" pushed from our corporate site KO'd them twice. Not suprisingly, we had to remove them from the network, not only the prevent the knock-outs, but because without the fixes, they turned into virus farms in short order.
One of the differentiating features in the underlying architecture of the Steeplechase VLC product, is a real-time, deterministic operating system called Intime. This RTOS was developed by Intel in the 1970's and exists in millions of embedded controllers. When running on a PC, it provides a segmented memory space for the control logic and ensures deterministic performance regardless of what Windows is doing. It also provides protection from what is known as the Windows “blue screen of death” fault, which was very prevalent in the Windows NT 4.0 days.
During the NT 4.0 days, the Intime RTOS would replace the hardware abstraction layer (hal.dll) with it's own. Subsequent MS Windows OS updates would replace the Intime hal.dll and this would indeed pretty much render the PC unusable. Fortunately, the Intime product has evolved to the point where replacing the hardware abstraction layer is no longer necessary.
Not only that, but if you do get one of their famously cryptic error messages, good luck with that - the VLC guys will blame the drivers, the drivers will blame the OS, and Microsoft will simply ignore you because, hey dude, they're Microsoft.
Admittedly, we could do a better job with the errors that come from our I/O drivers. This is something we are working on.
In our defense, we do think that our tech support people are very good at translating the errors and we are always making a conscience effort to improve the error messages. (And again, I do take a note of pride here in that our tech support personnel -on all our products- is not an outsourced call center.)
When you are a company with a PC-based control software product, you find yourself assisting customers with the troubleshooting of not only your own product but everything else that runs on the PC as well. Admittedly, sometimes certain problems are Microsoft related and out of our control. In these situations, we do our best to provide a work around that is satisfactory to the customer.
I should point out that you don't run into this issue with Beckhoff products. Since they make the units stem-to-stern, they take all responsibility for it's behavior when component pieces won't play nice. And no, I don't work for Beckhoff.
Any Beckhoff product that runs in a Windows environment has to face the same issues that every other software supplier faces.
However, I definitely agree with you regarding the customer benefits of “one call to make” vendor support for when components don’t work together as promised. With the acquisition of Entivity, Phoenix Contact is committed to taking responsibility for all aspects of a Steeplechase VLC/Phoenix Contact solution. Obviously, we cannot retroactively modify or take responsibility for legacy installations with third party vendor equipment, but I do believe our latest introductions of VLC-based embedded products on Phoenix Contact manufactured hardware to be very good examples of this philosophy.
(--continued next post--)