Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

Watchdog error with NI-CAN 2.2 PCMCIA and LAbview 7.1

I try to build up a communication with a Aircondition control unit (car) over CAN with Labview 7.1. therefore I open a write channel and a read channel on different addresses. I am using channel API. Write and read direction are combined with a wait.vi to be sure, that written queue was cleared and read command will be first called, when data is available on read-queue. But the wait.vi gives out State 18 and an error code 0xBFF62021 (Watchdog timeout). I initialize the read port with period 2000ms, read and write queue=0, receive changes only=false, receive unsolicited, transmit by response=false, datalength=7.
Why does the error happens? Is there a possibility to prevent this watchdog-error?
0 Kudos
Message 1 of 6
(4,603 Views)
Hi Michael,

Just to understand it right: You are using the Channel API and you feed the handles (tasks) from the CAN Initialize (or CAN InitStart) into the ncWait VI from the Frame API?
If that is the case, it does not work – the VIs of the Channel and the Frame APIs cannot be mixed and matched.
I’m surprised that the ncWait VI does not generate an error message (other than the timeout) in this case.
However, I can see that the timeout error is generated, as the ncWait waits on Frame API states that (such as ReadAvail or WriteSuccess) which the Channel API doesn’t return. Thus, it simply waits for the specified amount of time and generates the error after it times out.

-B2k
0 Kudos
Message 2 of 6
(4,594 Views)
I replace channel API read/write with frame API. But I got still a watchdog error at the wait-function before the read function.
I reduced my program to a minimum:
1) open and initialize write
2) open and initialize read
3) write and wait
4) wait and read
5) close write,read.

Point 1,2 and 3 run without error. After wait the detected state is 0x12 and error is 0xBFF62021.

Who generate state code and which watchdog causes the error (software, NI-CAN card or the aircondition contol unit)?
0 Kudos
Message 3 of 6
(4,592 Views)
Hi Michael,

The timeout is generated by the NI-CAN driver software. The state you wait on simply did not occur within the specified amount of time. What state do you try to wait on? The returned state indicates the WriteSucess state (0x2) and a timeout (0x10).

Could you post an NI Spy log file that shows when the ncWait returns that timeout?
NI Spy captures calls from your VI to the NI-CAN driver. Launch NI Spy at:
Start » Programs » National Instruments » NI Spy

-B2k
0 Kudos
Message 4 of 6
(4,587 Views)
Hallo B2k,

attached you can find the SPY-file from the program run and a development and distribute export of the VI (ReadStartDiagnosticSession.vi). The error (watchdog timeout) occurs in the second sub-vi connect_setup.vi at the wait.vi before the read command within the while-loop.

I hope the listings will help you to give me a hint how to follow up or solve the problem.

Regards
Michael Gerber
0 Kudos
Message 5 of 6
(4,585 Views)
Hi Michael.

In this case, the (watchdog) timeout occurs because the CAN Object did not receive a frame within the specified period of 2000 ms (see 2nd ncConfigCANObj.vi for the receive object).
When the object is started via the ncOpen, the watchdog timer starts and apparently times out after two seconds. This 'error' interrupts the ncWait VI for the receiving object.

Thus, you might want to limit it to have only one instance that waits for the frame to be received: Either you specify a period when you configure the CAN Object for receive or you use the ncWait function.

-B2k
0 Kudos
Message 6 of 6
(4,506 Views)