programming the AB 1746-HSCE2 to measure rate value.

I'm using a slc504 with a 1746-HSCE2 high speed counter card. I need instruction on how to develop the necessary logic to make this puppy count between 40 and 60 Hz. I have two 24vdc proximity switches looking at bowl and scroll speed on a sludge centrifuge. Thanx, gary

u r outof luck

ask jaime

Thanks, "guest", that was both ungrammatical and unhelpful. One more and you'll have pulled off the lurker's hat trick.

I think the problem with Rate Mode at low frequencies with the 1746-HSCE2 is that the module calculates frequency every sixteen milliseconds.

If you have a 60 Hz signal, that's one pulse every 16.6 milliseconds. Depending on the width of the pulse and it's timing relative to the end of the measurement period, you're going to measure either one or zero pulses per period, leaving you with a measurement of 62.5 or 0 Hz. You couldn't measure down to 40 Hz.

What you need is an accurate timer with a longer measurement period. An I/O block with a built-in counter (like 1791D with DeviceLogix) might be one way to do it, or maybe a tiny Micrologix or other 24VDC input controller with high-speed inputs that could count the number of pulses across a full second.

Does the counter card only work in 'rate' mode?

Can the card be set up for count mode? Does the card support 'roll-over'? I mention this since it appears to be a centrifuge application, meaning the prox switch pulses will occur 'forever' as the unit rotates but obviously the count limit must be finite.

Lastly, exactly how fast do you need to update the rate information.

How precise does it have to be?

It might be possible to write an STI that runs at say 1000msec and use this precision time base to measure change elapsed counts. If speed is not an issue, you can write a filter routine to smooth the calculated value. You'll need to add logic to test for rollover to avoid a bogus delta value.

The STI should contain an immediate input instruction to read the data at the start of the interrupt.

Make sure the Interupt Latency Control Bit is set to a value of '1' for best results (S:33/8). This will give you a more deterministic time base.

If you are just using this rate value for a HMI display, then this solution should be more then adequate. If you are trying to perform some type of high speed control using this value for feedback, it probably will be too slow and not accurate enough.

Thanks to both Ken and Greg for their helpful suggestions. I believe the rate value mode will not work for my application because the module calculates the frequency every sixteen milliseconds and this is just to quick.

I think I'll switch back to the counter mode, run a STI instruction every second, and then use a filter routine to smooth the measurement as was suggested by Greg.

These signals are used to control a differential of about 70 rpm's. so hopefully the one second update won't be to long. The bowl is fixed at 1460 rpm so the diff is controlling the speed of the scroll to scrape the sludge from the bowl. I'll try it Monday.

Thanks again, Gary

jaime answering

it was not gramatical error its my name, and helpfull I am tired of being helpfull to him I always do his job. So he can ask me again

THIS IS THE LAST TIP I GIVE YOU ,IF YOU WANT MORE I AM GONNA CHARGE YOU OK? if you cannot do it let jaime do it he knows how.guys overhere dont know much about it but I know it you want it I want $$$$ here it goes:In the CPU cycle, it is not possible to measure speeds with sufficient accuracy in ranges that are usual in engineering.

Here you select a method that uses high-speed counters and a time interrupt (e.g. HSC3). The requirement here is that when the CPU is switched to "RUN" with the first cycle, the counter is initialized, the interrupt defined and assigned to the counter.
For this with the first cycle bit (S M0.1) you switch to a subroutine (e.g. subroutine 0), in which the time interrupt cycle is defined. Since the first cycle bit is only set in the first cycle after switching to the RUN mode, this interrupt setting is done only once.
Select, for example, Interrupt 0. The cycle time for the interrupt event 10 is written in SMB34.
In the example, Interrupt 0 is selected. You may only assign one specific interrupt to each process. You can of course increase the time interval of 10 milliseconds to any length you wish. When calculating the speed from the number of pulses you must take this interrupt time into account accordingly. The counter always stores the number of pulses per interrupt time interval in the variable double-word VD0. If your rotary pulse encoder delivers, for example, 50 pulses per revolution and your interrupt time interval is 10ms, then the rpm is calculated as follows:

(VD0 = number of pulses every 10ms) *6000 / 50.

For the pulses of your rotary pulse encoder to be transferred to the counter, you simply have to connect the signal output of your encoder to input E0.1 of the counter HC3. (If you want to use a different counter to the one in the example, it will of course have to be the input of the counter you choose).

just email me with a dollar bill in it and you will have the rite answer

Troll Alert...

The only way to deal with trolls is to limit your reaction to reminding others not to respond to trolls

"The only way to deal with trolls is to limit your reaction to reminding others not to respond to trolls"
If you know too much ,why nobody has had any good answer for this or the only thing you guys know is the "I am new and need training" i see zillions of answers to these because are easy to answer ,but this is a good one and laughing to youguys nobody seem to have experience on this but myself, any way my point is he wants the help he has to pay for it he knows how to get me, and I am not a troll just somebody who likes this hobby.Have a blessed day.

Troll

Troll:
If your are self sufficient, maby you should not waste your time with the rest of us.

I will not charge for my answers, and it will be right, troll.

Wow, this is a blast from the past.
Just for posterity, the HSCE2 will work in rate mode this application. Saying the update occurs every 16 msec is only partially correct. On the leading edge of a pulse on the rate channel the HSCE2 saves the value of a free-running timer and starts accumulating counts. After 16 msec it waits for the next leading edge and again saves the value of the free-running timer. So now you have an integer count value (but at least 1) and a high resolution time value to go with it. Divide counts by time, add some scaling and you have frequency. The thing to keep in mind is that at count rates you will get an update every 16 msec or so. At lower frequencies the counter must wait for a leading edge and that will delay the update.
Keep in mind there is a minor typo in the HSCE manual that can cause a whole lot of grief. Page 4-22 talks about the program counter bit in the counter control block. It seems to infer that you can have bit zero on along with bit 15, since it says that bits 1-14 need to be off if bit 15 is on. This is not correct. If bit 15 is on all other bits in that word must be off.

Keith

I agree with Keith here. There could be some confustion between the 2 flavors of high speed counter modules here: The plain HSCE and the HSCE2. It appears from what I can get out of the sometimes error prone manual (AB Pub:1746-UM002A-US-P) That the HSCE-2 will change it's rate sampling period based on what it is seeing on the input. There is a table on page 2-8 that looks something like this:

Rates (Hz)   |  Time Between  |  Time Between

             |  Pulses (ms)   |  Updates (ms)

-------------+----------------+-----------------

1 to 59      | 17 to 1000     | 17 to 1000

-------------+----------------+-----------------

60 to 1000   | 0 to 16        | 0 to 33

-------------+----------------+-----------------

Above 1000   | 0 to 1         | 16

-------------+----------------+-----------------

Further evidense of this 'hunting' behavior is found in Appendix E
on the differences between the HSCE and HSCE-2 where it lists the HSCE-2 as having a self-determined rate period.

Here is another tidbit from the manual on how to get the most accurate reading from the rate counter (from page 2-9):

Accuracy
The accuracy of the rate value can be ±0.005% (typical).For this resolution, the rate measurement value must be transferred in single-precision floating-point format. This format is only available when the module operates as Class 4. Fractional rates, those between 1 and 0 or -1 and 0, are not reported. The rate measurement value can also be transferred as an integer value. The integer format is available in both Class 1 and Class 4.

Click to expand...

Good Luck