LabVIEW serial update rate

[RavensFan]

---

@JvdM wrote:

If I don't put the delay in of 2ms then I get data update at the rate of 1 second.

The dsPIC sends every 2ms the following string minimal #X,Y*\r and max #XXXX,YYYY*\r where X is RPM ranging from 0 to 6000, and y is the setpoint range from 0 to 6000.

Labview should also send every 2 ms always 21 bytes of data (Kp, Ki, Kd, Setpoint) this one is fixed to 21 bytes.

If I disable termination character and set the read function to 20 bytes I get unreliable data, the received string is flickering.

Which isn't the case with 2ms delay and termination character.

---

If it is always 21 bytes, then you should disable the termination character and read 21 bytes.  Not 20 because the 21 first byte is going to remain in the serial port until the next time you read.  Then you'll wind up with 22 bytes, read 20, and the bytes of interest no longer where you expect them to be, the parsing will fail.

Other option.  If you get two packets of data in every 2 msec.  Do 2 VISA reads with the termination character enabled.  The first VISA read will get the #X,Y*\r  The second VISA read will get #XXXX,YYYY*\r.

The only issue with this method is depending on when you start the read, your very first VISA read may start in the middle of a packet of data.  And also your second VISA read will get a full packet, but it may actually be data that is part of the first half of your data string.

[JvdM]

No labview sends data back to the dsPIC that is always 21 bytes.

The data coming from the dspic ranges from 6 bytes to 12 bytes (depending on the rpm and setpoint).

[RavensFan]

I'm sorry, I misread that part.

Try the method I said, two consecutive VISA reads, termination character enabled, of at least 12 bytes in each read.  The only thing you might have to do is upon the very first time after opening the serial port, do one or two VISA reads so that you can be sure of the alignment of your data coming in as to which is the first packet of data and which is the second.

[JvdM]

It is only one packet every 2 ms with varying length so it could be:

#600,599* or #4500,455* which has this format"#RPM,Setpoint*".

So two visa reads has no use. Sorry for my bad explanation

[RavensFan]

Get rid of everything.  Get rid of the VISA write if you can.  Get rid of all parsing.  Get rid of your timed while loop.

Just read bytes at port in a loop, append the data to a string and display it on a string indicator.  Put a 0 msec wait in a regular while loop.  Does it work?

What kind of serial port are you using?  Is it a real serial port in the PC, or is it USB or ethernet based?  As I said, your baud rate is ridiculously fast compared to any normal serial port device.  Can you change the baud rate to something lower on the device?  If you are getting 12 bytes in 2 msec, a baud rate in the neighborhood of 128,000 should be fast enough to get your bytes across in time.

Have you tried setting up in Hyperterminal to see if that can acquire the bytes fast enough without problems?

How long is your serial cable?  At that baud rate, you need your serial cable to be pretty short to prevent problems.

[JvdM]

Just only read while loop without delay doesn't work only with a delay 2ms. Then it works (see dsPIC BLDC Logger - kopie).

I'm using USB to RS-232 the serial cable is very short the USB is 1.8m.

It its not the hardware I think. It is just windows in combination with labview.

But for now dsPIC BLDC Logger.vi sheems to work properly no weird data or what so ever.

[johnsold]

I agree with Ravens Fan.  Try what he is suggesting to help isolate the problem.  If your device requires that you send data, send a constant so the other loop is not required.  

You mentioned that the data being sent to the remote device represents (Kp, Ki, Kd, Setpoint).  Do you really need to be able to modify Kp, Ki,  Kd, or the Setpoint 500 times per second? You must have some operators with really quick fingers! I would only transmit any of that information when it changes, using an event structure to detect the changes.

Lynn

[johnsold]

Try this.  By moving the indicators outside the loop, you cannot see what is happening while it is running, but you also have no delays while LV and the OS tries to update the display 500 times per second.  The Bytes at Port property node is only reporting what is left in the buffer immediately after the read.  Depending on how fast the OS checks the buffer you may see a few characters in this array but the number should remain smaller than the number of characters in a message.

Lynn

[RavensFan]

---

@JvdM wrote:

Just only read while loop without delay doesn't work only with a delay 2ms. Then it works (see dsPIC BLDC Logger - kopie).

How does it not work?  You are reading data as fast as the while loop will allow but still allowing the processor time to handle background tasks like read the mouse and update the screen.  You didn't do the concatenate to string part I was talking about, so you are probably only going to see individual characters fly by on screen.

I'm using USB to RS-232 the serial cable is very short the USB is 1.8m.

It its not the hardware I think. It is just windows in combination with labview.

I wouldn't just claim its not the hardware.  USB/RS-232 adapters can have problems with their drivers getting the data from the RS-232 across the USB bus to the PC.  Some USB/RS-232 adapters work better than others.  Problems that hard serial ports in the PC on a PCI bus tend to not have.

Have you tried things in Hyperterminal?

But for now dsPIC BLDC Logger.vi sheems to work properly no weird data or what so ever.

So it is now working? 

---

[Henrik_Volkers]

Here is an untested producer consumer loop to read the serial.

To write values I would use an other loop to generate the setpoints and pipe(queue) them to the producer loop ...