J1939 program groups with symbols in Rx view : failed refreshes

[tcoquard]

Needing to receive and symbolically interpret a particuler J1939 message which can be either in the single- or multi-packet format (depending on its length) (in my case the standard DM1 message), I created the symbol file accordingly (message type is J1939PG and a large number of field definitions in case of very long messages with a large number of DTCs).

However, when looking at the periodically received message in the Rx list view, when the message contents change, only the raw hex data (displayed at the root node level) get refreshed, whereas the symbolic display (child nodes below) never updates.

This problem does not occur with raw non-J1939 CAN frames and a non-J1939 symbolic definition.

Has this bug been fixed in further versions of PCAN-Explorer and/or the J1939 add-on ? I've done a search on the forum and found nothing about it.


Thanks in advance.

[M.Heidemann]

Hello,

Can you provide us with some more information?

Perhaps a a screenshot from the Symbol-Editor showing your configuration
and perhaps the message it is supposed to apply to?

Also i assume your connection is configured to be a J1939 connection?

J1939.PNG (8.88 KiB) Viewed 9139 times

Can you confirm?

Best Regards

Marvin

[tcoquard]

I'll do this after the lockdown (in France, until May 11 or later) when working at the office again, where I left all the hardware needed for the experiment.
I indeed will have to do intensive testing on the project related to this.

[tcoquard]

Still working at home, I'll be able to answer much later only...

[M.Heidemann]

Hello,

Thank you for your reply!

Don't worry, we will be here to answer you, once you are able to check this.

Best Regards

Marvin

[tcoquard]

Hello.

Late after the end of the lockdown, I'm back on the project where I encountered the problem.
I've checked the properties of the connection, especially :

• Protocol=J1939
• Reassemble incoming packets=True

My symbols file contains a hand-made description for a J1939 DM1 message with up to 50 DTCs. Here is an excerpt :

Code: Select all

[DM1]
ID=1CFECA1Eh
Type=J1939PG
Multipacket=True
Var="Malfunction Indicator Lamp Statu" unsigned 6,2 /e:LampStt_e
Var="Red Stop Lamp Status" unsigned 4,2 /e:LampStt_e
Var="Amber Warning Lamp Status" unsigned 2,2 /e:LampStt_e
Var="Protect Lamp Status" unsigned 0,2 /e:LampStt_e
Var="Reserved for SAE assignment Lamp" unsigned 8,8 -o
Var="DTC#1" unsigned 16,24 -h /e:DTC_e
Var="SPN Conversion Method#1" unsigned 47,1 -o
Var="Occurrence Count#1" unsigned 40,7
Var="DTC#2" unsigned 48,24 -h /e:DTC_e
Var="SPN Conversion Method#2" unsigned 79,1 -o
Var="Occurrence Count#2" unsigned 72,7
// Etc...

Last minute clue : as shown in the two screenshots below, where I receive the same J1939 DM1 message with the same two DTCs (thus a length of 10 bytes), whose contents gets displayed correctly in raw format :
with the use of enums, the symbolic view only displays the 1st DTC :

Rx_NoMultipacketRefresh.png (8.17 KiB) Viewed 8837 times

... whereas without the use of enums, the symbolic view gets displayed correctly :

Rx_NoMultipacketRefresh_NoEnums.png (11.66 KiB) Viewed 8837 times

[tcoquard]

Again new last minute clues :

• After restoring the symbols file to its original state = with enums (by overwriting it externally with the correct version) and being notified by PCAN-Explorer of this external file change, now the symbolic view displays both DTCs correctly (with enums) ?!!!
• If I close and then re-open PCAN-Explorer, then the bug appears again (1st DTC symbolically displayed, 2nd DTC with '?' in all off its fields)

[tcoquard]

Additional hypothesis found from these latest facts :
the interpretation of enums may play no role at all in the bug.
Rather, the reloading of the symbols file triggered by external changes to it (no matter it has enums or not because it happened when I removed the enums, as well as when I restored them) restores the correct behaviour (symbolic display for the whole multipacket frame), whereas the loading on application startup turns the program into an inconsistent state (==> symbolic display of the beginning only).

[M.Heidemann]

Hello Thierry,

We'll need additional information to properly assess the issue you are having:

1. Which Version of PCAN-Explorer 5 are you currently running? You can get this information via: "Help" -> "About PCAN-Explorer"

2. Do you edit your symbol-file using an external editor?(Like eg. Notepad++, Sublimetext, etc)


Best Regards

Marvin

[tcoquard]

PCAN-Explorer version : 5.4.3.905
Use of an external editor for symbol files : yes, sometimes : Notepad++ (as far as I know, it does detect the text and new-line encoding and does preserve them upon saving, in case PCAN-Explorer were sensitive to them).

(I never encountered the aforementioned bug with raw CAN messages, which is my most frequent use case).