Cerbo GX start/stop issues with DSE4510/4520 generators

[EDIT: see Cerbo GX start/stop issues with DSE4510/4520 generators - #5 by preeve9534 for a summary of the problem]

Cerbo GX OS v3.72
DSE855 generator Ethernet/Modbus interface
DSE 4510RTH genset controller

The remote start signal on the DSE4510RTH is connected to NO on Cerbo GX Relay 1. CO is connected to GND.

The DSE855 GUI allows me to start and stop the generator and I can also use Modbus commands from a Modbus command-line app to start and stop the generator: i.e. the DSE855 is able to digitally control generator start/stop.

The Cerbo GX detects my generator and status and sensor readings are accurately displayed under Devices->DSE genset controller.

With Relay 1 configured as “Manual” operating the relay starts and stops the generator as expected.

So far, so good, but as soon as I switch to using the DSE genset controller subsystem things start going awry:

  1. With Relay 1 configured as “Disabled” Manual Start has no effect. I interpret this as meaning that the Cerbo GX cannot issue or for some reason is not issuing appropriate Modbus commands to the DSE855. Since the DSE855 is a generic interface to many DSE controllers I am slightly surprised by this.
  2. With Relay 1 configured as “Connected genset helper relay” Manual Start immediately starts the generator, but the Venus DSE genset controller interface updates to: Control status = Error, Control error code = #1 Remote switch control disabled, Genset status = Running, Genset error codes = None. This is confusing and suggests the problem lies with the Venus genset controller subsystem. Additionally, Manual Stop is disabled and the only way to recover Cerbo GX behaviour is to stop the generator manually and reset the generator controller interface: this clears the control status error in the Cerbo GX and re-enables the Manual Start button.

The “Remote switch control disabled” message seems not to be documented and I am at a loss as to how best proceed.

Advice very much appreciated.

P

Have you seen this exception in the manual

Special Case: DSE 4520 MKII (Venus OS v3.50 or later)

Unlike all other supported DSE controllers, the DSE 4520 MKII does not accept control commands via digital communication. Therefore, a wired control signal must be used through the “Connected genset helper relay” function. Further information can be found in the next section.

Since the 4510 is just a lower spec version of the 4520 i suspect that both show the same behaviour when it comes to remote control.

Thank you - yes I had seen that. However, many of the posts on DSE generator-related issues fail to mention the 855 Ethernet/Modbus interface and given this lack of clarity I am a little circumspect.

I note that (i) the only connection between the 855 and a supported generator is USB and therefore it is not accurate to say that these generators [sic] “do not accept commands via digital communication.” when with an 855 interface they must be doing so. I note that the HTTP interface generated by the 855 includes start and stop buttons which operate the 4510 and 4520 controllers correctly.

Notwithstanding this, I have done exactly as the post suggests and wired Relay 1 directly to the 4510 remote start input and, as explained in my original post this half works: Venus successfully starts the generator (i.e. no errors in the DSE environment), but the Venus generator control interface reports an (I think) undocumented error and locks up.

I mainly work with Comap but occasionally also see DSE controllers, so im not very familiar with DSE and Victron together. AFAIK the 4510/4520 only comes with a Canbus for the controller-to-engine communication, no other coms port (apart from the service USB) so the only way to get other communications going with them is through the DSE855. To me this then inherently means that any communication you want to have with a 4510/4520 needs the DSE855. Thats what i would interpret then as “the generator”. But it could definitely be stated clearer in the manual.

As to why the modbus side doesnt work, i dont know. Possible that its just a matter of " we never saw someone use it in the field so theres no need to look into why exactly this doesnt work" but thats just a guess.

As for the error you see, have you tried with VenusOS v3.50, since thats the version mentioned in the manual? If it works fine with that, but now with a newer version it doesnt, then its clear that along the way there was a bug introduced on the Victron side.

You are right about that the 4510/4520 plus 855 should together be viewed as “the generator”. The logic behind the documentation is very flawed since without an 855 in play the Modbus state/sensor data would not be available to VenusOS. In fact, I can squirt DSE documented start command codes at the 855 using a command line client and make the generator start. I’ll perhaps take a look at the Victron code when I’m feeling bored, but for now I’m being a bit more short-termist.

Reverting to OS v3.5 is certainly a good idea. I’ll report back here what I find.

The problem is present at least from VenusOS v3.5. This is what I think is going on:

The 4510 has three states: STOPPED, STANDBY and RUNNING. The “AUTO” button on the 4510 (and the mimic button in the 855 GUI) places the device into STANDBY allowing remote control by a digital input (e.g. by any connected CerboGX relay).

VenusOS detects the 4510 state via Modbus and uses this information to enable and disable its internal start and stop functionality: inter-alia start/stop buttons in the CerboGX GUI seem only to be enabled when the 4510 is in STANDBY.

The 4510 controller automatically switches state during operation, so, when the controlled generator starts, the 4510 switches to RUNNING.

This state change is detected by VenusOS which erroneously disables its internal start/stop functionality including the GUI start/stop buttons (it also incorrectly identifies the state change as an error). Consequently, it is impossible to stop a running 4510 generator from the CerboGX GUI. In certain configurations of the 4510 the system gets stuck in a restart - error - restart loop which is, at the very least, a little annoying.