With over 240 Function Codes as tools for your process control strategies, Bailey has essentially created a visual programming language. Where other control systems may require extensive programming to implement process control, the Net 90 and the Infi 90 have taken the drudgery away from the system integrator (which is more often than not, Bailey) and the user. Bailey does offer the ability to write your own code and create your own function codes, but this is seldom necessary.
Sometime in the early days of the Net 90, if not at its inception, Bailey conceived the idea that writing code, canning it as a Function Code, providing inputs, outputs and configurable parameters to give flexibility to the code, was the proper way to present it to the ultimate user. We could liken this to selling a relay instead of the magnetic core, wire, contacts, and plastic case to build your own relay. Coupled with the software offered at the time (CAD and Text Configuration), you have a fairly advanced system for its time. To date it is hard to find a software package more adept than the DOS-based CAD system for configuring Function Codes, even amongst the sophisticated Windows programs offered today.
Most Function Codes are straight forward, such as AND, OR, QOR, or Time Delay. Others offer the sophistication found in other DCS or PLC applications such as PID algorithms or MANUAL/AUTO Stations. Its not the functionality of the Bailey system that presents obstacles. But given all this functionality we often challenged by the documentation used to present it. The Bailey Function Code manual probably rates higher than most other Bailey documentation, but it is not without certain faults. In this chapter we provide supplemental information that will hopefully save the reader some time in the long run.
In recent years Bailey has taken the Function Code concept a step farther. We encounter macro-coded logic and control on an ever-increasing basis. Thats not to say certain users havent been using this technique for years. After all, the User Macro library is not a recent addition. Perhaps its taken this long for Bailey to justify investing the man-hours to develop quality macros. The benefits and problems associated with macro use deserves a chapter in itself. Since there is little, if any documentation for macro creations, we need to explore Function Codes in more detail to learn why certain macros are written as they are.
Theres little need to start at Function Code number 1, taking each one in sequential order. Instead well start with the one that is most problematic at the time. Eventually we can organize these in order by Function Code number to make it easier to refer back to this document for answers. But for now, the MSDD deserves some discussion.
FC129 Multi-State Device Driver
One of the more complicated Function Codes encountered, the MSDD requires a lot of study to use effectively and correctly. In the old Net 90 days it was seldom used. But as system integrators became acquainted with it, the MSDD is more prevalent and even overused. Fortunately it requires little more memory or execution time than the Remote Control Memory block, so we mustnt complain.
A common misconception is that the state selectors shown on the Operator Station, of which there are three, correspond to the three outputs of the MSDD. Only by virtue of the masks selected would this be the case. In fact, because the bottom selector on the Operator Station pop-up selects state 1 and the top selector state 3, it is desirable to use state 3 as the START, or on state of the controlled device. In the real world, we would normally put the START button on top. It is also desirable in the configuration to use output N (the first output) as the START command because is looks better on the CAD drawing. Therefore, state 3 would correspond to output 1 and the mask for state 3 would be 001.
One given with the MSDD is that Output Mask 1 will always correspond to State 1, Output Mask 2 to State 2, and Output Mask 3 to State 3. The Default Mask corresponds to State 0. Beyond that, almost anything goes. So the mask defines the state, making it almost unnecessary to use both terms in the same document. In fact, let me explain in the next paragraph the programming of the MSDD without mentioning the word state.
Each mask can be configured in one of 8 different ways to define the outputs: 000, 001, 010, 011, 100, 101, 110, or 111. When the operator selects Output Mask 3 with the top button, he could be turning on one output, two outputs, three outputs, or no outputs. But as mentioned earlier, if he wants mask 1, he selects button 1 to produce a desired action.
So that wasnt so hard. But in the above paragraph we could replace the word action with the word state. And because you cant select more than one button at a time, nor can the control inputs select more that one mask at a time, there can only be three states, or three separate actions.
Bailey doesnt dwell too much on the manual operation of the MSDD. Most of the discussion in the documentation refers to automatic mode where the control inputs select the state (mask). The basic RCM doesnt even have an AUTO mode, so the concept of MANUAL/AUTO control for a digital station in the Bailey system is rather foreign. It might make more sense if the M/A control were accomplished through a state selection. Were familiar with this method in the real world where a selector switch provides Hand/Off/AUTO or On/Off/AUTO control. Its not uncommon for the MSDD to be configured in this manner, where the State 2 button selects AUTO mode. Selecting State 3 or 1 (START or START) disables AUTO control.
Because of the manner in which AUTO mode is presented for the MSDD, operators become equally confused with the concept. This is mainly due to the poor operator interface, namely the pop-up control. Since we are accustom to three separate positions of a selector switch, one of which is AUTO, for such a feature, it makes sense to configure the MSDD with State 2 as AUTO. This, however, renders the MAN/AUTO button useless, if not confusing. On the other hand, for basic 2-state motor control, what does the middle button do?
We could probably blame the design engineer for using the middle button to select AUTO. But if we have a two-state control that we either want an operator to control or something else to control, what else do we do? Well, we can either go back to the Bailey method and accept the unused middle button, or we can do what we did in the RCM days. Then we used one RCM as a START/START and the other as AUTO/MANUAL. That was rather messy. With some competitors to the Bailey DCS who dont have three-state devices, we are relegated to doing just that.
So many of the applications for the MSDD are two-state motor control (on or off). Which method to use for achieving an AUTO feature is a matter of choice. If we use the middle button (State 2) to enable the AUTO mode, the operator will invariably want to first click the MAN/AUTO button rather than the State 2 button. And when he does click it, he will be presented with a feedback display in the lower portion of the popup which says he succeeded. However, the Mode display in the upper half of the pop-up window will still show MAN. Some operators have walked away thinking they put the control in AUTO.
So perhaps the better method, given the deficiency in the operator interface, is to leave the State 2 button unused and utilize the MAN/AUTO button. Be warned, however, that if you dont configure Spec 14 properly and the mode is being overridden, the operator can again be deceived. If the ones digit of Spec 14 is zero, he will not get the OVR (override) flag. You will find a rather subtle note in FC129 documentation telling you this:
NOTE: A logic 1 at S25 and S14 equals XX1 or XX2 will cause OVR to be displayed Wrong!
S14 equal to XX1 or XX2 will always cause OVR to be displayed, regardless of S25.
Bailey stated this as if you should be cautioned (disregarding my wrong flag). Actually, why wouldnt you want OVR to be displayed if the S25 override input is set? For the astute operator who realizes his selection feedback in the lower pane of the pop-up does not necessarily mean the MSDD accepted his command, he will madly click away at the MAN/AUTO button and then file a problem report that the station mode cannot be changed. It would normally be important to configure the MSDD such that OVR will be displayed when S25=1. Unfortunately there is a bug in the MSDD which makes it difficult to provide the OVR flag.
There is a workaround for this problem. It is common to use the DSUM Function Code to generate an input for the Adapt block that sets the value of S14. Use the same block that sets the S25 override as input to the DSUM block. Assign a weighting of 1.0 to that input. A second input to DSUM would have a weighting of 140 to set the MANUAL mode for the MSDD. A third input would have a weighting of 130 to set the AUTO mode. MANUAL and AUTO modes must be mutually exclusive through use of logic external to the DSUM function. With this configuration the OVR flag will be set "through the back door."
Remembering the feedback text in the lower half of the MSDD pop-up displays your last button selection and not the mode or state of the MSDD, how do you determine the mode or state? The answer is obvious for the state. Properly configured, the upper portion of the pop-up will show both the mode and the state. Also notice that if you click inside a second pop-up, the feedback text in the lower portion of the first pop-up goes away. Then when you re-click in the first pop-up, the feedback text shows the true state of the MSDD, but not the mode.
Remember, there is a difference between mode and state. You can configure the MSDD to create an AUTO mode external to the MSDD through use of one of its states, but the mode of the MSDD would remain MANUAL.
Send mail to Webmaster with questions or comments about this web site.
Copyright © 2003 Powergen Corporation · PO Box 2089 · Glenwood Springs, CO 81602-2089