Digital input acquisition speed expansion modules

[Authorless]

Looking at the hardware data sheet of the modules slimline, you see that there are inputs called high speed, what is the difference compared to the other available inputs?

If you want to read encoder pulses with maximum 200Hz frequency, you can also use non-high speed inputs?

[Sergio Bertana]

The high speed inputs are made with very fast optocouplers, and can acquire input signals with a maximum frequency of 50 Khz. All the other inputs have slow optocouplers and can acquire input signals with a maximum frequency of 10 Khz. But beyond the electrical speed limit, it is necessary to enter the operating logic of the acquisition module to understand its possibilities and limits.

A 5 mS digital filter is set up on all inputs (even the fast ones) which limits the maximum acquisition frequency to 200 Hz. The filter has been inserted to cut the rebound signals (Debouncing) of the electrical contacts, a PLC must acquire signals arriving from electromechanical transducers and must guarantee their correct acquisition.

On the fast inputs there is a counting circuit which uses the signal before the filter it allows to manage a quadrature encoder with a maximum frequency equal to that typical of the optocoupler.

[Sergio Bertana]

But to answer your question, I remind you that the FB exists in the function block library IOEncoder, incremental encoder over I / O (See manual extract). By connecting two digital inputs to this function block, it is possible to acquire an incremental encoder on them.

Of course the maximum frequency that you can manage depends on the speed with which the function block is executed, assuming to use the two inputs of the CPU module for the acquisition (They have no filter) by creating a simple ladder program like the one in the manual, you can insert the program in the fast task and running it every 1 mS you can manage encoders with a maximum frequency of 200 Hz (See application note).

You can also perform direct input acquisition via the function block SysGetPhrDI, get peripheral digital input, and then map the inputs to multiple instances of the function block IOEncoder managing multiple encoders.

[Maurizio Conti]

I am acquiring a DI battery with it SlimLine as from the following code:

FOR i: = 0 TO 21 DO
(* CASE i OF 
    0..5: DIN [i]: = SysCPUDI [i];
    6..21: DIN [i]: = SysDI00 [i-6];
  END_CASE; *)

  CASE i OF
    0: DIN [0]: =% IX255.0;
    1: DIN [1]: =% IX255.1;
    ...
    21: DIN [21]: =% IX0.15;
  END_CASE;
END_FOR;

While the uncommented CASE works, when I try to compact the code (commented code) I get the following errors: SysCPUDI => Complex variables cannot have process image
SysDI00 => Complex variables cannot have process image

However, accessing the SysDI00 array element within the watch window does not cause problems. What am I doing wrong ?

Also I ask you, if you want to acquire the DIs via Modbus is it advisable / preferable to use the Read Input Status (FC = 02) or place them on an internal variable and light with the Read Holding Registers function (FC = 03)?

[Sergio Bertana]

The problem is with the way the I / O process image is handled, you can find more information in this topic. In practice, the digital inputs are acquired by the operating system in the Slow task and are transferred to the UDINT SysCPUDI and SysDIxx variables, then they are transferred to the BOOL% IXxx variable table.

When a program refers to a variable% IXxx LogicLab checks which task the program is executing and if it is the Slow task, it refers to the real variable, if it is the Back task it performs a copy of the real variable in a support variable creating a further process image.

The process image let's call it a copy, it is made automatically only on% IXxx variables, so the solution to your problem is to run the program in the Slow task.

With reference to the acquisition from Modbus, both the 16 # 02 command Read input status that 16 # 03 Read holding registers, they have roughly the same length in bytes in the response frame so at the frame level they are comparable. Then of course the first returns you an array of BOOL while the second returns one or more words that you will then still have to unpack to get the values ​​in BOOL variables.

[Author]

Post