PLC IOs on multiple pages

Thank you jhonathan for the reply. Your example is very useful.

I am wondering if we can go a step further and have some connections between the PLC and the digital input so that the labels can be automatically updated.
Is there a way to have some variable that can be used for the label of the PLC that can be also used for the digital input so that both labels can be updated automatically?
Are there any global "variables" that can be used in the label formula that can be used on multiple pages?

Also I am wondering if there is another way to connect the PLC to the digital input / output, because I would like to use a text formula for the wires - concretely I would like to have a page number in the name of the wire for example %id.01. In this way when you try to check something you can quickly find the wire. Unfortunately if the wire go through multiple pages then this is not possible, so this is why I was wondering if there is another way to connect a digital input / output to a "master" PLC.

I've been using the "Function" field of the wire to store what the channel is assigned to.  It works quite well together with folio references, which you can define and style yourself.  A folio reference can include a dynamic text element for its "Function" attribute, which automatically displays the Function of the connected wire (on both ends when linked together).

Attached sample project shows a little of this in action:

1. A physical view of each PLC component. This is declared as a "master" element type so that others can be linked to it. The linking results in a nice table of references where this component is referenced.

2. A logical view of each connector of the PLC components. These are declared as "slave" element type and get linked to the physical view. That automatically makes the master's properties available for text display, such as the module type and of course its ID (with a back-reference to the folio with the physical view).

3. A generic "signal description" element declared as type "previous_report".  It has a single pin that gets connected to the logical PLC connector element.  This connection (wire) then gets assigned a Function attribute naming what the channel is used for.  It automatically displays the Function and has a spare text field by default that is used to record the logical input / output number as a reference for the software developer.  These pages give you a nice overview of what channels are assigned and for what they are used.

4. The opposite "next_report" element type is drawn as a "channel header". It gets inserted wherever in the schematic the channel is needed (though limited to one place per channel).  It again has a dynamic text field displaying the Function attribute value.  Link this element to the previous one, which is rather easy to do because the possible link targets table shows the Function value, so you just need to pick the semantic name you've given the channel's signal.  Note that this "header" element could be used stand-alone, connecting its pin to the sensor directly.  But that doesn't work for the case of analog differential or RTD inputs, where several pins are required for the channel.  Thus there's a standardized "channel body" element as well, see below.

5. The "channel body" element exists in different variants, for example 1 to 4 used pins.  It is declared as element type "slave" again, to be linked to the physical module representation.  That makes it clear where the signals are connected to, and pulls in the referenced module type attribute again, so you easily see that it's an analog input for example.  It has an almost unnoticeable pin on the top-left corner which is designed to automatically connect to the "channel header" element, to make sure there's a connection and the Function attribute is actually displayed.  For the individual pins, there are separate text fields to describe exactly on which terminal of the module the channel resides.  This is unfortunately still a manual process, you need to jump back to the linked "signal description" (just double-click the folio link), remember which terminal(s) the signal is connected to, jump back (another double-click) and adjust the texts.  Doing it manually has the advantage that you can pick the order for multi-terminal channels, such as 4-wire RTD inputs, to untangle your connections.

It's a bit of work to get the PLC-specific parts set up first (because the existing library symbols have no master-slave relations there), but I think it's worth the effort.  Remapping a channel is done with a few clicks and some manual text updates.  Note that if you really need the same channel referenced in more than one place in your schematic, you could still place more "signal description" elements connected to the same PLC terminal.  I've done that for Modbus channels for example, where it nicely summarizes references to all Modbus-connected sensors.

Overall I guess I'm a programmer, used to stuff being generated for me based on a single declaration, and error-checked by the compiler.  QET is more of a "smart pencil" so I wanted to make as much as possible automated and linked together to avoid mistakes and mismatching references.  More features in this direction, allowing to link stuff together on a semantic level, would of course be great.