[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problems - da Vinci cont.

Dear Folks,

Thank you to all those who replied, most of whom, avidly defending their 
systems. As several suggested we and da Vinci reps. have already checked 
our cabling which is very good. Infact for some of the differential 
signals we are using dual-screened twisted pairs, which is infact better 
than the single screened cabling which da Vinci supplies. (We have of 
course also used the da Vinci cables too.) We have also recently changed 
the ethernet cable, but this did nothing.

Most of the faults seem to point to software rather than hardware.

What I neglected to say is that we are using an URSA Gold and the system 
is using PAL and mostly 25 f.p.s.  This is problably why many of you in 
the States are happy with your systems and we are not so; we have the 
feeling that the whole system is optimized for 30 f.p.s. and not 25 
f.p.s. We have good reasons to belive this:- 1) When you try to edit with 
the TLC it usually hits it first time on 30 f.p.s. whereas with 25 f.p.s. 
it takes more attempts (though still unreliable). 2) When you load a 
confiuration (with 25 f.p.s. selected) it sometime sets the speed to 30 
f.p.s. although we have not one configuration with this setting. So, 
somewhere in the dark caverns of the software is lurking this 30 f.p.s 
default which pops out when you are not looking! Then the question must 
be asked: if the 30 f.p.s is still in there somewhere, what other "30 
f.p.s. based" default factors are floating about in the software and jump 
in the wrong place now and again? Also, why is it that the TLC works 
smoother on 30 f.p.s than 25 f.p.s.? Surely some algorithms must be 
optimized for 30 f.p.s.?

Another area could be the ethernet system: On a normal PC ethernet it is 
common knowledge that if you have too much traffic on the bus it falls 
down because there are no free time slots and no machines can get in 
without another crashing into its data stream. (This is where a Bus 
Contoller controlled system like the MIL.STD. 1553 is much better because 
this cannot happen.) I donīt know if on the da Vinci each panel is a 
seperate initiator, but if this is the case then there could be problem 
if another part is moving alot of "housekeeping" data and the machine 
gets busy. Also, if a node transmits a package and there is an 
error, it could have not enough time to transmit another one. 
Again this is a software problem. Shortly we will put an bus analyser on 
the net to see if this could possibly be the problem. (Has anyone tried 
this yet?)

What do you think?

Once again, thank you for all your help and we look forward to hearing 
from anyone who can help us again.

Best wishes,

Phil Budden
DAS WERK, Munich
phil at das-werk.de



thanks to Jim Erickson, Rick Pagliaroli, Drexel Williams, and Dave Grey
at Colorlab (Maryland) for their support of the TIG in 1997
mailinglist digest available......posting guidelines on the webpage