ā06-21-2021 06:06 AM - edited ā06-21-2021 06:07 AM
Hi Massimiliano,
Massi@INO wrote:
which I32 counter are you speaking of? Is there a solution to avoid this overflow error?
Somewhere hidden in the code an I32 counter is used. Maybe inside Matlab ("VideoReader()"), maybe inside the LabVIEW-Matlab interface. (Most often Rolf knows such internals much better than meā¦)
Can you read (all) the video frames correctly when running that Matlab script using Matlab ("inside the Matlab IDE")?
ā06-21-2021 06:14 AM - edited ā06-21-2021 06:16 AM
@GerdW wrote:
Hi Massimiliano,
Somewhere hidden in the code an I32 counter is used. Maybe inside Matlab ("VideoReader()"), maybe inside the LabVIEW-Matlab interface. (Most often Rolf knows such internals much better than meā¦)
I can't really make much sense of the 3 VIs. Just noticed that the problem about those 3500 images very closely correlates to the I32 limit. As far as I can see in the VIs itself I do not see any obvious I32 problem on the LabVIEW side. All LabVIEW file IO functions use internally 64-bit offsets since LabVIEW 8.0 and since about 8.5 that is consistently implemented everywhere I have come across.
But some of what I see in those VIs makes little sense so I can't be sure there couldn't be some hidden issue somewhere too. But the VideoReader implementation on the Matlab side is probably a good suspect here. Without knowing more about its implementation it is simply a guess though.
ā06-21-2021 06:44 AM
Thank you very much, i will try to understand if this I32 counter is somewhere inside Matlab or inside the LabVIEW-Matlab interface. However, as soon as possible, i will try to implement everything only on Labview and avoid Matlab. Thanks again, massimiliano.
ā06-21-2021 06:49 AM
Thank you very much for your considerations, I will try to let Labiview do the entire work to eliminate any possible problem coming from Matlab and i will try to re-organize the Vls according to the various hints i received here. Thanks again, massimiliano.