NI-CAN Error -1074388990

[JavelinHS]

hmm feels strange that I cant edit my posts but anyway...

I wrote a test-application to figure more out, where the error occur and *surprise* I've got a new error (shown in the attachment).
The test-application does nothing than read every 2 milliseconds all CAN-messages (ncReadNetMult.vi) in one loop and
write a couple (from 6 message till 11) CAN-messages (ncWriteNetMult.vi) every 2 milliseconds.

I hoped I could crash the driver again to figure out why, when and where it actually happen but as I write before, a totally different error appear.

If anyone got an idea, even it sounds stupid, please tell me.
I'm runnin out of Ideas.

[Paul_F-MCP]

From your snapshots you are writing 9 messages every 2mS presumably with the default write queue length of 10? I would not expect the message transmission to take even 1mS, but it is possible that if the processor is overloaded that the loop iteration time may vary. In that event you could get a write queue overflow if the timed loop processes missed periods and tries to catch up. Have you tried a longer write queue length?

I couldn't work out what the TL2 plot showed - if this is iteration time then it's a lot less that the loop time. Id this showing the actual processing time to send the CAN messages?

The only other suggestion I can make is to collect an array of the start and end times of the timed loop to check that there's not somethign odd happening there. Is there other code within the timed loop that could take in excess of the 2mS to execute and then maybe cause two calls in quick succession?

Sorry I can't be of more help.

Paul

[JavelinHS]

---

@Paul_F-MCP wrote:

From your snapshots you are writing 9 messages every 2mS presumably with the default write queue length of 10? I would not expect the message transmission to take even 1mS, but it is possible that if the processor is overloaded that the loop iteration time may vary. In that event you could get a write queue overflow if the timed loop processes missed periods and tries to catch up. Have you tried a longer write queue length?

I couldn't work out what the TL2 plot showed - if this is iteration time then it's a lot less that the loop time. Id this showing the actual processing time to send the CAN messages?

The only other suggestion I can make is to collect an array of the start and end times of the timed loop to check that there's not somethign odd happening there. Is there other code within the timed loop that could take in excess of the 2mS to execute and then maybe cause two calls in quick succession?

Sorry I can't be of more help.

Paul

---

I tried a couple settings with even the write and the read queue but nothing seems to help or change anything. The NI-RT monitor shows me the CPU load and none of the 8 CPU got a total load from over 40% so I don't think its a CPU problem.

Ya you are right it shows the iteration duration from the loop we are talking about. I thought that the timed loop works in the way, you give the loop the order "don't spend more than 2ms per iteration" and iteration duration shows you how long he really needed for one iteration. but maybe I'm wrong.

I found something interesting in the NI-CAN Software/Hardware manual page 10-138

"Use ncWriteNetMult.vi to place one or more frames into the Network Interface write queue.
This function does not wait for the frames to be transmitted on the network."

couldn't this be the reason for my queue overrun in the 2ms loop?

Thanks for the suggestion, i gonna try this.

thank you for wasting your time with my problem

regards Patrik

[JavelinHS]

I did some measurement today and I gathered some new (for me very confusing but anyway) information about my problem.
I run my program with an Micro Autobox (dSPACE) to make sure that the problem isn't anywhere else.

My first settings were, I run my main-CAN-writing-loop every 2 ms and i got an buffer overflow. OK seems legit in the way that my CAN-Cards are to slow for 2 ms.
Second test settings, I run the main-CAN-writing-loop every 4 ms and I could see that my program cant write faster than 3ms and it got some delays till up 8ms (pic 4).
Third test settings, I run the main-CAN-writing-loop every 6 ms and my Program needed between 5 and 7 ms to send the CAN-message (pic 6).
Fourth test settings, I run the main-CAN-writing-loop every 8 ms and my Program needed between 6 and 10 ms to send the CAN-message (pic 8).

In every test-case I've got the Error -1074388990 (internal Error NI-CAN driver). So even I runs my Program in a 8ms loop (what is quite slow) the driver Crashes. I had still a few thoughts why but I didn't want to manipulate your thoughts so if you got any good idea please let me know.

regards Patrik

[Paul_F-MCP]

Hi Patrik,

I presume for these tests you were running your application in LabVIEW RT on an RT target and measuring the actual CAN message timing with the Autobox?

If that's the case thene there's certainly something very odd going on because it woudl appear your timed loop is running slow. Have you tried coverting the loop to a normal while loop and measuring the iteration time to make sure nothings slowing it down? Assuming that this shows a problem in the code you can then split it up into sections and test out where the issue is occurring.

I've not used LabVIEW RT so things may be a little different, but by default I think the loop is set up to "Discard missed periods, maintain original phase"

If this is the same on RT then I would expect you to see blocks of timing at multiples of the loop time, which doesn't quite look right on your plots - the 4mS one does show lots of 8 and 4mS but also some other timing which I doubt is down to transceiver delays. The 6mS plot looks more sensible, but the 8mS one also looks a bit odd to me. This does tend to suggest that the problem might be a delay in the code contained in the timed loop though.

What hardware are you running LabVIEW RT on? I'm not an expert on CAN, but I can have a look at the specs and see if I can spot anything that might help.

As a matter of interest I assume you're running Matlab/Simuling and dSPACE RTW on the Autobox.

Paul

[JavelinHS]

Hi everyone,

sorry again for the late response but we did a couple test and I wanted to wait till we got some results.

So first of all, it seems to be impossible for my CAN-cards to send every 2ms CAN-messages (I gonna do some more test, maybe I can optimize my Program). The really strange things happen in the 4ms loop (driver crash) but I might figured out why. It seems that the distributed (one in the fast 4ms loop another in the slower 100ms loop) access to the CAN-Hardware causes the Problems. I Put them both in one loop and my Program is more stable than before.

But as I said I'll do more test 🙂

regards Patrik

[Paul_F-MCP]

Good luck.

Paul

[JavelinHS]

Hi everyone,

after a couple more test, it seems that I could avoid the Problem.
First I moved all CAN transmitting and receiving stuff in one loop.
Second to avoid that read and write might block each other,

I created a 1ms loop and every even step he writes and every odd step he reads.

To be sure that read and write get one full millisecond.

My Problems seems to be solved but I'll do more research.

regards Patrik