I implemented J1939 Manager to my project and added some mesages into the ECU. Now I want to get a bit for the acknowledgement of the message. I want to be sure the message is received by control unit successfully. Is there a way for it?
Thanks in advance,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Er... what kind of messages are you transmitting?
If you are transmitting a normal PGN (not the ones, mainly from J1939-73 or e.g. the Reset, that require the ACK/NACK response) you have no way to know if the remote control unit has received the message, because CAN is an unconfirmed protocol and most J1939 PGN are unconfirmed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your answer.
I have created a PropB message (0xFF00), added it into the Tx signals window(inside the ECU which is under the J1939 manager). But as far as I saw, there is no prepared feature for acknowledgement.
Maybe I can add a byte for acknowledgement manually and check this inside of the ECU manually.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But a Proprietary B is a broadcast message. There is no "receiver" as far as the J1939 standard is concerned.
If you really want to have a "destination" you should use the Proprietary A (and implement acknowledgement, since it is an unconfirmed PGN as well).
Yes, I know that most people use Proprietary B space as destination-bound messages based on a fixed source address. It's still the wrong thing to do.
Then there are some idiots that use Proprietary A for what should have been broadcast messages, either using a dummy destination address or the broadcast address (and that causes some stacks to drop the messages as invalid since the broadcast address is allowed (actually mandated) only in the Address Claim PGN which should have really be a broadcast message in the first place).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just want to implement extra acknowledgement info for the control unit side.
this defeats the entirwbpurpose of CAN J1939. It has been designed to be intrinsically safe and cannot have any data losses.
So by introducing this extra ack you lower your bandwidth and use the protocol as not intended.The reason it is "uncomfirmed" is because it is not necessary.
Last edit: aliazzz 2022-01-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, "intrinsically safe" and "cannot have any data losses" are big statements.
First of all, a communication protocol is almost never "intrinsecally safe", let alone J1939. Perhaps the control units are, but not the protocol itself.
By default, except on some PGN like TSC1 (if counter&checksum are not 0xFF anyway), you cannot detect e.g a "babbling idiot". You don't have by default transmission of bit-inverted signals along with straight ones like in CANopen safety or CRC like in STW custom safety protocol (yes I know the message CRC, but apparently someone smarter than me has determined that it is not as robust as it should be to be claimed safe).
Also, most J1939 stacks do not implement receive timeout, or it's an opt-in (like in Codesys via ReceiveWatchdog). It's not mandated by the standard (except for transport protocol and address claim).
The concept of "data loss" is more vague and somewhat philosophical. Maybe one of the receivers goes off, so it misses a broadcast (this is independent of the PGN length, it happens also with the broadcast TP). Is data really lost if other units have received it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good info. You clarify the usecase issue and a specific definition problem at the same time. A user specific solution seems like the only remedy, which is also maybe not the most favourable solution if chosen wrong. So the way I see it it's either that or accept the situation as is. Too bad this has not been forseen in the protocol. Did you ever do some digging why this has not been resolved in the protocol itself?
Last edit: aliazzz 2022-01-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bear in mind that I am not the OP, I do not want to implement an acknowledgement scheme in J1939.
Some manufacturers of safety-certified J1939 devices use inverted signals on two different addresses and/or counter+CRC and monitor timeout of received messages if any, but I do not know anyone that check for an acknowledgement.
The only request/reply pattern I implemented in a J1939 ECU was a CANopen SDO interface on Proprietary A.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just for your information I want to share with you what I did for this. I just used ReceiveParameterGroup and ReceiveWatchdog function blocks to understand the specific message is received by PLC. I tested it and it works.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi All,
I implemented J1939 Manager to my project and added some mesages into the ECU. Now I want to get a bit for the acknowledgement of the message. I want to be sure the message is received by control unit successfully. Is there a way for it?
Thanks in advance,
Er... what kind of messages are you transmitting?
If you are transmitting a normal PGN (not the ones, mainly from J1939-73 or e.g. the Reset, that require the ACK/NACK response) you have no way to know if the remote control unit has received the message, because CAN is an unconfirmed protocol and most J1939 PGN are unconfirmed.
Thanks for your answer.
I have created a PropB message (0xFF00), added it into the Tx signals window(inside the ECU which is under the J1939 manager). But as far as I saw, there is no prepared feature for acknowledgement.
Maybe I can add a byte for acknowledgement manually and check this inside of the ECU manually.
Yes, in this case you can check a response with a ReceiveWatchdog https://help.codesys.com/webapp/LvXY4WjsWFNOt1Hf6flhwiAK3oY%2FReceiveWatchdog;product=IoDrvJ1939;version=3.5.17.0
and examining the content of your custom acknowledge message when xReceived output goes TRUE.
But a Proprietary B is a broadcast message. There is no "receiver" as far as the J1939 standard is concerned.
If you really want to have a "destination" you should use the Proprietary A (and implement acknowledgement, since it is an unconfirmed PGN as well).
Yes, I know that most people use Proprietary B space as destination-bound messages based on a fixed source address. It's still the wrong thing to do.
Then there are some idiots that use Proprietary A for what should have been broadcast messages, either using a dummy destination address or the broadcast address (and that causes some stacks to drop the messages as invalid since the broadcast address is allowed (actually mandated) only in the Address Claim PGN which should have really be a broadcast message in the first place).
The message what I used is not specific for a receiver. That's why I added PropB message as a broadcast message.
I just want to implement extra acknowledgement info for the control unit side.
I just want to implement extra acknowledgement info for the control unit side.
this defeats the entirwbpurpose of CAN J1939. It has been designed to be intrinsically safe and cannot have any data losses.
So by introducing this extra ack you lower your bandwidth and use the protocol as not intended.The reason it is "uncomfirmed" is because it is not necessary.
Last edit: aliazzz 2022-01-14
Well, "intrinsically safe" and "cannot have any data losses" are big statements.
First of all, a communication protocol is almost never "intrinsecally safe", let alone J1939. Perhaps the control units are, but not the protocol itself.
By default, except on some PGN like TSC1 (if counter&checksum are not 0xFF anyway), you cannot detect e.g a "babbling idiot". You don't have by default transmission of bit-inverted signals along with straight ones like in CANopen safety or CRC like in STW custom safety protocol (yes I know the message CRC, but apparently someone smarter than me has determined that it is not as robust as it should be to be claimed safe).
Also, most J1939 stacks do not implement receive timeout, or it's an opt-in (like in Codesys via ReceiveWatchdog). It's not mandated by the standard (except for transport protocol and address claim).
The concept of "data loss" is more vague and somewhat philosophical. Maybe one of the receivers goes off, so it misses a broadcast (this is independent of the PGN length, it happens also with the broadcast TP). Is data really lost if other units have received it?
Good info. You clarify the usecase issue and a specific definition problem at the same time. A user specific solution seems like the only remedy, which is also maybe not the most favourable solution if chosen wrong. So the way I see it it's either that or accept the situation as is. Too bad this has not been forseen in the protocol. Did you ever do some digging why this has not been resolved in the protocol itself?
Last edit: aliazzz 2022-01-14
Bear in mind that I am not the OP, I do not want to implement an acknowledgement scheme in J1939.
Some manufacturers of safety-certified J1939 devices use inverted signals on two different addresses and/or counter+CRC and monitor timeout of received messages if any, but I do not know anyone that check for an acknowledgement.
The only request/reply pattern I implemented in a J1939 ECU was a CANopen SDO interface on Proprietary A.
Hi All,
Just for your information I want to share with you what I did for this. I just used ReceiveParameterGroup and ReceiveWatchdog function blocks to understand the specific message is received by PLC. I tested it and it works.