Tool to manage openinverter via CAN

[davefiddes]

Another missing section from the readme. To do an upgrade run

Code: Select all

pip install -U openinverter_can_tool

Pip caches its files in ~/.cache/pip . openinverter_can_tool doesn't cache any files yet.

[davefiddes]

Hmm

Code: Select all

Traceback (most recent call last):
  File "/home/debian/.local/bin/oic", line 33, in <module>
    sys.exit(load_entry_point('openinverter-can-tool', 'console_scripts', 'oic')())
  File "/home/debian/.local/bin/oic", line 25, in importlib_load_entry_point
    return next(matches).load()
  File "/home/debian/.local/lib/python3.7/site-packages/importlib_metadata/__init__.py", line 169, in load
    return functools.reduce(getattr, attrs, module)
AttributeError: module 'openinverter_can_tool' has no attribute 'cli'

I don't know why it does it but this seems to be an artifact of the way that python setuptools functions in development mode (i.e. when you run "pip install -e .[dev,test]"). It is possible to run the tool in this mode from anywhere but rather than run "oic" run "python -m openinverter_can_tool " instead. For example:

Code: Select all

$ python -m openinverter_can_tool log --help
Usage: python -m openinverter_can_tool log [OPTIONS] PARAMS... OUT_FILE

  Log the value of PARAMS from the device periodically in CSV format. Multiple
  parameters may be specified separated by a space. OUT_FILE may be a filename
  or - to output to stdout.

Options:
  -s, --step INTEGER RANGE      Time to wait before querying for new data in
                                seconds  [default: 1; 1<=x<=3600]
  --timestamp / --no-timestamp  Include a timestamp on each row of the log
                                [default: timestamp]
  --help                        Show this message and exit.

Hopefully this will help someone in the future.

[johu]

I would deem it possible that it was attempting to run oic with python2 which is also installed in beaglebone and used as default

[davefiddes]

Not python2. Turns out I'm an idiot and wasn't specifying the module correctly in my setup.py. Pushed a change that fixes this. Probably the least valuable thing I could have done this morning but at least nobody will see this problem again.

[davefiddes]

Made another release. This one adds:

• Configurable timeouts. Slow clients or busy CAN busses would sometimes report timeouts. This is now configurable and defaults to 1 second rather than 300ms.
• Simple network scanning. It's now possible to interrogate the network (first 20 node IDs) to find out what nodes are available.
• Fix a broken implementation of the "start" command which was sending the "defaults" command. (Neither command supported by stm32-sine at this stage)

[davefiddes]

Just released v0.0.7. This adds:

• Enumeration and bitfield parameters are now displayed with the symbolic name rather than a number.
• Logging to a file will now flush the output after each line allowing you to "tail -f" the output to see what's being logged.
• A bug in the stm32-sine v5.24.R parameter database files that omitted the details of all possible errors for the "lasterr" parameter has been fixed.

[johu]

Nice, thanks. Using the tool on a regular basis for BMS development now.

Do you think it's worthwhile including the firmware update?

[davefiddes]

Makes sense to have one go-to tool I think so I was planning on adding firmware update support. I need a utility that will work with the C2000 as well as your STM32 CAN bootloader. Have a feeling that the protocol can't be 100% identical due to architectural differences but haven't really got to designing that yet.

Other stuff on my mental roadmap:

• Caching of parameter databases
• "VCU emulation" that will generate a CAN frame at 100ms intervals with the canio bits and a throttle position. I'll be possible to control vehicle direction and throttle interactively with the keyboard.
• Setting enum and bitfield parameters using symbolic names(should have been in the last release - oh well)

[johu]

I have added a function to load the legacy canmap from flash, so now the inverter can continue on the master branch of libopeninv.

[davefiddes]

That's good news. I've got parameter caching going today and it really improves the responsiveness of the tool.

[davefiddes]

Just released v0.0.8. This adds:

• Parameter databases are now cached locally. This is a *massive* usability improvement and minimises CAN traffic in normal use. Requires a very up to date stm32-sine development build. Works automatically for any project using an up to date libopeninv.
• It is now possible to write values to parameters using symbolic names where appropriate:

Code: Select all

oic write potmode DualChannel
oic write pinswap PWMOutput13,PWMOutput23

The parameter database cache is stored in an appropriate cache location for the platform the tool is run on. On Linux it's ~/.cache/openinverter_can_tool on Windows it's 'C:\\Users\\your-user-name\\AppData\\Local\\openinverter\\openinverter_can_tool\\Cache'. The files are cached by CAN SDO node ID and the automatically generated checksum the device reports. The files can be extracted from the cache and used directly if required though I'm not sure when this would be useful.

[mane2]

Hey! I would love to use this on my project. Love the idea and how it works.

Thought when I installed in on my RPI in the car and run any command, I get stack trace. Executing "oic dumpall" for example, gives me stack trace ending like this

File "/home/xx/.local/lib/python3.9/site-packages/canopen/sdo/client.py", line 304, in read
raise SdoCommunicationError("Unexpected response 0x%02X" % res_command)
canopen.sdo.exceptions.SdoCommunicationError: Unexpected response 0x60

I added the configuration file, and it finds the inverter. That command works.

I'm running latest stm32-sine. Do I need to download some database for it to work, or flash another stm32-sine firmware?

[davefiddes]

Thanks for giving the tool a shot. I'm sorry it's not working.

If I understand you correctly "oic scan" is reporting that your inverter is communicating ("Found possible openinverter node: 1")?

It should be possible to run "oic listparams" to get a list of all of the possible configuration parameters and spot values. This will automatically download the parameter database from the device.

Another simple command to test is "oic read version" which should output:

Code: Select all

$ oic read version
version             : 5.27.R-sine

You really need to be running stm32-sine 5.27.R (FOC or SINE - it doesn't matter). It's possible to use earlier versions but there were too many bugs for it to be reliable.

If none of these works can you install the candump command with "apt install can-utils" and run "candump -l can0" in another terminal session on your Pi. Then run "oic listparams" again. This will log all the can frames to a file called "candump-xxxx-xx-xx_xxxxxx.log". If you are set up to use Wireshark or SavvyCAN to log frames that would work too.

Also, can you post the whole stack trace. Thanks!

[mane2]

Hi Dave! Yes, oic scan reported, found openinverter node 1.

I haven't tried oic read version. Will test it next.

Yes, I'm running 5.27.R.

I'll try candump, but as the bus is shared with other devices too, like charger, bms etc .., there is lot of traffic.

I briefly looked at the code, and as there was mentions of "response", I started wondering if this tool is to be used only with inverter active in the same bus? I had a feel that some other device sent messages between request and response, and this software thought the wrong message was the response, thus missing some data from response.

[davefiddes]

It should be fine on a busy bus. It's important when running multiple openinverter systems that they have unique "nodeid" parameters. With the default config you are using the tool will send messages with ID 0x601 and the inverter will reply with ID 0x581. If there is a conflict on the bus this will confuse things a lot.

There was a long standing bug in stm32-sine which didn't allow operation with a nodeid other than 1. I suspect this also applies to VCU firmware. Changing your inverter to nodeid 2 might be beneficial. You then have to add "-n 2" to each oic command.

You can filter out unimportant frames with something like "candump -l can0,601:7ff,581:7ff". If you change to nodeid 2 the CAN IDs would need to be changed to 602 and 582.

[mane2]

Oh, my BMS is sending constant 0x601 messages to limit DC current to inverter. That must be the reason why reply is invalid! Tool reads the dc-current-limit reply and as it's 0x581 as well, and probably the data in resoinse is just the new dc-current limit, not the reply the tool is expecting.

So I need to disable the dc-current limiting while using the tool. Hmm.. I wish the 0x581 reply message would have something to identify the request, which the response is related. Now only one tool can talk to inverter in a bus at the same time.

[davefiddes]

Ah. That's not going to work. You can't really have two SDO clients modifying the same device simultaneously.

If you have control over your BMS software it would be better to get it to output the DC current limit in a new CAN message at regular intervals. Then you can map that as an CAN RX parameter.

[mane2]

Thanks for the tip! I will do that!

[johu]

I have worked on the CAN module a bit more. I have split the SDO handling to a new module.

https://github.com/jsphuebner/libopenin ... 35759273b9

I have also changed the way that values can be mapped onto the bus via an SDO. Now two SDOs are needed
SDO Index 0x3xxx, subindex 0 contains the parameter id, bit position and length in the data field, e.g.

Code: Select all

0x601#0x23 0x0A 0x30 0x00 0xF6 0x07 0x08 0x08

(value ID 2038, bit position 8, len 8 (last byte)

Now we need to send a second SDO with subindex 1 (map TX) or 2 (map RX)

Code: Select all

0x601#0x23 0x0A 0x30 0x01 0xE8 0x03 0x00 0x00

It contains a 24-bit gain times 1000 and a 1-byte offset. The COB ID (10) is still encoded in the last 11 bits of the SDO index.

UPDATE: just added, subIndex 3 will delete the value from the mapping.

Does this seem feasible? Do you want to add it to oic?

[davefiddes]

Interesting. The stateful nature of the sub-index 0 and 1 or 2 is unconventional but should be OK.

For it to be useful as a general API I think we need a read capability. Just reading back from the sub indexes 0, 1 and 2 would be fine. Listing all mappings would require a brute force of all known parameter IDs but that seems fine.

In addition to the basic parameter mapping create, read, update delete commands I would like to be able to save and load maps to a local file. I think it should be possible to do this with a DBC file which would allow easy import into SavvyCAN and other tools.

[johu]

Yes, was thinking about making it one of those multi message transfers but then that's stateful as well.

The mapping is also provided in the json but that is of course quite bulky. And double maps don't appear, i.e. if one parameter is mapped multiple times.

Could also redirect "can print" to CAN but that isn't very elegant either.

Reading back from the same object is ambigue because the addressing data is in the SDO data portion.

Maybe I should think this over and handle it like setting parameters. I.e. the address is the parameter ID, subindex 0 and 1 are the first mapping for that parameter, 2 and 3 the second and so on.

[davefiddes]

Sorry for the slow reply. Not been working on OI or CAN for a while and the thoughts are a bit dusty.

I wonder if it would be simpler and more logical to map the CanMap directly to a CAN SDO Index. That is, have the index be the position within the Tx or Rx CanMap. The sub-indices could then be the parameters (param, canId, offsetBits, length, gain and offset). We'd also need an enable subindex as well so that partially configured maps weren't made live before they were ready. It may be an idea to have a special index to obtain the maximum number of map entries to avoid spamming the device with lots of unsupported requests.

This approach would remove the stateful nature of the protocol completely. It also seems to map to the internals of the CanMap class reasonably cleanly.

[johu]

So say index 0x3001 to 0x3020 or something and index 0x3000 subindex 0 is just the number of items

Then
subindex 0 - COB Id
subindex 1 - data ID, bit position and length
subindex 2 - gain and offset
subindex 3 - 0=disabled, 1=TX, 2=RX

The programming will be slightly inefficient because internally the mapping is a tree structure. But then these messages won't be used often.

And you can only "commit" the entry when all sub indexes have been set so it still is somewhat stateful

EDIT: maybe the tree structure should be reflected.
So 0x3001 would contain all TX mappings for COB Id x

subindex 0 - COB Id and flag - 0=disabled, 1=TX, 2=RX
subindex 1 - data ID, bit position and length of item 1
subindex 2 - gain and offset of item 1
subindex 3 - data ID, bit position and length of item 2
subindex 4 - gain and offset of item 2
...

[johu]

After programming around for a while I'm running into the pros and cons of the various approaches.
If reading and writing the map is symmetrical and index based, you always need to download the entire CAN map to know which ID is on which index and what the next free sub index is. So while this approach looks cleanest it is actually harder to use.

The original approach makes it easy to add new items but only allows standard ids and is hard to read back without knowing the mapped ids.

So now I'm thinking to leave reading index based, say indexes 0x3001 to 0x3040 or so let you read the mapping as described above
Index 0x3000 lets you add a map, stateful as in the original approach and with the COB id in an extra sub index
Writing all zeros to an item in the 0x3001-0x3040 range deletes the respective item from the map and that gap is closed by moving the following ones up.

[davefiddes]

That sounds workable I think.

Would you allow updating of existing entries or would they have to be deleted and recreated? Might be nice if adding with an existing CAN ID/parameter pair would replace the existing mapping details.

When listing I'm assuming I have to iterate through each sub-index until I get an error.

If I understand correctly apart from delete the 0x3001 mapping list would be read-only.

Some examples of how the commands might look:

Code: Select all

oic map list
oic map add tx 0xA5 angle --position 0 --length 16 # gain defaults to 1, offset to 0
oic map add tx 0xA5 idc --position 16 --length 16 --gain 42.34 --offset 128
oic map delete tx 0xA5 # Remove all parameters mapped to Can ID 0xA5
oic map delete tx 0xA5 angle # Remove just the "angle" parameter mapping
oic map add tx 0xA5 idc --position 32 --length 16 --gain 10 --offset 0 # Updates the existing "idc" mapping
oic map save my-clever-can-map.json
oic map load my-clever-can-map.json # Just adds to the existing map. An --erase option would erase before loading
oic map erase tx