Home › Forums › Help and Support › Problem with Resolve and DTP94
- This topic has 26 replies, 2 voices, and was last updated 7 years, 10 months ago by DigiJoe.
-
AuthorPosts
-
2016-05-04 at 22:59 #2854
Right, I forgot that the packaged python that I ship with DisplayCAL only runs from within its own environment. Please replace
"/Applications/DisplayCAL/DisplayCAL.app/Contents/MacOS/python"
in the above command line with justpython
and try again. Thanks.2016-05-04 at 23:07 #2855Ok, that worked. I do some test now and report.
2016-05-04 at 23:14 #2857Without resolve it working without issues. There is no difference caused by the time between the commands from the second terminal session. Interesting is, that the DTP reader won’t work again until a USB Disconnect/Connect if i close the main session with control-c. That is the same behavior that happens after it crashed within the normal resolve measurement.
PS: If i close the main terminal session by Q, the reader is working when i start a new run.
- This reply was modified 7 years, 10 months ago by DigiJoe.
2016-05-04 at 23:26 #2859Interesting is, that the DTP reader won’t work again until a USB Disconnect/Connect if i close the main session with control-c.
[…]
If i close the main terminal session by Q, the reader is working when i start a new run.
Hmm I would have expected Ctrl+C (interrupt signal) being caught by dispcal so it can end communications with the instrument cleanly, but maybe it just exits. The Q case sounds fine and as expected.
So this basically leaves the interaction with Resolve as possible point of failure. DisplayCAL talks to Resolve over a standard TCP socket connection. So maybe there’s some interference with that and USB comms, or Resolve rendering patterns trips up USB comms to the DTP94 (although I have no idea how, and why it only happens with the DTP94).
Anyway, thanks for testing. I think if I want to try and debug this, I’ll have to acquire a DTP94 first so I can actually try and reproduce the problem myself.
2016-05-04 at 23:29 #2860How can i address Resolve as target from the cli? I assumed it would be -dweb:20002, but Resolve shows Connected and nothing changed.
2016-05-04 at 23:31 #2861How can i address Resolve as target from the cli?
You can’t – Argyll CMS doesn’t directly support a Resolve connection.
-dweb
is meant for HTTP clients (i.e. browsers).2016-05-04 at 23:38 #2862Ah ok, i thought Resolve uses something like REST or JSON over HTTP.
2016-05-04 at 23:54 #2863The complete thing is a bit weird. Maybe a bit more informations helps to find the source of the problem.
Scenarios:
Dispcal -> NVidia GTX 980 TI -> GUI Monitor 1 -> DTP 94 -> Dispcal OK
Dispcal -> NVidia GTX 980 TI -> GUI Monitor 2 -> DTP 94 -> Dispcal OK
Dispcal -> DaVinci Resolve -> Blackmagic Intensity Pro 4K -> HDMI Monitor -> DTP 94 -> Dispcal FAIL (Best run 58/154)
Dispcal -> DaVinci Resolve -> Blackmagic Intensity Pro 4K -> HDMI Monitor -> Spyder 4 -> Dispcal OK
Dispcal -> DaVinci Resolve -> NVidia GTX 980 TI -> GUI Monitor 1 -> DTP 94 -> Dispcal SEEMS OK, Still running (210 / 810)2016-05-04 at 23:58 #2864Interesting. That could mean there may be some sort of interaction between the Intensity Pro and Argyll’s USB comms with the DTP94. Weird. That would mean acquiring a DTP94 won’t likely enable me to reproduce the problem (if that is indeed what’s happening) – I’d need an Intensity Pro card, too 🙁
2016-05-05 at 0:02 #2865Yes, that was exact my thought. I test a few more things for now.
2016-05-05 at 10:52 #2866It getting a bit more weird every day, Florian. After i got a fully calibration process of the viewer windows inside Resolve – i tried the external monitor in Resolve again. And i got over the first step with 154 Patches without problems last night. I will try full run today. I updated the Intensity Pro Driver two days ago, … i will further investigate this.
2016-05-05 at 18:54 #2870Ok, there is still a problem, but is not as easy to reproduce as before.
18:49:44,970 Patch 7313 of 7672 18:49:44,970 Current RGB 12 90 73 0.046075 0.352888 0.285736 18:49:44,971 DisplayCAL: Sending RGB 0.046 0.353 0.286, background RGB 0.000 0.000 0.000, x 18:49:44,971 0.0000, y 0.0000, w 1.0000, h 1.0000 18:49:44,971 DisplayCAL: Patterngenerator sent count: 7313 18:49:47,947 18:49:47,947 Sample read failed due to communication problem. 18:49:47,949 DisplayCAL: Waiting for send buffer 18:49:48,004 DisplayCAL: Sending buffer: ' ' 18:49:48,060 Hit Esc or Q to give up, any other key to retry: 18:49:48,060 18:49:48,060 Sample read failed with unhandled error. 18:49:48,061 The instrument can be removed from the screen. 18:49:48,064 dispread: Error - dispd->read returned error code 2 18:49:48,065 18:49:48,085 DisplayCAL: Reached EOF (OK) 18:49:48,272 ...aborted.
-
AuthorPosts