Hi Graeme,
Thanks for responding. I guess I will just keep trying. Funny, but adding the
debug flag does seem to decrease the frequency of hanging.
The message "Written 'full_ramps.ti3'" confirms that the .ti3 was written out
though,
so it's a big puzzle that you say it wasn’t.
namarupa: dispread -v -d 2 -c 1 -a -F -P 0.5,0.5,3.0 full_ramps…
Place instrument on test window.
Hit Esc or Q to give up, any other key to continue:
Measured display update delay of 47 msec, using delay of 162 msec & 1 msec
inst reaction
patch 256 of 256
The instrument can be removed from the screen.
munki_simulate_event: terminate switch thread failed, canceling I/O
io_callback: result 0xe00002eb, length 0
On May 22, 2020, at 1:09 AM, Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:
Jim Ferwerda wrote:
Hi,
To do this I hand-made the attached full_ramps.ti1 file that has 256 RGB
entries
between 0-100 (excerpted below in case I can’t post attachments). When I use
this file
with dispread, the measurements proceed nicely, but then intermittently
(more often
than not) dispread finishes measuring, gives the message “The instrument can
be removed
from the screen.” and then hangs, never writing the .ti3 file.
The instrument can be removed from the screen.
munki_simulate_event: terminate switch thread failed, canceling I/O
io_callback: result 0xe00002eb, length 0
dispwin_del called
dispwin_set_ramdac called
dispwin_set_ramdac returning OK
dispwin_set_ramdac called
dispwin_set_ramdac returning OK
Restored original ramdac
Written 'full_ramps.ti3'
namarupa:
sounds like a tricky one, since dealing with failed USB I/O is something of a
black art.
It's hard to guess whether this error is a result of the instrument not
responding,
or something the O.S. is doing.
The message "Written 'full_ramps.ti3'" confirms that the .ti3 was written out
though,
so it's a big puzzle that you say it wasn't.
But the only way to really debug this is to be able to reproduce it.
Cheers,
Graeme Gill.
