Use of counters on logic inputs

[Fernando]

I need help regarding some problems I’m facing using the high speed inputs on the equipment we have recently bought. My current configuration consists of:

– CPU Module(MPS046*100) 
– Mixed signal IO card (PCB122*100) address:0
– Relay I/O card (PCB129*000) address:1

I’ve successfully used the FB (SysGetCounter) with the CPU input (255.0). Is it possible to use also the 255.1 as an high speed input ?

I’ve also tried with to use the inputs from the relay I/O card with no success (inputs from 12 to 15) how can I count pulses from this inputs ? Can i use the same SysGetCounter to interface with them ? (the error I’m getting from the SysGetCouter FB is the 9981202)

[Sergio Bertana]

The SysGetCounter FB manages the physical hardware counter that is available on the DI00 of CPU module and on some I/O extension modules (please refer to its documentation). The Relay I/O card hasn’t the counter it has only the quadrature encoder counter and for this the FB returns an error.

Now the question is how faster is the clock signal you have to count, because by reading the logic input module on Fast task you can sample frequencies up to 400 Hz.

[Fernando]

In my application I have 4 “clock” signals. 2x 358Hz and 2x 60 Hz. So, would it be possible to read them with a normal digital input and counter FB ?

Before experimenting with the SysGetCounter I’ve tested with a normal I/O but the counter starts loosing pulses before reaching the 60Hz using an LD program (Fast task).

[Sergio Bertana]

The range of frequency can be read surely in a Fast task program but you have to make some considerations.

First consideration, the program at every 1 mS acquires the clock signal status, so other than the frequency it’s important to consider the signal duty cycle. It’s important to know how much time the signal remain active and not active, these times must be longer than the execution time of the program (1 mS).

Second consideration, in the Fast task program you cannot use the logic inputs mapped in the memory (I.e. %IX0.0) because these inputs are not acquired immediately but they represent the process image. To acquire the logic inputs immediately you have to use the SysGetPhrDI, get peripheral digital input FB.

Third consideration, the inputs on CPU module can be read fast they are directly attached to the CPU. The peripheral modules are connected by using a I2C bus and to read a module it’s required about 200 uS. For these reasons it’s better to use the inputs on CPU module for the signals with higher frequency and other inputs for the lower frequency. Moreover a single read acquires all the 16 inputs on the module so if you have many clock signals it’s better to connect them to the same module.

[Sergio Bertana]

To help you to understand better all the considerations reported before, I’ve developped an example project, that counts clocks from 4 digital inputs. As you see in the project print there are two ST programs (Source code download).

FastClockCounter: executed on Fast task acquires the 2 digital inputs of CPU module and manages two counters on them.

SlowClockCounter: executed on Slow task acquires the 8 digital inputs of estension module (Address 0) and manages two counters on them.

Considering that the program executed on Fast task it’s very short and to acquire the inputs form CPU module requires few uS, it’s possible to execute the fast task faster than every 1 mS. This allows to acquire fast clock signals, the minimum time can be set for the Fast task execution is 100 uS.

In the example project I’ve created the StartUp program, it’s executed in the Boot task and sets the Fast task execution time to 800 uS instead of the default value of 1 mS.

[Fernando]

Until now I’ve experimenting with a Lab, clock generator to be able to control the “Duty Cycle” I also thought this could have some part on the problem so I’ve tested with several “duty cycles”, but from you explanation it all points now to the way I’m reading the IOs and when they are realy sampled.

Also if I’m using the “LogicLab watches functionality” to look at counter value during runtime do this impact on the PLC execution time in a way that it could also lead to the problems I’m having now ?

I’m going to test the project you have posted and will post back the results.

[Sergio Bertana]

About the “LogicLab watches” they work on modbus communication they display the values at the end of Back task execution. All the communications as all the disk operations stretch the backround execution time but haven’t any effect on the Fast and Slow tasks.

Obviously I remind that Slow task stretches the Back execution time and the Fast task stretches the Slow and Back tasks execution time.

[Fernando]

Its working now. Thank you!

[Autore]

Post