setting up digitizer Oce G6301

[Chris C Rewerts]

>From lists-owner at amber.cecer.army.mil Thu Aug 13 05:45:06 1992
>
>Does anyone know how to install a Oce G6301 (A0-size) digitizer on a HP
>9000/375 platform? We have a problem running v.digit: When entering the
>register points the following error message occurs:
>
> HOLD:  We are out of sync with the digitizer.  Trying to recover 
> SYNC recovered... CONTINUE
>
>Our digitizer has been configured as a Calcomp 9100 and is connected to the
>computer via a 3-pins serial RS 232 connection. We use the Calcomp digitizer
>driver from Grass 4.0 (in ~/src/mapdev/digitizers/calcomp). Does anyone have 
>a solution to this problem? Many thanks!
>
>Elwin Koster
>e-mail: ekoster at let.rug.nl
>

The "out of sync" sounds familiar. We have been using a Calcomp digitizer
(a calcomp 9500 hooked to a serial port of a Sun Sparc I)
for several years and this problem plagued us. The most aggravating
part was that after the "sync recovered... continue" message came
along, we were not able to continue. This left the terminal window,
graphics window, and vector file all in a bad state (since
the terminal text was using curses, the graphics monitor had
not received the R_close_driver() call... that kind of thing).

The problem manifests itself seemingly randomly. We have not been able
to associate it with other factors with digitizing or the computer
system in general. At one point, at the suggestions of helpful
CERL folks, we experimented with different #DEFINE statements
in some code file (I don't remember which, sorry) which, as I recall,
had to do with the rate of data expected from the digitizer. This
didn't seem to help.

My solution was to hack up the code a bit so that when "sync" is
recovered, you can keep on going. I did *not*, however, solve the
problem. I just got rid of the nasty part of the symptoms. Our
digitizer users still report getting "out of sync" errors. With my
revised code the worst thing that happens is that they might end up
redoing the last line or point, which is better than having to kill
off all the processes by hand and starting all over.

The question remains: what is "out of sync"? This is my understanding
of it: the digitizer is talking through a tty serial port to the
digit programs. When the puck is on the board it sends a 
a stream of lines of data telling the board coordinates and 
other info, like a status code, like this: 18879,20433,ARU 
When this line doesn't look right to the program, it figures
that it is "out of sync".

I was poking around and found the "Diagnostics" directory in the
src/mapdev/digitizers/calcomp directory, so I gave it a try. I started
modifying the dig_dev.c file and came up with a solution that might
work. I must tell you that I did not take the time to thoroughly
understand the programs... I just started experimenting. In doing so
I modified the D_readall function in dev_dig.c file. 

In essence, what the modification does is to force the program to keep
reading what the digitizer is sending until it looks ok again, then
it goes on with what it was doing. I started to send my modified
version of the dig_dev.c file with this letter, but it was 500 lines
(and did not contain any "subscribe" or "unsubscribe" requests to the
mailing list ;-), so if anyone is interested, I will gladly share the
file by email if you promise to tell us any further insights you may
have on the problem.

Chris Rewerts                        Internet: rewerts at ecn.purdue.edu
Agricultural Engineering             UUCP:     rewerts!pur-ee
Purdue University                    BITNET:   rewerts%ecn at purccvm