|
/*****************************************************************************/
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 color.
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 input.
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 quality.
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 text.
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 buffer.
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' tool.
/*****************************************************************************/
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') ENDIF
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 results.
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 background.
/*****************************************************************************/
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] :
getimage ªU03FC02F800003FC10108000000000103E8EE18
ªU03FC02F800003FC10108000000000103E8EE18 ªU03FC02F800003FC10108000000000103E8EE18
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
getimage
ªU03FC02F800003FC10108000000000103E8EE18FFD8FFE000104A46494600010100000100010000 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 :
getimage ªU03FC02F800003FC10108000000000103E8EE18
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.
/*****************************************************************************/
|
|