J1939 - What to do

Issue #65 resolved
Brian Thorne repo owner created an issue

I'd like to hear your thoughts on the J1939 issues that exist within this library. I’ve only seen it work properly with the kvaser backend, and I don’t know if anyone is using it?

Option 1 - Full Repair

Carefully go through the design, identify areas of strength and weakness. If necessary entire implementation may need large scale refactoring, document and test properly.

This may require significant effort. Personally I would like at least one industry sponsor willing to commit resources to help with development and testing.

Option 2 - Deprecate and remove

Decide that enough is enough, cut a release that warns of impending removal and then in 6 months or so remove the protocols part of this library.

Option 3 - Leave well alone

The default open source action... leave the functionality despite knowing there are significant issues and lack of documentation. Perhaps one day someone will have the urge to fix it.

In any case I’m very keen to hear opinions.

Comments (8)

  1. Phil Birkelbach

    I would vote for #2. python-can should do CAN really well and leave the higher level protocols for other packages.

  2. Travis Travelstead

    I would say the same. Option 2 I think makes the most sense, focus on the core tool and allow the most flexibility on usage and platforms.

    If people are interested you/we/them could start another project just to maintain CAN protocol libraries instead of trying to mix the two.

  3. Rapzak

    Hi,

    I am starting using this library, main reason are the J1939 protocol :) Just to let you know that there is a use for it. But i see no problem in split it up - but hope it still could be made so it can work together. /Rapzak

  4. Mike Molt

    I'm a bit of a noob, so forgive me if I'm speaking out of place, but can't those wanting to utilize the J1939 protocol just map their messages into an extended can message?

  5. Brian Thorne reporter

    Thanks all, I agree that option 2 makes the most sense. I've released version 1.5.0 to pypi which adds a deprecation warning to both the protocols sub-package and the J1939 module.

    @Rapzak or anyone else wanting to use the J1939 code - please feel free to copy (or start again) in another repository.

  6. David Miller Lowe

    I also have a need for the J1939 stuff and have pulled off the protocol to a separate repository.

    You can get the updated repo python-j1939 off github and with minor changes (importing j1939 directly)

    Generally the only changes I have made to my scripts are to change

    from can.protocols import j1939
    

    to

    import j1939
    

    Please post any issues or change requests to github and I'll try to get to it!

    Miller

  7. Log in to comment