Frequency input MC4xx

Have you checked the signal amplitude vs. the MC42 trig levels?

If you have a picoscope or similar simple oscilloscope, it would be good to check how the signal looks like when it doesn't register at the MC42.

The pull-down of the MC42 should bring you below the required 1 V for low trig.

What voltage does the PNP sensor bring the signal up to?

Could it be that it is so close to the required 4 V that when the frequency increase, it does not have time to rise above the trig level?

Thanks you for the reply.

It seems that the switching voltage is the supply voltage (12V+ in this case). 

Could it be that the signal stays High and does not drop low enough at higher Hz?

SPEC:

Yes, in that case it sounds more plausible that the problem is that the sensor output does not drop low enough as the frequency increase.  

If you can get a scope measurement of this it should be clear, but if you are in a rush and don't have an instrument at hand, you could try adding an extra external pull-down resistor. 

The MC4x has a 6.8 kOhm pull-down, so at 12 V you are loading the sensor with about 1.7 mA when the output is high. 

Since the sensor datasheet states that it can survive up to 50 mA loading current, you should have a pretty good margin to experiment with external pull-down. 

Another factor to consider is the cable, it could be interesting to try out how it works if you run a shorter cable length for testing purposes.

Thank you for your valuable feedback!

The external PD resistor did the trick. 

We started off straight away with a 1k resistor and immediately got an accurate and stable reading. So a 1k is what we are using.

Thanks again.

Hi there again,

I have another anomaly regarding the frequency input... We now get a stable reading from our sensor which is good, but it seems that the reading is lagging a bit, it takes about a second or 2 for the input reading to change to the actual Hz.  

The problem is that we need to limit output functionality on a machine as soon as the RPM drops below a certain value. Now what happens is the RPM drops too low too quickly before the logic responds. 

the functionality must reduce with the RPM drop but without so much latency.

Is there anything that I can do to get a faster reading from the input?

Hi,

The modules system cycle time controls the sampling rate.  The CAN messages it transmits must be a multiple of the system cycle time.  In one closed loop control system I am working with, I have the system cycle time set at 10 milliseconds (mS), with CAN transmit rates set at 50, 100, 250, and 1000 mS, depending on the type of data associated with each frame.

Good Luck,

Mark

One clarification.  All inputs on any IQAN module are sampled once per system cycle time.  Setting the system cycle time to 10 mS means that particular modules inputs are sampled 100X per second (1/.010).

Best practice is to figure out how fast your control system needs to work, which in turn will dictate how often the inputs need to be sampled, which must be faster by a factor of two, at a minimum,  per the Nyquist sampling theorem.  I would suggest you determine the rate of change in RPM for which you need your system to respond (RPM/second), which in turn will determine your system cycle time for that module.