Automotive and Embedded Networks

cancel
Showing results for 
Search instead for 
Did you mean: 

labview misses a read when using Ni USB 8473 can interface

I was wondering if anybody here has had experience with this problem... I already talked to a Labview tech but i have not received an answer yet...

 

This is my problem..

 

I have a program that  when a button is pressed, it initializes a can interface to CAN0 for example, then it writes... then it waits about 100mills and then it reads... My computer is connected to a simulator through the USB 8473 interface (I have the problem when I connect it to the hardware I am going to use), and everytime I write, this simulator sends a response... The problem is that sometimes I don't see a response... I have made sure that the simulator responds so I know it is responding... I have changed the waiting time before the read from 1 mills to 100 mills to 1 second, and still with the same result... 

 

The way I have fixed this problem is by reading multiple times (3 times)... so every time I send a request, i wait 100 mills... then I read once, wait 25 mills, then read again, wait, then read again....

 

So, I wanted to know if anybody here has had to do this in order to get around this problem...???

 

 

The reason why I was asking this is because I also have another application that has to monitor my hardware by sending requests every 100 milliseconds... so I have two loops, once that writes requests every 100 mills... and another that reads the responses every 20 mills... but sometimes it looks like eventhough i read this many times, I still miss some frames, which are caught later but still not good enough...

 

I have posted a different thread about the above problem...

 

If you have questions just ask please...

 

Thanks

 

 

 

 

0 Kudos
Message 1 of 14
(9,623 Views)

Hi,

What do you mean a LabVIEW tech? Is this someone at National Instruments? Did they have any advice? It is hard to say what could be wrong without taking a peak at your code, can you post that? Also, how are you sure that you device is sending a response? Can you run bus monitor on another port, ie another USB-CAN device?

Matt
Applications Engineer
National Instruments
0 Kudos
Message 2 of 14
(9,607 Views)

Hey carspidey,

 

You could use ncWaitForState.vi (in the Frame API->Advanced palette) waiting fot this state:

 

00000001 hex Read Available

At least one frame is available, which you can obtain using an appropriate read VI.

The state is set whenever a frame arrives for the object. The state is cleared when the read queue is empty.

 

The VI should return only when there is a read available.  So you would do your write, then WaitForState, then read. I think this will probably be the most efficient way to design your application.

 

Let me know if it works.

 

O. Proulx
National Instruments
www.ni.com/support
0 Kudos
Message 3 of 14
(9,606 Views)

Yes, by Labview tech i meant NI Support... sorry about that...

I am still waiting for them on this subject...

 

I'll attach a simplified version of my code (the only difference between this code and the original is that i parse all the data that i get...)

 

I am attaching these if a couple replys... 

 

Run the receive and respond (simulator) then run the CAN_PROBLEM vi... click on the OK button to write then read... you can tell it missed the message when the Frames to Read field is 0...

 

 how are you sure that you device is sending a response?

 

Very sure... 100%... the original simulator lets me know when it sends the response...

 

Can you run bus monitor on another port, ie another USB-CAN device?

 

I did that, and the other USB-CAN gets it... the program I am running on the other computer is called CANyliser... I think that program waits until there is something in the queue (which I am not doing with mine)... I am just reading after I have wrote teh message (reading after about 100 mills I wrote)... So I am assuming that's plenty of time... i have increased this waiting time to 1 sec and still get the same behaviour...

 

 

Download All
0 Kudos
Message 4 of 14
(9,604 Views)
These two vi's are just encapsulations of the Read and Write vi's... Sorry about that...
Download All
0 Kudos
Message 5 of 14
(9,603 Views)

You could use ncWaitForState.vi

 

I might be able to use this VI... but, I have two different applications... one where by pressing buttons, i can send different writes (requests for data frames)... So if I press button 1, i send request with arb ID 1, and then expect one CAN frame... but there are other buttons that will expect three CAN frames... so this wait state will only read the first frame.... and to read the other two, i'd have to loop it right? I mean, I can definitely try this... way better than what I have right now... But I still would like to know why sometimes when i read after waiting some time (tried 1ms, 100ms, 1s all with same behaviour) I just don't see anything in the queue....

 

Another reason why teh ncWaitForState.vi would be a bit difficult to use is because on my second application, i have to send 4 requests embedded in the data part of one frame... these 4 requests (writes) returns 6 frames... if I use the ncWaitForState.vi worst case, i'll be reading 6 times right... rather than once or twice if the READ worked everytime... you know what I mean... the second application actually has two while loops right now... one writes every 100 mills... and the other while loop reads every 20 milliseconds... and even this setup fails to read all frames before it writes again (I created another thread for this)...

0 Kudos
Message 6 of 14
(9,602 Views)

Hello carspidey,

 

You could still use the ncWaitForState.vi but with this state:

 

00000008 hex Read Multiple

A specified number of frames are available, which you can obtain using either ncReadNetMult or ncReadObjMult. The number of frames is configured using the ReadMult Size for Notification attribute of ncSetAttr.

The state is set whenever the specified number of frames are stored in the read queue of the object. The state is cleared when you call the read VI, and less than the specified number of frames exist in the read queue.

This state applies only to Series 1 and Series 2 interfaces.

 

This method is the most efficient because it uses less processing.  You could also use a polling method similar to what you are doing right now.  What you do is "Read Entries pending".  When there are more than 0 frames in the queue, you do your read.  You can keep doing the Read Entries pending until there are X number of frames available.  

 

Finally, my last recommendation is to put your initialization code and closing code outside your while loop.  You do not need to initialize and close the interface repeatidly.

 

I hope that helps.

 

O. Proulx
National Instruments
www.ni.com/support
0 Kudos
Message 7 of 14
(9,579 Views)

"You could still use the ncWaitForState.vi but with this state:

 

00000008 hex Read Multiple"

 

I was thinking of using that but then I don't want to set the number of frames to wait for... I am trying to make this application a bit generic (some of its parts will be used for other programs as well)...

 

 "You could also use a polling method similar to what you are doing right now.  What you do is "Read Entries pending""

 

This is what I do... I only read if read entries pending returns a number greater than 0...

 

"Finally, my last recommendation is to put your initialization code and closing code outside your while loop.  You do not need to initialize and close the interface repeatidly."

 

My application has two tabs... one where I do exactly what you just said here... and the other where it is a bit different and therefore I found it a bit easier to initialize write read close everytime the user presses a button... I really appreciate your suggestion here...

 

I guess back to my main question... why is it that sometimes when I check for the number of frames in the queue, it is 0, even though there should have been something in there...

 

Like I said, I initialize, write, wait, then read and there is nothing to read, then close... And this only happens sometimes... I have varied the wait time from 1mills to 100mills to 1 second and the behaviour is the same...

 

My solution to this problem is to check for the queue size to be greater than 0 three times every 25 mills... when it is greater than 0, then i read and process...

 

I'd like to know if there is a bug with labview i guess... At this point is more like I want to know, because like I said I already found a solution to my problem...

0 Kudos
Message 8 of 14
(9,537 Views)

Hi, I have a problem in reading multiple frames of data from my device as well

 

I always able to read only the first frame of the data and the subsequent frames are lost.

I would like to know is this due to the confirguration problem or anything that i miss out?

 

Thanks for help

 

 

0 Kudos
Message 9 of 14
(8,283 Views)

Hi Xilun,

 

You will have a better chance of getting good answers if you start a new thread for your question. This thread is 4 years old.

 

Feel free to link back to this thread here when you have posted a new thread.

 

In brief response to your question, I would recommend checking out the example VIs installed with the NI-XNET driver, such as "CAN Frame Input Queued.vi" or "CAN Frame Input Stream.vi"

 

Good luck!

 

Joey S.
Senior Product Manager, Software
National Instruments
0 Kudos
Message 10 of 14
(8,264 Views)