10-29-2009 12:31 PM
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
10-30-2009 04:05 PM
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?
10-30-2009 04:08 PM
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.
10-30-2009 05:01 PM
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...
10-30-2009 05:02 PM
10-30-2009 05:19 PM
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)...
11-02-2009 10:19 AM
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.
11-09-2009 12:55 PM
"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...
10-06-2013 09:28 PM
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
10-08-2013
08:27 AM
- last edited on
12-16-2024
05:17 PM
by
Content Cleaner
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!