timing issue or am I asking too much?

[jbrandall]

I have an FMD16-16 that is giving me fits.
Basically the plc has to monitor a shaft that is turning up to 90 RPMs and do some different things depending on other inputs.  I have an arm that passes a proximity sensor every revolution and I use the pulse period to calculate the speed of the shaft every scan.  While the shaft is making one revolution, another sensor is picking up 1 to 9 pulses very quickly. I think I have attached the program which has 31 rungs of ladder logic (not counting comments) and there are 22 custom functions which contain 55 IF/Then statements, some of which are nested.  I also read all 8 analog inputs, some 3 times quickly, as well as do several For I=1 to 10 Loops and control two PWM outputs.  Along with all that, I am asking for 64 bytes of data via a router and the hostlink protocol every 1/4 second.  I'm wondering if my problem stems from asking the processor to do all of it's work in the 2/3 of a second that it takes the shaft to turn one revolution.  What happens is that my RPM reading randomly goes way out of range and when I try to record it in memory, I sometimes get a double entry.
The problem started when I added this code: (and the function 'EndTrip' is called)
   IF juice_switch=1
      IF TESTIO(pickup) SETIO PumpOut SETPWM 2,5000,5 REM nozzle rate?
         IF injector_pump=1 SETPWM 1,7000,10 REM injector rate?
         ELSE SETPWM 1,3000,10  SETIO nozzles2 REM nozzles2 rate?
         ENDIF
      ENDIF
   ELSE CALL JuiceOff REM everthing off!
   ENDIF REM no juice

juice_switch is a DM memory location that I can toggle between 0 and 1.  pickup is input7.  Everything works fine up the point that I turn 'pickup' on WHETHER juice_switch IS ZERO OR ONE!??  Tried rewiring to input8 with the same results.  In my mind 'pickup' should not even come into play if 'juice_switch' = 0.

 I don't have a good concept of how fast a processor can do its calculations?  Is there a chance that I can't have the plc do everything I want in 2/3 of a second?  Is the PULSEPERIOD command interrupting the ladder logic?  It does recover and keep running, but the out of range RPM reading causes other problems.   How can I test this? What else could be wrong?

[support]

The best way to test is to simply cut off all other PLC activity and only run the pulse measurement/counting routine. It is true that the CPU can potentially get overloaded with activity, but this would typically affect program functions like sending data over the network or calculating data and not so much special inputs that use independent hardware, as is the case for the HSC and pulse measurement inputs.

In general, random extra counts are caused by switch bounce from the sensor or system noise. If the issue still arises after isolating the pulse measurement/counting routine, then this is the likely cause.

Most noise can be filtered out by adding a 0.1uF capacitor between the signal connection at the PLC input and common (0V). The cap should be wired as close to the PLC input as possible.

Bounce is more difficult to deal with and is best handled with software filtering. If possible, you can use an oscilloscope to view the bounce waveform and find out how long the bounce signal lasts each revolution. The PLC program should not accept any new counts within that time frame.

The program did not seem to be attached. Please send it to support@tri-plc.com with reference to this forum post.

[jbrandall]

Found it!  Fixed it!!  Mechanical relay coil collapsing field causing phantom/extra pulse some how some where.  I've been warned about this for years but have never seen it.  Fixed with a diode.  Thank you for heading me in the right direction!