CanWarnComm

[Brian C]

Greetings.

Background

---

According to the NI-CAN Help file...

If no CAN devices are connected to the network interface port, and you attempt to transmit a frame, the CanWarnComm status occurs. This warning occurs because the missing acknowledgment bit increments the transmit error counter until the network interface reaches the error passive state, but bus off state is never reached.

I'm using a single USB-8473 with no CAN connection. 

Test Program

---

The test program consists of...

1. ncConfig - set NC_ATTR_START_ON_OPEN to NC_FALSE
2. ncOpenObject - to open the port
3. ncGetAttribute - to get the hardware serial number
4. ncConfig - set the baud rate, read Q, write Q, CAN masks, and NC_ATTR_LOG_COMM_ERRS to NC_TRUE
5. ncAction - NC_OP_START
6. ncWrite - write one frame with three data bytes; return value is zero
7. ncWaitForState - NC_ST_WRITE_SUCCESS; timeout set to 30000; return value is CanErrFunctionTimeout
8. ncCloseObject

Question

---

When / how is CanWarnComm returned?

Thanks,

Brian

[Justin_E]

Hey Brian,

The warning should be passed from the ncWrite function. I'm assuming that you are not seeing this warning being passed from that function, so I connected up a USB-CAN device to my machine to see if I could replicate the error, and also was unable to see this warning. I'll have to research into this a bit more to figure out what's going on.

[Brian C]

Hello Justin,

> The warning should be passed from the ncWrite function.

Actually, I exepcted ncWaitForState to return the warning.

> I'm assuming that you are not seeing this warning being passed from that function

ncWrite returns zero (success) and ncWaitForState returns timeout.

> I connected up a USB-CAN device to my machine to see if I could replicate the error

> I'll have to research into this a bit more to figure out what's going on

Thank you.

Brian

Message Edited by Brian C on 04-07-2009 02:44 PM

[Justin_E]

Hey Brian,

I've worked on this issue a bit more and have been able to replicate the warning message. I've verified that the warning is passed from the ncWrite function, and believe that I know why you aren't seeing this error with your application. With the ncWrite function, the transceiver will try to send the frame over and over again until it is successful. The program will move past this function onto other functions (in your case, ncWaitForState) while the transceiver is attempting to send. If the ncWrite function is called a second time, the warning will be returned because the transceiver was never successful in sending the frame. The reason you are not seeing this warning is because you are calling the ncWrite state only once. The ncWaitForState times out because it does not see a success, which is expected. If you were to remove the ncWaitForState and run through another ncWrite, you would see the warning message. That warning message will never be returned from a single ncWrite.

[Brian C]

Hello Justin,

> If the ncWrite function is called a second time, the warning will be returned because the transceiver was never successful in sending the frame.

Yikes!  That makes error recovery very difficult for a query / response protocol.

Is there any other way to obtain the bus state?

Can the bus state be determine with ncGetAttribute?

Is it possible to get a notification when the bus state changes?

Thanks,

Brian

Message Edited by Brian C on 04-08-2009 06:38 PM

[GPIB_Guru]

Maybe a dumb question - but why isn't getting the timeout from wait for state sufficient?

[Justin_E]

Hey Brian,

You might be able to use the ncGetAttribute function with this attribute : NC_ATTR_SERIES2_ERR_ARB_CAPTURE

If you take a look at page 11-52 (or 546 of 692) in the NI-CAN Hardware and Software manual (found here : http://www.ni.com/pdf/manuals/370289k.pdf ), you'll see that bus errors are captured in the Error Code Capture register. The first bus error is stored here until you get this attribute. So, if a bus error has occured, you should be able to see it with this attribute, but again the warning message that you want to see might not have been generated yet for the same reasons discussed above.

[Brian C]

Guru,

> Maybe a dumb question - but why isn't getting the timeout from wait for state sufficient?
 

I need to be able to tell if the converter is bus off (cable problem) or error passive (no device connected).

Thanks,

Brian

Message Edited by Brian C on 04-09-2009 12:09 PM

[Brian C]

Hello Justin,

According to the documentation, "the CanErrComm status occurs" when the converter goes to the bus off state.  Does this mean that any of the CanErrComm* return codes could be returned?  Do the return values CanErrCommStuff, CanErrCommFormat, CanErrCommNoAck, etcetera indicate the converter is bus off?

Thanks,

Brian

Message Edited by Brian C on 04-09-2009 12:59 PM

[Justin_E]

Hey Brian,

I don't believe that this means the bus off state occurs if any of the CanErrComm* values are returned. A bus off error ONLY occurs when the transmit error counter exceeds the value of 255. CanErrComm* values can be returned even if this state has not been reached. From the manual, it looks like you will have to log the bus errors (using the ncSetAttribute function) first, then during an ncRead function you'll be able to determine of the bus is off. When bus errors are being logged, the ncRead function can return a value of 6 in the IsRemote field (refer to table 11-17 on page 11-77, or 571 of 692 in the NI-CAN Hardware and Software manual). If this value is returned, the other return values can indicate if a bus error has occured. It looks like the CommState byte in the Data field indicates the communication state, and if this byte has a value of 2, then the bus is off.