Posts by B.Ru

Please update to the most currect VA release 3.1.2.

Simply contact our support team: support@silicon-software.de in order to get the download link.

Please post the version mentioned in the VA About box:

pasted-from-clipboard.png#

Thank you for this report.

Using your test VA design in VA 3.1.2 shows -35 before and -35 as a value after the CastBitWidth operator.

That yould be the expected behaviour.

What VA 3.0 version are you exactly using?

Here you can find a good starting point in our runtime/SDK documentation on the event functions.

In order to simulate the above VA design please insert an image longer than 1024 lines.

A longer image will force several output frames, each including a "last line" of 4 byte, representing a:

• 0xFFFFFFFF if it is the last image of the single gate image stream
• 0x0000000 in case of the first or intermediate image for transfer
• How it looks like in VA simulation:
  pasted-from-clipboard.png

Thank you for your detailed question.

Below you can find a single design giving the answer to 1. and 2.

VA Design LineScan_Context_Feedback_BRudde_v01.va includes all necessary details for determining the end of an 1D image stream on the basis of an added meta data flag (32bit flag):

BRudde_Line1D.png

Additionally you can register a software callback on the gate start/rising and end/falling edge if required.

Implemented in front of EventToHost operator.

After building an overlay bit, representing the last pixel of a gate, this flag is used as an appended meta flag of 32bit:

BRudde_Line1D_2.png

Therefore the whole flag bit image is reduced to the last pixel of the image:

BRudde_Line1D_3.png

In the Runtime/SDK folder %SISODIR5%\SDKExamplesNew\examples\fglib\Events\ you can find the c++ source code to access and register the required sofwtare callbacks:

      std::string eventName = selectEvent(mFgHandle->getFgHandle());
            uint64_t eventMask = Fg_getEventMask(mFgHandle->getFgHandle(),eventName.c_str());

            fg_event_data data;
            data.listener = this;
            fg_event_info info;
            status = Fg_registerEventCallback(mFgHandle->getFgHandle(), eventMask, EventCallback, &data, FG_EVENT_DEFAULT_FLAGS, &info);
            if(status != FG_OK)
                throwLastFgError();

            const unsigned int enable = 1;
            status = Fg_activateEvents(mFgHandle->getFgHandle(), eventMask,enable);
            if(status != FG_OK)
                throwLastFgError();

Please enjoy

Thank you for giving feedback on this.

Here in the C# wrapper documentation it is mentioned that the void* type is changed to SisoImage.


SisoImage.toByteArray(uint imageSize)

The above function is mentioned at the end of the page, but will give you the byte array representation.

Based on the byte array it should be possible to create a openCV Mat / Image without copy.

Quote from cwalker888

... But the Coordinate_X(Y) images are 2D images and the COG_X(Y) data is 1D. Any suggestions on this one?

Writing all COG X/Y coordinates found by a BlobAnalysis_2D directly into an artificial image is not possible so far. The output of the BlobAnalysis is a list of object features, where the COG's are not sorted by X/Y position. Since these list entries as a result of a of a BlobAnalysis are not sorted it is not possible to reconstruct an image on this basis, because the image is produced linearly: pixel by pixel and line by line, starting at the top left corner.

To solve this it would require a kind of memory. As long as the COG X/Y coordinated describe a small image the operator Histogram can be used. Use CreateBlankImage and SyncToMax to resize the object list to the target resolution and use Y coordinate as MSBits and the X coordinate as LSBits and scale the output into a 2-dimensional image using SplitLine. This will only work in case the required X and Y bits for the ranges are equal or less than 16 bit: That is the maximum number of bits for an histogram.

This would mean that the required resulting image size is 256x256 or less.

Example VA design for that idea ( source RegionCounts_COGxy_BRudde_v02.va ) :

pasted-from-clipboard.png

You can simulate with your image and check the result.

Since the maximum resolution is 256 * 256 pixels in this case, please have a look into the H-Box (norm_COG_XY_List) to see how the area of the oject is used to normalize the COG coordinates and limit these to 8 bit value range:

pasted-from-clipboard.png

Dear Pier,

As far as I understand your request it is very likely that the mismatch of the stamps in between of the line-trigger-counter and the real line-sensor-data is caused by the latency/delay of the GEV transfer.

In order to double check you can connect the line-trigger to the grabber and measure the mismatch in between the triggers and the GEV data being received.

Best regards,
Björn

Please contact our support department support@silicon-software.de for this.

Since this is a GigE Vision (GEV) camera the data transfer into the grabber can not be exactly synchronous to the real increments of the encoder. In GEV the pixel/line/image data is split into several packets and transferred asynchronously to the sensor exposure.

You can build the COG (X/Y) using Coordinate_X(Y) in the same manner.

Please use the operator RowSum togehter with ColSum for the basic functionality.

The design below is showing the basic details of the requested algorithm.pasted-from-clipboard.png

Download VA Design: RegionCounts_BRudde_v01.va

Dear Ryuji Narita,

My first idea would be to use the VA design below (VA design, download Acq_Test02_VCLx_BRudde_QuickFix.va ) :

pasted-from-clipboard.png

This is only a quick guess, but it may be a solution.

From my point of view, two small FIFOs were missing in order to avoid a dead-lock condition.

These FIFOs have the name MiniBuffer_A/B.

Please tell me if this is a valid fix, because I could not find the time to investigate in runtime.

My recommendation would be to modify the processing behind the Blob Analysis in a serial way, on the basis of the mentioned operators in the previous post.

Dear Lily,

Thank you for your interesting request.

You mentioned "we can get them" concerning some of the details.

If that does mean that you already have some VA sources for this, can you please attach these to the thread here?

That would help me adding the requested details to an existing VA design.

If you need Max_n for each Pixel n per line, you can use ColMax operator.

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.

Thank you for your feedback.

This thread is now marked as closed, but in case of questions do not hesitate to re-open or post into it.

Dear Ryuji,

In case your design requires multiple images that are acquired during a period that is longer than the pre-set acquisition timeout you need to increase the acquisition timeout in microDisplay:

pasted-from-clipboard.png

more Details in microDisplay documentation section 2.5 linked here.

Dear Ryuji,

Please send or attach a valid image for simulation.

Instead of using a MultiInput-Sync you can serialize all the data and investigate the stream instead.

That would require much less ressources and will not cause a dead-lock in case of un-expected data.

After the Sync you are using an ADD on the synchronized inputs, it is possible to use a FrameSum, RowSum or Count operator instead. I would recommend the FrameSum.

Dear Arjun,

The MultiPulse-Mode of the SignalDelay is of static character:

the number of delay ticks is fixed after synthesis.

SignalDelay in MultiPulse Mode will not reproduce the duration as expected in case the Tick input is downscaled.

So it is recommended to use only the edge ( SignalEdge ) and apply the duration later.

The possible/supported Delay duration itself is based on the Tick frequency applied.

If using 10bit(can become more) for example, 1023 delay ticks are possible.

Using 1000 pulses at tick input frequency 1 kHz will delay exactly 1 second.

If you present f_input = 4 Hz, the output frequency will be 4 Hz too, but delayed by the amount of ticks, where tick = f_tick.

f_input can be delayed by the precision of f_tick.

So if you want to use different delays you can modify f_tick during runtime instead of the SignalDelay delay parameter.

f_tick is normally generated by Generate operator.

The pulse width in the sketch below is not valid in case of a tick frequency below system clock.

So please only use the rising edge of the pulses and not as shown below: