The program in the PLC provides the logic control for the motors in the SR and SL Rotators. The program is written in three distinct, yet interlocking, states; the move up stage, the rotation, and then, the move down stage.

• State one starts from the pre-set downstage position moving upstage, leading into state two.
• State two is the 180-degree turn, with the SR unit leading the SL unit in the rotation.
• State three, the movement back downstage, starts when both units have completed the rotation in state two.

At any point in the sequence of moves, the units can be stopped, backed up, stopped again, and then continued forward once more. The execution of the program is done with the three buttons on the hand held control forward, reverse and stop. There is one user variable for the program -- the speed control potentiometer.

The drive mechanism for each unit consists of two DC electric motors; each motor has a control board governed by the Programmable Logic Controller (PLC). The program that runs in the PLC makes its decisions based on a distance count from an encoder which is located next to each motor. In the progression of the moves, only one motor, and its encoder, reverses its rotational direction. The non-reversing motor, and its accompanying encoder, is called the master; the reversing motor is called the slave.

Once the distance counts have been determined, by trial and error in the on-stage testing phase, those values are written into the program. The program loads numeric data, i.e. encoder counts, into memory areas known as registers. The speed control variable, known as the offset value, is constantly sent to register (D1). The maximum speed value, a non-variable, is loaded into a register (D3) by a software command at start-up. The maximum speed value is combined with the offset value from the speed potentiometer. This new value becomes the adjusted speed value (D4). The adjusted speed value is copied to four additional registers. Two of the additional registers are used for the SR Unit, and two for the SL Unit. As with the motors, the registers for each unit are known as a master speed register and a slave speed register.

The numeric value in each of the speed registers is copied into a digital-to-analog converter. That converter outputs a DC control signal that is proportional to the digital input from the speed register. The greater the control signal, the faster the unit moves. The direction of the motor rotation is dependent on the polarity of the output signal. A positive value input produces a positive output control voltage. Likewise, a negative value produces a negative control voltage. The control voltage signal, from the digital-to- analog converter, is sent to the motor control circuit board; again, one for each motor. That board then sends a much larger proportional DC voltage directly to the drive motor.

The unit position is tracked by the use of a quadrature signal from incremental encoders. There is one encoder for each motor. Just as in the master/slave set up for the motors, there is also a master count register and a slave count register for each unit. As before, the master count encoder only counts in one direction, where as the slave count encoder counts up and down.

As I mentioned before, the only way to prove the program and the mechanical systems is to actually run the units in a real-time situation. Before the Pre-Tech last summer I ran the program many times in the shop. Those tests proved the logic of the program, but not how the units would actually behave under power, with the full weight of the units in motion. Motion adds a dimension not possible to account for in static testing. The largest of these unknowns is the stopping distance of the unit. To discover when, in the encoder count, to tell the motors to begin stopping requires some trial and error analysis. The stopping distance is dependent on the magnitude of the mass of the unit, the velocity of the unit, and the ramp-down setting on the motor control board. Different masses of each unit require a different stopping distance for each unit. Since the units will weigh more when they are completed, additional on-stage testing is required to determine the new stop counts.

Another factor that influences the accuracy of the movements is how the units are initially set on spike. They must be spiked based on the structure of the unit being parallel to the plaster line, not by just lining up the art. If the art matches on the downstage face and the framework of the unit is not parallel to the plaster line on the downstage side, it will not be parallel after the transition is complete.

The PLC program cannot completely overcome the limits set by the selection of mechanical and electronic components. The motor control boards selected for this system are ideally suited for use in a non-precision setting, such as running a conveyer belt, 24 hours a day, 7 days a week.

To execute the move predictably, the motors need to be synchronized in their rate of travel. With the in shop testing, I found when the same information was sent, at the same time, to the motors, there was a variation in speed between the forward and reverse direction for the same motor. This becomes an issue in both states one and three. In each unit, one motor rotates clockwise, the other rotates counter-clockwise. This means in each unit, one motor turns faster than the other, with both seeing the same value control signal. The control boards provide only a single trim potentiometer to set the maximum allowed speed; it does not calibrate forward and reverse to the same speed.

That difference showed up in the Pre-Tech. To get the units to come to spike in the third state, the units were purposely sent past 180 degrees in the second state. That, again, required many tries to determine the encoder count number. As I see it, a better choice would be a system that provides feedback from the motors directly to the motor control boards, thereby directly ensuring a constant rate of speed.

The program presently uses only the master encoder for the counting of distance. Once the count is reached, the motors are shut off. Assuming the motors were synchronized, this approach would work well. I could add the slave encoder to the program to try to coax the slower motor to spike after the faster motor has already stopped. My observation was, in the third state, if both units were not already parallel to the plaster line, one unit hits the other and changes the alignment anyway.

The rate of travel can be monitored, providing feedback to the PLC program. This can be accomplished by comparing a slave count register to a master count register. A percentage of the difference is then combined back into the slave count register to increase or decrease its value, resulting in an increased or decreased speed of the slave motor. I have a concern about this approach, comparing counts to synchronize the motor speed. What I expect to see is the slave motor always seeking the correct speed from the master. This may induce some unwanted oscillation (over-correction) in the unit. I can program the PLC to do this comparison, but without further testing, I do not expect it to work well.

In my estimation, there is nothing wrong with the current program. I suggest not having a generic programmer write a new program, but to have someone who is proficient with this type of equipment - drive motors, control boards, and Mitsubishi PLCs - to look at the current program and then suggest possible alternatives or modifications.