LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why do I get a -1074396065 error when copying from an acquisition buffer?

I am copying an image from an acquisition buffer into another buffer of the same size and image type using 'IMAQ copy'.

 

Usually, this works fine.

 

Sometimes, I get an error, -1074396065. This is the code for "Cannot resize an image in an acquisition buffer."

 

Both images display when I probe them just before the error. I explicitly check that they have the same size and image type.

 

Any ideas why this could be happening? Different border thickness? How do I even find that out?

0 Kudos
Message 1 of 7
(1,773 Views)

Hmm, "acquisition buffer". Does it mean you try to copy into image where camera is writing data and locking that image?

0 Kudos
Message 2 of 7
(1,769 Views)

It might nominally mean that, but that's the exact opposite of what I just told it to do. I'm copying FROM the acquisition buffer. That's the first thing I checked (though if I were copying it that way, the code would never work at all instead of usually working).

0 Kudos
Message 3 of 7
(1,761 Views)

Another example of "My code doesn't work, please tell me what is wrong without my showing you the code".  Sometimes the Error Message is so clear ("Error: Division by Zero" -- fix = "Don't Divide by Zero!"), but when dealing with IMAQdx, nothing is that simple.

 

Please attach the VI (or VIs) that are involved.  If I had to guess (which is all that I can do without seeing the code), I'd guess that you've set up IMAQdx not quite right, and are trying to access a "buffer in the process of being written by the IMAQdx Driver", hence the (not quite appropriate) Error Message.  But, then again, this is only a guess ...

 

Bob Schor

 

P.S. -- attach the VI (or a LabVIEW Snippet of the entire VI, if you know about those).  Do not attach a screen shot of all or part of the block diagram -- these cannot be closely inspected (can't examine "hidden cases"), can't be executed, and can't be "tweaked" and "tested", thereby wasting our time.

0 Kudos
Message 4 of 7
(1,741 Views)

You said,

 

Another example of "My code doesn't work, please tell me what is wrong without my showing you the code".

 

No. I said,

 

Any ideas why this could be happening? Different border thickness? How do I even find that out?

 

I asked a general question and a specific question. Valid answers in this case could be, "This error sometimes happens when X, which is not what the error description says." Or, "I know that differing border thicknesses do not cause this problem."

 

Once we're past that, then I have to do the very, very hard work of getting a reproducible example, let alone one that's small enough to be tractable. The VI in question is a subvi of a subvi of a subvi. Snippets aren't going to help - can you imagine? "Oh yes, this is exactly what he said - copying from one image space to another -but without more we have no way to be sure that all those properties he said he checked that it has are actually apply. What the hell use was this code snippet?"

 

So I do NOT think it was unreasonable to check for easy stuff before doing that.

 

 

0 Kudos
Message 5 of 7
(1,732 Views)

I was able to trap this error using the IMAQ ImageToEDVR.vi and not using the "Delete Data Value Reference" before loading another image into the same buffer.  I suspect that using the EDVR version of the ImageToArray function requires the EDVR to be closed / deleted before the buffer can be re-used.  Hope this helps. 

0 Kudos
Message 6 of 7
(890 Views)

Hmm!

 

That looks like it might have been the problem - though it appears I mooted the issue years ago. Maybe I solved it by accident while cleaning up other code, and never figured out why it went away.

0 Kudos
Message 7 of 7
(886 Views)