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

[*3d0g]

Right now I'm working with two channels of 10,000,000 samples each, and one channel just decided to not go through the wall of a case structure.

I'm working ADC 8-bit for now. ...minus my data disappearing through a wall.

Clearly I've introduced an open path going through the structure.

I have four parallel shift registers, one for each channel's raw data.  All four go through the case structure.  Channel 1 goes awry after it has its data.  Channel 2 cruises through just fine.  It truly is a bizarre LabVIEW response.  What a debug!!

[*3d0g]

debug continues

I figured I'd get a better look at the data, crossed my fingers LabVIEW didn't run out of memory on me, and then sent the raw data to a waveform display.

Yep, it's a sine wave. But it's only on the left side of the wall of the case structure.  The other side is a line, due to the mysterious zeroes.

This is weird.

[*3d0g]

debug continues

It's just like I'm troubleshooting and the feedthru is open.  One side signal. Other side no signal. Open circuit through the wall. ...except my signal is an array exiting a case structure, not a faraday cage wall.

[*3d0g]

debug continues (dc)

This is getting fun!

On the right side of the wall I inserted a "replace array subset." I then went to another new vi with the data from a previous right side capture, made it a constant, and then pasted it into my vi, feeding it into the replace array subset.  iow, I inserted a test signal on the other side of the open.  were the line shorted to gnd my test signal would get pulled to ground, drawing high current. (yes, I've dumped uppercase and pretty grammar.)

Yep, there's my sine wave on the scope vi as expected.  (recall I tested the path, first. that path is good.)  

There's an open through the case structure wall!

but how? what is this LabVIEW quirk I am missing?

what a bizarre bug!

[*3d0g]

dc

what would cause an array to initialize to zero by going through the wall exiting a case structure?

the line comes in, gets its data, enters the right-side wall with data payload, and then exits the right-side wall with zeroed data -- the payload vanished.

inserting a signal after the right-side wall shows no issue looking down the pipe to, in the end, have the inserted test sine wave showing just fine in the waveform display. the path to the display has been proven.

i have to take a break and think on this.  (sorry for hi-jacking my own thread btw. i have to figure this out, and I know there are a lot of brilliant people here.)

[*3d0g]

dc

nope, I'm flat stumped on this one.  time to knock off and do something else, let it churn, and hopefully someone here has an idea.

It's plain as day. Look at the output and there's my test wave coming through just fine. Look at the data before exiting the case structure and there's the real wave coming from my function generator into the oscilloscope.

what a bug!

it has something to do with a glitch at the case structure, but I have four identical paths through it and one is failing.

[JÞB]

---

@*3d0g wrote:

dc

nope, I'm flat stumped on this one.  time to knock off and do something else, let it churn, and hopefully someone here has an idea.

It's plain as day. Look at the output and there's my test wave coming through just fine. Look at the data before exiting the case structure and there's the real wave coming from my function generator into the oscilloscope.

what a bug!

it has something to do with a glitch at the case structure, but I have four identical paths through it and one is failing.

---

Toss an Always Copy on the wire branch.  Sometimes the LabVIEW compiler's optimizer will try to save a buffer allocation erroneously.  This special bug has been seen much less frequently in recent years.   But, with mishandled very large data sets I could imagine that you uncovered a strange edge case that was not addressed and the LabVIEW memory manager got confused. 

Still, go back to my other post and see if a more suitable solution presents itself.

[rolfk]

You talk alot about what you think you are seeing and complaining about how it is not what you’re expecting but all we have is your litany of words saying the same thing over and over again.

If you had instead attached your VI (back-saved to 2019 or earlier) back in your original post about that problem everybody could have looked at it and pointed out possible pitfalls, or from my own experience most likely, wiring errors that look like there is a wire connection on a tunnel (the little boxes on your “walls”) but it isn’t or is different and hidden under the frame border!

Instead you go on a monologue of tens of posts and pretty much lost anyone who might have been willing to look into it long ago.

[altenbach]

---

@*3d0g wrote:

"so if the driver is doing it right, it should not be DBL as you claim."

That blew my mind; it's a new paradigm.  You're saying that just because the waveform clearly claims (DBL) that it isn't.  It doesn't blow my mind if what you're really saying there is that in order to get that waveform, which is double, math was done prior and that if I dig deeper I will see this.  That I get -- no new paradigm, there.  Correct, it's actually 16-bit integers that were converted to the doubles in the waveform. ...if that's indeed what you're saying.

---

If the waveform says it's DBL, it is DBL and they are doing it wrong. If it is I16 (Yes, as I said, waveform can be I16!), you would be able to easily tell (...and if you would finally show us some code, we could give much more specific advice!). 😄

I think your main problem is that you are trying to outsmart the LabVIEW compiler with some ill conceived ideas, looking in all the wrong places. Yes, shift registers are useful, but they can't magically create memory out of hot air and the LabVIEW compiler can often be equally efficient even without them. It all depends on how you program it.

Sometimes you need indicators, e.g. as (output connectors for subVIs!) and in these cases it is important to have the front panel closed. It also helps to disable debugging.

[*3d0g]

Wow Rolfk!  Relax.  We are talking two different things, I think.

As of last night I hijacked my own thread due to a bug that just popped up due to a change to using shift registers to get my raw data out and to the converter section.  The data was had from memory fine but then vanishes right out of the chute.

This shift register thing is a recent discovery, relative to the start of this thread, as something else to try, after the thread was begun based on the "driver" I got from LeCroy, where they're claiming huge double data in a returned waveform is possible.  I was just interested in that question, there.  But this thing, now, is a different animal.  I hijacked my own thread, yesterday, in the hopes that you more knowledgeable people might say, "aha! I've seen that before!" and then give me an idea I've not considered. 

Reasoning this bug out a little, letting it churn, I'm thinking what I'm dealing with, somehow, is scope, the scope of the case structure function(ality.)  I'm thinking as the array exits it falls out of scope and reinitializes, or something like that.

My apologies, Rolfk.  I'm happy and thankful you have participated in my thread -- you are very knowledgeable and I see you bringing value to this forum over and over.  However, there is no way I'm posting my scope software to this forum.  It is loaded with non-public material.  It is not happening.  I may post a snapshot of a dataset or a partial screen output, but that's about it, and maybe.  No, we go by words this time or we don't go on this one.  I know everyone wants to see vis, but sometimes you can't have it.  It is what it is.