Proximity switching time.

allscott

Member
Join Date
Jul 2004
Posts
1,332
This is going to sound like kind of a dumb question. I am dealing with a proximity switch that is switching too fast for my PLC to see. It is skipping pulses occasionally.

I plan on fixing the problem with a pulse extender, this one to be precise.

http://www.balluff-ua.com/pdf/KT_PulseExtender_EN.pdf

Can I assume that if I can see the light on the prox switch on and off that the output of the sensor is also switching at the same rate? I assume the circuitry that turns the light on is part of the circuitry that also switches the output.

I can physically see the output switching on the prox every time but when I monitor in my PLC I miss the odd one as the process speeds up (PLC 5). The application is a single pulse on a wheel that is turning up to about 1 pulse/second max. The scan time of the plc averages about 50ms. The input is a regular 24VDC input on RIO. I thought things would be fast enough when I installed this prox but I was wrong.

Any other advice other than what I am planning?
 
The scan time of the plc averages about 50ms.
That is a very slow scan speed... your program must be quite large. For purposes of comparison, I was in a similar situation with a SLC500 system that had a scan rate of about 20 ms. I had issues with a number of prox sensors that were looking at parts moving by at high speed. The lights on the sensors were clearly blinking, but the PLC would not consistently pick up the blips. I added a pulse stretcher to the offending sensors (a Turck SmartPlug) and that solved the problem.
 
It is a very large program with lots of PID's, BTR/W's etc... and a lot of Remote I/O. To be honest I never even considered scan and I/O update time as an issue when I installed the prox, and well here I am...

I will have a look at Turck and see what they have, thanks.
 
Pulse extender is probably best with 50ms scan time. You could try a larger diameter prox, larger diameter target, more iron content in target, closer sensing distance, use a magnet target.
 
Hi,

PLC 5 have a PII option [Processor Inputs Interrupt, selectable from the controller properties]which scans a sub routine upon the input is interrupted.
Back in the old days we used to tie sensors which detect minute objects to it and count the numbers accurately. It was very useful as the gap between each sensor trigger was very small itself, no room for pulse extenders. [for example - count a 40 pin connector pins which is enclosed in around 45mm cage moving at >500mm/sec]

Some info can be found on this thread.

http://www.plctalk.net/qanda/showthread.php?t=18609

Regards
 
Why not increase the detection area of the wheel. If you increase the detection area to Half the size of the wheel then your pulse would last 500ms at 1 RPS 10 times your scan rate. If you only care about 1 on and 1 off pulse per revolution. That seams to be the simplest and cheapest solution.
 
PLC 5 have a PII option [Processor Inputs Interrupt, selectable from the controller properties]which scans a sub routine upon the input is interrupted.
Back in the old days we used to tie sensors which detect minute objects to it and count the numbers accurately. It was very useful as the gap between each sensor trigger was very small itself, no room for pulse extenders. [for example - count a 40 pin connector pins which is enclosed in around 45mm cage moving at >500mm/sec]

Some info can be found on this thread.

http://www.plctalk.net/qanda/showthread.php?t=18609

Regards

Ok, I never knew what the PII tab was for. I have set one up but haven't been able to test it yet. My question is since this is a remote rack how do I know how fast the RIO is being updated? I thought (and I may be wrong) that RIO ran asynchronous to the scan and the information was held in a buffer. Is that correct?

Also the PII asks for the rack and group which in my case is Rack 2 group 0. So I entered in 20 into S:47 in the processor tab. Does that mean it will monitor the entire word for an Input change? I don't see anywhere I can specify an actual input bit. I set the file number to 26, the compare value to 1, and ran a clr instruction on S:51 at the end of Lad26. Am I missing anything?

I am also curious as to how this will affect the STI that is already in the program? Lad 3 is an STI file that has all the PID's in it that is set at 100ms.
 
Last edited:
Why not increase the detection area of the wheel. If you increase the detection area to Half the size of the wheel then your pulse would last 500ms at 1 RPS 10 times your scan rate. If you only care about 1 on and 1 off pulse per revolution. That seams to be the simplest and cheapest solution.

I could do that but it will involve machining a radius in the wheel and then machining a piece of metal to insert into the wheel. There isn't any room to just make the flag much larger in diameter or make the prox much larger.
 
Hi,

There are some considerations need to be taken when choosing PII, it had precedence over STI. STI will only be executed after the PII routine is completed. So it is important to keep the PII routine as simple as possible.

Please read the PLC 5 user manual for more details. My memory is vague as well, it has been more than 8~9 years I used a PLC 5. And I stopped installing RSLogix 5 in my new PC as we do not have anymore projects with that beast. [Customers became more cost conscious, maybe]

http://literature.rockwellautomation.com/idc/groups/literature/documents/um/1785-um012_-en-p.pdf

BTW to specify which inputs to have PII function you need to use the Bit mask S:48 & Compare Value S:49

Regards
 
pii will not work as it is a RIO.

Try in your program to run only the needed routines at that time.
So when you have seen the prox run the visualisation and others, then stop everything and wait for this prox again.
 
allscott said:
...I can physically see the output switching on the prox every time but when I monitor in my PLC I miss the odd one as the process speeds up (PLC 5). The application is a single pulse on a wheel that is turning up to about 1 pulse/second max. The scan time of the plc averages about 50ms. The input is a regular 24VDC input on RIO. I thought things would be fast enough when I installed this prox but I was wrong.

Any other advice other than what I am planning?

allscott,

What are you doing with the signal? Are you trying to calculate the speed of the wheel from the number of pulses, or similar?
i.e. do you need pulses?

Or are you just monitoring the rotation of the wheel for underspeed to stop the wheel if the pulses fall below a certain frequency?

If you are just looking for confirmation that the wheel is rotating at a minimum frequency, then I would suggest using what I call a 'centrifugal effect' proximity sensor.

When I used to contract I did a lot of work in the grain handling business, specifically Maltings. That industry uses a lot of analogue process control - speed, air/water temp, moisture, CO2, valve and pump modulation. Although using older Texas Instruments PLCs, likewise, the programs could be complex with a lot of PID loops and special function routines. So scan time overheads could be relatively high.

The industry also uses many belt/chain conveyors, bucket elevators, large rotating fan belts, etc., which, in our case, all required rotation monitoring for underspeed on the non-drive end (belt or chain brake). The standard proximity sensors we used involved long runs back to the PLC. We suffered the same problems with seeing the pulses at the sensor, but missing pulses in the program. We found and sucessfully used hundreds of Telemecanique XSA-V proximity sensors.

These sensors internally monitor the impulse frequency and output a steady signal to the PLC once an adjustable preset frequency is reached or exceeded. This is why I call them 'centrifugal effect' sensors. You adjust the required RPM threshold using a trim-pot on the sensor. They offer a couple of RPM ranges to suit different applications.

These sensors also simplify your monitoring logic in the PLC as you don't have to monitor the on/off pulses, but instead just monitor for presense/loss of the steady input signal with a short de-bounce timer.
There is also a built-in 9sec run up time where, when they first sense rotation, they switch the output high for this duration, and then switch to normal monitoring mode. This also saves you having to program logic to ignore the signal for a time during run up.

As Telemecanique are now Schneider, the older Tele XSA-V range now fall into Schneider's OsiSense range, but is still catalogued as XSA-Vxxxxx.

I've attacted the Data Sheets for both the older Telemecanique XSA-V and the newer Schneider OsiSense XSA-V.

The XSA-V11373 is the DC 6-150 impulses/min model, which would suit your 60 impulses/min range.

If of course it suits your application.

G.
 

Similar Topics

I am new to the forum and don't know a lot about electronics. I am learning as i go, and i am hoping someone here can help me. I am looking for a...
Replies
4
Views
3,154
Hi all, First, thank you for reading the thread. So I had a task as the following: An up-counter must be programmed as part of a batch-counting...
Replies
7
Views
238
Hi Members, Currently, I'm working with Motor Generator speed measurement. Just wondering if possible or not my integration system for speed...
Replies
5
Views
1,882
Hi please need your help, can I install the Proximity Probe 21508-02-12-05-02 Bentley Nevada on the drive 1442-DR-5850 from Allen-Bradley using...
Replies
2
Views
2,132
Newbie here - I'm working on a project for a class and experiencing problems with getting my proximity sensor to activate a solenoid. I'm using...
Replies
9
Views
3,298
Back
Top Bottom