atto-Systems OODGoto atto-Systems OOD

FAQ : Frequently Asked Questions ...

Sorry for the poor style, but we need to be able to edit this easily in order to use our time for support and not for webdesign :) ...

We are still collecting. So if you have a VIMOS-related question without an answer in the documentation or on this page send an eMail to :


Is there a way to binarize an image ?

Yes of course there is a tool for binarization. It’s called ‘Find blobs’ tool,
because in the ‘Connected’ mode it does object segmentation. However if you
only want to binarize the image you better use it in ‘Unconnected’ mode and
select ‘Destructive’. Now everything with a brightness between the two
thresholds gets one color and the background gets the other color you specify.

You can combine ‘Destructive’ and ‘Connected’ if you want to exclude certain
objects from the foreground color. If you use the connected mode and specify a
minimum and a maximum size only objects with a fitting size get the foreground

You may also want to have a look at the ‘Watershed Segmentation’. And then
there is a ‘Simple binarization’ feature within the ‘OCR’ tool ...


How can I mask out parts of the image ?

There are some ways to do this. To quickly fill a rectangle with a given color
use the ‘Find blobs’ tool in ‘Destructive’ mode, set the upper threshold to
256, the lower to 0 and set the two fill colors to your desired color.

If you need a freeform mask you can draw it black on white as a PC bitmap and
upload it to the camera as an image area. During the first cycle of the user-
program load the file and copy the area to the second image (freeze buffer).
Now you can use the ‘Image area’ tool to make an ‘AND’ operation between the
mask in the freeze buffer and the image in the frame buffer (main image).

In some cases it may be usefull to use the pointlist tools. Fill the pointlist
with the coordinate of all the points of your mask. Now you can translate and
rotate that part of the pointlist quite quickly. So if you know where your
object is and how it is rotated, you can do the same with the coordinates in
the pointlist and then draw the pointlist content at the actual location. This
could help with the rotation of freeform masks.


Are there differences between the simulation and the real camera ?

There are some differences :
The Simulator has always all tools, but the real cameras do not. The VIMOS for
the small sensor cameras is divided into a main module and additional modules
with part of the tools. Depending on the size of the flash memory more or less
modules can be loaded, so more or less tools are available. However the sensors
are based on the normal cameras with ADSP processors and these cameras do not
have some of the tools (i.e. Median filter, Object Recognition, ...). The new
cameras based on the TI processors have the most complete list of tools, but
only color cameras support the color tools ...

Another difference between PC and camera is the execution speed. Because of
different hardware and optimized software sometimes the cameras are much faster
then the PC and sometimes it’s the other way ‘round. Execution speeds are
different between cameras too. The small sensors and the ADSP based cameras
often have to switch between modules, which slows them down, but some tools are
highly optimized and running fast. The TI cameras load the whole VIMOS as one
module which is the reason for the delay at startup and are generally much
faster because of their powerfull processor. If you have a project that
requires high execution speed please have a look on our speed tables for
orientation. On the ADSP cameras keep in mind, that there may be additional
delays that you will have to test on a real camera.

On the PC the Simulator normally uses the harddisk to read and write files.
That is good for testing, but on the camera the permanent menory is a Flash
EEPORM. That kind of chip is not overwritable and whenever the camera writes
a new file the memory is filled until it is totally full which is a real
problem. Therefore don’t write user-programs that write a lot to the Flash.
They will run on the PC, but not on the camera. To improve the situation we
have added a new tool that allows the deleting and packing of the Flash, so
that you can continously save certain configuration data after you deleted the
older version of the file(s). On the TI based cameras (VC20xx) VIMOS is able to
use the MMC (Multimedia Card) which has its own file management and is able to
return unused memory to the user.

Yet another difference between the ADSP based cameras and the PC simulation is
the available dynamic memory for some tools (i.e. Find blobs). It is possible
that the tool runs on the PC, but can not cope with a complicated situation on
the camera because of missing free memory. The only tool where this happens
regularly is the ‘Find blobs’ tool when ‘Connected’ mode is selected and there
are too many objects (several hundred). This happens when there is noise or
dust in the image. You could try to use a ‘3x3 filter’ or an ‘Area tool’ with
‘Subsample’ to minimize the number of small objects.


What are the basic configurations for the use of VIMOS ?

The most simple situation is where you have only one camera which is controlled
through its PLC-inputs and returns status information and results through its
PLC-outputs. That way the serial interface of the camera is not used, so you
can always connect a laptop and configure the program, take images and so on.
The camera can be one of the small sensor cameras VCM40/M50 if you don’t need
high image quality, full resources and video output, or it could be a bigger
camera for precise measurments, graphical display, more memory, higher speeds
and better connectivity.

In some cases the PLC-lines will not be enough and you’ll need to use the
serial interface of the camera for communication with the PLC or other
hardware. That’s no problem with the sensor cameras because they don’t have
mouse control, but on the bigger cameras it’s possible by selecting ‘Other I/O
device’ and baudrate in the configuration (simulated camera on the PC) before
you save the user-program. Configured in such a way the camera will normally
use the serial port for communication and not receive mouse control. To force
it back to mouse control restart the camera with connected mouse and move the
mouse just a bit when the version information is displayed at startup.

The next possible configuration is to connect two cameras with their serial
ports, so that they can exchange information. It is even possible to connect
more then two cameras when RS232/485 adapters are used. So a network of cameras
(and a PC) can be build. At the moment we add support for Ethernet to the
bigger cameras that will improve things further.

An other aspect of possible configurations is the use of a touchscreen and/or
serial keyboard with trackball on a secondary connector of the bigger cameras,
so that the primary serial port (or Ethernet) remains free, but the user can
still fully control the camera or camera network.

Finally the serial port (or Ethernet) can be used to access additional inputs
and outputs - at a much lower speed then the build-in periphery of course.


How do I get images from the camera ?

There are many ways, but let's mention some of them ...

1. In the VIMOS Simulator in the menu go to /Camera/Camera Files Functions.
   There is a 'Picture' section where you can set the shutter and then
   capture images. First you need to make a connection to the camera.
   If it is not running any program and you know the baudrate, just select
   that baudrate and then click on 'Find camera'. If you don't know the
   baudrate, select 'Auto find'. If the camera is running a program, that
   is started automatically after power on, the easiest way is to set the
   right COM: port and then click on 'Wait boot'. Now you need to switch
   the power to the camera off and back on. Click 'OK' on the messages
   and then you should be connected to the camera. Before loading images,
   you should select the highest baudrate at which your PC communicates
   with the camera without errors. That depends on the length of the
   cable and on your PC.
   This method of taking images is easy, but has the disadvantage of using
   JPEG image compression, were you can not adjust the compression level.
   The other drawback is, that you can not trigger the camera from a PLC

2. Write a small VIMOS program that captures the image and use the VIMOS
   Recorder software to record the images that your program sends to the
   PC harddisk. You should use the 'Send image area' tool to send a part
   or the whole image. To be able to send data, you need to switch the
   mode of the serial device to 'Other I/O device' in the configuration
   of the VIMOS kernel. You can do this in the Editor in the properties
   dialog of the program (menu:/File/Properties) or in the VIMOS kernel
   (Simulator or on the camera) in the main menu in the 'Configuration'.
   There you should also select a reasonable baudrate. If you have been
   using the mouse on the camera (i.e. Edit mode), then you need to
   restart the camera (Exit the camera-VIMOS normally through the menu).
   After VIMOS has started without the mouse (Simulator not connected
   to the camera anymore) your program should be executing and sending
   images over the serial port. Now the VIMOS Recoder program on the
   PC can receive them.
   The advantage of this approach is, that you can send the images in
   exact the same way you can later use them, when you have finished
   writing the VIMOS program. You can use the same way to trigger the
   image capture and you can apply image processing before sending, i.e.
   the preprocessing. You don't need to send the whole image, but only
   the important part which will be faster. And you can define the
   quality of the image, so that you can decide if you need speed or

3. We offer a similar Recorder program, that does not capture VIMOS
   images, but works with its own small camera software. That program
   allows the user to adjust the shutter and compression level in the
   Windows dialog and then records all images coming from the camera.
   It is also possible only to display the images (live mode). The
   part on the camera is able to be triggered from the first PLC line
   or to work in freerun mode. Please ask us about that software.


How do I get text into VIMOS (the string buffer) ?

VIMOS handles only results, points and angles directly as tools arguments and
tools results. In the Editor you meet them as int, float, point and angle.
The 'int' comes from the statistic counters. Normal tools results are always
'float'. It was our goal to keep the number of different types of arguments
to a minimum in order to save precious system resources.

Therefor there exist some other global buffers to handle other types of data.
The 'Pointlist' can take items like contours, lists of objects (blobs) and
can also be used as a global scratch buffer (storage for global variables).
The 'String buffer' handles strings. Most tools that produce strings or take
them as input data work with the 'String buffer'.

It is just an array of 10000 characters. Normal write operations take a start
position and maximum length and they return the count of characters written
to the buffer. For instance you can tell the OCR tool to write its result at
position 1000 and to write a maximum of 100 characters. Then the OCR tool may
read "A B C" and will return, that 5 characters were written - 3 letters and
2 spaces between them. So after the end of the OCR tool cell 1000 will contain
the letter 'A' and cell 1004 the letter 'C'.

Inside the buffer the characters are ASCII coded.

Strings have two major purposes. On the one hand they can be the result of an
image processing tool like OCR or Barcode reader. On the other hand they can
be used for some display in the user-interface of the VIMOS program. All the
GUI tools for example take the text they display out of the 'String buffer'.

So in order to display some message to the user you need to fill the buffer
with text. The same is true if you want to realize some ASCII based serial
protocol. For instance the user could get messages, that he can see or answer
on a terminal program.

Let's devide the text into static text and dynamic text. The static part stays
always the same, but the dynamic part is generated dynamically, i.e. as the
result of some image processing tool. So we need to think only about the static

The easiest way to get text into the 'String buffer' is the 'Load string' tool.
It takes a file from the Flash memory, Multimedia card (MMC) or the harddisk
and loads the content into the buffer. That can be done automatically when the
VIMOS program is loaded. The option is located within the VIMOS configuration
under 'General purpose ...'. Normally the file str0.vm is loaded if that had
not been changed by the user. Later, during the execution of the VIMOS program
you can use the 'Load string' tool.

So what you need now, is such a string file and the right content within it.
There are three major ways to get that :

1. You can use the 'VIMOS String file Editor', a Windows application that you
   can download from our website. You get a short help screen when the program
   is started.

2. You can use the 'VIMOS String Converter' a command line tool that you'll
   find in your VIMOS/Simulator directory (Strc.exe). Its use is described in
   the chapter '6.1.2. String compiler' of the 'Tools Description' help file.

3. You can generate such files with the VIMOS kernel when you use the 'Save
   string' tool. In that case a given part of the buffer is stored to the disk,
   Flash or MMC and you have your file. Such an approach is not very usefull
   for normal help strings or so, but can be usefull if you want to generate
   a string with some kind of algorithm.

In general when something is not working, please check :

1. The string has to be in the buffer, so it should have been loaded before.
   That could have been done when the VIMOS program was started or when the
   'Load string' tool was executed. A special case is the Simulator when you
   call it from the Editor with a tools 'Edit in Simulator' option from the
   tools context menu. In such a case the Simulator is 'kick started' into
   the 'Edit mode' and you get placed directly into the menu that allows you
   to configure that tool. Therefor NO 'Run mode' is ever executed and your
   'Load string' tools were not called, so that the String buffer might be
   empty (or contain other data). Then your GUI would look strange. We have
   now at least implemented an auto-load of the string file that is given
   in the /Configuration/General purpose. So IF you have enabled that and
   IF that string file is present, then you get it loaded even in that case.
   The other way to get things straight would be to call the 'Run mode' just
   once until your strings were loaded.

2. In order to load a string file it has to be in the Flash, MMC or harddisk.
   So make sure, the file is really there. To work in the Simulator, the
   str?.vm file should be in the same folder as your VIMOS program.

3. The file must contain what you expect :) ... You can check this by placing
   a button on the screen (in Edit mode) and setting the right start location
   of the buttons text (label). If you don't see your text, its not in the

4. Make sure, your text is not overwritten after you loaded it. For instance
   it would not work to load the label of a button from file into location
   1000 of the 'String buffer' and to then execute an OCR tool to the same
   location. The OCR would just overwrite the label and the next time the
   button is displayed it would show the text that the OCR did read ...

   To avoid such situations I recommend that you keep a list of used locations
   in the buffer (same applies to the pointlist). That list should be a comment
   at the top of the program file in the Editor.

Exceptions :

There are currently (at least) two tools that have strings as their internal
parameters - the 'Textbox' tool and the 'Compare string' tool. While these
tools are usefull in the way they are, they are also historic exceptions to the
concept. In other words - they should not be there. But when the Textbox was
implemented, there still was no 'String buffer'.

To fill the strings arguments of these tools you need to use the Editor. There
you can directly enter some static text into these tools. please note, that you
can NOT export that text argument as a public parameter of some subroutine.

While these text arguments provide a nice shortcut for simple programs, they
are also against some VIMOS mechanism. If you plan to create a big project,
better use the 'String buffer' alternatives. The 'Compare string' tool does
have a switch that allows you to use the 'String buffer'. The 'Textbox' can
be replaced by the GUI 'Edit' tool in most cases.


Why get some 'End' tools disconnected after I call 'Update in Editor' (F6) ?

The 'End' icons you place in the Editor are not tools in the true sense of the
word. They are just a representation of a logical jump the end of the program.
There is only one such end and until now (Jan.2004) after calling that function
all arrows would point to the first 'End' icon in the program. To improve the
situation, we have now changed the algorithm, so that every arrow that goes to
an 'End' goes to the closest 'End' icon to its starting point. That should work
in most cases, but if you have made a diagram were another 'End' is closer to
an arrow then the 'End' it was originally connected to, then that arrow will
cut corners and jump to the closer 'End'. The same may happen, if the distances
are equal. In such cases please delete one of the 'End's or move them a bit.
Sorry for the inconvinience.


What's .err ? How to use it ? How to detect tools errors ? Why is the program
returning a good (the last) result, when actually a tool failed ?

The .err 'version' is normal to most results. It's the error-flag. You can
check if the tool performed successfull by checking, if the .err is zero.
If not, you have an error. You can even make a switch depending on the error
you have got (i.e. edge not found).

A costumer wrote :
> Err 9001 is returned by edge detection (number of edges) when no edge is
> found: how can it be tested against a "real number" of found edges? I wanted
> to detect when more than 1 edge were found, and it didn't work because when
> NO edges were found the result was still detected as bigger than 1 !

Answer :
Please use the .err part of the result and check if it's zero. So the IF tool
would have the form :

IF ((R1>1) AND (R1.ERR==0)) ... then you have more then 1 edge ...

This is a general thing, so I'll explain it a bit ...

In VIMOS the tools 'own' their results (like global variables), so every result
of every tool always exists. If the tool is not executed, the results stay the
same. So that for instance if you execute an edge-detect only once (1st cycle)
and use the resulting point down in your program every cycle you always 'have'
this point.

BTW: The (.err) error information is handed down from tool to tool. So if a
tool produces an error and another tool uses its result(s), then that other
tool will produce the same error - and so on. So you can only get a valid
final result (with .err == 0), when you go through the 'Pointlist' or other
global storage like the 'String buffer'. For instance if you use an OCR tool
to read a string and write it to the 'String buffer' and you then use the
'Compare string' tool to compare that string to something you expect, then it
is possible, that in the first execution cycle the OCR reads the right string
successfully and you get a good result, but in the next cycle the OCR failes
(can not read anything). Then the 'Compare string' tool would still read the
string from the first cycle out of the 'String buffer' and would still produce
a good result, because the content of the 'String buffer' was not overwritten.
To avoid this, the .err part of the OCRs 'length' result should be checked. In
the described case that would eventually happen anyway, because normally you
would link that 'length' result to the 'length' input of the 'Compare string'


Blob / Edge detection 2 / Contour tool seems to return / displays wrong results
or seems not to get displayed at all.

These tools (and maybe others) store there results in the Pointlist. In VIMOS
tools execution is devided from tools display (overlay drawing). First one
cycle of the program is executed, then the tools overlay drawings are drawn.
The reason for this behaviour is to achive the same time delay for a tool in
each cycle (were possible). For instance an 'Edge detection 2' tool may seek
edges in a 400x300 window on 300 scan lines. If may find 2 or 2000 edges, but
the execution time will not be much different in both cases. On the other
hand the drawing of 2000 little crosses takes some time. Now assume, that after
the edges are detected a second image is taken for some reasons. And assume,
that the part in front of the camera is moving ... Then you see, why you may
want to delay the drawing of the crosses.

But there is a side-effect of this approach. If the result of a tool gets
changed during the execution phase more then once, then only the last result
gets displayed in the overlay. There are two major ways for that to happen :

1. The tool is executed in a loop. In that case it gets drawn only once in the
   end of the cycle and it is drawn in the state of its execution during the
   last cycle of the loop. Such a loop is created by GOTO -> LABEL tools.

   If you need to get all the drawings, you may consider to place the tool(s)
   into a subroutine and call that subroutine within the loop. That will
   force the drawing directly when the subroutine returns - every cycle.

2. The tools data is overwritten. That can only happen for tools that store
   their results in global buffers (i.e. Pointlist, String buffer). When the
   tool has written its results and then another tool overwrites the same
   location of the buffer before the drawing, then the drawing routine of the
   tool is taking the other tools results as input and draws things that have
   never been produced by the original tools execution. For instance a blob
   tool may display blobs outside its region of interest (ROI). You may be
   forced to use the same part of the global storage for more then one tool.
   In that case better switch off the first tools display inorder not to
   confuse anybody (including yourself) by the wrong drawings. You should also
   note that condition in a comment in the Editor file of your program.

BTW: The 'Pause' tool, when in the 'Wait click' mode, also forces an immediate
drawing of all tools before it so that you can see the results of the tools.
In the 'Wait time' mode no such drawing is done.


How is overlay managed (displayed, erased etc.)?

Each tool creates its own overlay drawings, but the drawing is done for all
tools after the execution of all tools, or when a 'Pause' tool is reached. So
the VIMOS main-loop starts with checking the serial port, eventually taking a
new image (if selected), then executing the tools, then drawing the tools ...
then the next cycle ...

As mentioned the exception is the 'Pause' tool. In the 'Wait click' mode it
draws all tools before itself.

You can 'hide' some of the tools, so that they are not drawn. Then they may
perform better (faster) ... (Right-click on the icon in the Editor) ...


How can I setup a Wait loop for image taking that captures when an input rises
(real camera) or when mouse button is clicked (simulation)?

Easy ...

LABEL1 --> GET_I/O --> BUTTON --> IF ((I/Ox=1)||(BUTTON_EVENT==3))
                                 YES --> TAKE PICTURE
                                 NO --> GOTO LABEL 1

Note however, that this is not the fastest possible triggering. So if you have
fast moving objects in front of the camera, they may have moved past ...
In such a case you need to use the special trigger modes of the 'Take picture'
tool. The 'Wait for (IN0==1) or (IN0->1)' modes can be used in the Simulator as
you can set and reset IN0 by hitting 'ALT+1' on the keyboard. If you don't do
that, the Simulator will hang at that point. Currently there is no way to
simulate the 'Wait for Trigger' option in the Simulator.

Additionally :
In case of missing trigger event the system may hang. A reset trigger (IN3 = 1)
breaks the wait loop. The sensor cameras (VCM40, VCM50) have two PLC inputs IN0
and IN1 - in this case the reset trigger is IN1 = 1. The wait-trigger loop is
also broken when the camera receives data through the serial and keypad ports,
i.e. from a mouse or touch-screen.


How can I erase something written with a 'Textbox' tool?

The 'Textbox' has 3 fields. the 1st and the last are static, the middle is
connected to a result, angle or else and depends on that result (number).
Since the whole overlay is recreated every cycle of the program execution, you
simply should exclude the 'Textbox' from the execution ... like this :

Tool X --> IF (tool x error) Textbox ('ERROR')
           ELSE              Textbox ('GOOD')

Always only one of the two messages will be displayed ...


Can I display a tool only when it failed or only if it was successfull ?

Well, not directly, but you can create that effect if you add the same tool in
an IF (error) ... structure and switch of the drawing of the original tool. Of
course duplicating the tool will change the execution time, but drawing it will
do the same (with smaller impact) ...

Example : Edge detect <don't draw> --> edge_point
         IF (if edge_point.err) // error happend during edge detection
           Edge detect <draw>   // the same Edge detect, but only for drawing
         ELSE                   // no error happend
           use edge_point for something


How can I do a loop like: Find blobs - For all found blobs display a Text Box
showing area and a marker on center of mass ?

Please have a look above at :
Blob / Edge detection 2 / Contour tool seems to return / displays wrong results
or seems not to get displayed at all.

As you can see there, you could solve that by placing the text output into a
subroutine. Please read to the end of this answer, because you can not use a
'Textbox' (see below).

Without subroutines you could only get the effect if you place for instance 20
'Textboxes' in your program and display only that part of them that is needed
at the moment. Of course that will become unpleasant if you have too many

Example : Find blobs --> place results in pointlist from index 1000
                     --> number_of_blobs
         IF (number_of_blobs.err == 0)
           IF (number_of_blobs >= 1)
             Get Pointlist item [1000] --> point1
             Marker at point 1

           IF (number_of_blobs >= 2)
             Get Pointlist item [1001] --> point2
             Marker at point 2


           IF (number_of_blobs >= 20)
             Get Pointlist item [1019] --> point20
             Marker at point 20

OK, I agree that this is not nice. Better use a subroutine :

         Subroutine Marker
           Marker (public point)

         Main program :

         Find blobs --> place results in pointlist from index 1000
                     --> number_of_blobs
         IF (number_of_blobs.err == 0)
           Set Pointlist parameter [500,0] = 0 // init helper variable count
           LABEL 1:
             Get Pointlist parameter [500,0]              --> count
             Calculator (1000 + count )                   --> current_index
             Get Pointlist item [current_index]           --> point
             Subroutine Marker (point)
             Calculator (count + 1)                       --> new_count
             Set Pointlist parameter [500,0] = new_count
             Calculator (number_of_blobs - new_count)     --> remaining
             IF (remaining > 0)
               GOTO LABEL 1:

Note : You'll find, that you you'll not be able to use a 'Textbox' tool within
the subroutine, because you'll not be able to declare the 'Text_2' parameter
'public'. That is, because that parameter may be of type string and strings
can not be public arguments of a subroutine. In order to overcome that, you can
use a 'Number to string' tool and a 'Show string' tool within the subroutine
(instead of the 'Marker' in the example above). The first tool writes the
number into the 'String buffer', the second displays it from there.


Why do I get a black image when I load an image from the 'Freeze buffer' ?

The Freeze buffer is the second image buffer in VIMOS. You can access it mainly
by two tools - the 'Copy image' tool in the 'Other tools' section for transfer
of whole images between both buffers and the 'Image area' tool in the 'Image
processing' section, that gives lots of different operations between sections
of one or both buffers ... The normal image is called 'Frame buffer'. So if you
did not write anything to the Freeze buffer you should expect a black image ...


Why don't I get a contour, when using the blobs 'edge_point' ?

You probably have a bright blob on a dark background. The starting point of the
contour-following has special requirements :

- needs to be dark
- needs to have at least one bright neighbor
- should not have 8 bright neighbors

(dark and bright in respect to the threshold)

Since the 'Edge pixel' of the blob is within the blob, it gets the 'blob'
color, when you use destructive mode. So in order to use it as the starting
point for the contour following you need to make the blob darker then the


Some details about the 'Send image area' tool and the serial protocoll ...

[Note: This is something I wrote for some project. It may not cover the whole
 area, but should give a lot of usefull information, if you want to write your
 own program that communicates with VIMOS.]

I have configured the 'Send image area' tool to do ASCII transfer, 75% JPEG
quality, no blocks and checksum checking ...

The tool first sends the header, waits for the second byte of the checksum as
an answer from the receiver (you can just send back the last byte you get from
the header, or you can calculate the checksum and send what you got).

After receiving the checksum, the tool sends the image content and at the end
you have to confirm the checksum again ... That's it. I'll add all the data-
formating below ...

You can do this by hand in the terminal ... After the tool is called you'll
see the header. Enter the last two characters (they represent the second byte
of the checksum in ASCII hexadecimal) ... after receiving this, the camera is
going to send you all the image data ...

Note : The camera sends the header max. 3 times - about once a second. You need
to answer with the correct byte of the checksum right away. If you don't answer
the tool stops after the 3rd time it sent the header.

Example [Note: In the project 'getimage' invoked image transfer] :


This would be 3 times the header without you responding with 18 ...

Note : I have inserted the line-feed after each header, the camera is not
sending a linefeed, but makes a small pause of about 1 second between the
3 headers ...

Example, when you answer correctly (sorry for the long mail):

Answer 18 (header) and D3 (end) ... otherwise img repeated 3x

FFDB004300080 ... D3

Send Image area data format :

2 starting bytes encoding the coding scheme :

       - 0xAA, 0x55 (ªU) for ASCII  transfer or
       - 0x55, 0xAA (Uª) for BINARY transfer

Header (bytes):

       - image dx MSB, example: ( img.dx >> 8) & 0x00ff
       - image dx LSB, example:   img.dx & 0x00ff

       - image dy MSB
       - image dy LSB

       - size of jpeg, example: ( long )size >>= 24;size &= 0x000000ffL;
       - size of jpeg, example: size >>= 16;
       - size of jpeg, example: size >>= 8;
       - size of jpeg, example: size &= 0x000000ffL;

       - send encoding (encoding & 0x00ff)
       - send bpp (bpp & 0x00ff)
       - send reserved1&0x00ff
       - send reserved2&0x00ff

       - send block size MSB  (blocksize >> 8) & 0x00ff
       - send block size LSB  (blocksize) & 0x00ff

       - send checksum flag ( checksum & 0x00ff )

       - send wait time in mS, MSB (wait >> 8) & 0x00ff
       - send wait time in mS, LSB (wait) & 0x00ff
       - send checksum first byte &0x00ff
       - send checksum second byte &0x00ff
       * The checksum consists of 2 bytes and includes all header's bytes
       * checksum_first_byte  += (send_byte) & 0x00ff;
       * checksum_second_byte ^= (send_byte) & 0x00ff;

       If the 'wait time' is > 0, the sender will wait for an answer,
       otherwise it will start to send the next data.

       If the 'checksum_flag' is == 1, the answer must be equal to the
       checksum_second_byte. If not, the sender will repeat the header
       data (in total 3 times, then quit).
       If the 'checksum_flag' is == 0, the answer can be any byte.
Send JPEG data ( included JPEG header ) :

       The data is divided into blocks of blocksize.
       Last block may be less (?).
       If the 'wait time' is > 0, the sender will wait for an answer
       at the end of each block.

       If the 'checksum_flag' is == 1, the answer must be equal to the
       checksum_second_byte of the block. If the answer is not correct,
       the sender will repeat the block (in total 3 times, then quit).
       If the 'checksum_flag' is == 0, the answer can be any byte.

Example :


Starting bytes :
ªU       - 0xAA 0x55 for ASCII transfer

Header :
03FC     - dx (0x03FC = 1020)
02F8     - dy (0x02F8 =  760)
00003FC1 - size of JPEG (0x00003FC1 = 16321)
01       - encoding (0x01 means JPEG encoding, 0x00 is bitmap)
08       - bpp (8 bits per pixel)
0000     - reserved
0000     - blocksize of transfer (0x0000 means 'no blocks', send all)
01       - send checksum ? 0x01 = YES
03E8     - sender waits for 0x03E8 = 1000 ms = 1 s for checksums
EE18     - checksum of the header (they are two different checksums):
           03+FC+02+F8+00+00+3F+C1+01+08+00+00+00+00+01+03+E8 = 3EE -> EE
           03^FC^02^F8^00^00^3F^C1^01^08^00^00^00^00^01^03^E8 =  18 -> 18

Then comes the image itself with the same checksums at the end ...


What about the echo of the 'Receive string' tool ?

That tool is intended for human use. Computers would normally transfer data by
using 'Send/Receive pointlist' tools, but of course they CAN use the 'Send/
Receive string' tools too.

Because humans would probably use a terminal program to communicate with the
camera, the camera returns everything that the 'Receive string' tool receives.
That is called echo. It's also a good way for the operator to see, that his
data is really ariving somewhere. For instance if you type 'getimage<ENTER>',
the camera (more precise the 'Receive string' tool ) returns :

     67 65 74 69 6D 61 67 65 0D 0A
     g  e t  i m  a g  e \r \n

Note: When you have a 'Send String' tool communicating with a 'Receive string'
tool, the echo response from the receiver will get into the serial receive
buffer of the transmitter. If more then about 60 characters are transfered,
that receive buffer will overrun. You can let the receiver check the echo data
(compare it to the data he sent) or let him delete the receive buffer after the
'Send string' operation. Use the 'Clean receive buffer' tool for that purpose.


The regions of interest of some tools seem to get moved by a pixel.
Some drawings seem to be a pixel away from were they are expected.
Why is that ?

As it is, we use some speed optimized libraries and some of the optimizations
require, that a tools region of interest (ROI) is located at an even starting
adress (word boundary). That leads to an even horizontal location. The same
applies to some overlay drawing functions. So small deviations can happen, but
that should not have any influence on the precision of measurement results.


I have used tools for serial communication and configured the Simulator to use
an existing COM: port of my PC. I have also configured the serial device in the
VIMOS configuration to 'Other I/O device'. After starting my program in the
Simulator it hangs ... Why ?

Your program expects input from the serial port ! It is waiting for such input.

Therefor the Simulator must hang until you send something. Since the simulation
is an image processing realtime environment, it takes almost all of the PCs
processing power while active.

In order to be able to send serial data to the running program, you need to
configure the serial device in the Simulator to a real COM: port - i.e. COM1:.
Now you have to connect another PC through a so called nullmodem cable to COM1:
and you have to run a terminal program on that other PC (or you can run other
software that communicates serially with the simulated VIMOS program). Within
the terminal you can send control strings to the Simulator. The Simulator will
react on them. If you have added a command, that ends the program (calling the
'Exit user program' tool), like 'Q' or 'X' and you can call that command, the
Simulator will stop the simulation and your PC will be fine.

Because of the use of the same code (which is necessary for obvious reasons) on
the camera and the SIM, the Receive string tool does hang, while waiting for
serial input. It does the same on the camera.



The information may be outdated or accidentally wrong and is given without guarantee. (C) 2002 J. Beutel

Please read the legal information you find at our imprint.