LabVIEW
Buffer reading, buffer de lecture
Hi Simon,
@aerosimon wrote:
I'm sorry, I didn't see the need to do this as I had copied your program.
But by showing just an image of the frontpanel we cannot be sure about this point…
@aerosimon wrote:
the commands are in the right order, the answer strings are the expected ones, just not in the right order.
What are you doing before you call this TARE routine?
Do you send any other commands before? Does the device send current values without the need for new requests?
Are the received responses just off by one index in the array?
Simple solutions:
- Read from your device in a separate loop until you get a timeout: now the receiving buffer is empty before you go into the TARE loop. Now the device should respond with the expected answers in the correct manner…
- Turn off "automatic" transmitting of readings from your device before calling the TARE loop.
- Send the TARESETUP=UP command and read the responses until you receive the "UP" response. Then execute the other TARE commands in the loop…
There are so many ways to handle such simple problem…
@aerosimon wrote:
The values in the array are never in the same order, sometimes they arrive in the right order but most of the time this is not the case, there is no sequence, it is totally random
Do you say that measurement device doesn't behave in a predictable manner?
Does the manual of that device describe a predictable behaviour? In case it does: return the device to the manufacturer and claim for a full refund!
Which kind of device does reply to requests "never in the same order" "totally random"???
@aerosimon wrote:
TARESET is waiting for X Pa.
The values in the array are never in the same order, sometimes they arrive in the right order but most of the time this is not the case, there is no sequence, it is totally random
Reset the device, so you are sure it doesn't have answers queued up in it's buffer.
It is unlikely that the first command gets any other answer then an answer to the first command.
If the first command returns an answer to the 2nd command (that hasn't been send yet), apparently the device can look into the future...
A pile of answers queued up would explain that.
Search LabVIEW like a graph! 
Hi Simon,
@aerosimon wrote:
The values are given only when I start the program and the answers are received in a totally random way, without order, nor recurrence of position.
Put that device into the trash. Get a device which acts in a predicatable way!
Or follow all the suggestions you got here in this/your thread: send a request, the read the answer(s) - until you receive the expected answer…
Btw. do you even think about telling us the type of your device and linking to a (programming) manual for that device?
All we get from you is hearsay, without any real proof…
@GerdW wrote:
Hi Soul,
@AeroSoul wrote:
To me it sounds like the device is of his own making and he's trying to read from it and gets "random" answers.
In this case he should fix the firmware of that device instead of trying to create a way how LabVIEW is able to handle that "random behaviour" device…
On the other hand, if the device gives answers to questions that will be asked in the future, I'd be interested.
Not too useful as a device, but devices that demonstrate time travel are worth studying.
@aerosimon wrote:
the answers are only sent to random buffers, but the answers themselves are the expected ones. They are simply mixed with each other.
Thank you for your time.
If you only send 1 (the first) question, and wait for an answer, how is it possible that the device sends an answer to the 2nd question that hasn't been asked?
What random buffers do you think there are? The device has a FIFO buffer, the PC has a FIFO buffer. Everything should be first in, first out.
