Posts by B.Ru

Hi,

Thank you for the positive feedback on this.

FG_HEIGHT and FG_WIDTH are related to the target memory buffer size in software.

These values are independent of the DMA transfer itself and only interesting for software like microDisplay.

FG_HEIGHT * FG_WIDTH * bytes per pixel define the maximum amount of data that can be transferred into a ring-buffer element.

In real world applications these details are handled on the basis of meta lines or other sources for additional details.

In V-series projects many different approaches exist.

So FG_HEIGHT and FG_WIDTH are handled purely by software and should not get related to hardware.

But to make a useful add-on for a user you can calculate the required values for FG_WIDTH and FG_HEIGHT on the basis of parameter translations in VA and write these as intended values next to FG_WIDTH and FG_HEIGHT...

Thank you for your positive feedback,

Thank you for the updates out of the use case.

This is making the transition from theory to practice easier.

Download (MOD_CXP-Mono8-4672x3416-synchro+trigger.va), in there you can find a slightly modification of your VA design.MOD_CXP-Mono_FLEX.png

AppendLine combines the full image - independent of its size - to a single line.

SplitLine converts this line to small portions of image data that are independent of the input resolution.

The SetDimension DIRECTLY in front of the DMA gives a default to FG_WIDTH and FG_HEIGHT for software interpretation.

That default can be changed.

I did a quick review of your design and it is simply forwarding the camera image into two parallel ImageBuffers.

These ImageBuffers apply the X_Length set as parameter.

A workaround would be to use AppendLine and SplitLine to handle the image as pure block of data and send it to the DMA.

The DMA is handling all data as linear block and transfers it as linear block.

By this the flexible Y_Length is used of the real amount of data. Please be aware that this will produce some strange side-effects and you need to know the input dimension for correct visualization in the sofwtare part outside of VA.

In case you are using an ImageBuffer (SelectROI, or similar) you have to update the regions of interest (ROI) dimensions.

Especially the ImageBuffer requires a ROI update on the X_Length.

Y_Length is taken from the input image and not changed.

The ImageBuffer applies the X_Length set independent of the input width.

Hi Theo,

The shared memory concept provides a lot of benefits, but handling the higher paralleism is producing some unwanted side effects.

I would recommend to use FrameBufferRandomRead and pre-sort the parallelism data in advance in order to replace the ImageBufferSC.

You can also use a LineMemoryRandomRead is case it is only affecting the sorting of single lines.

You can hide the higher paralleism in the the bit-depth for the ImageBufferSC too, but that become kind of static.

Since you want to handle only two different modes I would recommend the following:

ImageBufferSC_Replacement.pngImageBufferSC_Replacement.va

The attched VA design includes the design of the screenshot below.

It is based in signal operators that decode an AB encoder signal at Mode X2:

The ShaftEncoderCompensate makes sure that ony forward pulses are used.

The DownScale selects the correct phase (=2) for A or B switching Illumination 1 or 2, while the diagram below shows 3 phases.

Signal analysis is only possible in the runtime and can be done on the basis of our Scope Operator.

ShaftAB_Illumination.png

The Scope enables a very precise analysis.

Thank you for your answer and the invested efforts.

In case a newer version is getting released you should find it with the link below:

Runtime Release Notes

Dear Jayasuriya,

Please check if this still happens with newer runtime version:

In case the newer runtime version is not a solution please contact our support@silicon-software.de
Thank you.

Hello,

Please use the

Sgc_* commands for configuring a CXP camera as shown in the screenshot above.

The Gbe_* commands are intended for GEV (GigE-Vision).

The Sgc_ C# Wrapper is explained in the runtime SDK:

C# SDK Wrapper : siso_genicam

The Gbe_ C# Wrapper is explained in the runtime SDK:

C# SDK Wrapper : gbe

Please be aware that several enumerators may be blocked due to a running acquisition.

For some cameras parameters the acquisistion needs to be stopped, since these can not be modified during an active acquisition. That is camera XML related.

Same for Gbe_setEnumerationValue function...

Dear Jayasuriya,

When you select the appropriate enumeration value in the GenICam-Explorer it will show the example code automatically below with the parameter info.

See screenshot for more details:

Ok, Thank you.

Ok, thank you

Hi Pierre,

Please calculate the expected performance of a link on the basis of its properties like parallelism 8 (P=8) and bit depth of 8 bit (B=8) and the defined system clock of 125 MHz (S).

In theory such a link provides up to 1 GB/s = P * B * S = 8 * 8 bit * 125 MHz.

How to calculate easily ...

ALL O-type, all P-type, MOST M-type perform at an efficiency of 100%.

Exeptions are:

Memory (ImageBuffer and friends) : in case of non-linear addressing

Memory (ImageBuffer and friends) for mE5 marathon : shared memory

DMAtoPc : mainboard/chipset related

All camera operators can only deliver at the used interface maximum speed.

Side effects of SYNC, InsertImage, InsertLine cause limitations and even deadlocks in case of wrong usage.

The VA "Bandwidth Analysis" is only usefull for very simple designs representing a single straight stream.

Hi,

The design itself is connected by parallelism 8 (P=8) at 8 bit (B=8) with the DMA using a system clock of 125 MHz (S).

In theory this provides up to 1 GB/s = P * B * S = 8 * 8 bit * 125 MHz.

In practice the DMA will work at a lower bandwidth due to certain overhead and the used mainboard chipset.

Here the number of connected PCIe lanes, the used PCIe Gen and the trained PCIe playload size are of interest.

Our runtime includes a driver that supports our DMA900 or DMA 3600 engine which in general tries to deliver the maximum possible bandwidth.

In case the PCIe payload size is >= 256 the bandwidth should be around 900 MB/s in case 4 PCIe Gen1 lanes are used.

If the PCIe payload size is < 256 the bandwidth will be less than 900 MB/s in case 4 PCIe Gen1 lanes are used.

A lot of additional and chipset related details would come into the discussion.

But to make this post short: A bandwidth of 640 MB/s may be related to a PCIe payload size < 256.

If you want to check this in runtime please consult microDiagnostics and look into the log on the start page: DMA.png

In this case we can see:

PCIe Performance: PCIe is highspeed capable

That is an indicator that the DMA engine can work at up to full performance:

PCIe x4 Gen1 = DMA900 ok = up to 900 MB/s possible

PCIe x4 Gen2 = DMA1800 ok = up to 1800 MB/s possible

PCIe x8 Gen8 = DMA3600 ok = up to 3600 MB/s possible

If the PCIe Performance is stated NOT highspeed capable the performance will be less.

PCIe x4 Gen1 = no DMA900 = less than 900 MB/s possible

PCIe x4 Gen2 = no DMA1800 = less than 1800 MB/s possible

PCIe x8 Gen8 = no DMA3600 = less than 3600 MB/s possible

I do not have typical PCIe performance measurements for this case,

but a bandwidth of 640 MB/s could be caused by a PCIe payload that is < 256.

But we have a performance test you can use in microDiagnostics:

Details on microDiagnostics : PCIe Performance Test

Those tests are related to different image sizes. Please check this for your case!

Additional reasons could be multiplexed/shared or less connected PCIe lanes.

A PCIe slot may support less PCIe lanes that the physical connector.

Or the design expects PCIe Gen2 but the mainboard only supports Gen1.

Hi Jayasuriya,

Thank you for the data.

In the GenICam XML we can see these two values showing the affected registers:

  <IntReg Name="ColorCorrectionMode_Value_ctrl" NameSpace="Custom">
    <Visibility>Invisible</Visibility>
    <Address>0x80023000</Address>
    <Length>4</Length>
    <AccessMode>RW</AccessMode>
    <pPort>Device</pPort>
    <pInvalidator>PixelFormat_Value_ctrl</pInvalidator>
    <Endianess>BigEndian</Endianess>
  </IntReg>

  <IntReg Name="Height_Value_ctrl" NameSpace="Custom">
    <Visibility>Invisible</Visibility>
    <Address>0x800230c0</Address>
    <Length>4</Length>
    <AccessMode>RW</AccessMode>
    <pPort>Device</pPort>
    <pInvalidator>BinningVertical_Value_ctrl</pInvalidator>
    <pInvalidator>DecimationVertical_Value_ctrl</pInvalidator>
    <pInvalidator>SensorHeight_Value_ctrl</pInvalidator>
    <pInvalidator>SensorOperationModeRaw_Value_ctrl</pInvalidator>
    <Endianess>BigEndian</Endianess>
  </IntReg>

This is not a solution, but you can use this additional detail to communicate with the XML/camera manufacturer and our support. If you want you can even modify the XML by your own and check/load it in our GenICam explorer in order to check.

0x800230c0 : Height_Value

0x80023000 : ColorCorrectionMode