Using a proximity switch to detect speed

Hi,

First time posting a question so bear with my ignorance.

I'm trying to figure out an easy way to use the pulsed output of a proximity switch to provide 2 basic functions:

1) A zero speed switch which will shut down the system if the proximity switch does not pulse at least once in 4 seconds. (OK, I think I know how to do this. ..The second one is the harder one..)

2) Measure the period between the leading edge of the pulses from the proximity switch. Details: Reading off of a 48 tooth sprocket at between 0.40 to 1.50 RPM. Very slow system.

I would like to use the calculated speed to vary the output of a variable speed drive to increase the rated speed regulation to a more acceptable level. (Approximately 0.25%) The VSD is controlled by a 4-20mA signal from a PLC. The PLC will integrate the prox speed feedback to slightly alter the 4-20mA signal from the PLC to match the commanded speed more accurately.

The VSD is a Mitsubishi FR-S510-0.4K which has a rated speed accuracy of 1% of full speed. Full speed at 75Hz is 1.5RPM. Lowest speed is about 20Hz (0.40RPM).

Any ideas?

Thanks.

prox and other such fine things

Beej, or is it BJ? It sounds as if you have all your facts laid out and know just what it is you would like to do, so what is stopping you? Try your hand at some code and see where it takes you. If you have some particular code that you have tried and need help with, there are folks here who will be able and willing to do that. However, you will find that since there is no consulting fee attached to answers posted here, very few of the regulars like to do consulting for free. Advice is often free, consulting is very seldom ever free. Go for it and be bold.

You'll get better results putting a feedback module on the drive and mounting an encoder on the motor. If the drive model doesn't support feedback, upgrade to one that does.

Trying to regulate motor speed using a feedback device attached to the driven load instead of directly to the motor is difficult due to the dynamics of the gearing between the motor and the load. Tuning such beasts is no fun, and the results are usually less than you hoped for.

Closing the speed loop in the PLC will be at least an order of magnitude slower than a properly implemented feedback module on the drive. By that, I mean that the drive should be able to calculate the speed error and the required correction to the speed command at least ten times faster than a PLC can.

So it sounds like you are trying to get a precise and accurate reading from a slow moving object. The slightest variations in the speed you read are going to cause considerable fluctuations in your "fine-tuning".

I think you would do better to "read" something, anything, that is moving faster!

You should certainly keep your zero-speed sensor at the end of the driven line.

For speed, you have to find some way to read more data, more often!

Fig-1:

0.........1.........2.........3.........4.........5...
0.........1.........2.........3.........4.........5...
.........1.........2.........3.........4.........5...


Fig-2:

01234567890123456789012345678901234567890123...

An awful lot of stuff can happen between 1 and 2 in Fig-1. Your speed could be dropping towards zero and you won't know it. Then, when you finally trip the sensor, your "correction" to the 4-20mA signal is going to be HUGE!

And, as slow as it is going, things like humidity, dust, and what-not can have an effect on where you actually detect the tooth. That also will cause HUGE, unwarranted changes in your 4-20mA.

The key is to make small corrections, often. As in Fig-2.

And the idea of "modifying" the commanded speed is not so good. That value should remain as the reference.

For your first objective, the zero speed switch, you just need two time delays. One is enabled when the contact is closed (NO contact from the input in your ladder logic), the other is set when your contact is open (NC contact from the input in your ladder logic). if either delay times out your system has stopped. You put a contact from each timer in parallel to set the alarm coil.

I'll disagree a little with the others on the speed control. First of all, the output speed regulation of most VFDs is quite good, and if you tell it 75% speed you will get 45 Hz and the motor will run at 75% of full load speed. The only variable is the motor slip and andy slip in belts in your system. If you need very precise and fast response control, Steve and Terry are right, and I would follow Steve's reccomendation. however, if you can afford some time delay and a little error, you can use a high/low comparison, add/subtract a small increment to your output, and use a time delay between checks. If you have a "deadband" in your comparisons you can get stable control with a minimum of tuning.

What consulting fees?

And consulting is what again?

Using a proximity switch to detect speed.

Man, you guys are amazing! I just posted these questions a couple of hours ago!

In response to my name, I pronounce it "Beej" not "Bee Jay".

Tom, I was considering something very similar in regards to the "zero speed" sensing. Thanks.

On the second question, I understand the concern about trying to close such a loop with a prox rather than a more precise solution such as an encoder. Our problem is that this problem just reared its ugly head recently when we discovered that one of our customers (in Japan) had a very large variation in speed that seemed to coincide with a sizable temperature swing. Our in-house testing seemed to confirm the existence of the problem but not to the degree (no pun intended) that they did.

Unfortunately, we have already spent a fortune on European EMC testing with this drive and are therefore "stuck" with it. It's also very cost-effective and allows us to penetrate markets that we would otherwise miss if we "over-engineered" the equipment. Adding an expensive encoder would not be well received. Did I mention that it's also in a Class 1 Division 2 Group B hazardous location?

Factors working for me include:

A very smooth load. Variances will manifest themselves over minutes or even hours. A "self-compensating" 4-20mA speed reference could be very useful to offset any temperature-induced differences in speed.

BTW, the drive has a +/- 1% speed regulation capability but it's only guaranteed between 15 and 35 Deg C. It's anyone's guess what the variation would be outside those temperatures.

Thanks again.

Beej

Sorry guys, I'm not trying to get free "work" from you, I'm should rephrase my question to read:

Do you think it will be possible to make this system work? The programming will actually be left to the Customer (who integrates the system into their plant) but we will provide them with some example code.

Re: Using a proximity switch to detect speed.

Beej said:

Man, you guys are amazing! I just posted these questions a couple of hours ago!

Click to expand...

Hence the forum title "LIVE PLC Questions and Answers"...

Terry's point about wild speed variations is something to be very concerned about. You may need to look at the change in speed over a period of time to confirm that the information is valid, so you don't make unnecessary alterations.

Another solution might be to ramp the changes slowly.
IOW, if the speed changes drastically, don't compensate drastically...

See THIS POST I made a while back about "smoothing". It (sort of) explains my slow change idea.

beerchug

-Eric

Thanks for the "Consult"

Hey Beej, I have a very similar situation. The prox keeps croaking due to HEAT (the system is a very fast rotating kiln up a max of 1.5 RPM when it is really going and about .5 when slowed down) Currently the location of the sensor is the prob now to relocate (below current location and looking up) and use a Toothed gear of a larger diameter to sense off of and a heat blankey over the heat shield (26guage sheet steel). Thanks for the read it WILL go into use.

Beej,

Can you clarify the nature of the speed variation over a temperature range? Let's say that you're using a PLC analog output to generate the 4 - 20 mA speed reference to the VFD, and you're maintaining a constant value in the analog output register.

Is the problem;

1. The analog signal varies with temperature?
2. The frequency output from the VFD varies with temperature while the analog signal remains constant?
3. The motor speed varies with temperature even though the VFD's frequency output remains constant?

If the problem is either #1 or #2, would it be easier to maintain the PLC or the VFD within a tighter temperature range?

Your proposed solution could work, but it could also introduce some new instability into the system. You're trying to maintain a constant motor speed. The further you remove the feedback device that measures motor speed from the motor, the greater the potential for instability. What you could wind up with is a system where the average motor speed follows the speed reference more closely, but with more 'ripple'.

Increasing Resolution

Here is a little something to think about. Use two prox.'s picking up the same gear but physically mounted in such a way that they are triggered alternately 1/2 tooth apart. That should double the resolution. Another suggestion, if the teeth are wide enough then use the "OFF" state of the prox to trigger a one shot and the "ON" state of the prox to trigger a second one shot. Then with a little bit of logic drive a counter with both changes of state. Next compare the count during a time period to develop the error correction signal. Is the 48 tooth sprocket is part of the actual drive train or a dummy just for the prox pickup? If it is possible maybe you could mount an additional sprocket and add some more prox's that way. I know this doesn't sound like conventional methods and maybe even a little crazy, but sometimes weird things will work.

Sid

Turck makes a good product but these guys are right you should increase your counts for greater resolution/better control.



http://www.turck-usa.com/products/interface_logic/pdfs/auto_C21-22.pdf


Roger

okiebob-

Here's a great switch that I use in Hi-temp applications (up to 400 deg. F).

Topworx GO Switch

This is what I've come up with in respect to the "zero speed" aspect of the prox logic:

Drive running
-------||--------------Timer set for 4 seconds

Prox input
-------||-----[ons]----Timer reset

Timer Prox Alarm!
-------||-----------------(L)--
Dn.bit

So, if the drive is running, the timer will start timing. The proximity switch will reset the timer before it reaches 4 seconds. If the timer reaches 4 seconds, it will latch a proximity alarm bit.

The one-shot is to guard against the drive stopping on a geartooth and keeping the timer "reset".

jrwb4gbm, your idea of using both the "on" and "off" states of the prox is an inspired one. The fact that the on/off duty cycle is probably not exactly 50/50 makes me think that you would have to have an even count before doing any math on the period. The sprocket is part of the driven system.

I'll have to look into the costs of the Turck and Topworx products, we have a really tight budget. Thanks for the info, though.

Steve, we tried to get this specific information from the Customer, but since the unit was only a test unit and the test is over, they were reluctant to look into it any further. My gut feel is that the high control cabinet temperatures were affecting more than our VSD. The PLC shares the same cabinet as well.

Thanks again for all your help, guys. I'm going to be signing off for the weekend. Have a great weekend!

Beej