motion guru

I am curious if anyone here ever looks at employment opportunities when honestly looking for a new job.  I know recruiters look here based on previous job posting efforts - our experience with recruiters has been spotty at best.  Before posting another job here, it would be good to hear whether or not people actually seek employment opportunities among these posts. Thanks, Ken Brown

We landed one talented engineer - still looking for another . . . http://www.appliedmotionsystems.com/careers/systems_engineer

After two years of slow but steady business - this year has picked up dramatically for us. We purchased part of another integrator who has gone out of business and we need to make a step change to take on a family of motion intensive systems. We helped this integrator develop this product family and sold them the basic components to manufacture these systems - as such, we can support it well - however, we need to deepen our engineering bench to properly deal with new orders and requests for software updates. We presently have an ad on Craigslist -> http://portland.craigslist.org/clk/egr/1841784858.html If this sounds like something you would enjoy doing - (motion control / PLC state logic / HMI development) . . . we have a good team of engineers and we are looking for the right person to join that team. Experience with Siemens Simotion / 840D CNCs a plus. Thanks

Our market focus is coordinated drive systems and this is a fairly common web converting application that we have done for a number of customers. Our approach in the past has been to gut the DC drives / motors and replace with ACVector and deploy all new draw / tension control algorithms. The Machine already has an Allen Bradley PLC for state logic and draw / tension calculations and this data passed to the Series 6 PLC via a serial connection. In this case, the customer does not have the budget to replace drives / motors / PLC / HMI. Their Achilles heel is the Series 6 PLC. I would rather put something in that we know works and that can be used later with new drives (DC or AC depending on budget) without throwing any of the investment away. I am confident that we can manage the coordination of the motors with any number of controllers - at this point, we would prefer to simply give the drive an analog velocity command (or torque command - which would keep all the tuning in the central controller) and close the velocity loop using the encoder feedback external to the drive. If the DLAN network connection was open - and you could purchase a LAN card that slipped into a Logix PLC rack, this would be a slam dunk. . . but since it appears to be closed and they want to get rid of the Series 6 PLC - we will look for ways to manage coordination of the motor shafts with a separate controller and "hopefully" interface with the drives via. an analog Velocity or Torque command.

I was able to get a few photos of the cabinets and a better estimate of date of manufacture - Built in early 90's, GE2000 Drives with DLAN to Series 6 PLC. Specifically, it was referred to as DLAN- Do you know if it is possible to do a lobotomy on the drive and ditch the DLAN altogether? The motors have encoders with dual outputs on them - it might be easier to use one of those outputs with a velocity loop controller (MO2AE Logix Motion Card) to manage coordination. Of course, this would only work if the drives could be controlled in velocity mode from an analog command on the front of the drive . . . which seems like a really basic function that it should be able to do.

Steve - thank you for the information. I have quite a bit of experience with the 9070 PLC and using third party cards on the VME bus - but it sounds like the communications gateway card that would be available to interface at the drive might be problematic in this case. My experience with approaching the drives supplier for this kind of option is that I eventually find myself bidding against them for the work - I don't want to go there. My preference is to coordinate the drives with a controller that has a ControlNet interface (can I say that on the GE section of this forum?) :) I see lots of retrofits of these drives with Avtron front ends, Siemens front ends, etc. Time to do some more research.

I have a customer that would like us to replace his Series 6 PLC that is managing upwards of 8 DC drives. He does not have prints of the machine and he does not have code listings. Before jumping into the bidding process - can anyone comment on whether or not the Series 6 PLC has some kind of drive coordination capabilities. ie does the series 6 have some kind of network connection to the drives? This machine looks like it was manufactured in the late 80's . . . The I/O and logic on the machine are managed by a PLC5 - I am thinking that it might be easier to have the machine and drives use a common PLC platform, but the budget wont stand for new drives at this time and in order for me to figure out coordination of the drives, I need to have some idea of how the Series 6 GE PLC interacts with the GE drives. (I believe the drives are older DC2000 series drives). Anyone familiar with this kind of PLC / Drive combo? Thanks,

Our customer's specification precludes the use of any wireless technologies in this plant. At present, I think I am going to use 485-485 optical isolators and daisy chain the signals on the PLC side of the optical isolation units.

I have 4 field devices that I need to communicate with over an RS485 network. The devices use an Optomux protocol and I would like to keep them isolated from one another. I know the easy way to solve this is to simply daisy chain them all together and connect to the CP341, but I'd like to electrically isolate them from one another so as to prevent possible damage due to surge or cable crushing as this is a large machine with lots of potential for cable damage. I am aware also of several "Ethernet Serial Providers" . . . would it be better to use a device like this and bring the Ethernet cable into an Ethernet comms module? Any thoughts on this would be greatly appreciated.

Virtually any motor that can be controlled can be made into a servo motor - we have fitted hydraulic motors with encoders and closed a servo loop on them with good success and even hydro turbines in generating plants can be turned into servo motors and this approach now allows exact positioning of the generator rotor such that optimum synchronization with the line is achieved prior to closing the breaker by controlling rotor position rather than looking at the generated sine wave. (note that this requires servo positioning of both turbine blades and wicket gates which are controlled with low pressure hydraulic pressure from the same water source that is driving the turbine) . . . reviewing the designs from the 20's and 30's and tearing those antique governors out and replacing them with a DSP based controller gave me mixed emotions. The real question should be - what motor technology is best suited to the application - assemble the speed torque characteristics of the various motor technologies - look at the requirements of the application, select the motor based on that criteria - add an encoder and a "current, flow, pressure" amplifier with suitable bandwidth and control it with a servo loop and you have a servo motor. We have developed a huge database of induction and servo motors from a dozen or so manufacturers - all are characterized by torque / inertia specifications as well as synchronous speeds, field weakening characteristics, etc. It often surprises folks when they see a $1000 Baldor induction motor with encoder perform as well as a $12,000 Indramat Servo motor in an application simply because the application torque, speed, stability requirements are better served by the cheaper induction motor.

No set rules that apply to all situations - we do have applications where every output is fused by necessity. A machine making beer bottles with literally thousands of outputs - when one solenoid shorts or a wire shorts - you do not want to shut down any more of the machine than necessary with the faulted output signal. Individual fusing allows continuation of machine operation and as mentioned, ease of troubleshooting the offending circuit. I have designed and built panels for a variety of fortune 100 manufactures that write this into the specification - yes it is costly - but in the long run, 200 fuse blocks is cheaper than an hour of downtime on a system that runs 24x7 for 10 years before it is expected to be retired. Not crazy at all . . . in fact, not fusing is crazy in a lot of cases.

We have switched almost entirely to zinc plated backpans for noise suppression and ease of grounding with large scale drive systems. We can get drive mounting brackets, EMI shields, shelves, etc. plated cheaper than painting as well. Makes a nice package. Here is a shot of a panel under shop test - pretty much all hardware and backpan components are zinc plated.

We typically provide two general binders for each system: 1.) Operators Manual - describes how to run the machine, definitions for each of the alarms, HMI description - mostly oriented on the Process that the machine controls or performs rather than how it performs the process. This would be analogous to a manual that tells you how to drive your car rather than a manual that tells you how to fix the engine in your car. 2.) Technical Reference Manual - describes the technical details of the machine. Should include the following: General Overview including major control system elements Processor specific item descriptions (sections of PLC, HMI, Drives, Motion Controllers, Safety System, Etc.) Troubleshooting guide Save / Restore Instructions Appendix including - schematics, code listings (as appropriate), cut sheets from individual components or additional manuals for non-standard items This is just a suggested format - our format changes depending on the size of the project and the experience level of the customer . . . as well as how much they value documentation (are they willing to pay extra for good documentation). Again - put yourself in the customers shoes - ask yourself, "what would I need to support this system if it were to break down and I needed to troubleshoot and fix it?" A big topic - and lots of flexibility in how you address it.

If the customer has no standard - and you want to do your job decently . . . then put yourself in the shoes of the customer and consider what you would need to know in order to support the machine long term. We have a full time technical writer on staff who is not very technical - which works well from the customer's standpoint because if she can figure it out well enough to write about it, likely the customer can read what she has written and follow along well enough to get done what needs to be done. We design and build high-end motion and coordinated drive systems that typically have a ControLogix PLC and multiple HMIs - a mix of ControlNet and Ethernet and sometimes DeviceNet networks, Safety Systems (sometimes including a Safety PLC) bla bla bla. We have manuals that describe in detail including screen shots on how to back up and restore the configuration of each device - including the drives. We assume they have almost no experience in doing this and write at a level of about 8th grade. When we have an instruction manual for the machine - we write from an operators perspective on getting the machine set up and making routine changes to the machine. So often manuals are written like "This is the main operators screen, it has the following controls . . . bla bla bla." This tells people about each of the features of the HMI, but they don't have a clue how to make a product change. Regarding prints - you should have good electrical diagrams - the device names on the prints should match the tag names in the PLC database. Your choice as to whether you provide the prints in a native CAD format or in PDF format. Regarding individual component data sheets - by all means supply them. We provide a hard copy of everything in a binder - then we also scan everything to PDF files and burn a CD. We use a program called Frame Maker that has conditional switches in it to develop system documentation - it allows you to write a full featured manual that references other documents to include and index appropriately at will - it is a lot of work to set up, but once you have done the hard work up front, manuals of high quality are a snap after that point. Manuals and documentation are a huge investment that is rarely appreciated for the amount of effort required. However, once you have made the investment - the customer is better able to support themselves and as such is less likely to suck up your time doing support when something happens down the road.

We have tried a number of methods - at present we are using lexan strips with adhesive labels - non-conductive and easier to read when components are elevated off the backpan. We tried mounting directly on the backpan but our customers requested something easier to read and not obscured by wiring. They also requested non-conductive so that test leads would not inadvertently short out on the label holders.