Re: [LCtalk] Falling off the network

[mattyo]

On Jul 30, 2005, at 19:27, Fokko van Duin wrote:
> At 00:43 -0400 30-07-2005, mattyo wrote:
> > Greetings,
> >
> > I just got a LanBox, which I'm using for a project involving 
> > multiple video projectors, which I'm writing in Jitter.  I'm only 
> > using the Lanbox to control a few video scrollers -- not too 
> > complicated -- and I'm using the otudp object to control it.  
> > However, the box regularly falls off the network.
>
> The usage of otudp alone is critical as the LanBox requires the 
> correct protocol. Please consult our included examples (e.g. the LC+ 
> UDP Desk (OSX)), as there are no known problems when using it 
> continuously.
>
> Note Be sure you use the latest lcudp-pack (included with LCedit+ 
> v3.3), as it formats the udp packets in the right way for a LanBox.

I'm not clear -- what do you mean by otudp alone?  I've got a bunch 
of other stuff traveling on the network, using the new [mxj 
net.otudp.send] objects. Might they conflict?


> > There is not a ton of traffic on the network (6 computers total, 
> > no heavy data transfers), but after about 15 minutes, I regularly 
> > lose communication, and can only find it again by rebooting it.  
> > Not only does control data not work, it even fails to respond to a 
> > ping after that time.
>
> It looks like the box is crashed, AFAIK that is only possible by 
> sending incorrect udp packets. I assume that only 1 computer is 
> sending udp packets to the box?

Aha -- actually the data is coming from 2 different computers.  How 
would the box even know?  I could reconfigurre the patch to send all 
the otudp data through one, however.


> > I have left it entirely with its factory configurations, and am 
> > using max 4.5.4 on a Mac.  Any ideas how to keep the box happily 
> > talking?
>
> Can you send me directly your patch, so I can have a look?

the part that actually send it is pretty dumb, but here it is (all it 
is doing is opening & closing a fader scroller):

max v2;
#N vpatcher 342 332 942 732;
#P window setfont "Sans Serif" 9.;
#P newex 243 270 27 196617 + 1;
#P newex 242 196 63 196617 r DMX_chan;
#P newex 242 219 62 196617 pattr;
#X prestore 1 0 0;
#P objectname u865000016;
#P window setfont "Sans Serif" 12.;
#P message 306 117 49 196620 30000;
#P message 123 109 41 196620 5000;
#N comlet scroller shut;
#P inlet 228 95 15 0;
#N comlet scroller open;
#P inlet 74 84 15 0;
#P window setfont "Sans Serif" 9.;
#P message 232 158 55 196617 255 \, 0 \$1;
#P message 76 155 55 196617 0 \, 255 \$1;
#P newex 142 244 51 196617 change;
#P newex 141 219 56 196617 line 100;
#P number 186 297 35 9 1 0 1 3 0 0 0 221 221 221 222 222 222 0 0 0;
#P objectname number;
#P newex 142 273 40 196617 t b i b;
#P newex 164 345 154 196617 otudp write 192.168.1.77 4777;
#P newex 164 323 75 196617 lcudp-pack 254;
#P connect 10 0 6 0;
#P connect 8 0 6 0;
#P connect 6 0 4 0;
#P connect 7 0 4 0;
#P connect 4 0 5 0;
#P connect 5 0 2 0;
#P connect 2 0 0 0;
#P connect 2 1 0 0;
#P connect 0 0 1 0;
#P connect 3 0 0 1;
#P connect 14 0 3 0;
#P connect 2 2 3 0;
#P connect 11 0 7 0;
#P connect 9 0 7 0;
#P connect 13 0 12 0;
#P connect 12 0 14 0;
#P pop;


Thanks very much for your help.  If all it is is routing all the data 
from one machine, that's no big deal.  Out of curiosity, why is that 
a problem?  Also out of curiosity, are you looking to redevelop 
lcudp-pack so it is compatible with the new java-based objects?

Best,

\matty