BridgeModbusTcpImpl doesn't work when Cycle is referenced

English Forum
1

The BridgeModbusTcpImpl does not work when

	@Reference
	private Cycle cycle;

is added. It seems the FSM is stucked in the WRITE state

2024-04-01T09:30:40,819 [_cycle  ] INFO  [ker.internal.CycleTasksManager] State: WRITE -> WRITE (onExecuteWrite)
2024-04-01T09:30:41,816 [_cycle  ] INFO  [ker.internal.CycleTasksManager] State: WRITE unchanged (in onBeforeProcessImage) Delay [0] (time is invalid)
2024-04-01T09:30:41,818 [_cycle  ] INFO  [ebuglog.ControllerDebugLogImpl] [ctrlDebugLog0] _sum[State:Info] ess0[SoC:UNDEFINED|L:UNDEFINED|Allowed:UNDEFINED;UNDEFINED|On-Grid] modbus0[CycleDelay:0 ms|State:INFO: CycleTimeIsTooShort]
2024-04-01T09:30:41,819 [_cycle  ] INFO  [ker.internal.CycleTasksManager] State: WRITE -> WRITE (onExecuteWrite)
2024-04-01T09:30:42,815 [_cycle  ] INFO  [ker.internal.CycleTasksManager] State: WRITE unchanged (in onBeforeProcessImage) Delay [0] (time is invalid)
2024-04-01T09:30:42,818 [_cycle  ] INFO  [ebuglog.ControllerDebugLogImpl] [ctrlDebugLog0] _sum[State:Info] ess0[SoC:UNDEFINED|L:UNDEFINED|Allowed:UNDEFINED;UNDEFINED|On-Grid] modbus0[CycleDelay:0 ms|State:INFO: CycleTimeIsTooShort]
2

This problem was found during the implementation of high level modbus skip cycle function Modbus bridge skipcycle highlevel by cvabc · Pull Request #1 · girasolenergy/openems-fork · GitHub.

The core cycle time is needed to calculated how many cycles should be skipped

this.noSkipIdx = (int)Math.ceil(config.intervalBetweenAccesses() * 1.0 / cycle.getCycleTime());

The code can pass tests but cannot work on real hardware devices. After some try and error, it’s found that the import of even only 2 lines of code

@Reference
private Cycle cycle;

in the io/openems/edge/bridge/modbus/BridgeModbusTcpImpl.java file in develop branch would break the modbus bridge.

Normally this should be reported in github issues but issues is not enabled for OpenEMS GitHub - OpenEMS/openems: OpenEMS - Open Source Energy Management System.

3

Can you share more specific observation you have? Under certain circumstances underlying inversion of control mechanism might detect cyclic dependency and hold component from being activated. Other situation could be a deadlock. In case of a cyclic dependency appropriate log statement should be produced.

From what I understand you do not need access to cycle itself, but rather its time, am I right? If so, then you could try to obtain configured value by accessing ConfigurationAdmin service and its methods.

4

Thank you for the reply!

I also think it could be a deadlock, but not sure where.

From what I understand you do not need access to cycle itself, but rather its time, am I right? If so, then you could try to obtain configured value by accessing ConfigurationAdmin service and its methods.

Yes, only the core cycle time value is needed and thank you for the suggestion I have turned to ConfigurationAdmin and made the PR here

1 Like