- This topic has 4 replies, 3 participants and was last updated 9 years, 10 months ago da
.
-
Post
-
I'm working with a Slim Line and a Weintek terminal connected via modbus ethernet.
Working on my project I am faced with this doubt, what changes between managing the I / O of the system through the process image, and then pointing the input variable as% IX3.1 for example and the output variable as% QX1.0 for example. XNUMX, and instead manage them through the function block of get / set of the I / O?
Perhaps the difference is that if I activate an output through the function block it is activated immediately (apart from the 300us to execute the command), while if I manage it in process image it will be activated at the end of the plc task?
If so, to which task do the process images refer, to the slow one or to the back one?
The question is interesting and gives the opportunity to clarify how the Slim Line system updates the I / O.
All logic I / O modules connected to the CPU module are updated automatically (Process image) and mapped in the% IX and% QX table in the slow task. The inputs are acquired before and the outputs are managed after the execution of the user program. So the image of the status of an I / O is valid for the entire execution of the slow task.
For the task back, a "parallel" process image is created which reports the state of the inputs before execution and manages the outputs after the execution of the user program, this "image" of the state of an I / O is also valid for the entire execution of the back task. Warning! the management of the same logical output both in the slow and back task creates misalignments between the two tasks and è da evitare.
In task fast if you want to manage the I / O at the execution speed of the task, you need to acquire its value and manage its activation with the appropriate FBs. If you use those mapped in the table% IX and% QX they will still be updated at the execution speed of the slow task. Warning! the execution of the fast task interrupts the execution of the slow task, therefore acting on the variables% IX and% QX "dirty" the process image of the slow task.
The use of the I / O management FBs as you said allows you to directly acquire and manage the I / O modules regardless of the process image. Warning! the management of an output module must be done considering that the slow task will manage the process image, therefore it could set in the outputs a different value from the one set by the FB causing the outputs to flash.
As regards the management of the analog I / O, the appropriate FBs must be used. It is possible to insert the FBs indifferently in all the tasks, but if not for exceptional cases, my advice is to insert the call in the task back.
It is also possible to acquire an input and / or manage an output on an analog module in a task and acquire another input and / or manage another output from the same module in another task.
If an analog input value is used in several tasks, it is acquired in the task executed faster and the value acquired in the other task is used, without running the FB again.
I don't understand why the examples such as FBOnOffCycle do not show the changing inputs neither in simulation nor trying to give voltage to the DI00 terminal of the CPU. I thought that by declaring% XI0.0 it would be enough for the input to be read without having to add appropriate reading FBs. Am I doing something wrong ?
Since 16 modules can be connected to the extension bus of the CPU module (Addresses 0 to 15), the I / O of the CPU module are addressed with module address 255. So if you use process image mapping you have to map the inputs as % IX255.0,% IX255.1,… and outputs such as% QX255.0,% QX255.1,… If you manage the I / O directly with the relative function blocks you must define module address 255.
Attention, this rule does not apply to CPU modules NetlogIII, in that case the I / O of the CPU module are mapped to 0 address.
The reason for this difference is that the form NetlogIII is based on a OEM CPU module, which already has wired I / O (Module address 255). The physical hardware part of I / O is nothing more than a 20 I / O expansion module (With 0 address) connected to the CPU module extension bus. Any other expansion modules connected to the bus will automatically take addresses from 1 to 15.
- You must be logged in to reply to this topic.