Labview serial update rate

[JvdM]

Hello,

Currently I'm developing a BLDC controller with a microchip dsPIC, at this point I'm designing and tuning my control loop.

For that I need some data monitoring, I want to Labview for this in combination with RS-232.

So the question is how fast can labview receive data, current I used the basic serial example and changed it to I timed loop.

With this I can receive data at 500Hz, but the DSP can put the data out at a higher rate but labview doesn't.

I used termination characters.

So my question is it possible to receive data at 1 or 2kHz ? max baudrate is 921600 (windows limited)

And if possible what can I do to make it work

[mikeporter]

What you need to know is the number of bytes per second that you can transfer, To get that divide the bit rate (the 921600) by 10. The thing to remember is that with ascync communications there is a 2-bit overhead (minimum) per byte.

This division will give you the maximum transfer rate under ideal conditions - but conditions are never ideal. You have to send commands, get responses and maintain everything else that windows has to do. And then there's the question of whether the serial ports on both ends of the connection can run that fast.

Having said all that, Is it possible to send and receive 2000 bytes per second? Without breaking a sweat...

Mike...

[JvdM]

so 921600 baud that means every character takes roughly 1.1us (1/921600), I want to sent and receive a total of max 50 bytes between labview and the dsPIC.

This takes 1.1us * 50 = 55us that is 5.5% of the time in a 1kHz update rate (which is the minimum rate of a timed loop in labview).

Would it be possible to sync the timed loop with the serial ?

[JvdM]

For I test I only send bytes from the pic to the PC with a 10Hz rate, what is the best way to trigger labview to start the loop by reading the data ?

Tried serial events but is doesn't work properly

[mikeporter]

You're off by a factor of 10. Baud refers (somewhat inexactly) to bits per second - to get characters per second, you have to typically divide by 10. That gives you 92160 characters per second, or a new character about every 10.85 usec, so 50 bytes will take 0.542 msec.

I shouldn't worry too much about the minimum rate of a timed loop as you don't want to use one for this type of application if you care anything about timing accuracy. Remember timed loop ot not, it is still running under a non-deterministic OS.

Mike...

[JvdM]

Hmm I always thought dat baud was characters per second en bps - bit per second.

But what I'm trying to do is receive data coming from a PIC at 1Mbits at a rate of 1kHz. For a test it always sends 6 bytes "#0,0*\r".

So what is basicaly has to do is wait for the * (or \r termination activated) and then read the data to a string (which can be further analyzed).

And then wait again for new data.

When I put this in a while loop without delay it some times reads zero bytes at port. And when I put a delay it sometimes reads more then 6 bytes.

In the end it has to read the data from the PIC and then send data at 500Hz to 1000Hz rate.

Is this possible, or i'm asking to much from labview/windows which I can't imagine.

[LV_Pro]

Ok, we were typing at the same time.

Also, are you sending just one character each way at a time? Do you have to process the data, like the remote sends a character, the LabVIEW program reads it and sends an appropriate response?  As Mike said, a timed loop gives you better timing accuracy than a simple loop with a Tick Count function or whatever, but running under Windows, MacOS or whatever it can have big variations if the OS decides to service another thread, say the operator wiggles the mouse rapidly. To do accurate timing requires either doing it in hardware, or a variation of that, or running under a RealTime Operating system, with hardware being the more accurate between those two.  

How are you determining how many characters to read? Are you using the bytes at port function, and reading only 6 at a time? That allows you to "sync" your reads to the source, and if you put it into a producer-consumer pattern (shown in the LabVIEW examples) you can even be analyzing the returned data while receiving it.

[JvdM]

What I want to test is the frequecy response (bode diagram) of my BLDC controller including PI and motor.

What I had in mind is that every control loop cycle (500Hz or 1kHz) the dsPIC sends its current RPM value and the setpoint used at that moment.

Send this back to the PC (Intel i7 2600k 8 threads) with labview, then labview immediately sends a new setpoint (coming from a frequecy sweep generator) to the dsPIC.

And then read out the string and convert it to to numbers (RPM and setpoint) and plot those in a chart/array for further analysis (which will be done offline).

So basically Setpoint generator and data logger in three steps, -->Read data-->Send data--> log data and generator new setpoint at a rate of 500Hz or 1kHz.

I know windows isn't determistic, as long as it doesn't misses data. I have tried timed looped which is much better.

But I thought maybe used the data as "time reference" because is sends data at a steady rate

[Dennis_Knutson]

I would simply have a normal while loop with the VISA Bytes at Serial Port. When the number of bytes is greater than 0, do your read (i.e. place this inside a case statement). You can specify some large number of bytes to read since you have a termination character. You do have to set the correct termination character with the VISA Configure Serial Port. The default is a LF - not the CR you are using.

[JvdM]

 I'm using the bytes at port function. the number of bytes varys at the moment  but not more then 16 bytes is coming from the dsPIC.

The last character is always "*\r"