CANopen electric motor drive integration into "Boat" page using Node-RED

Node-RED
, ,
81

I’d have thought the CANbus bandwidth is in no way an issue, it can cope with far more traffic than any TPDOs hitting it – the issue is how fast the driver code can run, especially if it’s written in Python. In this case it’s better to ignore the TPDOs and issue SDO requests (e.g. once/twice per second) and only process these, to keep the amount of processing down – as well as avoiding the need to reprogram the controller, which (unless you already have them…) needs the Sevcon IXXAT H/W and DVT S/W which cost almost $1000… :frowning:

I know that motor/controller temperature should also be readable via CANbus once this is working – but since my boat doesn’t currently have this, it uses wired Victron temperature sensors. Not as good due to thermal mass and delay, but all that could be done at the time.

82

Having a C or Cpp based driver that works with Sevcon controllers out of the box, without having to configure/program those Sevcons, due to costs and complixities involved as mentioned in this thread a few times, is the best possible solution for me.

Python & Node-RED might work as well and offer lower barrier wrt people modifying it. But cone at CPU cost,

Wrt Node-RED: the next step for anyone is to simply try it. Few hours work max I’d think.

Before going into Node-RED, make sure that there is data coming in, run candump from the commandline. See google for candump details.

1 Like
83

The alternative way is to define/require the PDOs required for this data to only be sent at a max of 2 a second which should allow the use of a Python driver. afaik nothing much works ‘out of the box’ but I have not tried a Sevcon controller (they may come with a basic set of PDOs programmed for their own gauges)

84

And access to my customers vessels I may add. Which is somewhat problematic as these are commercial tourboats practically running in 24/7 operation.

That said, your involvement @mpvader is countering my primary concern to some extend: the hurdle to get Victron actually be willing to incorporate a community provided extension to Venus OS itself. Which, to be clear, I very much appreciate!

And for those wondering how this relates to my DESS endeavors: I build large capacity propulsion battery systems for marine application based on Porsche Taycan re-use modules. A significant part of the value of my work is to extensively test those modules before selecting a perfectly matched and balanced set of modules to manufacture a bespoke customer battery system with. That is the why of us running full power DESS Trade systems: it provides a most economical solution to cycle test our modules in our match and select process.

1 Like
85

It looks like the C/C++ driver is feasible and the best option, especially since you’ve offered to give @citolen access to the velib C library – thanks for that support :slight_smile: :slight_smile:

It also shouldn’t then have any CPU/speed issues like using Python might have. And working “out-of-the-box” without reprogramming the Sevcon is a big advantage… :wink:

This would be a big step forward to making the “Boat” page easily usable for people with electric boats and Victron equipment :slight_smile:

86

We currently use custom code to emulate the ‘Sevcon’ protocol on Curtis controllers (to display the data on our custom QML guiv1 screens or the victron guiv2 boat display). Our plan to move to a better solution is :

  • define a ‘generic’ CanOpen set of PDOs to provide a more complete set of motor data than the legacy Oceanvolt one (better support for multi-motor setups, Torque reading, alarm indications/codes, more status data (on cooling pump state/remote control enable etc)
  • Implement this using a Venus python driver to prove the concept and get all the dbus entries working.
  • Implement on the Curtis controllers we currently use for our motors (with max 2 per second message rate)
  • If enough community interest help work on a C driver

The existing Sevcon interface does not really support enough data to be super-useful (in particular fault codes) and Curtis have indicated that they don’t see enough market for NMEA2000 to implement it on their controllers.

Happy to collaborate on the ‘generic’ CanOpen PDOs.

In terms of the high cost of the ‘development’ kits. This is an issue - however all the electric narrowboat motor suppliers should have this and be able to implement a new protocol. It will be difficult for individuals, however some level of ‘programming’ is always required for PMAC motors since the controllers are paired to individual motors during commissioning.

87

For us Node-RED is not a good solution as it can’t readily be installed or updated as easily as QML or python (for example you have to know the actual name of some the devices on a boat for things like PV voltage so has to be customized per boat)

88

Controller programming is no issue for boatbuilders who already have the kit and knowledge and have to do it anyway, but it is for all those boats like mine that are already out there.

I’m sure a boatbuilder would be happy to come out and do the work, but would have to charge for half a day or a day’s work depending where the boat is, which would probably cost almost as much as the Sevcon development kit…

89

Agreed, but if there was a generic ‘Victron’ CanOpen PDO format then at least suppliers could start supporting it like they did with the Victron BMS CanBus protocol. For your situation the best hope would be someone supporting an open source motor controller - there is no incentive for the current manufacturers to offer anything for free (and even when they charge a fortune for their development kits they are really not designed for new users outside their company)

90

The issue is that the Sevcon is far more widely used in boats (and home-brew EVs) – especially in Europe – than the Curtis or other controllers, and that’s where most of the demand for this function is coming from – including the people willing to do the heavy lifting of building it.

And it’s far quicker and easier to build and verify/debug a driver to support one type of hardware than a generic one which has to be tested against multiple platforms, and make sure that setting the wrong controller type doesn’t result in possibly catastrophic “wrong” commands (since there are no fixed meanings for CANopen messages).

So I expect the initial version will be Sevcon-specific. Whether a more generic one comes later will depend on demand and the willingness of somebody to write/verify/debug it… :wink:

91

Happy to have an improved Sevcon driver with more data supported and would contribute if useful - would be pretty easy for us just to emulate it on Curtis as a step in the right direction.

92

@citolen Thanks for all this. It looks like we can use the same mechanism to read the SDOs on Curtis controllers. Wrote a quick Python script to test it but got into dependency hell with the canopen library on the cerbo (tomllib). The python-can library works fine so will try just using that directly when I have time to figure out the message sequence.

Got a bit further - ended up having to install the canopen library without dependencies - could not get ‘msgpack’ to install as the built-in python didn’t have tomllib which was expected in Python 3.11 and above.

Update: The following sequence successfully installed canopen-python on a clean cerbo running 3.62:

opkg update
opkg install python3-can
opkg install python3-pip
python -m pip install canopen
python -m pip install canopen --no-dep

Note that the first canopen command will fail when it gets to msgpack but everything else is ok - so we run it again without installing dependencies. This means that the troublesome msgpack doesn’t get installed but so far it doesn’t seem to affect anything

1 Like
93

@citolen Got RPM and direction working with a Curtis F6 controller - the following (send to the default node id 0x26) worked on my boat and matches what we are getting through the PDOs. Will get the other values working in the next few days but haven’t yet figured out how to identify the Curtis controller as those SDOs aren’t in the documentation I have.

    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

    dbusservice['/Motor/RPMtest'] = abs(rpm)
    dbusservice['/Motor/Direction'] = 0 if rpm == 0 else 2 if rpm < 0 else 1
1 Like
94

Normally every CANopen Device provide the identification information via this generic Object Dictionary entrys

Index Object Name Description
1008 Manufacturer Device Name Stores the name of the manufacturer.
1009 Manufacturer Hardware Version Stores the hardware version of the device.
100A Manufacturer Software Version Stores the software version of the device.
95

Thanks, I will give that a try in a few days. Taking the narrowboat down the tidal thames to Limehouse on Wednesday - don’t want to fat finger something and accidentally change a parameter in the controller without realizing!

96

A quick hello to let you all know I’m still lurking in the shadows and appreciate the work and progress. I have (limited) access to my customers boat to test on the Sevcon controller itself, are we close to a feasible (test) solution yet?

97

Hi Jan,

Yes, I’ve got a working version of the driver that I would be happy to share with you and anyone else that would like to beta test it.
It’s currently running on my boat successfully.
Before I can share it, it’s waiting on Victron to validate a couple of things to ensure the privacy of their library before I make the driver’s code public.

I will keep you updated as soon as it’s ready to test.

In terms of the installation steps, it’s going to be even easier than anticipated.
You will be able to copy a single file on an SD card or USB flash drive and plug that into the GX product to install the driver.
No need for SSH access, Large OS, Node-RED, etc…