Small PLC application...

I've been given the task to install a means to check the strokes per minute of an oilfield pump. I've written the logic, which I will attach but I'm having some difficulties deciding on the display..I'm leaning towards the Optimate OP-440 because I dont need any of the fancy push buttons and stuff - they just need to know strokes per minute. Does this particular panel meet my needs? It will have to allow my integer file to be displayed and not a predetermined message like its leading me to believe.

Thanks in advance!

can you please put the PDF extension file...so that everybody can look into it (i do not have rslogix at home)

how do you do that?

edit: I figured it out...see attached.

They're cheap and they work. I used 14 of them (OP414 I think) 4 years ago. In a fairly rough indoor industrial environment they have held up well. One or two cracked bezels from abuse, but all still function that I'm aware of. Mine had 6 setpoints that read/write to 12 consecutive words in a Micrologix 1000. I think it will read/write 32 bit words in other compatible processors, so in my Micro it wrote to N7:0 through N7:12, skipping the odd numbered words. The base address is selectable, but in my application it had to be in the N7 file. Other PLC types may open up more options here. Another quirk, when it first communicates with the Micro, the Optimate will overwrite any PLC addresses configured as Setpoints (adjustable) with it's internal values. There is a ladder logic workaround that is not too difficult that controls this. Not a concern for read-only, non-cumulative values like you described, but chances are you'll want to use all available addresses and if writes are involved, beware of this.

ELake20 said:

how do you do that?

edit: I figured it out...see attached.

Click to expand...

May be i'm missing anything, but that way you will always have zero in N7:0, since you clear C5:0 before using it to multiple with 60... so zero (C5:0) mul 60 will be zero..
So you would need to exchange MUL and RES operators..i.e. multiple, then clear C5:0, That way would be right...

let me know if I misunderstood anything...

There could be some multiplied error by reading the strokes per second and multiplying it by 60 for strokes per minute. I would count the actual number that occur in a minute and update a holding register every minute. How many strokes can occur in a second?

You could do the whole thing with a Moeller Easy 800 "smart relay". You could put it in a polycarb box w/ a clear cover or in an enclosure behind a window. It has a small display screen that you can use to show numbers from the plc.

Not sure if AB private labels the Easy 800 in their pico lines. The lesser models cannot display register values, just analog signals and counter presets and counts.

<disclaimer: I work for a Moeller distributor>

oopsie...thanks for pointing out the small error with the XIC.
The reason I had the .PRE of T4:0 @ 100 was so that N7:0 would be updating every second. I wrote this sight unseen - I'm not sure what kind of "strokes" this thing will churn but the logic, while ugly does infact work. I can put a Time Base bit in parallel of the Prox input for simulation purposes and it seems to work.

You will never read anything other than 0, if you have the RES before the MUL, look at it again...

Having been around many oilfield mud pumps, they typically operate at 120 strokes per minute max. Occasionally I have seen a couple that ran 140 strokes initially and then were backed down to 125 or less. As the well deepens, the stroke count actually drops off.

If you get 1/2 stroke per minute accuracy, you will have matched most stroke counters currently in "the patch" as it is refered to by most oilfield hands.

Aside from the order of operations error, it looks like it will work, but may result in an unstable value. The way your code works, it's gonna update every second, and reset the cycle counter, so so if it's running at 3.5 strokes per second average, one second may get three strokes, and the next four, then three, then four, instead of 3.5.

I normally do rate calculations by finding seconds per cycle first. Then div 1 minute by that to get cycles per minute. This way, every cycle generates a fresh value. On a slow cycling system, this will give you accurate feedback the fastest. so you can see the impact of very small adjustments immediately.

Have a look at this little nugget of code for a Micrologix1000 (No floating point, so it's not any more accurate than yours, but a DDV, or a processor with Floats would take care of that.)

Red Lion and many others have small rate meters that can be configured to display strokes per minute. They would need to be wired to a sensor that changes state once per stroke, or to a PLC output. Once installed, your total time invested would be about 15 min.
Good luck

http://www.redlion.net/

bluebyu said:

Red Lion and many others have small rate meters that can be configured to display strokes per minute. They would need to be wired to a sensor that changes state once per stroke, or to a PLC output. Once installed, your total time invested would be about 15 min.

Click to expand...

Here! here!
Most types of digital panel meter can be cofigured to give a ppm / rpm reading.
Using a PLC and digital display to do this (if that is all it is doing) seems a bit sledgehammer and nut to me.

OkiePC said:

Aside from the order of operations error, it looks like it will work, but may result in an unstable value. The way your code works, it's gonna update every second, and reset the cycle counter, so so if it's running at 3.5 strokes per second average, one second may get three strokes, and the next four, then three, then four, instead of 3.5.

Click to expand...

I downloaded it and ran it...yes very unstable

OkiePC said:

Have a look at this little nugget of code for a Micrologix1000 (No floating point, so it's not any more accurate than yours, but a DDV, or a processor with Floats would take care of that.)

Click to expand...

Now that's what I call good code, thanks, I will be sure and use it if ever needed