LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

sudden stop of File writing

Solved!
Go to solution

@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.

0 Kudos
Message 21 of 27
(129 Views)

Hi Kevin P

 

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

WWolf78_0-1643190664187.png

 

the recommendation is to set a fixed value like that:

WWolf78_1-1643190788666.png

 

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"?

 

0 Kudos
Message 22 of 27
(125 Views)

VIWeek 2020/Proper way to communicate over serial

(courtesy of crossrulz)

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?

(Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).



0 Kudos
Message 23 of 27
(119 Views)

@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. 


"Should be" isn't "Is" -Jay
0 Kudos
Message 24 of 27
(112 Views)

@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:

WWolf78_0-1643190664187.png

 

the recommendation is to set a fixed value like that:

WWolf78_1-1643190788666.png

 

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?


"Should be" isn't "Is" -Jay
0 Kudos
Message 25 of 27
(109 Views)

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!)

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO
Message 26 of 27
(89 Views)

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?


"Should be" isn't "Is" -Jay
0 Kudos
Message 27 of 27
(80 Views)