Labview serial update rate

[JvdM]

I don't get any error, very often a overflow but then retart the VI and everything is oke.

The PIC sends every 2ms 12 bytes of data and no 952 bytes, so it is indeed accumulated data.

But still don't what is causing the zero's.

Would it help or is it possible to give the timed loop a dedicated CPU core for faster proccesing under windows ?

[RavensFan]

Have you actually put an error indicator on that wire to prove you don't get an error?  Right now you could be getting an error and not seeing it because the error wire is handled all the way to the tunnel of the loop.

I don't if you should actually be using a timed loop in regular Windows.  Try changing it to a regular while loop.  The benefits of timed loops are more for real-time operating systems.

You may want to try disabling the termination character.  Then read all of the bytes at port.  Parse all that you get looking for the carriage return in that given loop iteration, and store any excess bytes in a shift register to be concatenated with the new data that comes in on the next loop iteration.

Does data only come in whenever you've sent something to the device like a query/response format?  Or is the data coming in continuously even if you don't send something out of the serial port?

[JvdM]

I have now put an indicator, is shows no errors.

The PIC is sending continously data at 500Hz so NO send/response format.

[Henrik_Volkers]

 Use a producer/ consumer loop

  The producer only read the serial and queue the data to the consumer loop

  In the producer (read serial) loop avoid any contact to the frontpanel (indicators/controls), so it can run outside the GUI thread .. if you want to check VISA errors (or warnings use an extra queue)

  Pipe the raw string and decode it in the consumer loop.

[JvdM]

Now created two loops one a normal time loop with serial read and write without any delay.

And a timed loop for the display.

The data is only update every second. with a 2ms delay is updated very fast but bytes at port reaches 3000.

[johnsold]

Please post your latest version so we can see what is going on.

In general when the bytes at port continually increases it is an idincation that you are not reading the data fast enough.

Lynn

[JvdM]

See attachment for VI

Without delay in serial loop it doesn't work properly

[RavensFan]

What does "it doesn't work properly" actually mean?  You can't make statements like that without giving details.  There are thousands of ways something might not work properly, but we can't read your mind to know what that is.

Generally, loops need some kind of delay or something to throttle their speed so they won't become a greedy loop.  Even a wait statment with a 0 wired into it can help with that.

Have you tried my suggestion of disabling the termination character?

If in a 2 msec span, you get a 100 bytes at the port and bytes 50 and 100 are the termination character, you proceed to do a VISA read of a 100, you'll only get up to byte 50 because the termination character ends the read.  You will have 50 bytes remaining in the serial port.  Next iteration, you get another 100 bytes, you'll now have 150 in the port,  bytes 50 (originally 100), 100, and 150 will all be termination characters.  You try to read 150, but you'll only get 50 bytes because it stops at the termination character.  Now 100 bytes will remain in the port.  This will continue.

Unless you read from the port faster then packets of data (as defined by their termination character) come in, you'll fill up the port whenever you've configured the reads to stop at the termination character.

I still don't think you've clearly defined what your data looks like and how fast the data is arrive at the port.  You say you have a baud rate of 921,600.  (Please note that is ridiculously fast and well above what any normal serial port application is.)  Assuming a roughly 10 bit per byte ratio, and the bytes are arriving continuously without any pause between bytes, you could be getting 92,160 bytes per second.  That is 184 bytes in any 2 msec time slice.  If you are getting more than 1 termination character in those 184 bytes, then you are certainly going to run in the situation I described above.

Define your actual data rate.  Define the actual structure of your data.  Then we might be able to assist to say whether bytes at port way of reading is appropriate or not, and whether you should be using a termination character or not.

[JvdM]

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.

[RavensFan]

What does "it doesn't work properly" actually mean?  You can't make statements like that without giving details.  There are thousands of ways something might not work properly, but we can't read your mind to know which way it isn't working.

Generally, loops need some kind of delay or something to throttle their speed so they won't become a greedy loop.  Even a wait statment with a 0 wired into it can help with that.

Have you tried my suggestion of disabling the termination character?

If in a 2 msec span, you get a 100 bytes at the port and bytes 50 and 100 are the termination character, you proceed to do a VISA read of a 100, you'll only get up to byte 50 because the termination character ends the read.  You will have 50 bytes remaining in the serial port.  Next iteration, you get another 100 bytes, you'll now have 150 in the port,  bytes 50 (originally 100), 100, and 150 will all be termination characters.  You try to read 150, but you'll only get 50 bytes because it stops at the termination character.  Now 100 bytes will remain in the port.  This will continue.

Unless you read from the port faster then packets of data (as defined by their termination character) come in, you'll fill up the port whenever you've configured the reads to stop at the termination character.

I still don't think you've clearly defined what your data looks like and how fast the data is arriving at the port.  You say you have a baud rate of 921,600.  (Please note that is ridiculously fast and well above what any normal serial port application is.)  Assuming a roughly 10 bit per byte ratio, and the bytes are arriving continuously without any pause between bytes, you could be getting 92,160 bytes per second.  That is 184 bytes in any 2 msec time slice.  If you are getting more than 1 termination character in those 184 bytes, then you are certainly going to run in the situation I described above.

Define your actual data rate.  Define the actual structure of your data.  Then we might be able to assist to say whether bytes at port way of reading is appropriate or not, and whether you should be using a termination character or not.

EDIT:  I see you've answer some of my questions while I was typing the post.  Remember the other part of what I said is that when it comes time to parse the data when using the bytes at port method with the termination character disabled, you will have to search for the termination character and store the remaining part of the string in the shift register.  Keep doing that until you don't detect the termination character.  Still hold on to the excess bytes in a shift register and hold on to them to concatenate to the beginning of the next set of data you read.