LabVIEW and large data sets are incompatible. T/F? I say T.

[*3d0g]

mcduff: BTW, do you have anything on this crazy need to use a local variable to get an array out of a conditional structure?  All the other channels (there are four total, but only two have real raw data) have no issue -- the other three channels pass data out fine. ...actually, I need to check the two unused ones, still.  It's presently assumed they are fine. 😉

I'll shortly try out the magic Always Copy.  ...not there yet.

[*3d0g]

I changed my mind.  I am there.  (As I see it it's too much trouble to do the pretest of the other two channels.)

However, you want a picture.  You've got a picture:

It's the top shift register line (line one) with the problem.  Lest I clutter the space I removed the local variable store, for now.  Also, as I understand it, now, that local variable uses memory that isn't returned when it goes out of scope.  Frankly I'm concerned about the disabled troubleshooting block.  That's a giant indicator.  I used it to figure out the workaround(, except it isn't as it eats memory.)

As can be seen, it's a simple conditional structure block.  Line one just loses all its data going through the wall for some reason. 

[*3d0g]

btw no the Always Copy didn't work.  to me it makes no sense to put it after the exit.

[*3d0g]

here's the "workaround"  ...I got rid of the other since it didn't work.

Now just follow line one with a disable block that either keeps the trace or injects the local variable.  As I learn more about this (I'm still troubleshooting the phenomenon) I'll let you know.  It looks like a bug, but that doesn't mean it is, in my particular case. 

[*3d0g]

Yes, there's a problem with the tunnels.

I'm experimenting with where I write to the local variable.

This is a state machine, so it has multiple walls to the left for the initialized array to get in, finally, to the capture shown, above.

I have found that it matters where I write it, even though it's all supposed to be the same shift register array line, all leading to the outside wall where I defined the local variable at the output of the array buffer.  (The array that'll be used with the MemoryMove.)

This is strange, not reasonable, to me.  Perhaps it's reasonable to someone out there?

[santo_13]

It is good that you're iterating through several options but from business standpoint I would evaluate the need to bring in the experts if there is a bigger risk at stake.

I don't know about your business constraints, if possible I would recommend hiring a LabVIEW consultant to help evaluate your requirements and architect the solution.

[*3d0g]

I put Always Copy in a disable block, dropping it all along the line, in and out of the case structure.

The only thing that works is the local variable bypass workaround.

At present it's as I said.  The variable is defined at the initialization of the buffer, written after the MemoryMove, then read on the right side of the case structure (iow, after exit,) and finally injected into the shift register path.  That's the only way my data has gotten out.  Channel 2 works fine, and its case looks identical to that shown in the picture, above, except it uses the line under line 1, line 2, and the boolean line is moved down one tunnel.

I just don't get it.

[*3d0g]

Santo_13: What are your thoughts on this tunnel that can't retain data?

[*3d0g]

I figure it's about the MemoryMove, but why does the other channel work just fine?

[*3d0g]

I have a new requirement: tunnels that work.

LOL!