Dear Saito-san,
You can simply adopt the distortion approach into the scaling details.
Posts by B.Ru
-
-
Dear zhuomuke,
In case you would go for a mE5-MA-VCX-QP platform you could save 2 of the 6 image buffers due to the shared memory approach of this platform. So you will require 4 buffer and have 4. Tha would be a perfect fit.
-
Hello together,
Would it be useful to post some C++ code on how to interpret the 12bit data corretcly in the context of a display example?
-
Dear Saito-san,
Thank you for this feedback. I forwarded your feedback to the product management.
For now you can use the ParameterTranslation in order to rebuild certain details as far as possible with the aspect of making AcquisitionApplet's similar VA Designs.
-
Dear Jayasuriya S.,
Please check the DMA for the VA Design manually in microDisplay.
So you have to build a CreateBlankImage approach instead of a camera into the design.
Using SourceSelector would enable you to include the camera and the simulator at the same time.
The CreateBlankImage operator would deliver as much data as the DMA can transfer.
In microDisplay(X) you can see the obtained bandwidth and use this as a good indicator for the possible DMA performance.
In case of further questions on this do not hesitate to contact me.
-
Dear Saito-san,
An 1D image distortion can be handled by aLineMemoryRandomR(ea)d operator.
The appropriate example would be ScalingLineP16.va :
-
Dear Silverfly,
The amount of FPGA external RAM ressouces is currently restricted to a maximum of 4.
In case of symmetric configurations and synchronization in between of the cameras an approach with InsertLine and AppendLine with ImageFIFOs directly behind the cameras it may become possible to write all camera image stream data into a single RAM ressource. That is additionally a question of the required bandwidth, because a single buffer needs to handle all 4 camera-streams at the same time.
-
Dear Silverfly,
The restricted performance in your PC may be related to a DMA limitation of the mainboard.
- Could you please look into microDiagnosis and run a DMA performance test?
- Please post the log of mDiagnosis here. That could give some indications.
Thank you.
-
I have installed a Marathon VCL frame grabber with the runtime v5.6.1 and flashed my applet there. When I tried to do performance test in Micro diagnostics , I received an error attached here. Could anyone help on this?.
Please contact your local support center for issues like this.
Basler Support contact list...
From my point of view the not running perfromance test is not a real/hard issue as long as the hardware itself is present in microDiagnosis and microDisplay.
It can be related to different version of applet in graber and existing file in runtime.
Please let me know if our support could help you.
Thank you.
-
Dear rvdbijl,
is the Ironman board limited to 4 DMA and 4 Imagebuffer instances? VA 3.2.0 won't let me add a 5th one in my project and pass Design Rules Level 1. The resource index won't go over 3 for either one
The number fo DMA-Transfers is limited to 4. You can use InsertImage/AppendImage, InsertLine/AppendLine to show two images below of each other or next to each other using the Insert*/Appen* approach; please take care that these approaches require some synchronization memory for serializing lines or images. For two results/images that exist at the same time, please use InsertLine/AppendLine and a ImageFiFo (size 1 line per input) to handle the waiting time for the lines being forwarded one after the other. An image serialization is normally "cheaper" concerning hardware ressources that an additional DMA channel.
The amount of ImageBuffers (real frame grabber hardware RAM modules) is limited to 4.
-
Dear customer,
Concerning your question. If you want to run mDisplay with a single camera and multiple DMAs,
please make the following setting:
mDisplay -> Tools -> Settings -> Check "Ignore Camclock status" and apply:
That may help to start all DMA according to your requirements.
If that is not showing the expected behaviour, then please paste your VA design here if possible.
Thank you.
-
Dear Theo,
The Overflow parameter of the ImageBuffer operator is not stable enough to get a reliable feedback.
That can not besolved by a parameter translation itself.
This VA design OverFlowDetection_v01_BRudde.va will be a reliable approach:
It measures the amount of pixels going into the FIFO and leaving it.
By this the current fill-level can be seen while being the first memory behind the camera (infinite source = enabled) and directly in front of the first RAM related memory (inifinite source = disabled) operator.
So in case the first RAM memory operator is not accepting or refusing the arriving data this can be detected.
Additionally there is a EventToHost operator that sends an overflow event in case the small FIFO is geting filled up.
A progressive detection on the basis of an OK, critical and error fill-level are used.
-
Your input is forwarded as feature request.
-
Dear Pierre,
I hope I understand or interpret your question correctly:
The DMA transfer (DmaToPC's FG_FORMAT) mentions the wrong bitdepth?
- 8 bit instead of 12?
- Can you please check if the camera is sending 8/10/12 bit as expected?
In case the camera sends 8 bit and the design expects 12, the representation of the data would look wrong for 12 bit visualization.
-
Dear Theo,
Thank you for your honest post.
-
Dear Theo,
Thank you for this hint.
I forwarded your input to the product and development management already.
As far as I know is the naming of the runtime/SDK CXP Acq_QuadCXPx1* acquisition applets working with four single link cameras versus the VisualApplets operator with the name CXPQuadCamera sourced by two independent naming conventions.
Both are using Quad, but the runtime applet name is supporting 4 cameras, while the VisualApplets (VA) operator is intended for 4 CXP links representing a single camera.
Do you have a better naming for these CXP*Camera operators?
Maybe: CXP6x1Camera, CXP6x2Camera, CXP6x4Camera
Quote...effect the parallelism I hope but it might, correct?
The different VA CXP camera operators support parallelisms above the minimal one on its output node, which is based on maximum interface bandwidth and format mode setting (dynamic/static is affecting this). The paralleism in combination with the system clock defines the maximum bandwidth of a single link. When you selected the CXPQuadCamera operator you will have a default or parallelism 32. In case you require for your project CXPSingleCamera is will be 8.
The current version of our CXPQuadCamera operator supports CXP x1 x2 x4 link configurations during runtime, and as words of solace I can tell you: The single(x1) or dual(x2) link CXP camera will work with the CXPQuadCamera (CXPx4) VA operator...
One more hint on something related to that:
The minimal paralleism of the camera operator will always be used inside it and may affect the image resolution of the image going into your link with an optinally different paralleism.
As an example for this:
Camera delivers 1024 x 1024 pixels in a CXP6-4 configuration into the CXPQuadOperator.
The operator is having a minimal paralleism of 20 and default of 32.
So the image will get internally the line length of 1040 pixels. Then at the output it becomes a paralleism of 32 and this acts exactly like ParallelUP operator. So you get a line length of 1056 pixels into the link.
Setting the maximum image width to the correct value is mandatory in this case.
You can simply use ImageStatistics operator directly behind the camera operator to investigate this.
After that a ImageBuffer will help selecting the real region of interest of the image.
The paralleism is not affecting the image height directly.
Ok, I am now completely of topic ...
-
Hello,
The remove image procedure inserts a delay of exactly one full frame.
The previously inserted FIFO was able to store a single line.
Because of that there was a deadlock as soon as the first line ran into the SYNC(module16)...
Below you can see a screenshot of the solution and the VA source code below:
Download VA Design: grab_test_BRudde_v01.va
That version will work as expected.
The VA simulation is not taking care of the synchronization in hardware,
that detail needs to be fixed by the developer during design time.
For explanation:
The remove image approach causes a delay of a full frame in the upper link (by-pass) and requires a memory for a full frame.
-
... Is there a way to check whether the incoming image is large enough to be processed and to choose not to process it based on its size?
This would require to wait for the last line of an image and would cause a full frame latency and require a memory operator.
Since a VA design is always working on the basis of a pipeline, that should be able to handle the full camera bandwidth, it is possible to make this a decision (based on a VA inserted binary flag or similar) in the related software process behind the VA processing.
-
Thank you for your positive feedback.
-
In the most current version I can not reproduce your reported irritation.
Please let me know if the newer version solved the issue.
