Hello, has anyone helped in this problem. I want to improve my block and have only one input in FB with HW_ID of device. Now in my block i have extension to 10 inputs with HwSubmodule constant in case when programmer want to maps all inputs from device which has a few input process images like COGNEX cam. This FB has additional diagnostic functions for the module/device from which inputs are read.

Mr. 0_Einstein, in my opinion this is good solution which could make programmer life easier. We don't need create tags for modules or external devices in Profinet and we have one universal block to map all inputs to whatever DB using only one input info like HW_ID.

Can be there anything easier? But how to read all inputs from module/device...

------------------------------------------------------------------------------------------
Split from Hardware Identifiers from all modules.

Ok, so if I understand you correctly this means that in TIA Portal is impossible to read whole input data from module/IOdevice using only one Hw identifier of this device, right Mr. Einstein?

It's worth noting that I didn't ask about correctness of my solution, I only want to know whether SIEMENS give us possibility to map or handle inputs in easy way (use one device ID and have access to all inputs of this device even if we have several telegrams defined by gsd file in HW).

I believe it is possible.  I use as an example S7-1214 CPU, where I read all inputs and write all digital inputs and write all digital outputs with single HW_IDENTIFIER.  Since 1214 CPU has 14DIs and 10 DQs, declare declare two tags in the DB or TEMP of your FC/FB:

s7_1214_inputs array[0.13] of BOOL

s7_1214_outputs array[0..9] of BOOL

Now, call DPRD_DAT with HW_identifier and connect #s7_1214_inputs to its output.   States of all digital inputs of the S7-1214 are written to the #s7_1214_inputs array.  Same with output, write from logic to the #s7_1214_outputs array then use DPWR_DAT function to transfer from the #s7_1214_outputs array to the physical outputs,  This example is of course with native siemens hardware component (S7-1214 CPU) but I've been using this method with other 3rd party hardware (e.g. Ricelake P/N scales)  so I would imagine you can do the same with your Cognex  hardware by creating specific UDTs for the input and output area of the hardware and calling it using DPRD_DAT and DPWR_DAT functions.

Olgierd.

Hi

I also use, quite often, the DPRD_DAT with the 1500. It uses the HW_IO, so if the GSD defines more than one submodule, you will have to enter them all somewhere. That works well.
I also want to extend this way of proceeding to all my devices.
This function is dedicated to have "consistent data" (which can make sense for a very very long barcode or a servo, for example), but there is no real alternative to read an address range according to an HW without the "consistent thing".

I am just studying the question, because I read here (1200) :
https://support.industry.siemens.com/cs/mdm/109759862?c=86660468363&lc=en-GR
"If you are using the DPRD_DAT and DPWR_DAT instructions with consistent data, you must remove this consistent data from the process-image automatic update. Refer to"PLC concepts: Execution of the user program"for more information."

That puzzles me. I believe that using DPRD_DAT increases the use of PN and cycle time, but significantly or not ? I'm waiting for the delivery to test all this...
And also try to remove the process-image automatic update, but this information come from 1200, not 1500. I'm still looking for the equivalence for the 1500..

In other way, I'm guessing we can also use the RD_ADDR to get the corresponding address range for the submodule, then use PEEK or a MOVE to push. I have not tried yet.

I guess I will have to test both solutions and compare.
If there is no difference, DPRD_DAT seems easier to me.

OP, for your question, I don't know how to update all the submodule with only the "Device".
Certainly because we can have several telegrams defined by gsd file in HW. Perhpas you can try the GEO2LOG "Determine hardware identifier from slot", to find all submodule, then use DPRD_DAT with each...


It would be really good if we could type the name of the Device, and directly have access to its process image, no ?
At the declaration, the Devices are assigned a number (used by DeviceState for example), why don't have a fonction to read/write the accorded process image easily ?
The point is that we are encouraged to work in absolute addressing, fine, but why keep the %I and %Q ? (I'm trolling, a little bit)

Olgierd

Another option is to use UDT as an IO Tag and call it as such in the user program.  I think the only down side of doing that is lack of direct access (:P) meaning all tags that belong to UDT will be read/write from/to the process image and possibly create program error if not connected IO is accessed from the user program.  I'm not sure about the data consistency.

 Yes, but when you have 240 same devices, it's painful. (this is not the norm, I'm aware of it)

I'm lazy, I want my DATA from all same devices in an array, so I can LOOP them.
And we can't declare in IOtag, an array [1..240] of udt which start at %i100.0

A second reason is that  if you are wrong somewhere, the %i can be shifted, whereas by using HW, which are constants with an equivocal name, the risks are less. IMO

Correct, no array of UDT can be used, but you could read array of words and then move to the array of UDT in the DB.  I realize this is additional step which takes more CPU clocks.

When new IO tag is created that overlaps existing array or UDT tag, the Portal flags it as duplicate address (tag address in the PLC Tag Table has yellow background color).