Unicast Bandaid

By 5 commentsCategory: EOS, Film, Hog, Networking, TroubleshootingTags: , , , , , ,

Recently, I was on a commercial gig and realized something had happened to my network switch, as it was dropping universes.  This is a very stressful thing to happen on set.  It was a small truck package with about 5 universes active.  A good trick for these events is to patch some dimmers (that control no actual lights), set them in an effect and let them run.  However, three of my universes were full with no room for that.  

Since I’m an Eos programmer, I went to Patch and was considering shifting to Artnet when I finally noticed something I had seen for quite a while, but never used: the Unicast column in Patch>Protocols.   

I’m pretty good at networking, but nowhere near as knowledgable as I wish to be.  So I’d never played with Unicast before.  It occurred to me that I might be having either a multicast problem or can EEE problem.  Of the two, multicast was more likely.  So I decided to try Unicast and see if that made a difference.

I input the IP address of the Stardust in each line and watched as all the universes locked on on the front of the unit.  If you already are familiar with multicast issues- you know that locking on isn’t the issue.  It’s staying locked on.  So I spent a very hyper-aware first hour looking at the Stardust over and over.  It stayed locked on.  

Over the weekend, I left the console setup with the Stardust to test.  I didn’t change anything for output since an EEE problem would be tied to lack of changes in output.  It stayed locked on the whole 30 hours I tested.

Later- I was having yet another struggle getting Hog to connect with Capture.  While I was spinning my wheels and doing the same tricks over and over again waiting for a handshake, I noticed the Unicast column in Hog as well.  I assigned the IP address of the Capture computer and it instantly locked and stayed that way.

I want to be sure to repeat- I’m not a networking expert.  I’ve learned how to setup and troubleshoot networks but that doesn’t mean I have the depth of underlying knowledge to tell you definitively WHY something works.  But this works and for some of the most irritating kinds of problems.  I’m happy to have another trick to try when my network is being difficult.

What mysterious network issues have you been hit with?  Let me know in the comments.

***

Mark LaPierre is a programmer in film, television and theater based out of Albuquerque.  He grew up in live entertainment and has been a designer/programmer for musicals, concert dance, live music, circus and corporate.  Mark is a proud member of IATSE, an ETC Eos trainer and an enthusiastic trainer of many other platforms and subjects.  He offers remote console coaching in 30 minute to 4 hour times as well as a full range of training in person.  If you enjoy his content, please consider commenting on his posts on the website to appease the Algorithm.   

5 comments

  1. Chris Steele - Reply

    Interesting. I see you are using a trick I thought of a while ago, but haven’t used in the real world yet: setting a “dummy load” channel on each uni and letting it run a sine wave. Can’t remember where I got the idea for that or if I thought of it myself, but it reassures me that you use that too.

    We can see you were using sACN here. Were you using your M4250 managed switch at the head end? Any other switches between your host and the Stardust?

    I thought unicasting would be a strange fix for sACN, since if I understand it correctly, sACN only uses the host’s addresses to perform an initial handshake and set up some parameters, but then the actual data is sent in the multi-casting range 239.255.x.x . But this is good evidence it works to solve universe dropping.

    I don’t know if Eos has an equivalent, but Onyx has a nice feature that detects Ether-DMX nodes and other devices like Stardusts and shows you it knows about them. It doesn’t always detect all nodes, but it does usually show most things. What Onyx lacks is the ability to specify unicasting to a manually entered address. Rather, it offers a setting for which universes are unicasting, but I presume it decides where to send them based on what devices on the network it thinks are asking. Obviously a sub-optimal situation.

    Reading this article prompted me to fire up Capture and sACN and recreate the problem I have often had with getting Capture to recognize and lock into an sACN stream. As usual, I got sACN outputting on my Onyx machine, and verified it was present on the network by seeing it on an ether>DMX node attached. But neither sACNView nor Capture on my laptop was registering it. I’m not sure what really fixed it, I was poking around in network adaptor settings, and closing and opening sACNView to refresh it, and I accidentally clicked the update button on the start screen. So I let sACNView go ahead and update, and as soon as it started, everything popped into operation, and it’s stayed solid since.

    I will say, in the past, I believe I got it working by intermittently enabling CITP data on the host machine sending sACN. It seems like that wakes things up on the other end. Then I can turn off CITP on the source machine and the sACN remains recognized.

    • Mark LaPierre - Reply

      I was using a Zyxel GS 1200 5hp. The issue appears to be that the unit reset itself (or something magically pressed the recessed Reset button). So in short- it wasn’t configured, and that was the issue. So I now have added to my check list “Sign into and confirm settings for switches” for prep before production.

  3. Owen - Reply

    I have used uni cast to send data to led pixel rib on tha was not responding before and it solved my issues.

Leave Comment

Your email address will not be published. Required fields are marked *