I’m facing difficulties in the implementation of the device.
- OpenEMS setup on Windows.
- OpenEMS edge running with a Scheduler, Debug Log,Simulator DataSource: CSV Predefined,Simulator GridMeter Acting, Controller Balancing Symmetric, and Controller Api Websocket.
I run the ModbusSlaveSimulator at 8502, add the Bridge Modbus/TCP and my new meter and get the following error:
2023-06-15T12:36:58,600 [_cycle ] WARN [ms.edge.core.cycle.CycleWorker] [_cycle] Error in Scheduler. StackOverflowError: null
2023-06-15T12:37:08,030 [modbus0 ] INFO [dbus.api.task.AbstractReadTask] [modbus0] FC3ReadHoldingRegisters [1:1000/0x3e8]: 01f4
2023-06-15T12:37:08,610 [_cycle ] WARN [ms.edge.core.cycle.CycleWorker] [_cycle] Error in Scheduler. StackOverflowError: null
StackOverflowError: null would mean something is getting into an infinite loop while setting up the meter.
This output persists even if I remove the previous componenets.
How do I interpret this error and debug the issue? I know java debugging but I’d appreciate advice on what points i should be looking for.
StackOverflowError is also a hint for infinite recursion, i. e. a method calling itself without termination.
If you are able to share the relevant code, we could suggest something or you can inspect the
handleEvent method of your component.
Thank you for the response.
The code is the one used in the Implement a device page. I have made no changes.
I checked the output of the activate function in my device I’ve already posted the message. I have no idea where this recursion is happening or how/where to debug . How can I be sure the FC3ReadHoldingRegisters task is being completed successfully?
unfortunaltely it is very hard for me to guess you code, but you can take a look at existing modbus devices to get ideas how to implement your device.
Generally there are a lot of devices that implement modbus communication in OpenEMS. For example take a look at EvcsAlpitronicHyperchargerImpl.java.
Feel free to post any question if you get stuck somewhere in the process.
I will do as suggested. Thanks for the sample device suggestion.
I did find that one of the channels in the Scheduler All Alphabetically is being declared incomplete and may be the cause of the recursive error.
My code is the same from the Implement Device page and I have the following channels added:
[ID=_PropertyCycleTime, type=INTEGER, activeValue=10000, access=READ_ONLY]
[ID=IgnoreDisabledController, type=BOOLEAN, activeValue=false, access=READ_ONLY]
[ID=_PropertyIgnoreStateComponents, type=STRING, activeValue=[""], access=READ_ONLY]
[ID=_PropertyNetworkConfiguration, type=STRING, activeValue=UNDEFINED, access=READ_ONLY]
[ID=State, type=INTEGER, activeValue=0:Ok, access=READ_ONLY]
[ID=_PropertyKeyForFreeApps, type=STRING, activeValue=0000-0000-0000-0000, access=READ_ONLY]
[ID=MeasuredCycleTime, type=LONG, activeValue=7135 ms, access=READ_ONLY]
[ID=_PropertyUsbConfiguration, type=STRING, activeValue=UNDEFINED, access=READ_ONLY]
[ID=_PropertyApps, type=STRING, activeValue=, access=READ_ONLY]
The last one _PropertyApps , has no active value set. Is there a property within Channels that would let me trace the class that adds it?