Dear Danna,
When I look into your file:
Then there are several timeouts.
In case the camera configuration and applet configuration:
When I see it correctly then this camera operator is setup for CL DECA 10tap 8 bit, while in this thread you mentioned above requiring: CL FULL 8tap at 8bit. You can change FullMmode during runtime, so no resynthesis is required.
do not fit to each other no data can get forwarded.
That may cause the timeout.
Since deadlock-scenarios show the same behaviour:
Do have the VA-Expert and/or Debugging license?
In case of yes, we can start investigating yor design on that basis.
If not, then we need to go for SelectSource probes for runtime...
I only use one DMA to output the color image
The number of DMAs will not influence runtime/SDK error handling.
Dear Danna,
Thank you for your feedback.
Does your answer above mean that the format of the camera and the VA software program do not match?
I just wanted to oint out that a common reason for timeouts is a mismatch in CameraLink modes between camera and frame grabber.
What format should I set the camera and VA software program accordingly（2020-2-27-LSTCA__MOD_BjoernRudde）?
The format CL DECA (10 tap 8bit) and CL FULL (8 tap 8bit) is supported by the camera and the grabber you are using. The difference is simply the possible bandwidth
While 10 taps at a frequency of 82 MHz deliver:
(82 MHz) * 10 * (8 bit) = 820 MB / s
and 8 taps
8 * (8 bit) = 656 MB / s (both values linked to calculator)
it is simply a question of bandwidth.
A second side effect is that the horizontal transfer resolution inside CL is a multiple of the tap count at 8 bit.
Where can I check it? On the software interface?
Inside VA you can check it following the menu bar > Tools > License Manager:
Just let me know if you have VA Expert or the VALib Parameter and we will go into the deadlock investigation on the basis of debugging operators, what is pretty straight forward and time efficient, or we go for a standard way that includes slightly more efforts.
Dear Danna,
Thank you.
We will go into the investigation on the basis of standard operators.
I will prepare some details and come back to you.
Please give me some time for this.
Dear Danna,
The structure below shows how to make artificial probes in your design:pasted-from-clipboard.png
Each DebugProbe_N H-Box includes a mechanism to stop forwarding data. That will mask out any stop stream (inhibit) from the later processing.
ProbeSelect needs to be set to the DebugProbe you want to see.
By this you can go through your design to find the reason of a stop condition.
We can find the reason where the design blocks.
The Detach.Value can be set to 1 to avoid forwarding data and possibly causing a stop of the datastream:
That approach masks out the dead-lock detail that causes your timeouts.
First of all we should check if data from the camera arrives as expected, and then step by step through your design.
You can copy/rebuild this approach into your design.
This approach can get simulated, too.
I'm sure that we can find the issue causing your timeouts.
The example VA-Design:
Dear Danna,
Additional hint to the post above:
The H-Boxes DummyProcessing_X are placeholders for your processing steps.
Dear Danna,
When you look at your design you have a network processing the data.
All the data goes as a stream through all operators.
Directly after the camera's image buffer you have access to the camera data.
That is the reason we add the first probe there.
A second probe behind first processing block.
Looks like this now:
Here you have an example of implementation: 2020-2-27-LSTCA__MOD_AddDebug_BjoernRudde.va
You can add several additional probes where you want.
In case of inside a H-Box you can avoid "ugly" links by using TxImageLink and RxImageLink operator.
In order to select a certain probe, disable all stream dumps by setting Detach.Value=0 in DebugProbe_N that are before the probed link.
Default setting in the attached VA Design is DebugProbe_2.
Dear Danna,
The VA file in the previous post is already correct:
The Detach.value cuts of the stream to further processing, but not for this output.
This structure can be simulated.
Put an image in by a SimSource and simulate.
You will see that a SimProbe directly before the DMA will get filled with image data from camera directly.
The rest of the design will be nearly "silent".
Dear Danna,
Since all Detach.Value's are dynamic we can change behaviour directly.
SelectProbe.Select (SelectSource) is dynamic too.
So you can change during runtime and iterate into the cause of irritation.
Dear Danna,
The we go through synthesis and into runtime.
There we look if we get camera data.
In case of yes, we switch to next probe.
By this manual process inside mDisplay we can see where the dead-lock may be.
Dear Danna,
So next step,I should generate HAP file from this VA program, and run mDisplayX.
Am I correct?
Yes, that is fully correct.
In mDisplayX you can go through the different Probe-Sets, starting with Camera image.
Best regards,
Björn
Dear Danna,
Here in the VA forum we are all helping each other.
As soon as you have the system running and see the first images we can go on with the investigation.
Just let me know what the results are and we and the community will solve upcoming irritations.
Best regards,
