itv-16 fast input on a slc 5/03

tinma10

Member
Join Date
Aug 2010
Location
maine
Posts
5
i am using a ivt-16 fast input sinking card for a pulse encoder, the pulse happen at a frequency of 2hz the prox switch from the encoder is 24v dc. the problem i'm having is the input starts missing pulses as i approach two pulse a second. even with the sti set to interrupt every two ms and the only thing in the ladder logic being a int and iim it still won't catch the pulses consistently. the l.e.d.s on the front of the input card are flashing in time with the signal that my o-scope is reading. been on the phone double checking with alen bradley support, they just keep saying it should work and now aren't returning calls or e-mails
 
Welcome to the Forum !

Go ahead and post that test program and folks can have a look. It should be no trouble at all to count pulses using that module.

I generally use the DII rather than the STI.

Is your pulse train a square wave with equal on/off periods, or is it a short pulse that comes every few hundred milliseconds ?

What is the maximum frequency you intend to measure with this controller ? Are you measuring frequency, or trying to count a specific number of counts for something like a position ?
 
the on/off duration are close to the same. the prox is reading pulses from a encoder wheel roughly twice a second. the program will use a bsr or bsl dependent on forward or backwards through the process.
 
Unfortunately I don't have time to figure out those BSL/BSR instructions and what they're supposed to do.

I would set this up by configuring the DII function to run Ladder File 5 instead of using the STI to perform an Immediate Input then returning to the main file. Attached is an example.

You can add a simple CTU or ADD instruction inside that routine to perform a speed test on this input, but I'm confident it can capture some pretty fast inputs (up to about 400 Hz in my experience).
 
yeah the problem exist even when the only thing in the processor is configuration and a iim on rung three with the sti executing it every three ms. only one of the inputs on the card is for the pulses for the encoder, i've never used a dii. the sti is the way that rockwells engineers suggested that i do it.
 
I personally think that the DII is the best choice for this application, rather than the STI.

I would set up a very simple test where you simply count pulses for 10 seconds while running the encoder wheel at a fixed speed.

My attachment didn't make the last post; the DII is similar to the STI in that you select a program file to run every time it executes. The masks and input configuration are different, of course, to select particular inputs rather than a time period.
 
I personally think that the DII is the best choice for this application, rather than the STI.

I would set up a very simple test where you simply count pulses for 10 seconds while running the encoder wheel at a fixed speed.

My attachment didn't make the last post; the DII is similar to the STI in that you select a program file to run every time it executes. The masks and input configuration are different, of course, to select particular inputs rather than a time period.

I have to concur with Ken's excellent advice, and disagree with the Rockwell Automation Engineers on this one. Using a DII makes much more sense when dealing with Hardware Triggers. STI has its place, and is very useful, but this is not the best Application for it. You will see much more repeatable results with the DII in your Application.

Stu....
 
believe i got it

the dii is giving me a nicer response without adding much scan time. the problem seems to be that the trend wasn't showing the digital signal that the processor was receiving properly. after setting up the dii i put the input on the same rung as a nearby output and watched the ouput flash in time with the input telling me that the processor is receiving and updating the data correctly and must only be the trend having an issue. is that a common thing or am i looking at another program. :nodi:
 
Don't rely on the trend tool in RSLogix500, or the visual indications as shown in any windoze program to tell you that a relatively quick pulse is working correctly.

You should be able to rely on the value in the counter address in the PLC to be updated accurately, although the display on your PC of that address will experience some latency.

When we switched from DOS to windows for PLC programming, that was my first gripe...I can no longer watch the bits diddle on screen like I could with DOS.

The histogram and trend in RSLogix500 are limited to update rates of about 0.1 seconds...
 
thank you guys you provided faster and more thorough support than even our techconnect contract. i was much appreciated.
 

Similar Topics

Hi All, I've been playing with 2 stratix switches in my test bench and seeing how different configurations affect the behaviour when 2 managed...
Replies
3
Views
189
Dear all, Im using Allen Bradley Compact Logix L36ERM as a PLC. and facing a problem where I need to create a FIFO buffer that fills an...
Replies
5
Views
1,640
Dear Members; We have Fluke 754 hart communicator. We have wired up three transmitters of Rosemount Model C3051 with this input module. But when...
Replies
4
Views
1,801
Hi all, I have several machines utilising a PF755 on CIP motion. Occasionally the operator reports the jog speed ramps up rapidly, then the drive...
Replies
2
Views
1,326
Hello guys, this is my first post on this forum and i hope u can help me. Im doing a project where we need to read data in the Wincc Professional...
Replies
0
Views
1,012
Back
Top Bottom