labview arduino uno bad transfer of data

[brevan]

Hello,

i have some problems with transfer of data from the arduino uno to labview.

I have made a VI where i can control the power of a heating device with temperature measurements with arduino uno.

The problem is that once in a while the wrong temperature is captured in labview by missing the digit or a number eg. labview gets 2000°C in stead of 20.00°C or 1.25 °C in stead of 15.25°C.

When i watch the serial plotter from the arduino program these mistakes do not occur. So I assume it will be a problem with labview settings or my VI.

In attachments a set of data extracted from the VI and the VI itself and the arduino script

[RavensFan]

You are missing the subVI's.  Especially the one called SerialArduinoSubVI which is probably where the problem occurs.  Without seeing what is going on in there, I can only take one wild guess.  That is that you are opening and closing your serial port within that subVI and you are possibly losing data.

[brevan]

Yes i forgot to amend that VI,

But when i incorporate the subvi it also gives these problems

[RavensFan · Accepted solution]

Yes.  That subVI has 2 major problems.

The first is like I said.  You configure and close the serial port every iteration.  There is a risk that the device could be sending data that you'll miss at the moment the serial port is closed.  (Though it doesn't really explain why you'd miss the decimal point out of the middle of the bytes of data.  Serial ports should be configured and opened when the program starts.  Written to and read from within the loop.  And closed only after the program ends.

The second major problem.  Why do you have the property Data Bits wired up to the number of bytes to read.  Bytes and bits are two different entities.  And in this case, Data bits is the number of data bits defined by the serial port configuration.  Probably 8 and would always be 8 and has nothing to do with the number of bytes actually at the serial port.  Number of bytes to read is how many bytes you actually want to read from the serial port, could be 1, 50, 1000, ....

Does your device send data continuously without prompting?  Does it use a termination character?  If it isn't, using a termination character like a carriage return or line feed, then it should.  It will help you break up the ASCII data coming through into packets.  Your serial port configure is set up to look for termination characters and that it would be a line feed character. Use the termination character, and said your VISA read to some arbitrarily large number.  A number that is larger than the longest message you expect to receive.  The VISA read will return as soon as it sees the termination character and give you a complete packet of data. 

It is often a good idea to have a query/response communication protocol with your device.  You write a command to it that says "give me the value".  It reads it and responds back and gives the value.  Otherwise if it just sends data continuously without prompting and you don't read it fast enough, you could overflow your serial port (which would give an error and there you could lose data), and even before that, you could be reading stale data that is at the front of your serial buffer while you device has already sent hundreds more data points after that.

[brevan]

Will these adjustions also speed u the iteration time? Because now the iteration is taking 3 seconds, but for a proper control i want to speed it up to be more responsive. Or do i need to make other adjustments?

[RavensFan]

I have no idea.  First you need to getting it working correctly.  Then you can worry about how to make it run faster.

Right now I can't see how you could get more than 2 readings per second.  You have a 500 millisecond "metronome" wait in your main while loop.  So it really can't run faster than twice per second, and could possibly take longer depending on how long other parts of your code take to run such as your Com PS communication.

After that, the rate of data is probably more dependent on what is happening on the Arduino.  You can't read data any faster than you device sends it.  So you need to make sure that is able to generate and send data as fast as you want it to.

[brevan]

Dear,

It worked very well and it did fasten the iterative process very much.

The VI in attachment has the adjustments i made

[RavensFan]

I'm happy to hear it is working better.

I would still get rid of Bytes at Port.  As I said, just wire a constant in there that is larger than the longest message you expect to receive.

The problem with BaP is that if the message has only partially arrived by the time that property node checks the amount of data in the buffer, you are going to read a short buffer and get an incomplete message.  Then the next time the loop runs, you'll get the rest of the message which will also be incomplete.  Meanwhile if the "1" is your message to request new data, you will have request new data twice, and read incomplete data the two times.  The second packet of new data will be sitting in the buffer unread (until the next request and read).  The more incomplete messages you have because of th bytes at port not working, the fuller your buffer gets and the staler the data gets.