Posts by B.Ru

    Below you can see a simple VA design in order to check if the trigger is working as expected:


    BRudde_Paranoid.png

    BRudde_mE5MA_VCX-QP_Single_Capture.va


    The idea is to count the number of send line triggers versus the number of received lines.

    By this TriggerMismatch.Status should show a small value juming in between of 0 and 1 for low line rates.

    Only in case of special line scan cameras or higher line rates the plausible value is in between of 0 and N,

    where N is the amount of lines that is "stored" inside the camera or currently in transfer.


    In case of an area scan camera this will not work as expected, but it can be modified correspondingly:

    FrameEndToSignal, 2D links...

    Hi,

    i thought the direckt link from mr. rudde was the right one. I have visualapplets version 3.0.6, in the dokumentation is written that u could update it with gui by help -> update but there is no entry with update. How do i manually update it?


    best regards

    cn

    I answered this by an private message since we do not post VA download link here...

    Dear Pierre,


    In case you want to build for a mE5-MA-VCX-QP than you have to think of the different memory model of the marathon platform.

    The ironman platfrom is not using shared memory.


    Use the following example that is part of the VA installation:

    "%VASINSTALLDIR%\Examples\Acquisition\BasicAcquisition\mE5-MA-VCX-QP\Area\SingleCXP6x4AreaGray8.va"

    or here the version included in VA 3.1.1 for direct download:

    SingleCXP6x4AreaGray8.va


    The chapter in the VA documentation for shared memory.


    For a detailed discussion on other side effect of this please look into this different thread.

    Hi Pierre,


    There may be a second reason arising from the PCIe DMA performance of your test.

    You already mentioned that the DMA performance is capable of transferring

    (8 bit) * 4672 * 3416 * (148 Hz) = 2.36 GB/s

    So we can exclude the DMA performance.


    Did you try this VA design with the bandwidth optimized approach:

    BRudde_HIGH-BandWidth_CXP-Mono8-4672x3416+shading+bpr+gpi8.va

    or the still limited one:

    BRudde_CXP-Mono8-4672x3416+shading+bpr+gpi8.va

    from my last post?


    The VA design:

    BRudde_HIGH-BandWidth_CXP-Mono8-4672x3416+shading+bpr+gpi8.va

    is the one for higher bandwidth.


    Best regards,

    Dear Pierre,


    Please only instanciate the Input TriggerI of the CXP camera (link to documentation) for triggering the camera.

    If you want to select in between of two signals as trigger please use the Select operator (link to documentation).


    You can use the other inputs in order to send pulses to the camera, but the intended input for exposure triggers is TriggerI.

    Please make sure that the pulse length of these signals is ok for the camera. in case of too short pulses the camera may not react.

    Dear Arjun,


    Thank you for your question.


    The following design approach detects a signal at the external input and translates its rising edge into a single pulse.

    This single pulse is getting delayed in steps of one millisecond.

    Afterwards a new and fix duration is applied to it.

    In case of using the SignalDelay operator to directly applying the 10s delay it will use more than 11000% of the required FPGAs BlockRAM. By using a much lower clock at the input of SignalDelay it is possible with a minimum of ressources.



    PuselDelay.png

    VA Design as shown above: DelayPulseTrain_v1.03_B.Rudde.va


    You can easily copy it to any VA platform.

    Hi Jesse,


    Thank you for your feedback on this.


    You are right, there was a stupid error from my side in there.

    I forgot to modify the Infinite-Source Enable/Disable settings of the corresponding.

    Fixed in here and the older post above: mE5_MA_VCX-QP_Single_SplitImage_FIX_B.Rudde.va


    Nevertheless I would expect that that design would at least deliver some image data in microDisplay.

    Maybe the following setting is missing in your microDisplay configuration:

    B.Rudde_mDisplay_DMA_settings.png


    Setting the check box regarding Ignore Cam Clock Status to enabled/checked will help to start both DMAs while only a single camera is connected.


    Additionally theUse GenICam Parameters is disabled/unchecked, in order to avoid the camera settings being applied to the target memory buffer sizes.


    The above settings dialog is not affecting the runtime/SDK approach at all.

    Hi Pierre,


    A possible source/reason for the limited bandwidth is very likely related to the memory bandwidth in the H-Box Shading2D.


    The detail where the required coefficients are used is asking for a lot of data from a single RAM module on the ironman platform. In case the CoefficientBuffer(linked to VA online help) is used, we need to verify if the requested bandwidth can be delivered. In the documentation of the hardware ressources a bandwidth of up to 4 GB/s per RAM can be found for the CXP ironman.


    The camera is delivering:

    (8 bit) * 4672 * 3416 * (148 Hz) = 2.36 GB/s.

    The single CoefficientBuffer is requested to deliver:

    2 * 2.36 GB/s = 2 * (8 bit) * 4672 * 3416 * (148 Hz) = 4.72 GB/s

    Since we can "only" get 4 GB/s instead of 4.72 GB/s we have a limitation here:

    ((4.0 (GB / s)) / (4.74 (GB / s))) * 148 Hz = 124.89 Hz

    That is pretty close the the mentioned 122 Hz in your post and seems to me to be a plausible explanation for the limit you reported.


    Below you can see the single RAM that is requested to deliver 4.72 GB/s in practice, while the theory of the used links stated a higher bandwidth:


    R.Rudde_SYNC-CoeffBUffer.png


    So the option above is causing the limitation.

    Now we need a solution for this.


    Below two RAMs are used to get the coefficient data for the shading correction.

    It is using two RAM modules at full memory bandwidth by using the maximum bit-depth of 64 bit * 8 = 512 bit each and a FIFO with ParallelDN to meet the requested target bandwidth:


    R.Rudde_SYNC-Double-CoeffBuffer.png


    The modifed VA design can be found here: BRudde_HIGH-BandWidth_CXP-Mono8-4672x3416+shading+bpr+gpi8.va


    The requested bandwidth per memory module is now:

    (8 bit) * 4672 * 3416 * (148 Hz) = 2.36 GB/s

    and can be served by the hardware RAM modules in the ironman CXP.

    It are two RAM modules required, but there was one module left.


    Please give me some feedback if this solved your issue as expected.

    Thank you.


    ---

    Below a second, but minor topic is discussed:


    Below I removed an unnecessary SYNC.

    The SYNC did not affect the design in a negative way.

    R.Rudde_SYNC-Kill.png

    Modified VA Design without SYNC: BRudde_CXP-Mono8-4672x3416+shading+bpr+gpi8.va

    Hi Jesse,


    The dead-lock was indirectly caused by the ParallelDN's that were used in the odd/even line links.

    In case the data was coming in faster than the link properties allowed, data was not able to wait in the small FIFO buffers.

    That caused the design to loose data, leading to shorter and/or empty lines or images.

    Due to this the synchronization in between of the odd/even lines could not work properly/efficient and caused the mentioned dead-lock.


    The design below addresses the same result, but with a slightly different approach.

    Directly after the camera an additional ParallelUP is used in front of the RAM module.

    The ParellelUP is not really required, but enables a higher throughput in case one of the DMAs would stop the data stream for a short period of time. The RAM is now moved to the front. The SYNC is not required anymore since the odd and even lines are send to two different DMAs. The small FIFOs can still be found directly in fornt of the DMA operators.

    These small fifo's will take care of small stop conditions arising from the PCIe interface (DMA) and smoothen the data flow.



    SplitImage_MOD.png

    Modified VA Design above can be found here: mE5_MA_VCX-QP_Single_SplitImage_FIX_B.Rudde.va


    A second idea is sketched below, where only a single DMA is used to transfer the odd and the even lines next to each other:


    SplitImage_MOD_InsertLine_B.Rudde.png


    Here you can find the VA Design using the InsertLine approach: mE5_MA_VCX-QP_Single_SplitImage_MOD_InsertLIne_B.Rudde.va


    In case a single DMA transfer is sufficient and the data is accpeted within a single line you can use the approach below too:


    Simple_MOD.png


    This simple version of the VA Design can be found here: mE5_MA_VCX-QP_Single_MOD_Simple_B.Rudde.va

    As mentioned in our runtime help on Fg_getParameterProperty ...


    The required virtual parameter IDs are defined for RT 5.7.0 release as see below:

    If you have a look into the example source for the parameter iteration you can find the code below concerning the range details like Min,Max,Step for the value you would like to change.

    Please use our most current runtime version and the corresponding include files.

    Mixing different versions may lead to unwanted side-effects that potentially make debugging a pain.

    The frame grabber design needs some details on the forwarded image data.


    The VA design MOD_CXP-Mono8-4672x3416-synchro+trigger.va can handle changes of the received image size without further interaction. But in parallel it does not know about the real ROI being used.


    You can use our Parameter-Translation to make it a single parameter call.


    In case you apply the native ROI approach and the X-Length is larger than the reiceved image, then the image size is increaed automatically. This leads to a higher bandwidth that may lead to a unwanted backlog(back pressure).