J1939 Error - Caterpillar ECM

try changing you Priority to 3.

This looks familiar with our machine, we have three similar errors when starting up (MD3) They are registered as Timeouts.

Thank you for your suggestion, David.
I changed the offending PGNs to priority 3. (They were all at 6.)
I'm going to keep an eye on the machine over the next several weeks, but that seems to have fixed it!

Jan, were you able to come up with any sort of resolution about it for the MD3?

Most engine messages are setup for Prority 3 when dealing with public SAE J1939 messaging.

About the priority on the JFIN, one recommendation is to use the 'don't care' option for this property, then the JFIN:s won't be filtered out based on priority, but only on PGN and Source Address.





About the J1939 error, you will get this status on a JPIN if it uses the property J1939 error check, and the bit-value is outside of the standard error detection range for J1939.



The error range for J1939 values depends on the size of the parameter:

• 2 bit: Error > 1
• 1 byte: Error > 250
• 2 byte: Error > 64255

The special case is when all bits are 1, then that means the parameter is not available.
IQAN will use the status "J1939 not available" for the case where all bits are one, and "J1939 error" for all other cases where the parameter is outside of the error detection range.
"J1939 not available" will not be put in the log, but "J1939 error" will.

The strange thing is, I don't see why you would get a "J1939 error" on these parameters. It would be expected if the offset within the data field was set wrong on the JFIN, or if the lenght was wrong on the JPIN. But this looks correct.

Thanks for the response, Gustav.

I experimented with different priorities, and with setting it to "don't care". I get inconsistent results with "don't care." Depending on the engine (we only use Caterpillar engines, but different sizes and age ranges), priority 3, 6, and "don't care" would sometimes cause the "J1939 Error" to show, and sometimes not.

I have more data now, and it seems to be pointing to a problem with the J1939 Error Check, as you suggested.

Here is a screenshot of an Analyze file, filtered to show only PGN 65262, engine temperature. I started the recording with power to the ECM off, and then turned the ignition on (ECM power-up) at 5 seconds. As you can see, the first two transmissions show 254 in the location of the engine temperature parameter.
The other parameters that show error also have too-high values for the first several transmissions. (Why, CAT, why?)

I guess my question at this point, is what exactly does "J1939 Error Check" do? It seems like the only thing it does is log errors if the J1939 data is outside acceptable limits... If that is so, I think we can run without it.




Here are screenshots of the corresponding parameter in the IQAN program:

I know it is designed to be a priority 3 message, this is stated in the Installation guide for the engine.

The parameter "J1939 error check" will have two effects if the parameter is outside the data range (bit value above >250 for a 1 byte parameter)
The channel status will change from OK to error, and the channel value will become the Error value defined on the JPIN.
The error status will also be logged in the system log.

Below is a printrsceen from a simulation, in the IQANsimulate window on top the raw value is shown (254), and in the IQANdesign window, the channel value is shown, here it is 0°C, the error value defined on the JPIN.


If you set J1939 error check to No, the JPIN will not consider the value 254 to be an error, and instead use the value sent out to calculate a temperature that is outside of the data range for Engine coolant temperature (-40 to 210 °C). The JPIN would get the value 214°C.



Since there is conflicting information about the priority, I would recommend setting Priority to don't care. That way you can use the same application for both the priority 3 and priority 6 variants.

Thank you Gustav, this has been quite helpful. We're going to set our ECM JPIN error checks to No by default, and continue to experiment with priority.