control serial comunication! help!

[Fonsi]

---

mikeporter escribió:
Actually, I think that is a string displayed in hex. But what is going on on the 4 frames we can't see? Lose the sequence structure!

Mike...

---

Mike,

I attached the block diagram of main pogram. 

Like you see, I got the decimal values and have one gauge  0 to 100%, also the data input in one subvi where I check each block the data is ok, no fault readings from the position of sensors, no touch correctly,... If I got the 8192 then go to the next event. If I find any error, I cut the transmission and write to device CDD9 = clear buffer data from device. So you can do another test. Sorry for unclean diagram.

[RavensFan]

---

@Fonsi wrote:

ravens,

I dont understand what you mean. 

The system is easy, sorry If I didnt explain it well. 

I modified a bit and it is :

My app say:  CDD1

device reply: ADD1

My app say : CDD1 CDD3

device reply: ADD3

My app say: CDD3

device reply: Start transfering 4 blocks of 4096 bytes.

The stream stop 2 or 3sec between each block. (the device change the freq of signal, then measure and send the data).

---

Now you are reading 2 bytes and comparing it to a 4 character string.  Once again, those two things can never be equal!

EDIT:  If that ADD3 is actually 2 bytes in hex display, then please turn on the Display Format indicator on that constant so we can see that fact.

[Fonsi]

---

RavensFan escribió:

---

@Fonsi wrote:

ravens,

I dont understand what you mean. 

The system is easy, sorry If I didnt explain it well. 

I modified a bit and it is :

My app say:  CDD1

device reply: ADD1

My app say : CDD1 CDD3

device reply: ADD3

My app say: CDD3

device reply: Start transfering 4 blocks of 4096 bytes.

The stream stop 2 or 3sec between each block. (the device change the freq of signal, then measure and send the data).

---

Now you are reading 2 bytes and comparing it to a 4 character string.  Once again, those two things can never be equal!

EDIT:  If that ADD3 is actually 2 bytes in hex display, then please turn on the Display Format indicator on that constant so we can see that fact.

---

Yes, sorry the constant and indicator are hex display!.

Btw, if the device is still communicating with the computer after my program has closed without closing the communication with device. 

When I start the communication again, to get rid of data once the port has been configured and the communication has started. Should it check the number of bytes at port?, and if it is not = 0 , clear or flush the buffer?. Otherwise it may get sync issues in the start.

Any another way?.

For design the vi, I need to use any while loop and read fixed number of bytes, when I get the 4096 check if it is ok, and then get another block. I would like to hear the best way to get it.

Thanks guys for your time.

Fred.

[Fonsi]

Any another way?.

For design the vi, I need to use any while loop and read fixed number of bytes, when I get the 4096 check if it is ok, and then get another block. I would like to hear the best way to get it.

Thanks guys for your time.

Fred.

[RavensFan]

Why would it still be sending bytes after you stop your VI?

It looks like this device should only be sending data whenever you write a command to it.  Once you've collected all the bytes, it shouldn't be sending anything else.

I would do the reading of 4 blocks of 4096 in a loop.  You can read 4096 at a time, but if you do, I'd be sure to set the size of the read buffer larger than that.  You could do a read of whatever bytes are at port at that time and keep building them into a string until you've collected 4 x 4096 bytes of information.

[Fonsi]

---

RavensFan escribió:

Why would it still be sending bytes after you stop your VI?

It looks like this device should only be sending data whenever you write a command to it.  Once you've collected all the bytes, it shouldn't be sending anything else.

I would do the reading of 4 blocks of 4096 in a loop.  You can read 4096 at a time, but if you do, I'd be sure to set the size of the read buffer larger than that.  You could do a read of whatever bytes are at port at that time and keep building them into a string until you've collected 4 x 4096 bytes of information.

---

Yes RavensFan,

The device sends data if you close the vi, it continues sending them. I can put Write visa and put CDD9 and it stop the transmission and reset, but If  you crash the vi for any error, it will goes sending data. I want only put it like prevention.

I tried to flush the byte at port, but it didnt works.  I need to break?. 

About the schema, I did like crossrulz told me. 1 loop with write fixed to read. I put 512 each iteration, so The gauge look good. When I got the whole block I test it and go fine and I didnt have the problem that I had before.

Fred

[RavensFan]

What if you open the port, detect you have bytes coming in, then write CDD9 to stop it.  Then you can flush the port (in case anything else came in while sending that message.  Then go back to your "regularly scheduled program."

[Fonsi]

RavensFan,

Thanks for reply!.

Yes, I thougth this idea, but when I write CDD9, the device take some time to recover and be ready, show some leds... therefore It is not the best clean way to do. I finally used this method:

I tried with while loop checking the bytes at port, but it take some time with 0 bytes, so It didnt work well. With For loop I get the majory of bytes in the first try and in the second the remaining. Works fine.

Thanks for help guys!.

Fred

[RavensFan]

If you don't tell the device to stop sending crap, isn't it going to keep on sending it no matter how many times you clear the buffer?

If you detect it wasn't cleared properly the last time you ran your VI, then that delay for the device to reset at the beginning of this VI is a small price to pay and something you need to do anyway.

[Fonsi]

---

RavensFan escribió:

If you don't tell the device to stop sending crap, isn't it going to keep on sending it no matter how many times you clear the buffer?

If you detect it wasn't cleared properly the last time you ran your VI, then that delay for the device to reset at the beginning of this VI is a small price to pay and something you need to do anyway.

---

 Yes, you are right!. I prefer the  no very orthodox way, since it visually is no noticed. It only takes 2 seconds to start the test. But yes, you are absolutly right.

 Now, I am busy creating one config screen in my program, where I select the com port number and save it in ini file. So the first time you open the program will open comport by default and then I could save the correct port in config screen.

I'm going to open another thread with this issues. I am getting crazy with ini files.

Fred.