Ion consoles and RPUs on wireless networks

I know there have been a few other forums posts on this subject, but I'm looking for a little more information.

We are currently using an Ion RPU to run a whole host of cue lists for museum exhibit lighting. The Ion is on a seperate network that speaks to a few Net2 DMX nodes spread all over the building. I have an Ion console that works wonderfully as a client when hardwired into the network.

I would love to be able to use the client console wirelessly for programming updates. The thought is to switch over to the main network used by the AV system, which has both wireless access and outside (protected) internet access.

I've seen some replies that mention not to connect the consoles to a network with outside access - why is this a problem?

And I've also seen that the Ion doesn't have a way to deal with dropped packets - if this is the case, why is the iRFR app able to interface with the system, but the console cannot?

Thanks in advance for any clarifiaction.

-Mike Daniels

National Museum of the Marine Corps

  • Hi Mike,

    There are two primary reasons for not connecting your lighting console(s) to a network that can talk to the outside world: Traffic and AntiVirus.

    Traffic: The lighting console on its own uses a fairly large amount of bandwidth in transmitting level information to the DMX nodes across the network. It is fairly important that this data get to its destination on time so that you don't experience any flickering or drops in lighting output. When you add in a connection to a corporate network, you now have much more traffic going across the wire that the devices have to ignore such as printer communication and email. Add in the open internet and you again increase that traffic exponentially. The lighting devices on the network, especially the Net2 Nodes, simply cannot take that much constant traffic that it has to ignore to get to the data coming from the console that they need and they will eventually just "give up".

    AntiVirus: The Ion console (and RPU) does not have any antivirus protection built into it. AntiVirus software tends to impede the abilty of the lighting control software to effectively perform. As a result, exposing your console to the open internet could result in unwanted viruses and malware being introduced to your console stopping its ability to control your lighting.

    You are correct that the console doesn't really deal with dropped packets very well. This is, in part, because the console is constantly sharing the show file between all devices (Primary, Backup, and Client(s)) and having to ask "did you get that" and wait for a response adds more time to an already time sensitive sharing process where it is possible that the data has changed in the amount of time the verification would take. When it detects that the show file being shared is out of syncronization, it will syncronize all of the data again to make sure that everyone has the same data. This syncronization occurs on all devices and when occuring you will not be able to make changes (usually on hardwired systems it is very quick).

    Technically, wireless client connections can work. The caveat that is always attached is that because you are constantly sharing the entire show file, if the client drops the packet that has part of the showfile, the entire system will attempt to resync which, given Murphy's Law, is usually at the most inopportune time. For that reason, we do not recommend wireless client for show critical applications.

    iRFR in contrast is more of an "on-demand" connection that doesn't need to share the entirety of the show file data, is less time critical, and uses a different underlying method of connection to the console that isn't practical for use of the entire show file. It only needs to send and receive small bits of data related to the current command.

    I hope this helps clarify why we recommend keeping your lighting network isolated from other network traffic and why we do not recommend wireless client for show critical applications.

  • Thanks for the more detailed information. The goal was to be able to set the console in some of the very few spots where I'm more than 300 feet from a node and its network switch, but the small advantage this confers isn't worth the potential problems mentioned.

    That being said, is ETC planning to adapt the current/future console lines to be able to address these issues?

Related