cycles per minute

[irondesk40]

have a machine that i have been upgrading from a older omron to a allen bradley, and trying to show cycle speed. The machine has a prox switch that is the cycle end prox. I have experimented on the desk, and hoping someone could take a look and see what you think. It is not very critical that it be dead on accurate, but trying to get it pretty close. there is a pot on the machine that controls a variable speed drive and the speed displayed on the screen is used to adjust the pot. the final machine will be a micrologix 1400, but only have a 1200 to experiment with. Hopefully someone would see a way to make it less code or possibly a better way that what i have experimented with on the bench. if you try to open, will have to change the .txt to .rss
thanks

 

[irondesk40]

forgot to label b3:5/15 as the cycle end pulse

 

[Ken Roach]

Let's take a bit of a step back and talk about the machine. What does it do ?

Tell us more about the machine and what sort of cycle it goes through, and how the variable speed drive's motor speed is related to the cycle time (is it the prime mover ?).

How many cycles per minute are typical for this machine ?

How long is the Proximity sensor true ? Does the machine stop at the prox sensor or just fly by it during the cycle ?

 

[OkiePC]

I have not looked in depth at the program but I did notice that you are counting for five seconds, then multiplying by twelve.

When faced with a task like yours, when the time for a single cycle is less than the unit of measure for time they want (minutes in your case), I normally calculate time per cycle as opposed to cycles per time unit (minutes per cycle instead of cycles per minute). Then, I store a few of those for averaging, and after averaging, invert (1/x) the value for display as cycles per minute.

By doing it that way, you can display the result much sooner in most cases. Without averaging, all you need is one product cycle from which you can calculate cycles per minute.

The minutes per cycle values will need to be floats.

And, you can FIFO the results of several calculations for your averaging. I typically store the ten or so most recent "Minutes per cycle" values, then I can set up the averaging logic to look at the most recent two, three, or (up to 10) until I like the end result.

 

[cwal61]

try this will give you real time Cycles Per Minute. I made this for Previous post that's the reason for explanation.

 

[irondesk40]

thanks will try ideas tomorrow. The packaging machine normally runs around 30-32 cycles per minute. The inverter drives a main motor and the machine has one of the omron cam units mounted on the operator panel. You put in the angle that you want the machine to stop, and the prox switch should make within that window and stop the machine for a product to be loaded. once loaded, machine starts cycle again, and of course there are flaps that get glued, closed etc. during the cycle. Its a pretty fast operation.

 

[irondesk40]

I have not looked in depth at the program but I did notice that you are counting for five seconds, then multiplying by twelve.

When faced with a task like yours, when the time for a single cycle is less than the unit of measure for time they want (minutes in your case), I normally calculate time per cycle as opposed to cycles per time unit (minutes per cycle instead of cycles per minute). Then, I store a few of those for averaging, and after averaging, invert (1/x) the value for display as cycles per minute.

By doing it that way, you can display the result much sooner in most cases. Without averaging, all you need is one product cycle from which you can calculate cycles per minute.

The minutes per cycle values will need to be floats.

And, you can FIFO the results of several calculations for your averaging. I typically store the ten or so most recent "Minutes per cycle" values, then I can set up the averaging logic to look at the most recent two, three, or (up to 10) until I like the end result.

like that idea as well, will experiment with it tomorrow. once cycle starts, there is from 1.5 seconds to 2 seconds untill the cycle end signal goes true. If i understand correctly what you are saying, once the cycle starts, start a timer, when cycle end signal goes true, move the timer value into a memory location. Do this for a few cycles, then add those values together and divide by the number of times you stored the value. does that sound correct? thanks to everyone,

 

[Ken Roach]

Alright, now we're going to have some fun. [cracks knuckles].

As Paul has mentioned, this is a good application to measure "time per cycle" rather then "cycles per time".

While MicroLogix controllers scan fast and have high-resolution timers, I still like to take advantage of the Event Interrupt (EII) function.

You wire your proximity switch to one of the fast Inputs (usually Inputs 0-3 on the MicroLogix 1100 or 1200) and configure an EII function.

The EII's basic function is to watch for a discrete input to change state and then executes a Subroutine.

The most accurate way I've found to measure time between DII interrupts is to use the system's "free-running clock". In SLC-500 and MicroLogix controllers this is status file word S:4.

In your interrupt subroutine, you can have something as simple as two rungs:

Rung 1: Move the value of S:4 to a storage register
Rung 2: Move a value of zero into S:4

And ta-daa... you have an event interrupt that gives you the number of clock ticks between events. The S:4 clock increments every 100 microseconds.

1.5 seconds = 1,500,000 microseconds = 15,000 hundred-microsecond counts.

 

[irondesk40]

Alright, now we're going to have some fun. [cracks knuckles].

As Paul has mentioned, this is a good application to measure "time per cycle" rather then "cycles per time".

While MicroLogix controllers scan fast and have high-resolution timers, I still like to take advantage of the Event Interrupt (EII) function.

You wire your proximity switch to one of the fast Inputs (usually Inputs 0-3 on the MicroLogix 1100 or 1200) and configure an EII function.

The EII's basic function is to watch for a discrete input to change state and then executes a Subroutine.

The most accurate way I've found to measure time between DII interrupts is to use the system's "free-running clock". In SLC-500 and MicroLogix controllers this is status file word S:4.

In your interrupt subroutine, you can have something as simple as two rungs:

Rung 1: Move the value of S:4 to a storage register
Rung 2: Move a value of zero into S:4

And ta-daa... you have an event interrupt that gives you the number of clock ticks between events. The S:4 clock increments every 100 microseconds.

1.5 seconds = 1,500,000 microseconds = 15,000 hundred-microsecond counts.

Thanks, to be honest, i will probably have to read this a few times to fully understand, never used a interrupt routine. How would you do it if you did not use the interrupt routine, hate to ask, but would you have a sample code

 

[bernie_carlton]

One unasked question. As noted in your first post, how close is "close enough"? What percent accuracy do you want? 1%, .1%, .01%? How the data will be used will help determine this. If you are watching a number go by then 1% will be fine. But if it's being used for some form of data collection or control of another machine then you may want another digit.

And how often do you really want to update? Every 5 seconds like your first ladder? After multiplying by 12 you have like 10% accuracy. What do you really want? That will determine the path of this discussion.

 

[Ken Roach]

This trick works because if you put any number (including zero) into the S:4 register, the controller will simply count up from there. As long as you're not using S:4 for other things in the program, you can use it for this purpose. It does not affect any T4:xx timers. Frankly, I'm not sure if it affects the Real Time Clock.

So let's see, there are 600,000 "ticks" of the 100 microsecond clock in a minute, so 600,000 divided by 15,000 = 40.000 cycles/minute.

To get all the data types to play nice in a MicroLogix you have to do a little juggling, from S:4 -> Integer -> Long Integer -> Floating Point.

Here's an example, untested:

 

[irondesk40]

thanks to everyone, will download sample and take a look tomorrow. rpm not used for any data collection or anything, just a reference on the display as to the machine cycle speed.
not sure how accurate it really is at the moment, i would guess if you shooting for around 32 cycles per minute by looking at the display, if someone from industrial engineering timing machine to set rate for pay based on how many packages etc.. coming off machine that the opertor running, then should probably try and make it as accurate as i can.
thanks

 

[irondesk40]

This trick works because if you put any number (including zero) into the S:4 register, the controller will simply count up from there. As long as you're not using S:4 for other things in the program, you can use it for this purpose. It does not affect any T4:xx timers. Frankly, I'm not sure if it affects the Real Time Clock.

So let's see, there are 600,000 "ticks" of the 100 microsecond clock in a minute, so 600,000 divided by 15,000 = 40.000 cycles/minute.

To get all the data types to play nice in a MicroLogix you have to do a little juggling, from S:4 -> Integer -> Long Integer -> Floating Point.

Here's an example, untested:

dumb question, looked at the sample and not exactly sure how you would use a input from a switch and use it in the logic to determine rpm, i know i must be overlooking something, getting late, so will take a better look tomorrow. thanks a lot

 

[OkiePC]

like that idea as well, will experiment with it tomorrow. once cycle starts, there is from 1.5 seconds to 2 seconds untill the cycle end signal goes true.

So, 1 / (1.75 seconds) = 0.5714285714 * 60 = 34.2857142857 cycles per minute

If i understand correctly what you are saying, once the cycle starts, start a timer, when cycle end signal goes true, move the timer value into a memory location. Do this for a few cycles, then add those values together and divide by the number of times you stored the value. does that sound correct? thanks to everyone,

Not exactly...I normally have a free running timer, in your case, .01 timebase, preset of 32767. No conditions, separate reset instruction later.

So, when the cycle complete bit goes true, i pass that through an inline oneshot (OSR or ONS depending on model!) to a bit.

This bit then triggers the storage of the accumulator, resets the timer, increments the FIFO (I use a COP instruction instead of the more cumbersome FFL/FFU pair) and updates the running average.

Sometimes, instead of just copying the ACC, I DIV the Tx:y.acc by a value with a Fa:b destination to typecast the operation, and give me cycles per minute for each and every cycle right off the bat. You need a DIV instruction anyway in order to turn seconds into minutes...

Often, though, knowing the duration of past cycles is more useful than knowing their "projected rate" which is what that gives you. Then you need to plan for rollover depending on the maximum totals your averaging logic must deal with, whereas, calculating a float cycles per minute for each object, and then averaging those, avoids the need to deal with integer rollover.

If the timer times out, you will have 327.67 second per product, so having some extra steps in cases where you're machine is down for longer than that duration will increase the accuracy. I normally just have a rung that CLRS my rate math if the DN bit is set, so I show "0.00 ppm" on the HMI instead of "0.18 ppm"...after machine starts, and with a rate of 30 per minute, and averaging the last three to five samples the on screen indicator will self correct in just a few cycles.

Methinks that for an operator feedback mechanism for a pot, you want to update the HMI immediately, if not Sooner, (no averaging, or do the averaging and show both...perhaps even allow the number of cycles for the averaging to be an operator adjustment.

Oh, the First in/first out stack is merely a COPy instruction.

I COP Fa:1 to Fa:0 with a LEN of 9 then I move the newest value into Fa:10, and average Fa: (10-number_of_samples) through Fa:10

 

[irondesk40]

Here is what i wrote on the bench during lunch today, i took the approach of using the time between prox is off and on. Appears to work, i simulated speeds with timers. Hopefully this is okay.