binary write crashes timed loop?

[NicB]

By following the other thread I think this one could be entitled "Do I need a Timed Loop?"

I suppose the frame rate is controlled by hardware and I do not see any reason to try synchronization at this level - frames comes with 500fps rate from your camera, and acquire VI is the synchronization point in your application.

My suggestion in the above post is very similar with "Writing Larger Blocks - An Improvement" slide from the presentation (somewhere at 40 minutes). Wait for multiple frames and write all at ones (probably those hard disks can even rest a while).

---

Enrico Segre wrote:

Rather, can you please argument further on "(Tip: writing text files might be faster than binary)"? That may be an interesting point. I'm using unbuffered write, in the real thing, anyway.

Thanks, Enrico

---

I am not a NI internal but I think when using "Write to Binary File" the elements are written one by one, even if the element size is 1 byte. When writing text LV passes the entire string to low level OS functions. However, I am not familiar with Win32 file I/O API, so the observation might not be effective here.



I apology for the above wrong calculation - don’t know how those 40 seconds came out.

[Enrico_Segre]

---

NicB wrote:

By following the other thread I think this one could be entitled "Do I need a Timed Loop?"

No, I'm sorry, I definitely don't want this thread to slip into a discussion about programming philosophy. My focus is on "This crashes; isn't it a bug??"

My suggestion in the above post is very similar with "Writing Larger Blocks - An Improvement" slide from the presentation (somewhere at 40 minutes). Wait for multiple frames and write all at ones (probably those hard disks can even rest a while).

I'm aware and perusing the suggestions of this link and its companions -- but in the real thing.

I am not a NI internal but I think when using "Write to Binary File" the elements are written one by one, even if the element size is 1 byte. When writing text LV passes the entire string to low level OS functions. However, I am not familiar with Win32 file I/O API, so the observation might not be effective here.

ok, unbuffered vs OS-buffered write. Know.

I apology for the above wrong calculation - don’t know how those 40 seconds came out.

Maybe1GB instead of 1TB?

Enrico

[NicB]

---

Enrico Segre wrote:

---

NicB wrote:

By following the other thread I think this one could be entitled "Do I need a Timed Loop?"

No, I'm sorry, I definitely don't want this thread to slip into a discussion about programming philosophy. My focus is on "This crashes; isn't it a bug??"

---

Time Loop means thread, threads means OS support, but XP64 is not supported. It seems this particular question got its answer already.

---

Enrico Segre wrote:

---

I am not a NI internal but I think when using "Write to Binary File" the elements are written one by one, even if the element size is 1 byte. When writing text LV passes the entire string to low level OS functions. However, I am not familiar with Win32 file I/O API, so the observation might not be effective here.

ok, unbuffered vs OS-buffered write. Know.

---

No, it's not. It is about further processing (e.g. check endianess). Probably the array is copied (memory allocation) even if you have 1 byte elements. Anyway, 8 CPUs could handle such simple tasks in time.

[Enrico_Segre]

---

NicB wrote:

Time Loop means thread, threads means OS support, but XP64 is not supported. It seems this particular question got its answer already.

grinning...

ok, unbuffered vs OS-buffered write. Know.

---

No, it's not. It is about further processing (e.g. check endianess). Probably the array is copied (memory allocation) even if you have 1 byte elements. Anyway, 8 CPUs could handle such simple tasks in time.

Here I apologize, I misread, taking element size for array size. I agree on all accounts - native writing may or may not avoid a conversion, fast cpus and memory channels should handle the troughput, some versions of the streaming vis in the devzone interface directly to kernel32.dll functions, which may or may not be the most efficient choice.

 

Well, thanks anyway for all the comments,
Enrico

---

[Chris_G.]

Hello Enrico,

It sounds like you have a pretty good handle on things at this point, but just to clarify, we do not consider this to be a bug sinceXP x64 is not technically a supported OS for NI software.  We definitely appreciate the feedback though, and we are always open to product suggestions for future revisions of our hardware/software.