Buffer reading, buffer de lecture

[aerosimon]

I did not configure a serial port, I simply assigned 2500 to READ I attach the picture. I don't know how to configure serial ports.

[aerosimon]

With what can I program read/write every 100ms?

[GerdW]

Hi Simon,

---

@aerosimon wrote:

With what can I program read/write every 100ms?

---

When you don't know how to configure a serial port or how to put a wait of 100ms into a loop then you REALLY should take the "Training resources" offered by NI (in the header of the LabVIEW board) to learn LabVIEW…

[aerosimon]

Does anyone know how to empty the memory buffer at the end of the program?

[GerdW]

Hi Simon,

---

@aerosimon wrote:

Does anyone know how to empty the memory buffer at the end of the program?

---

Why should that matter at all?

When the "program ends" (and is removed from memory) LabVIEW will also release memory used for that program…

[wiebe@CARYA]

---

@GerdW wrote:

Hi Simon,

---

@aerosimon wrote:

Does anyone know how to empty the memory buffer at the end of the program?

---

Why should that matter at all?

When the "program ends" (and is removed from memory) LabVIEW will also release memory used for that program…

---

And if it doesn't, it's not the end of the program 😁.

[aerosimon]

I agree because when I run a program, the arrow is black. For me, when it becomes white again, it is the end of the program. But I noticed that sometimes, especially when I run another program quickly after the first one, the answer of this program is the one that was expected in the previous program (knowing that the previous program had already given the right answer) which would mean that the buffer keeps in memory the previous answer.
I know you're going to tell me that you have to wait to give the next command even if it's in another program but I'm already waiting.
Maybe I don't wait long enough...
In the manual of my device it is written I quote: "The IEEE-488 receive buffer is 250 bytes deep. The molbox1+ will hold OFF release of the NRFD handshake line until it can service and empty the receive buffer. This keeps the buffer from overflowing." but no time is given.
Furthermore it is written and I quote: "IEEE-488 commands must be terminated by a single linefeed character with the assertion of the EOI line." but I don't understand what this means, how do you make a linefeed? it is not stipulated...

Regards,

margot.

[RavensFan]

---

@aerosimon wrote:

I agree because when I run a program, the arrow is black. For me, when it becomes white again, it is the end of the program. But I noticed that sometimes, especially when I run another program quickly after the first one, the answer of this program is the one that was expected in the previous program (knowing that the previous program had already given the right answer) which would mean that the buffer keeps in memory the previous answer.
I know you're going to tell me that you have to wait to give the next command even if it's in another program but I'm already waiting.
Maybe I don't wait long enough...
In the manual of my device it is written I quote: "The IEEE-488 receive buffer is 250 bytes deep. The molbox1+ will hold OFF release of the NRFD handshake line until it can service and empty the receive buffer. This keeps the buffer from overflowing." but no time is given.
Furthermore it is written and I quote: "IEEE-488 commands must be terminated by a single linefeed character with the assertion of the EOI line." but I don't understand what this means, how do you make a linefeed? it is not stipulated...

Regards,

margot.

---

That is where you are confused.  You ended the VI you wrote in LabVIEW, but you did not end the LabVIEW program itself.  When LabVIEW ends, then it will release all the memory it has used.  Since you say when you run your VI again it seems to be affected by what happened when you ran it before, it seems you have uninitialized shift registers.  Those are a features in LabVIEW where the data (and thus memory space) is stored in the shift registers of a VI between calls to that VI.  Just because the VI stopped running, doesn't mean those shift registers get cleared.  It also indicates that if that you have some bugs in your VI, or its overall architecture where you aren't probably initializing the shift registers on the first call of the VI.

[wiebe@CARYA]

---

@aerosimon wrote:

I agree because when I run a program, the arrow is black. For me, when it becomes white again, it is the end of the program. But I noticed that sometimes, especially when I run another program quickly after the first one, the answer of this program is the one that was expected in the previous program (knowing that the previous program had already given the right answer) which would mean that the buffer keeps in memory the previous answer.

---

Note that this buffer doesn't need to be program memory. The data could be in a hardware stack, or the device's firmware stack. 

A VISA Clear might do the trick...

---

@aerosimon wrote:

I know you're going to tell me that you have to wait to give the next command even if it's in another program but I'm already waiting.

---

You have more than 1 program?

[aerosimon]

and how do you initialize the register shift? I haven't found any information about this.