Axioline F C++ Initialisation with output-only modules

We’ve written a custom C++ application running under the plcNext runtime on an AXC F 2152. We’re utilising it in 5 existing configurations (That work perfectly) where there are a mixture of SE4 and SE6 modules always with at least 1 DI16 and 1 DO16 module. A clean PLCNext Engineer program (2021.0.5 LTS) has been loaded in all instances with two blank ESM tasks, some basic network settings and no variable mappings etc, purely to populate the /opt/plcnext/projects/PCWE/Arp.Io.AxlC/5ebe…tic file.

We are now attempting to utilise this in a scenario with an SE4 and 3 x DO16 and a blanking plate (Have also tried with an RTD4). In this scenario, our C++ code always bombs out at the ArpPlcGds_EndRead:

[code]
// Unlock buffer
if (!ArpPlcGds_EndRead(gds)) {
    Log::Error("Failed to ArpPlcGds_EndRead for module {0}", Name);
}
[/code]

I do recall from the old forums seeing a post where there was some back and forth between the Axioline F team and the PLCNext engineer team regarding an issue where the Axioline bus didn't start up or work fully until some data had been transferred across the bus. I can no longer find that thread after the new migration. Our code change related to that post was to implement:

[code]
// Initialise data to zero for everything
for (std::vector::size_type i = 0; i != modules.size(); i++) {
    IOModule* module = modules[i];
    module->Initialise(); // Internally get the buffer ptr & variable offset
    for (uint32_t j = 0; j < module->PortCount; j++) {
        module->WritePort(j, 0); // For output modules, sets every port (i.e. 1 bit for a DO)
    }
}
[/code]

I've tried re-using some code from my earlier forum post regarding "hot reload" to re-initialise the Axioline bus and having no luck.

I am met with the following diagnostic status register\t"0x02E0" which is 
[code]
The controller is in the STOP state or no application program has
been loaded. The output data is blocked (substitute value behavior is
active)
[/code]

This is received whilst seeing the following in the plcNext runtime logs (obviously running):
[code]
09.09.21 08:08:50.214 ProcessManager            DEBUG   - Shared Library 'Arp.Plc.AnsiC.Library' with path '/usr/lib//libArp.Plc.AnsiC.so' loaded.
09.09.21 08:08:50.222 ProcessManager            DEBUG   - Shared Library 'Arp.Plc.Domain.Library' with path '/usr/lib//libArp.Plc.Domain.so' loaded.
09.09.21 08:08:50.239 ProcessManager            DEBUG   - Shared Library 'Arp.System.UmRscAuthorizator.Library' with path '/usr/lib//libArp.System.UmRscAuthorizator.so' loaded.
09.09.21 08:08:50.474 ProcessManager            DEBUG   - Component 'Arp.Plc.AnsiC' of type 'Arp::Plc::AnsiC::AnsiCComponent' (Version 2021.0.5 LTS (21.0.5.35585)) from library 'Arp.Plc.AnsiC.Library created.
09.09.21 08:08:50.477 ProcessManager            DEBUG   - Component 'Arp.Plc.DomainProxy.IoAnsiCAdaption' of type 'Arp::Plc::Domain::PlcDomainProxyComponent' (Version 2021.0.5 LTS (21.0.5.35585)) from library 'Arp.Plc.Domain.Library created.
09.09.21 08:08:50.480 ProcessManager            DEBUG   - Component 'Arp.System.UmRscAuthorizator@runtime' of type 'Arp::System::UmRscAuthorizator::UmRscAuthorizatorComponent' (Version 2021.0.5 LTS (21.0.5.35585)) from library 'Arp.System.UmRscAuthorizator.Library created.
09.09.21 08:08:53.628 root                      INFO    - New connection established
09.09.21 08:08:53.711 root                      INFO    - Keep alive: OK
09.09.21 08:08:56.719 PlcDomainProxy            DEBUG   - Registered PlcComponent Service for component 'Arp.Plc.AnsiC'
09.09.21 08:08:58.773 CommonRemoting            DEBUG   - Service requested from serviceProvider 13: Arp.Plc.Commons.Services.Internal.IPlcComponentService
09.09.21 08:08:59.317 root                      INFO    - Keep alive: OK
09.09.21 08:08:59.939 root                      INFO    - PLC Load
09.09.21 08:09:00.951 root                      INFO    - PLC Setup
09.09.21 08:09:01.865 root                      INFO    - PLC Start Warm
09.09.21 08:09:01.869 root                      INFO    - Subscribed to Device Status service
09.09.21 08:09:01.870 root                      INFO    - Intialised GDS for module Arp.Io.AxlC/0.~DO16 at address 0x5968b8 with offset 0
09.09.21 08:09:01.871 root                      INFO    - Intialised GDS for module Arp.Io.AxlC/1.~DO16 at address 0x596a60 with offset 2
09.09.21 08:09:01.872 root                      INFO    - Intialised GDS for module Arp.Io.AxlC/2.~DO16 at address 0x596ad8 with offset 4
09.09.21 08:09:01.872 root                      INFO    - Intialised GDS for module Arp.Io.AxlC/3.~AI64 at address 0x596b50 with offset 6
09.09.21 08:09:01.876 root                      INFO    - Found the Axio Master service
09.09.21 08:09:01.909 root                      INFO    - AXIO reset successful
09.09.21 08:09:01.933 root                      INFO    - Intialised GDS for status register at address 0xafd017b8 with offset 0
09.09.21 08:09:01.935 root                      INFO    - AXIO Status Changed from FFFF to E002
09.09.21 08:09:02.111 root                      INFO    - AXIO configuration create successful
09.09.21 08:09:02.135 root                      INFO    - AXIO configuration read successful
09.09.21 08:09:02.147 root                      INFO    - AXIO configuration load successful
09.09.21 08:09:02.152 root                      INFO    - AXIO data output enable successful
09.09.21 08:09:02.154 root                      INFO    - Found the PLC Manager service
09.09.21 08:09:02.164 root                      ERROR   - Failed to ArpPlcGds_EndRead for module Arp.Io.AxlC/1.~DO16
09.09.21 08:09:02.178 root                      ERROR   - Failed to ArpPlcGds_EndRead for module Arp.Io.AxlC/1.~DO16
09.09.21 08:09:02.195 root                      ERROR   - Failed to ArpPlcGds_EndRead for module Arp.Io.AxlC/2.~DO16
09.09.21 08:09:02.207 root                      ERROR   - Failed to ArpPlcGds_EndRead for module Arp.Io.AxlC/2.~DO16
09.09.21 08:09:02.223 root                      ERROR   - Failed to ArpPlcGds_EndRead for module Arp.Io.AxlC/2.~DO16
09.09.21 08:09:02.242 root                      ERROR   - Failed to ArpPlcGds_EndRead for module Arp.Io.AxlC/2.~DO16
[/code]

The only way I have been able to get it to "work" is if I map, in PLCNext engineer, a DO16 to one of the RTD4 inputs (16 bit to 16 bit), then loading that project, restarting our runtime, results in a working and reading program (for all DO's) and a status register of 0x00E0 (All good).

Any suggestions welcomed!
If it's the same conversation I'm thinking of, this relates to the LED on an Axioline I/O module not going green until output data had been written to the module. So for a DI/DO module where only the inputs were connected to program variables, the module would appear to be in error, even though the inputs were being read OK. This could be solved by connecting an output port to at least one output on the I/O module, even if that variable was never used in the program.

I don't think your issue relates to that earlier one.

My first thought is that when there are no input modules on the Axioline bus, it doesn't make sense to try to read Input process data from the Axioline bus. There will be no process data in the Axioline input data table for output modules (unless I'm mistaken). Would it cause a problem if you didn't [b]read[/b] the Axioline process data for configurations that don't have any Input process data?

I also have the diagnostic 0x02e0. I have the idea it has to do with C++ port connection types. PLCNext Engineer however blocks connecting to wrong types… So I’m not sure.

I have connected the following ports, using starterkit:
ai-1 to In port C++ program (uint16)
di-1 to In port C++ program (bool)

Hope someone knows the cause of this behaviour..

Hi Arne.

Do you get the same behaviour when you don't connect any I/O ports?
What PLC/FW version and I/O modules are you using? With this information we can try to reproduce the behaviour here.

Jep, I’ve disconnected them and still the same. Also rebooted the controller.

I've the newest starterkit (with the black backboard) with a PLCNext hw version 02. 
I/O is AXL SE -DO16/1 -DI16/1 -SC-A -AI U 0-10
I'm using software:
2021.0.0.489 plcncli
2021.12 eclipse ide
Firmware 2021.0.5 LTS
Engineer 2021.0.4

Can you please try declaring one Out Port variable in an IEC program, of type BOOL, and connecting it to one of the digital output ports on the DO16/DI16 module?

Does that remove the error?

Yes… Status is 0x00e0 now and I am able to read the inputs now! Are you able to explain why this behavior happens?

There is a „feature“ of Axioline I/O modules (or at least the ones that have outputs), that the I/O module will appear to be in error until process data is transferred to the I/O module. When the I/O module is used with an AXC F controller, this simply requires that at least one of the outputs on the I/O module is connected to an OUT port variable in the PLCnext Engineer project, even if that OUT port variable never changes.

This behaviour of Axioline I/O modules is by design, and it should not be a problem for most applications. It is probably preferable for the PLC program to set all the outputs on all I/O modules to known values, even if they never change.