Page 2 of 2
Re: J1939 program groups with symbols in Rx view : failed refreshes
Posted: Fri 4. Sep 2020, 08:23
by M.Heidemann
Hello Thierry,
Can you send us your project files (including the symbol file) via email to support[at]peak-system.com, so we might investigate this issue further?
We could not replicate this as of yet.
Best Regards
Marvin
Re: J1939 program groups with symbols in Rx view : failed refreshes
Posted: Mon 7. Sep 2020, 14:47
by tcoquard
While testing a stripped down version of my project I'm about to send, I managed to refine, even more, the steps to reproduce the bug :
- Reset the Rx view ([Connections] - [Reset] menu or equivalent tool button) while the embedded device periodically sends DM1 messages containing zero or one active DTC, which fit in single CAN frames
- Expand the symbolic view ==> symbolic view displayed correctly
- Make the embedded device send the same DM1 message using the J1939 transport protocol (BAM method) by increasing the number of active DTCs ==> incomplete symbolic view display... unless you force a reload of the symbols file ([Apply] command)
- Reset the Rx view while the embedded device already periodically sends multipacketed DM1 messages (2 or more active DTCs) ==> symbolic view displayed correctly
- Reduce the active DTCs to one or zero (==> symbolic view is correct)
- Reset the Rx view again and expand the symbolic view again ==> same as in the beginning
- Again, increase the number of active DTCs to 2 or more ==> again, incomplete symbolic view display...
- Repeat such kinds of tests : they should behave the same... otherwise there may be some race condition somewhere (I've seen varying behaviours when restarting PCAN-Explorer instead of just resetting the Rx view)
Re: J1939 program groups with symbols in Rx view : failed refreshes
Posted: Tue 8. Sep 2020, 12:11
by M.Heidemann
Hello Thierry,
This is a bug present in PCAN-Explorer 5.
This behaviour manifests itself if the first message of DM1 is a regular 8 byte message,
prompting PCAN-Explorer 5 to not interpretate longer messages afterwards.
A workaround would be to ensure that the first DM1 message received is always a multipacket message or
flushing the receive list manually once a multipacket DM1 is not properly encoded.
A patch or bugfix for this is not available.
PCAN-Explorer 5 is out of support and does not receive any updates or patches anymore.
This bug is not present in PCAN-Explorer 6 and could not be reproduced with it.
Best Regards
Marvin