CANopen electric motor drive integration into "Boat" page

I know the REC-BMS is running at the standard 500kbps, don’t know about the Sevcon – what is yours running at, and is that the standard configuration?

IIRC I have manually set the Sevcon to 250kbps to play nice with our older iXXAT dongle, not sure what standard is. If you run into a rate mismatch issue, I’d strongly advice to add a dedicated USB to can-bus adapter instead of trying to adapt the Sevcon settings. Make sure you get one that is known to be supported, some of the cheapest ones work just fine but make sure to get an isolated version.

In the coming weeks I’ll be integrating a full Victron system on a customer tourboat replacing / simplifying a boatload :smiling_face_with_sunglasses: of mixed systems: 230Vac on 48V Lead-acid legacy bank, 24Vdc legacy light and heating 12Vdc instrumentation and a separate 77kWh 48Vdc propulsion bank (Li-Ion) with 15kW Sevcon. When the dust settles on that transformation I’ll be able to tell you exactly what will work.

1 Like

Thanks! It’s not the cost of replacing the Cerbo with a Mk2 that bothers me, it’s the hassle of swapping the hardware and making sure all the configuration data is transferred over – so finding a way to use the existing Cerbo would be good… :slight_smile:

Driver is ready to test!
Follow the instructions on the readme.
Let me know if you have any questions/issues.

4 Likes

Will try this as soon as I’m back on the boat in a few weeks… :slight_smile:

Thank you Nils, our build is still a few months away but this is a great addition to enable the Boat Page.

Impressive :+1:

@citolen did you have to change the Sevcon data rate – what was it set to by default?

@iand I guess it should just work by using the “Oceanvolt” profile.

I would also like to share my spare time project for integrating a Sevcon Gen4:

I tinkered around to integrate the Sevcon into the NMEA2000 network and thereby also into the GX device. It basically uses an ESP32 to translate between a CANopen on one and NMEA2000 network on the other side.

As long as you have a free CAN port available, I would recommend using @citolen his approach. But if both VE.CANs are already in use (with NMEA2000 being used on one) and you’re not afraid of soldering and flashing microcontrollers, then my approach might come in handy. Theoretically, it should also enable to have the Sevcon to show up on an MFD, although I have not tried that yet.

The project can be found here: GitHub - philipptrenz/ESP32-N2K-Sevcon-Gateway: NMEA2000-compatible CAN gateway for Sevcon Gen4 controllers: Enables the display of motordrive data on Victron GX devices.

3 Likes

I don’t think so, see earlier in this thread and other ones.

Oh yes, I was too hasty, the Oceanvolt profile runs at 250 kbit/s.

Also wrong format messages…

I did not have to change anything.
By default my controller was using 250kb/s and the Cerbo’s VE.Can profile was also set to 250kb/s.

The driver does not need to know about the data rate, as long as your controller and the GX device data rate match.

It’s quite likely your controller is configured to transmit TPDOs.
Use the candump command in Venus to check if data is coming through fine.
It would give you confirmation that you’re using the right data rate.

The issue for me is that i have a Cerbo Mk 1 with only one VE.CAN port, and the REC-BMS is already connected to this and running at 500kbps. So if I want to share the port I need to reprogram either the BMS (to 250k) or the Sevcon (to 500k), and this need hardware/software I don’t have (but my boatbuilder does, obviously). Or if I want to keep the rates different (as they are now?) I need 2 separate VE.CAN ports, which means replacing the Cerbo with a Mk 2…

For a Curtis F-series controller the following retrieves the basic motor controller data (Curtis also defaults to 250kb/s).

In terms of creating a C version (or adding to the Sevcon one), does the development environment need to be ‘Intel’? Last time I looked at building for Venus (for GUI v2) it wouldn’t support my MacBook…

    while True:
        time.sleep(1)

        man_name = client.read_sdo(0x1008, 0)  # Returns "AC F6-A 48-650-001" 
        if man_name == None:
            continue
            
        man_name_str = man_name.decode("utf-8")
        print(f"Man: {man_name_str}")
        
        if man_name_str[:4] != "AC F": # F-Series Controller
            continue

        hw_ver   = client.read_sdo(0x1009, 0)  # Returns "FSERIES_PRIMARY.7.0" 
        sw_ver   = client.read_sdo(0x100A, 0)  # Returns "1.0.47" 

        rpm = client.read_sdo(0x352F, 0)
        rpm = unsigned_to_signed(int.from_bytes(rpm, byteorder="little"), 16)
        
        swap_motor_direction = client.read_sdo(0x362F, 0)
        swap_motor_direction = int.from_bytes(swap_motor_direction, byteorder="little")
        if swap_motor_direction == 1: rpm *= -1
        
        abs_rpm = abs(rpm)
        print(f"Rpm: {rpm}")
        direction = 0 if rpm == 0 else 2 if rpm < 0 else 1
        print(f"Direction: {direction}")

        motor_temp = client.read_sdo(0x3536, 0)
        print(f"MTmp: {0.1 * unsigned_to_signed(int.from_bytes(motor_temp, byteorder="little"), 16)}")

        ctrl_temp = client.read_sdo(0x3000, 0)
        print(f"CTmp: {0.1 * unsigned_to_signed(int.from_bytes(ctrl_temp, byteorder="little"), 16)}")
        
        batt_current = client.read_sdo(0x338F, 0) # Total current for motor and controller
        print(f"BCurr: {0.1 * unsigned_to_signed(int.from_bytes(batt_current, byteorder="little"), 16)}")
        
        batt_volts = client.read_sdo(0x34C1, 0)
        print(f"BVolt: {0.01 * unsigned_to_signed(int.from_bytes(batt_volts, byteorder="little"), 16)}")

@mpvader Could I get a copy of the velib as well. Would like to try and get the Curtis SDO based interface working in C (got it working in Python). Not sure the best way forward here - whether to have separate C interfaces or try and support all controllers through one…

Would also like to to add a few more motor drive parameters to the standard dbus list for:

  • motorPower (just the power used by the motor - in addition to the existing controller+motor power value - this is reported by all controllers)
  • Torque
  • Error codes (this will be a list so will cycle through the errors - this may not be easy with a SDO solution but we have already implemented this using TPDOs)
  • Maybe some flags like coolant pump on, remote control enabled (though these could be left for a manufacture specific addition)

I’m not sure, see instructions here: howto install and use the sdk · victronenergy/venus Wiki · GitHub. Download that and try. And if it doesn’t work on your mac, then too bad and you’ll have to find another solution. I’m a bit strict in that, meaning: anything that doesn’t work out of the box with that SDK needs, often complex, work on our side that we’re not interested in, hope you understand.

Most or all of the Venus OS devs here work on intel machines.

yes I’ll email you.

@citolen and myself discussed that, and would be very nice to have it all in one. Which means: you can make a pull-request against GitHub - citolen/dbus-sevcon: Venus OS driver for Sevcon Gen4 controller: enables communication and motordrive data reporting via D-Bus. once you’re ready.

why?

ok for me.

Cycling through errors is not compatible with the notification system in the GX, also not with VRM. I do understand that it would be the least effort approach. I prefer to start with the other more simple things, and only start looking into + discussing this once the rest is done.

ok for me.

Gentlemen, sorry to hy jack this conversation for an off topic request, I’ll keep it short:
Does any of you know where to (urgently) buy a second hand (or new) Sevcon Gen4 Size6 controller, 48V 650A, SKF (hall) AB encoder, Asynchronous (squirrel cage) AC motor. Location NL/EU. Any help be much appreciated, let me know if I need to contact you per DM (not to further hy jack this forum)

First off hats off for your excellent (and quick!!) work Nils!

A while ago I was thinking of making a similar interface with Sevcon / display too.

Polling through the standard canopen interface seems much more logical than setting up PDOs.

To combat the unnecessary can bus traffic - Is it possible to inhibit or disable the RPDOs / TPDOs by setting the event timer to 0 / long or setting an inhibit time?

Mainly 0x1800 - 0x1808 sub 3 & 5.

I’ve only got experience with programming the sevcon through their own DVT.
Do you need to do anything specific to change values like setting access levels? Is this possible at all without specific handshakes through their ‘security by obscurity’ ?

Cheers, this makes me wanna buy a Cerbo!

1 Like