RSView32 momentary button delay

[blewis]

I'm new to this ecellent forum, and a little dated in my PLC knowledge.
Those familiar with the AB Panelviews know that when you place a momentary button, you can set the duration of this momentary pulse when the button is pressed. I typically set it at 0.2 sec which insured adequate time for the latch signal from the motor starter to latch my run signal in the PLC code.
I have a situation in RSView32 where I do not have this duration setting, and the operators are pressing and releasing the button before the PLC code picks up a run signal (via Intellicenters and devicenet) to latch it in. I hate to modify all of these rungs to use latches, unlatches, and timers to solve the problem. Is there a simpler way folks have used?
thanks in advance..

 

[rdrast]

Don't latch it with device feedback. Latch it in with the run command, but you will still have to go back and add timers and fault detection logic for Run_Asserted and Starter_Aux_Open.

No real easy way, but perhaps you could make a subroutine/function block/AOI to reduce the pain

 

[scottmurphy]

Set the bit ON in the HMI, then reset the bit at the end of the PLC scan.

I used this before in this type of situation, where the comms are slow.

This should not required too much extra work, and no timers at all. The existing logic can remain, with only the addition of the unlatch/reset/clear at the end of the program scan.

This should work with devicenet, not sure about the intellicenters though, how are they interfaced with the PLC?

 

[TConnolly]

Because RSView bit writes are asynchronous to the PLC scan, I don't do a simple reset at the end of a scan but I use logic that waits unitl the end of the second scan. It's alway possible that the rung looking for the bit is near the beginning of the program, but RSView doesn't write the bit until after the scan has passed that rung. In that scenario, resetting it at the end would mean the button press is not picked up next time the rung is scanned, resulting in the operator having to press the button several times. I end up burning an extra bit, but its only memory. The reset rung is still fairly simple:

  RSVIEW_PB             A    RSVIEW_PB

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

                   |

                   |

                   |            A

                   +-----------( )----

Another issue that I have observed on a couple of occasions when using RSView momentary push buttons is that a bit might be set by RSView but for some reason it fails to be reset - for this reason I have gone ahaead and included reset logic for momentary bits like that above just to make sure.

 

[blewis]

thanks for both replies:
The Intellicenters use devicenet, and we have an ethernet to devicenet bridge in an MCC cubical. So, the PLC communicates via ethernet. This works out well.
I'm afraid that the PLC will actually go through several program scan cycles while waiting to get a Run signal back from the starter via devicenet/ethernet.
I'm wondering if there is a macro or script that folks use in the RSView to set the pulse duration from a momentary button.
thanks again.

 

[TConnolly]

&tagname=1;pause(seconds);&tagname=0
The & causes immediate update of tag.
Not my favorite way of doing it, but hopefully it answers your question.

 

[scottmurphy]

Because RSView bit writes are asynchronous to the PLC scan,

Really, I didn't know that, trap for young players....

Another method that we have used, is very similar to yours Alaric, and to be honest, this is the best method like you say.

 

[Dua Anjing]

Another way you can avoid the asynchronous issue's would be to move your RSView bits into another memory area with a that way you control exactly when in the PLC scan the control bits become active. RSView writes to "RSVIew_write_tag" whenever it wants to and the PLC program ONLY moves "RSVIew_write_tag" to "PLC_uses_this_tag" at the start of a new scan. But I prefer Alaric's method. The SCADA sets a bit to initate a process and then the PLC does what it has to do and then resets the SCADA bit. you don't have to depend on the scada being around to reset the bit, also reduces your comms loading(if that's an issue)as you only have to do one write not two.

 

[blewis]

Lots of good input.
Alaric, the way I inerpret your last suggestion is to run a command with the button press that incorporates a delay, rather than just running the standard momentary function. I think that this would probably be my best solution. I prefer to handle most funtions in the PLC; however, this momentary dwell is just so much more efficient to incorporate into the button. I guess I'm also reverting to my old panelview functionality.
As far as latching in through multiple scans; I'm afraid that the processor could run through 100 scans before it ever picks up that run contact via devicenet. In the meantime, if the operator releases the mouse button, I get no latch in.
Thanks so much to all!

 

[TConnolly]

Since this is a MCC then I think it safe to assume you have several motors. What is unknown is if you are using a ControlLogix or some other PLC. So, making the less safe assumption that you are using a CLX...

To simplify programming and memory, create a UDT to define a motor data type, call it MOTOR_udt. You can call the UDT elements what you want, but for the example, lets have the UDT contain at least the following:
HMI_START_PB - boolean
HMI_STOP_PB - boolean
VERIFY_ON - boolean
FAULT - boolean
OUT - boolean
RST_NEXT - boolean
HOLD_ASSERT - timer.

Next in the program your motor control is going to be in create a locally scoped tag called _Motor of type MOTOR_udt. Create controller scoped tags Motor1, Motor2, Motor3, etc. of type MOTOR_udt for all of the motors in the MCC.

In the HMI each start/stop button maps to the corresponding bit in the UDT, eg, START MOTOR 1 PB maps to Motor1.HMI_START_PB, etc.

Now write one reusable subroutine to hanlde all motors, called MOTOR_sbr. This subroutine will be passed each of the motors as a parameter. Passing Motor1 as a parameter will copy the Motor1 into _motor, the logic will then be solved, and _motor will be copied out back to Motor1. Then passing Motor2 to the same subroutine will so the same for motor 2, but you won't have to create the code all over again.

This snip shows the MOTOR_sbr subroutine, no doubt it needs some work to fit your needs but it should give you an idea of what I'm talking about.

The subroutine implements basic motor start/stop logic + it provides up to 2-1/2 seconds for the Aux contactor to pull in and be communicated back to the PLC. If the contactor doesn't respond then a fault bit is turned on - adapt delay and fault logic as needed.

Your main program will look something like this:

Also, keep in mind that you could group all of the UDTS for the motors in the MCC into an array. The same thing could be implemented using a AOI as well, but AOIs are new and since you said you were a little dated I didn't take that approach, but if you were to learn them then that would be the way to go. This is just an example that I threw together really fast but it could be expanded to give you quite a bit of functionality and diagnostics if you expand the UDT and Motor subroutine.

 

[blewis]

I knew there had to be an easier way to do this. This is exactly what I was looking for. It eliminates most of the code for 200+ individual motors by simply passing a paramater unique to each motor. It also allows the use of a single start/stop pop-up instead of configuring an individual pop-up for each motor. Back in the good ole days, we did similar things by swapping groups of variables with tables. Things have gotten even easier.
Thanks so much!