CAN messages are not transferred to the Bus

[_Y_]

We encountered such a strange problem. LabVIEW program communicates with equipment via CAN. NI USB CAN is used. The program receives CAN requests and reply with series of frames.

Eventually, some frames in series are not transferred to CAN bus. I traced the execution down to "Write Net" node (CAN Frame API palette). All calls are executed properly; there are no error messages. However, corresponding frames do not appear in the bus (confirmed with log at other side and with external monitoring of CAN bus).

Appearence of the problem does not kill the communocation.

There is a strong filling that prpobability of the problem is higher when user switches controls of UI (i.e. when processor load is higher). However, it is only a guess.

I shall appreciate any advice about solution or about error-serching strategy.

Thank you

[Hooovahh]

You are asking a mechanic what is wrong with your car, without showing him your car.

Post the code that you have written which performs the operations.

What hardware are you using?  I assume one of the cheap USB devices but there are other USB CAN devices NI sells which use XNet.  What operating system?  What drivers?  What version of LabVIEW?

You mention user interaction might play a role.  Try moving windows around, scrolling windows, or minimizing and maximizing.  

What are you timing requirements?  How quickly do you need to see a frame, and respond with a new one?  What are the priorities of the messages?  What happens if you don't meet your requirements?

[_Y_]

Thank you for this reply. I sertainly must write more details. But some of your questoins already answered in the first post. I shall probably express this information in another way.

• I cannot post the code. It is a simulator with >1000 VIs.
• HW is NI USB CAN (I have written). The drivers are conventional for NI CAN. By the way, the same problem is observed with NI CAN cards and with IXXAT USB units.
• LV2010 is used with Windows XP. The problem appears with both Development environment and with EXE running in computers with RTM only. Some of these computers run Windos 7. However, all tests and development is done with W-XP computers.
• Yes, I try moving windows around, scrolling windows, or minimizing and maximizing. Any of this actions can conside with the problem.
• If I log what happens at LabVIEW side, all frames are send with good time margine. However, they do not appear in the CAN channel (I watch the channel with another computer). So, other side does not get expected reply. The channelk is not blocked: following requests (if sent) are answered properly.

[Hooovahh]

And as I said in my post:

"I assume one of the cheap USB devices but there are other USB CAN devices NI sells which use XNet."

Stating NI USB CAN can mean the NI USB-9862 which is also an NI USB CAN device.  What you should say is that you are using the NI USB-8473, if that is what you are using.

You say you've seen this issue on the "NI CAN cards" which ones?  Are they Series 2 CAN cards?  Are they XNet using the compatibility layer?  What is the model of the other cards you have used?  Sorry if I keep asking these same sorts of questions but assumptions will be made on how these are or aren't answered.

You didn't mention the timing requirement or priority.  The reason I asked is because lets say you have a timing requirement that after seeing the request frame, you need to reply within 10ms.  And if you don't then another request will go out.  Windows timing is a pain and you can't always guarantee a response in the time you need.  As a result you may not reply in time, and the request will go again.  If the request is a higher priority message than the response, then you will miss that request.  Looking at the CAN bus you will see two requests but only one reply.  Interacting with windows can cause additional jitter which may cause a delayed response.  The writes should look normal because the response did go out, but because of the priority, the message didn't get propagated on the bus until the bus was idle with no higher priority messages.

[_Y_]

Hooovahh,

Thank you for answering. Yes, my computer uses NI USB-8473. However, different workstations could use different CAN2 units (USB or cards). Unfortunately, I cannot get information about model of mentioned above card (that computer is not available for me today).

As I guess, you assume timing problems in my system. If they are, they are not so obvious.

The reply is expected within quite generous time (70-150 ms, dependently on the situation). Other side does not repeat the request unless I trigger it manually (Other side is not an equipment but a computer, however, I have only limited access to its fynctionalities).

The typical porblem looks like this:

LV program receives one frame request and repeats with up to 14 frames. In case of the problem, "Write Net" node (ncWriteNet.vi) is invoked 14 times but less number of frames appears in the CAN Bus (watched with third computer). The missed frames are not last in the sequence. They are missed randomly. The last frame appears in the Bus far before the timeout. The Bus stays silent until manual triggering of next request. 

I tryed to use "Write Net Mult" node (ncWriteNetMult.vi) to transfer all 14 frames at once. It requires more code but pays back - the problem does not appear (at least within short time of my yeaterday tests). However, I afraid, that such a solution only hides the problem.

Thank you again

[Hooovahh]

Well I would suggest you write all 14 frames at once, if you can.  It is likely better for the drivers but you are right it shouldn't be necessary.  Is the CAN port setup to have a single shot transmission?  Normally CAN has a hardware retransmit feature where the message will be resent if no one on the bus reads it.  This can happen if the message got corrupeted along the way.  If single shot mode is used it will be sent once no matter what even if the message is later lost.

Also how is it wired?  Hopefully you just have CAN High and CAN Low tied to the PC on the other end (High to High, and Low to Low).  You will also want a single 120 ohm resisotr between High and Low on each end (so two total).  This is to minimize reflection and isn't always required but according to the CAN specification they should be there.  If they aren't there messages could be lost.

[_Y_]

Yes, 14 frames at once is a better solution. However, IXXAT units do not allow it. But this probably can be solved using NI CAN only.

Unfortunately, I did not find how to check shot mode.

The cable is short and ok. I tried with and without 129ohm terminators and did not find any difference.

I found that different work stations are affected differently by the described UI activity. Probably I can split the problem in two parts: UI interference and random loss of CAN frames. But it could be done only at beginning of next week.

Thank you again

[MariusU]

Hey, 

My name is Marius from NI AE team. I had a read through your issue and I am happy you have done a good amount of troubleshooting. 

Have you tried implementing the same CAN communication outside your application? That might provide insight in this strange behaviour.

In the mean time it would be really helpful if you could provide your code responsible for the CAN communications. 

Thank you!

[dkfire]

You need to have two 120 ohm terminators on the CAN bus. One at each end of the cable. That is the requirement of the CAN bus standard.

Second: how fast do the 14 message have to be send? can you have a delay of 1ms in between?

Next is your UI interference with your program. That sounds like you need to refactor your application if you have that kind of problems. How much CPU are your program using? How much memory?

[_Y_]

MariusU, dkfire, thank you for replies.

I answer to your suggestions first then write about my new observations.

dkfire, there are terminators.

dkfire, interference from UI was my first guess. However, the CAN process runs asynchronously. I controlled all obvious possibilities that can link the CAN process with UI process (refs to FP objects and so on) but did not find any. However, this area is quite grey. I shall highly appreciate description of any link-searching strategy.

dkfire, I already tried to add 1 ms between frames. Unfortunately, this adds around 60ms to the whole pull loop causing new type of errors. Then I actually start to use mentioned earlier "Write Net Mult".

MariusU, I did not try to implement the same CAN communication outside the application. Other side will not communicate unless it has signals with other (non-CAN) channels. Of course, I could implement a simulating process in another computer but my resources for solving this problem are limited.

Instead I tried to use conventional step-wise code decomposition and found that the error is probably computer specific; i.e. there could be two different problems resulting in the same type of reported errors. One is observed only with development computer but not with two other computers.

The following illustrates the strange UI dependency:

I created completely new VI: quite a simple one:

It logs the actual time spent for each loop. The time is 5-6ms, of course. But! Each time when I resize window of conventional Windows Explorer, the time jumps to 240-270ms. The phenomenon takes place both in LabVIEW development environment and with running the VI as EXE. The phenomenon is not observed with three other computers that I tested.

This observation does not solve my problem with CAN but obviously indicates complexity of the problem: there are at least two interfering errors.