10-15-2013 12:34 PM
You have several problems. (not counting crooked and backwards wires.)
1. You are using Configure Serial Port in the while loop. That should only be done once before the while loop starts. It changes properties of the port and that can take some small amount of time that takes away how fast your loop can run.
2. You are doing picture functions in the same loop where you are doing the VISA read. Picture operations can take up some time thus also slowing down your overall loop rate. That is why I asked if things seem to run better if you disable your picture code.
3. The problem is definitely in your device. It seems to indiscriminately send out lots of data. The other software was probably designed to keep up. Your VI with the picture functions and the reconfiguring of the port every iteration probably prevents it from keeping up. It is often better to have code that is more of a "query and read". Your VI sends a "get data" command to the serial port. The other device gets that command and sends the current data back. Your VI will wait on that data and operate on it once it reads it. This prevents the other device from filling up your PC's serial port with data that you aren't read for.
There are other things you can do. You can put the picture functions in another loop and pass it data by way of producer/consumer. Of course if the consumer can't keep up, then the queue will keep getting longer. But do you really need every piece of data that the device sends? You could probably set the queue to be a finite size. Or use a notifier which behaves a lot like a 1 element queue.
10-16-2013 10:35 PM
RavensFan wrote:
You have several problems. (not counting crooked and backwards wires.)
1. You are using Configure Serial Port in the while loop. That should only be done once before the while loop starts. It changes properties of the port and that can take some small amount of time that takes away how fast your loop can run.
2. You are doing picture functions in the same loop where you are doing the VISA read. Picture operations can take up some time thus also slowing down your overall loop rate. That is why I asked if things seem to run better if you disable your picture code.
3. The problem is definitely in your device. It seems to indiscriminately send out lots of data. The other software was probably designed to keep up. Your VI with the picture functions and the reconfiguring of the port every iteration probably prevents it from keeping up. It is often better to have code that is more of a "query and read". Your VI sends a "get data" command to the serial port. The other device gets that command and sends the current data back. Your VI will wait on that data and operate on it once it reads it. This prevents the other device from filling up your PC's serial port with data that you aren't read for.
There are other things you can do. You can put the picture functions in another loop and pass it data by way of producer/consumer. Of course if the consumer can't keep up, then the queue will keep getting longer. But do you really need every piece of data that the device sends? You could probably set the queue to be a finite size. Or use a notifier which behaves a lot like a 1 element queue.
thanks for ur comment!
1. If I disable picture function, it'll work correctly. 🙂 Now, i'm try to pass the data by way of producer/consumer.
2. I need every piece of data that the device sends to simulate 3D quadrotor model, I'm using MPU6050 IMU.
10-17-2013 12:57 PM
@suxu wrote:
2. I need every piece of data that the device sends to simulate 3D quadrotor model, I'm using MPU6050 IMU.
Are you sure? If you are just using the data to update a picture for the user, you don't need to every piece of data. A user can only see about 30-60 updates per second. If you try to force all the updates and the update rate is too slow, you are going to wind up with stale images as the new data comes in faster than the picture can update. I'd argue that you could decimate the data, or only show the latest data as fast as LabVIEW can actually display it.
Now if you are trying to log all the data to a file, for later analysis, then I can see why you would need every piece of data. In that situation, you should send the data to another file saving loop. Try to optimize that loop so it can save data efficiently. Often that is storing up data and saving it out in larger chunks rather than saving lots of small pieces of data. If you do it in a separate loop, the slowness of the picture updata functions shouldn't affect the loop rate of the file saving looop.
10-17-2013 08:37 PM
thanks for your advice! ^^
04-03-2014 09:27 AM
Hi EVERYBODY
I'am student, and im working on project thats im using LABWINDOWD/CVI (2010) and Pic 18f4550 (USB connection).
I wrote my program on LABWINDOWS, and i program my piv in MICRO PRO C (version 5.60)
the program of the pic is to read what i write (i mean i write text and i must receive the same text).
i installed Visa, and i arrived to make the connection between ISIS and the LABWINDOWS (i mean i test everything vitually)
but when i write the text, the pic receivit without problems, and the pic doesn't send me the text, and i the LAbwindows show me that i have problem in this function (viread).
Actually i dont know the problem, and i need ur help because i need to start working practiclly on the project soon, and i nees to make sure that virtually i dont have no problem.
thank
04-03-2014 09:30 AM
04-04-2014 11:15 AM
You will get better support by posting to the LabWindows/CVI board or the Instrument Control (GPIB, Serial, VISA, IVI. This forum is for LabVIEW users, so it's not likely that LabWindows/CVI users will see this post. Hopefully the link that Dennis posted above can provide some insight to your problem.