scan times

I have a large program with a high scan time I am looking to reduce the scan time so I can pick up a prox. on a screw shaft with a fast sink card in stead of a HSCE (Older SLC-L532) on a setup. I have read several posts on how the SCP
Instruction slows down the scan ,I have 11 running along with a with a lot of other function blocks doing my calc. One of my questions was weather the scan time on the processor running in emulate on my lap top was an actual to what it would be in the machine. Second was weather an STI would be work to keep the prox count refreshed. I will continue to look for opportunities to reduce the scan. i noticed bu stopping the scan of just my one ladder doing the math cuts my scan time in half. is the scan time , Current (x10ms) S:3(low byte)=12
really 120ms, Thanks any input is appreciated.

can you code only one SCP block to be on one scan, so you need 10-11 PLC scan to update every SCP function.

Years ago calling only one PID or math block at time was one way to reduce scan times. There is no need to update all blocks on every scan, if you don't need rapid changes on some functions. Also different functions used different amount memory and processing time.

Yes, when working with large/slow systems the key is to only run blocks when needed.

Set up a counter that is counted up by one each scan and is restarted to 0 when it reaches 9. So it goes 0,1,2,3,4,5,6,7,8,9,0,1,2,3,4 etc.

Then you can select which blocks should run on which count. With that you are able to distribute the cpu load as you which.

Floating point operations are a lot more work for the CPU than logic. So go after that first.

Thanks for the quick reply. I am looking for ways to break up the ladder on scans and the counter will work. I only need these functions to run on setup and I could break up the setup by axis on several of them so they are not all running simultaneously. I use the SCP's also to give the real time settings to the screen but could set up some thing to not scan them unless there is a move initiated.

[Is] the scan time on the processor running in RSLogix 500 Emulate on my lap top [equal to] what it would be in the machine ?

Click to expand...

No, all of A-B's Emulators specifically do not attempt to run at the same clock speed as the controller. Emulate 500 is nice for testing the results of calculations or operations, but cannot emulate anything time-related, including PID.

It's a worthwhile exercise to reduce your floating-point and complex math burden on the CPU, so keep going with that.

But let's talk about the high speed input.

How fast is that shaft spinning ? Do you know how long the input pulse from the sensor flag is ?

Is your goal to measure speed, or attempt to measure total number of revolutions ?

The Discrete Input Interrupt feature might be worth looking into. It can trigger a specific Routine after it has collected specified number of counts in the background.

If you're trying to calculate speed, being able to grab the controller's free-running clock value after a specific number of pulses is one way to get the two values (counts and time) that you need to calculate speed.

I am counting pulses on revolution (8) for measurement, I will get an actual RPM
but it is not real fast.I was sending the input to IBT16, I have ran this program on other machines but used HSCE on all the axis, I am currently doing R&D on
another one and was trying to simplify it with less HSCE and encoders on some of the screw shafts. The tolerance is not so critical that it requires an encoder.
I am reading through the RS 500 Instruction manual I have never used the STI or DII instruction before. I am sure there is a lot of my program I can simplify.
Thank you for the information on EMULATOR this was something I questioned.
I ran a test on the machine using 16 ppr last weekend and it looked like that was to fast for either the scan or the ITB16. I ran a test a month ago with 4 ppr and it measured out fine. I was hoping the 8 ppr would work it will give me enough resolution but figured I would test the 16 befor I milled every other tooth off (using split sprocket) I only get the machine on weekends to do R&D so I have been running the Touchscreen OPC in Runtime Test and the SLC program in Emulate to test the functionality. I simulate the prox inputs with an S:4/4 bit and started to get concerned it was running slow.

As Ken mentioned - Look at the DII (Discrete Input Interrupt) function of the SLC. I think it is the only way you will get this to work other than a high speed counter card.

Thank you: I am reading up on how this function (DII) works and the best way to implement it per my situation. On another note I isolated all my SCP's and their scan and had no change in scan time. As Ken mentioned I am using 500 Emulate so this may not be an actual representation of scan time, although when I stop the scan of the entire ladder with them in it my scan time is cut in half on emulate. The only other functions I see continually being scanned in the ladder are LIM functions. Do they take a lot of scan time. Would I be better off with GRT-LEQ in series or perhaps isolate them with a bit to only check them when a set up is called for on that axis. The scan time I am reading (again in Emulate) is without a setup being called for, I will load program Friday, since it is basically already running in machine and does not affect the manual operation of equipment, and I will see what the actual processor scan time is. Thanks for the input and I will get cracking on understanding DII

Use one of the Turck Smart Plugs: http://old.turck.us/Products/Sensors/Smart_Plugs/

It will pick up a short pulse and give your PLC a longer one.

Have a read here for some basic advice on the limitations of using a digital input to count pulses...

64449 - Using a Discrete/Digital Input Module as a Counter Module
Access Level: Everyone

It basically says that, in general, you should be OK once you are not trying to count faster than 5 pulses/second, else use a dedicated high speed counter (HSC).

Also here for some advice similar to the above on using a DII...

40753 - Digital Input Pulse Counter: Maximum Input Frequency (Advice)
Access Level: TechConnect

Russ's solution would be ideal if speed is an issue for you. After 8 pulses at the sensor it will give you one pulse for a revolution, so the Pulse Per Revolution (PPR) is lower but still usable to calculate the RPM.

Using either method here i.e. counting raw sensor pulses, or Russ's pulse counter sensor, the PPR is very low. Either 8 PPR or 1 PPR respectively. With a low PPR the Period Measurement Method is preferred over the Frequency Measurement Method when calculating RPM.


Where Pulse Period = time from start of one pulse to start of next pulse
(which you must measure)

&

PPR = 8 (raw pulses)
PPR = 1 (Russ's pulse)

One pulse per revolution is usually better if the many pulses per revolution are not symmetric, else the RPM calculation will fluctuate. But low PPR means low resolution of the resultant RPM output.

Note: For PPR = 1 the maximum calculable speed is 60 RPM. If your application is running faster than 60 RPM then you will need a higher PPR.

I would stick with trying the 8 PPR first and using the DII to execute your RPM logic and see how you go.

Regards,
George

Thanks
I am using the 8 ppr for measurement the screw is 7 threads per inch.and moves a head on a slotter machine (corrugated box) there are 4 heads each with their own screw. I either add or subtract pulses based on screw direction and have a TOF set up to pick up any pulses on a drift once motor stops. I set it lower than the anti plug timer so direction could not have changed. I believe I am getting the pulses to the ITB16 ok, I was worried that the scan time through all the ladders would be longer than the pulse intervals and therefore I would miss pulses.