sudden stop of File writing

[wiebe@CARYA]

---

@Kevin_Price wrote:

To the OP:  solved for the moment, but I still think you're very likely setting yourself up for trouble with your specific use of Bytes at Port.  It appears that you then Read that same # of bytes and pass it along for decoding, *seemingly* with the assumption that you've read a complete message, not just part of one.

Using Bytes at Port this way is prone to giving you partial messages that decode incorrectly.

---

Also, the two cases that handle the data is clearly duplicate code.

Even if there are minor differences, put it in a sub VI that makes sense.

You absolutely never want to find yourself in a situation where you have to change the same thing in two places because you copied the code. Be lazy that way.

[WWolf78]

Hi Kevin P

I read about the issue regarding the "bytes at port" and there seem to be a consensus to avoid that:

the recommendation is to set a fixed value like that:

on the other hand there was the point in this case the "Visa Read" waits until it had read 1000 bytes, so this could create an delay.

what do you recommend for "bytes at Port" / "Visa Read"?

[Kevin_Price]

VIWeek 2020/Proper way to communicate over serial

(courtesy of crossrulz)

-Kevin P

[JÞB]

---

@GerdW wrote:

Hi Jay,

---

@JÞB wrote:

Since you open the file once and write many times, enable file Buffering!  There is an optional boolean for that into Open Create Replace File.vi that few people bother to read the help file about.

---

Thanks for this reminder…

But (atleast in LV2016) that buffering is enabled by default.So there will be no improvement by wiring a FALSE constant to a default FALSE input…

(You can disable buffering when needed.)

---

That boolean is called "Enable File Buffering (f)"  File Buffering is disabled by default to maintain cross platform compatibility since, only Windows supports File Buffering. 

[JÞB]

---

@WWolf78 wrote:

Hi Kevin P

I read about the issue regarding the "bytes at port" and there seem to be a consensus to avoid that:

the recommendation is to set a fixed value like that:

on the other hand there was the point in this case the "Visa Read" waits until it had read 1000 bytes, so this could create an delay.

what do you recommend for "bytes at Port" / "Visa Read"?

---

Alright! That's more than enough background for the GENERAL case of proper serial communications. 

What we should also address is the SPECIFIC case applied to your problem domain.  So, we need a bit of information from the User's Manual for the device you have.  What is the device? And, did you RTFM (Read The EFFing Manual)?

How are messages formatted? Do they have fixed size? Are they terminated with a special character? Does the message enclude size information?

[GerdW]

Hi Jay,

in my German LabVIEW2020 32bit installation that boolean is called "Disable buffering (F)" (from German "Pufferung deaktivieren (F)") and I saw the same English label in my LV2016 installation at work…

(The same is written in the LabVIEW2018 help!)

[JÞB]

Thanks for clearing that up.   Something is wrong with that default value!  I wonder what difference one might notice if you have multiple small writes.   

Time to wave down a BLUE BAR.  <  Shouldn't they be that ugly green these days?>

Hey, AQ or Darren, any input?