Today I am going to collect data in a more methodical way, but here is a sample of what I picked up yesterday.
You have to be careful with many of the entries. Things are often miss-marked. For instance, Maximum Charge Current very well may be to 10^-1, so if it reads out 392A they may mean 39.2A. Very common practice to offset by orders of magnitude while packing into CAN.
OFTEN… The Software Engineer on the other end does not know their Electrical Rules of Thumb and they miss something like mA, uA, Amps.
Sorry for the rude dump, I have just learned to post up at least SOME of the data before it is lost to “the Schindler Archive”. I have terabytes of projects like this. If I dont share the data then I cant help the next guy.
Often…
The next guy is ME!
Lol… Nobody searches the 4,800 posts of Schindler Engineering more than I do. This is my notebook 😉
When you clear errors and they hold you get this above on next scan. That is a big YEA!
When you clear X errors and X-3 come back, you get a different message alerting you to the fact that some errors were not cleared.
Above shows returning errors. Below shows variants of state
Each system is unique in their vocabulary, but fundamentally they all operate the same.
Inactive
0
Percent
Decimal
Picture all of this being packed into CAN messages and then unpacked. What do they call this one? CAN-FD iirc? Back in the day we had to hand pack all of this. It was true horror.
You have to know which module various messages are coming from. That is not displayed but selected from the Home Screen. After a while, you will know which module generated data.
Before that point, inundation with details. Some excruciatingly important, most CRUFT.
J1772 now reading a much more sane 57F. It looks like the transaction requested 16A of service. We are drawing around 600mA at 122V
122V * 0.6A = 73.2W
Ohms Law
Ok, so we are cooking off ~70W somewhere. That is actually quite a bit of power, far more than some relay coils is my guess.
You never know WHAT they decided to do in the decision tree, so malfunctions in something like the restraint system SHOULD BE CORRECTED! I could totally see some overzealous firmware engineer disabling drive in the event that the restraint system is malfunctioning.
Word to the Wise….
PLUG EVERYTHING IN, EVEN IF ((YOU)) DONT THINK IT IS IMPORTANT
GUYS LIKE ((ME)) PUT HOOKS IN THINGS
YOU HAVE BEEN WARNED
A system like this may have 42 “Faults” that it will cite as reason for not motoring. There very well may be 17 more which are silent killers. FAFO. Time is Money.
My guess is that the BMS Master is talking. I never did see long lists of String Voltages, but they do not always expose that at the User Level. There may be a lower level tool specifically for Unit Testing the Battery Sub-System.
Wonder if that really is the 575th battery of that year. Could be. It was a really small production run.
Ack
That is a hot bag right there above. We also see some UnderVoltage faults on string B, which implies a string A. I am sticking with my guess that some of the batteries drifted under after a long sit.
I am just peeling off random screen shots. This is not a complete package.
The machine is never going to tell you what the problem is. It is only going to supply data for you to use in determining what the problem is. OBDII in more modern vehicles has become so refined that it will even suggest Part Numbers for Replacement!
This… Not so much
