RSLogix5K -- D2SD-- Function Block

I was looking at using a Function Block D2SD (discrete 2-state device) for start/stop of motors and open/shut for valves.
Can somebody give a quick-start as far as where start permissives, run interlocks & start command should be connected?

Generally, looking for feedback on this block!

Thanks,
Giz

follow up

Has anybody ever used this Function Block?

IMHO, unless you really have a need to use the D2SD, or any of the other process/drives function blocks, you should just ignore them.

They are nifty to play with, I guess, but are more of a pain than they are worth, and virtually nobody in the maint. department is going to have a clue how they work (or don't).

Those devices are about 50 times more complicated than just doing it simply in ladder.


The corrolary here too, is, 'If you don't understand at least 90% of how one of the complex functions works, don't use it'.

Follow Up

I agree with you drast, but unfortunately I work for someone else. They seem to think this function block will be used as a template for all their on/off devices. Once the maintance gets to using them, they may find it easier/(not as difficult) to trouble-shoot. This is a new facility and their maintance doesn't have much experience with anytype of PLC programing. There are not alot of interlocks and permissives for each device so I don't think it'll get too cluttered.
Anyway, that's why I'm investigating this block.

I'm setting up an simple example for a motor start/stop:
-Start PB input
-Start Perm input
-Run Interlock input
-Run Feedback input
-Output to Motor Starter

I beleive I've got a handle on all Perm & Interlock input, as far as where to hang them on the function block. I connected the Start PB input to the ProgramCommand pin and seems to work except it requires a maintained contact (my start PB will be momentary). Is there a way of sealing around the startPB within FB routine or does this logic have to be done in ladder or elsewhere?
I'm still a little confused on where to connect the Run feedback signal (FB0 or FB1) and how to make it fault if not feedback.

Thanks!!!!!!

/sigh.

So, in complete ignorance, someone decides to come up with a standard, not knowing how it works, or even if it's applicable, just because 'it has a cool name'. <smile> I'm glad I don't work with you! lol

Anyway, you can use the SETD or RESD Set/Reset and Reset/Set blocks to latch the run bit on if you need. Of course, then you have to use OR blocks to reset it if you have several conditions that can stop it.

Sequencing can also then be problem if you are using the Discrete Device block to handle it's own interlocking and permissives.

Another option for that block may be to place it in OPERATOR mode and use pulses in to the OperState0Req and OperState1Req inputs to toggle between what becomes essentially ON and OFF.

Is the function block the implementation of this ladder logic?

Start_PB   Start_Perm   Run_InterLock     Output

---] [---------] [----+-----] [-------------( )--

                      |

Feedback              |

---] [----------------+

Steve: Only partially; in one (or two or three modes). That is the core of the 'Operator Operator' mode, which is completely different from the 'ProgramControl' or 'Hand' or 'Operator Program' modes.

In total, that 'simple' two state device has about 25 inputs, and 10 outputs. It includes the possibility of some time-based fault logic, and transition from and between several 'operating source and method' control modes, like most of the universal FBD blocks.

Your logic is what I much prefer to see, maybe with a seperate timer for a 'Fail' alarm. It is much more readable for one thing. Rockwell has been doing some nice things with CLX, but their FB's are overcomplicated by about 1200% for 99.8823% of the applications out there.

If you wanted to use the function block for the simple application that I posted, are there default settings for the unneeded parameters that will permit it to work properly, or will you have to enter a bunch of data that will be irrelevant for a simple application?

Sometimes in our quest for a 'universal solution', we overcomplicate the simple applications.

Steve: (and original poster, hope your reading )

The only defaults set to true in the block are the State0 and State1 Permissive interlocks. Even were there other defaults set, the way Rockwell has designed most of these <cough> 'Universal' function blocks absolutely positively requires you to initialize them properly just to get them into an operational mode.

Just plunking it down, most of the Function's that have 3 to 6 possible 'control sources' require one of them to be enabled. Without explicitly enabling one, the blocks often do nothing.

The wierd thing is, some enables seem to want a level signal, some want a transitional signal, and the override order isn't well defined in documentation.

follow up

Once again I'd like to mention that I'm a fan of ladder logic over Function Block in this case. I find it much easier to read/trouble-shoot. Like I mentioned earlier the maintance (2guys) don't have any PLC training so the Control Engineer would like to see them learn the FB logic. He likes the idea of the built-in fault and other features.

It appears there are default settings loaded for the unneeded parameters that will permit it to work properly. You can also select which parameters that you would like to make visible on the function block so you can uncheck/hide all the parameters not needed. I'm still struggling over a few issues on the Program/Hand/Override functions as well as the feedback operation.

Anybody know of an particular area of RA tech support that will have the most expertise with this function block.


Thanks for everyone's input!!!

The first clue for when and where to use this block is that it is grouped with "process control instructions". If you're implementing a DCS-like system, then the use of this block is appropriate. For run-of-the-mill motor control, it is overkill and likely requires a few anti-intuitive contortions to perform an otherwise simple task.

You'll notice in the help file that reference is made to an ActiveX faceplate that can be used to control this block. The intended use of the block is, for example, to control a butterfly valve in a process where:

• positive confirmation is required for open and closed positions
• failure to reach commanded position within a set time must be alarmed
• normally the valve is controlled in an automatic sequence
• an operator must be able to take manual control of the valve (via HMI) without affecting other devices

I'm still a little confused on where to connect the Run feedback signal (FB0 or FB1) and how to make it fault if not feedback.

Click to expand...

FB0 = feedback for '0' state e.g. 'closed' or 'off'
FB1 = feedback for '1' state e.g. 'open' or 'on'
Note that you can also define whether '0' or '1' is true for each of FB0 & FB1.
In order to prevent an alarm, the block must have 'true' confirmation of its commanded state.

The D2SD and D3SD had their first incarnations in the ControlView 'PCO' add-on (Process Control Option). That was an attempt to capture some of the DCS market and provide "standardised" programming. It fell flat however, since the PLC5 family processors (the target) did not have enough memory capacity for even a modest system. e.g. D2SD required a subroutine of 1200-1500 words and each device required 40 integers in data table. I can't remember how many different blocks were available, but I do remember that if you wanted to use all of them, the supporting subroutines would not fit into a PLC5/30 - never mind the subroutine-calling logic or the data table requirements.