Dear Danna,
As mentioned in my last post:
The Loop-Startup and Exit plus Restart is sometimes difficult.
The loop control is normally the reason for irritation in sync0.
So, you see a certain amount of loop runs in RT and then a dead-lock.
We would expect that one of the Image-Memory operators is running full, or the loop start/restart conditions are not getting met.
Dear Danna,
The Loop-Startup and Exit plus Restart is sometimes difficult.
I think this is a problem,but I don not know how to fix it?
Both of your questions point exactly into this.
Now I want to know the values of （StartUp_SUB--Sequence_Length--N_rolling） and （DynamicDivider--N_rolling）should be set to 128 and 50?
Is that right?
So as soon as I find some time I will look into it and let you know.
Best regards
Hello SWe,
Sounds like a demanding project:
As requested *known single pass features* plus add-on features, PDF annotation did not work for me:
afaik, your PDF is not missing basic features.
I am curious what your results will be.
Hi Theo a.k.a. L.Bu,
Sorry for my late response,
Kind regards from Heidelberg,
B.Ru
Dear ArjunLucid,
Just as an idea:
You can script the VA synthesis and make a secondary PC a synthesis machine if you need to.
Please be aware that you need a second VA dongle in that case.
Dear MatthiasR,
On page https://docs.baslerweb.com/liv…t/Memory.ImageBuffer.html you can find a formula regarding available memory. While this formula is intended for theImageBuffer itself, you will get details on the availabe memory on the basis of Parallelism, Kernel-Size and Bit-Depth.
Dear Lily,
You can build a loop for this on the basis of TxImageLink and RxImageLink and use ReSyncToLine to get the result of the previous line processed for comparison.
Did you implement a kind of loop for this?
Dear Danna,
Do you already have an update on the discovered irritation?
Best regards
Hi Theo,
Please use the following syntax for absolute path in Parameter-Translation:
${/Process0/HboxName/OperatorName.MemberName}
That will help you for absolute path usage in the write/read/range parts, but in general an absolute path is not fully supported.
Dear JSuriya,
Please have a look at the code below as changed in H-Box Buffer.
In detail the parallelism (x4 : x32 : x4) around the ImageBuffer is modified now.
Since the mE5 VCL is using a shared memory approach you should use as high paralleism around it as possible.
Here https://docs.baslerweb.com/liv…t/Memory.ImageBuffer.html you can see some more details in the available memory formulas on it.
This will enable you to use more memory and potentially more bandwidth.
Here you can find the modified design:
Best regards,
Björn
Dear Danna,
As shown above, when I only did Image、K2、Jet、roi、process、DIA H-Box, the hap file can work as expected.
So I think the problems that cause timeouts are from aver、image2 H-Box.
Am I right？
That sounds pretty likely, and now the real dead-lock reason needs to be found.
Please let me know if you have a clue how to find this.
If not, please post the related H-Box into this thread, so that the community have a look into it.
Dear Danna,
A simple Branch to 3 and then MergeComponents makes a mono path color.
Dear Danna,
As I can see below:
I already got the original image from the Camera.
But when I continued,there were timeouts.
you could get images from the camera. So the camera configuration and the intended CL mode are working as expected now. That is a good step.
In the quote above you mention that there were timeouts when you continued.
Please look a few posts back and you will see hints on RX/TXImageLinks.
Those can be used to "debug" a loop.
Since we are currently only investigating your design concerning the dead-lock, please use CastBitWidth / SelectComponent to make all pathes compatible.
When we found the reason, then we can go back to full operation mode, without the unnecessary probe-pathes.
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,
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,
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,
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 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,
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,
Additional hint to the post above:
The H-Boxes DummyProcessing_X are placeholders for your processing steps.
