Why this type-coercion dot at WRITE FILE?

[CoastalMaineBird]

I have reduced my mystery case to a simple one:

Place a NEW FILE and a WRITE FILE on a new diagram.
Place an instance of a TYPEDEF (any typedef) on the panel.
Wire the terminal of the typedef to the DATALOG TYPE input of the NEW FILE function.
Wire the same terminal to the DATA input of the WRITE FILE function.
Wire the refnum from the NEW FILE to the WRITE FILE.

Why is there a type-coercion dot at the DATA input of WRITE FILE ???
We just told it what type the file is - why does it need to convert anything ??

I ask because my real application might have a data chunk of 20 Megabytes or so - I don't want any real type conversion to slow me down...

[Chienwei]

Hi CoastalMaineBird,

I had experienced the same problem before. I ended up creating a constant from the typedef control, disconnecting the constant from type def, and wiring the constant to the DATALOG TYPE input of the NEW FILE VI. You'll be able to avoid the coercion dot by doing that.

Hope this helps,
Dan

[CoastalMaineBird]

I have two troubles with that:

1... The typedef in my case consists of a very complicated structure. I can hide the control easily enough, but the constant comes out at 10000 pixels high or something - too ugly to manage on the diagram.
2... Disconnecting it from its typedef loses the primary reason for using typedefs - instant updating from the master. As I am still in development of this part of the program, I'm sure it will change frequently.

My gut tells me that there is not REALLY any coercion going on. If your trick gets rid of the dot, that would seem to be proof. I have seen cases before where a typedef DBL has to be "coerced" to fit an ordinary DBL - I suspect this is the same thing.

I just wish I could go on something besides my gut feel.

[Ben]

Hi Coastal and Dan!

My first reaction to this Q was that it was another one of those "FYI" coercion dots that just let you know that the data type has changed but no new buffers are created.

So... I followed your instructions and used the "show buffer alloctions" feature.

The results are illustrated in the attached ZIP (contains LV 7.1 code and jpg).

I was supprised to find out that yes you are indeed creating a new buffer.

I also included an unusal construct where I typecast the typedef as itself (see jpg) and used to wire to the New file.

This fixes the extra buffer allocation (similar to Dan's approach bu typdef linkage is manitained)

BUT

I can not explain why it is different!

The un-explained behaviour makes me nervous.

Does anyone else have an explaination to this?

Perplexed,

Ben

[Ben]

I was posting at the same time as you Coastal.

I agree with your thoughts except I beleive the buffer IS being duplicated!

Ben

[CoastalMaineBird]

I was supprised to find out that yes you are indeed creating a new buffer.

ARG! When I'm passing a 20-meg structure to WRITE FILE, I don't want to waste the time (and memory) to make a copy !!!

I haven't used the SHOW BUFFER ALLOCATIONS feature (still on 7.0 in Windows), but it sounds like the thing to use to answer my question.


Now, the question is, what to do about it ??

I thought LabVIEW was smarter than that regarding memory usage and re-usage.

[Ben]

"ARG! When I'm passing a 20-meg structure to WRITE FILE, I don't want to waste the time (and memory) to make a copy !!!
"

Don't freak out yet!

My cludgey work-around does not duplicate the buffer while maintaining the typedef linkage!

Look at my jpg again and duplicate the odd typecasting.

Ben

[Chienwei]

What about use flatten the typeref to string first and write the string to file instead?

I can't think of any other solutions so far. If your structure contains clusters and arrays then the Type Cast solution won't work. Writing a typedef control directly won't work because "Disconnecting it from its typedef loses the primary reason for using typedefs" and the coercision dots...

Dan

[CoastalMaineBird]

What about use flatten the typeref to string first and write the string to file instead?

Because then I don't get the advantages of a datalog file - namely in file-selection dialogs and simple reading.

[CoastalMaineBird]

Look at my jpg again and duplicate the odd typecasting.

Yeah, I see it. I was "freaking out" at the idea that indeed, we are creating a separate buffer.

But your example does NOT get rid of the coercion dot!
You have wired your weird typecast into the OVERWRITE input of the NEW FILE, not the DATALOG TYPE input.

Wire it correctly, and the dot comes back.