Speed Compute

Hi all, I want to convert a speed meter of the can line filling machine from ordinary pulse tacho meter into a PLC S7-300 program and display it to OP17.

I count the number of pulses/1 second and multiply by 60 and display it as cans/minute. But if the machine is running in between 0-60CPM, i can not display exact speed.

Is there any ready made standard function or function blocks in S7-300 PLC that can be use for this application? or maybe some STL code for the same application.

Thanks

ebnaviojr said:

I count the number of pulses/1 second and multiply by 60 and display it as cans/minute.

Click to expand...

This value will be pulses per minute though not cans per minute unless im missing something. I pressume you already know how many encoder pulse there are per Can ?

If so then, Pulses from encoder per second X 60 X Pulses for 1 Can = CPM.

LH

The original post implied that there is one pulse per can.

Using just that signal one alternative is to measure the time between pulses as accurately as possible and divide 1 minute by the result. This would update the speed after each can. The usefulness of the information would depend on the accuracy and resolution of the timing method.

Another is to use a longer time period. One minute would give an exact reading of the previous minute but with the obvious one minute between updates.

A better solution, as implied by LongHorn, is to use some signal with a higher pulse rate per can. If the cans are being moved such that they are at a constant spacing then an encoder or other high rate pulse attached to the moving device could give a better signal. Count the signal for one second. Multiply by 60. Then divide by the 'pulses per can'.

Seems to me the most direct is to measure each can as it comes off the output conveyer using a prox type switch. Why measure oranges when you want a count of apples?

Dan Bentler

This topic has been covered hundreds of times but no one has said

At high speeds you count cans per second unit of time
At low speeds you count time between the cans.
So if the cans are running 0.8 cans per second you can see that you will get readings of 60, 60, 60, 60, 0, 60, 60, 60, 60, 0 if you try to measure cans per second. It is easy to see that using a timer and dividing 60/time would provide a better answer. Even if the rate is 7.5, you will still get 480, 480, 480, 420. However, if then quantizing of the timer error will also increase as the time between the cans is now only 133.333 milliseconds instead of 1250 milliseconds. Now the question is how much will the measurement error be as fraction of 133.333 ms as opposed to 1250ms.

An analysis of whether you should use the time between cans or cans per time should alway be done up front to choose the best method and sometimes you must use both and switch over at some point but you will not know until you to the calculations.

Thanks for the reply.

As what leitmotif told is correct. I am using proximity switch to detect the can. There is also constant spacing between the cans. I already try to use a timer as what peter suggested to measure the time interval between the cans but I got a very big error. Because the timer was not able to run anymore before the next can comes as the machine runs up to 1,200cans per minute.Or maybe my sequence of program is wrong? So i try these logic as shown STL code below. it works quite ok but the problem is ex.. i have 15pulses / second X 60 = 900cans per minute and if 16pulses / second X 60 = 960cans perminute. But if the machine is running in between 900 to 960 my display is showing 900,960,900,960 only.

I want to see the display Ex..910,911,912,913…………958cans per minute as the machine running in between 900-960cans per minute.

Any idea how to manipulate the value so I can display it as approx. the same as tacho meter?

NETWORK1
A I0.0 //CAN SENSOR
FP M0.1
= M0.1

A M0.1
JCN M001
L MW2
L 1
+ I
T MW2 //ACTUAL CAN COUNTS
M001: NOP 0

A M100.5 //1 SEC. PULSE CLOCK GENERATED BY CPU
FP M200.0
= M200.1

A M200.1
JCN M002 //UPDATE DISPLAY EVERY 1 SEC.
L MW2 //ACTUAL CAN COUNTS
T MW4 //STORED COUNTS

//TO DISPLAY CANS PER MINUTE

L MW6 //TOTAL CANS PER SECOND
T MW8 //PULSES PER SECOND
L MW8 //PULSES PER SECOND
L 60 //60 SEC.
* I
T MW10 //PULSES PER MINUTE(Display as cans per minute)
M002: NOP 0

L MW2 //ACTUAL CAN COUNTS
L MW4 //STORED COUNTS
- I
T MW6

BE

Why not use a running total of cans
AND
run a timer such that at the end of the timer for example one hour

Total cans divided by time (one hour) = cans per hour
Then reset timer and counter and start again

Dan Bentler

Maybe I'm wrong but....
We can start timer (approx. 10 sec.) with FP first can.
During this time we can count real flow of cans (inc number_of_cans with another FP of sensor). After timer stops, we have real quantity of cans, simply number_of cans multilply by 6. (if interval is 10 sec.).
So You can refresh on OP quantity of cans every 10sec.

markopo said:

Maybe I'm wrong but....
We can start timer (approx. 10 sec.) with FP first can.
During this time we can count real flow of cans (inc number_of_cans with another FP of sensor). After timer stops, we have real quantity of cans, simply number_of cans multilply by 6. (if interval is 10 sec.).
So You can refresh on OP quantity of cans every 10sec.

Click to expand...

You can base your reading on any parameter you want. Cans per second, cans for every time supervisor scratches his head, etc. The major questions is once you get this number what are you going to do with it?

Seems to me that cans per unit time (minute hour or what ever you want) based on machine run time is the most valid.

Dan Bentler

could use DT to keep a "long term" average

I had a situation recently where I needed to measure something that changed very slowly. An oil level than went down about 1 mm per hour. I needed it to drop several mm in order to make accurate readings as the level inicator had a resolution of 12 mm.

If I had better instruments it would have been easier, and better but then it would cost to much.

There were so many issues with this one measurement, I will skip to the part I think might be of use here.

I started reading the level in the tanl every so many seconds/minutes/hours, depending on the rate of expected consumption.

Then after each measurement I used a function that writes the number in the first row of a DT and shifts all the others down one.

(I am away from the software right now, do not have the number of the FB but it makes so many things easier. If you want I can find it and post later.)

We know how many entries are in the DT of course, we made it. I used 10. Then , as the DT fills up with data, I have a history, and I know at what interval the different readings were taken.

The next rung looks at one of the DT entries and when this entry is not zero it subtracts the first entry from this one. Since I know the elapsed time, I now have how much has changed in X time.

In my case I had one scenario where I could not take a reading until the unit had run for 24 hours. But I wanted the data to update more frequently.

I made this table take a reading every hour.

After the first 24 hours, I had a new 24 hour average every hour.

You case is just the opposite, but you could count cans per time interval and write them to the DT , using differnet starting points on the datatable, you can dissplay the count in the first minute and then move your average as more data becomes available or have different dissplays for different time periods.

Some people like to have the daily average, hourly, average, and real time for example.

You could also use 3 DTs.

I took a reading every minute in one and every hour in another and every 24 hours in a third. Each has its own merits.

You could read cans and every Xseconds take a reading.

After the first minute or so, do your math and dissplay the average speed.

For "real time" count seconds between each can as suggested above, No DT needed.

I went on to chart the running averages to give a graphical history of the data.

S7 can do so much and there are so many ways to get similar results. half the fun is exploring different ways to do the same thing.

It maybe posible to use 10sec. time or longer. But it will take time to refresh the value at OP17. Since the machine is running with the high speed, machine operator and manager is wanting a quick refresh on display as soon as they start to rotate the speed ref. potentiometer.I will try to simulate all of these ideas. I will let you know which one suits best for me.

Thanks,

According to me

Multiplying by 60 or something like that causes that error 900 960 900 960 ... because the PLC sometimes catches one more pulse or so by multplying it with 60 you just make the difference 60 times bigger than it is.

OP have a cycle of refreshing tags mostly the fastest refresh value on a OP is something like 100ms...

If I were you first I will check the cycle of the tag from WinCC Flexible or Protool.Then implement the code like counting the rising edges for 0.5 or 1 s and take the average of the last 5 to 10 of them and then multiplying the average of the last cycles by the time factor

like for 900 bottles going to 960 bottles in 1 second (assuming to start with the correct number which means the machine has been working for a while) it will go like 15 16 16 15 15 16 15 15 16 16 16 the sum of the constantly changes so after 5 first 5s you can take the sum of them and take the average
it will go like: 924 930 934 939 ...

For the fist five to ten measurement the differential may be a little high but it will settle after 5 or 10s

But after all if you want to see them very accuratly like you said 911 912 913 you should go for the timing procedure you can start up a timer with the rising edge of a can then you can stop the timer at the second rising edge ans start up another timer and goes on like this. By applying the average algorithm to the ms you will have a faster response...

If you want to have a clean reference like you said I will say go with the cans/sec not for cans/min because the multiplication for expanding always make the measurement errors 60 times bigger then it physically is.