Hi, So my theatre has assigned me the duty of moving some linear actuators for automation using a (not the, but a) lighting console. In experimentation and building I was able to do this with my laptop, with Nomad software and license key installed, over ARTnet with an arduino equipped with an ethernet shield and a motor driver module. Everything worked well, but at some point we'd moved into the space to install, and could not get our Nomad Puck to send the commands. We brought in an Element, and an Ion, and a different laptop with the nomad software and license key, and no other device besides my own laptop is able to control these things.
I've matched the settings, and ensured that ARTnet is being sent to the proper channels in the patch, we've modified the IP address and subnet masks and we've tried downgrading the software version on other laptops to match that of my own (2.5.2). The desired control consoles can all ping the arduinos over the network, but none seem to send it the proper ARTnet values.
Admittedly, I'm very new to ARTnet, or ETCnet, or anything that isn't a dmx cable. This project has taught me a lot, but I'm still missing some key information, apparently. Our head lx is stumped, as is our TD, and even our FieldService.ca technician wasn't able to help.
The show opens on Friday and everything is in place now, I'm afraid that I have no interest in rebuilding much of the arduino or its code to make this work. Just hoping to get my personal laptop back, and am baffled how it could be so special as to be the only Nomad that can work with these things.
Arduino will really struggle to do this.The AVR-based ones have very little bandwidth and processing available and thus gets very quickly swamped once on a 'real' network. They'll usually work just fine…
GarrettGB said:but none seem to send it the proper ARTnet values.
I would recommend testing this by putting a laptop in place of the Arduino and using The ArtNetominator to verify that proper Artnet levels are being received at that end.
If they are, then you will need to sort out why your Arduino isn't responding to them.
More likely, those Artnet levels aren't getting to the Arduino over the network, and you'll need to sort out why.
I would check in the Shell settings of the sending console / computer that Artnet is enabled and defaulted. That's Settings > Network, Output Protocols
I would also check that you're not running into a Patch limit of some kind - on the sending console, clear your command line, then press [About] (or the 'y' keyboard key) and double check allowed outputs.
What Arduino are you using and what's your personal laptop? I've been running into issues where Nomad on my Macbook will recognize some Arduinos(Leonardo/Mirco) but my PC Nomad won't. It was suggested it may be a driver issue, or that you need to spoof the PID/VID. Or you may just need to swap boards(if possible).
That only comes into play when you are using OSC over USB. This question is about a networked arduino.
I've done several projects with networked arduino. If all the routing seems to be correct the problem may be that the ethernet shield being used can't process all the packets that it is seeing. The wiznet 5100 based ethernet shields are really slow. I would try what Matt has suggested to make sure packets are making it to the arduino. Then you may need to do some logging with the arduino of incoming packets so you can see if it is having issues with processing.
Try to avoid ArtNet, it is a No-Go protocol, use sACN instead. There is some code for Arduino on https://github.com/claudeheintzAlso use switches like HPE or Cisco, switches from Netgear are also a No-Go. Unmanged switches are generally easier to handle.Also think about using OSC.
Are the Netgear switches a no-go for sACN or for EOS? I know some houses that have non-EOS consoles using sACN and unmanaged netgear switches...Im wondering if the netgear switch is causing any issues...
Some managed netgear switches blocks multicast communication out of the box, which must managed.
Arduino will really struggle to do this.The AVR-based ones have very little bandwidth and processing available and thus gets very quickly swamped once on a 'real' network. They'll usually work just fine in testing with one or two universes of data, then fall over at random intervals once there's many universes and all the other network data flying around.- Art-net is particularly bad because the receiving device has to receive all packets that might be Art-net and process them in the CPU before it can work out that it's not Art-net, an Art-net subprotocol it doesn't care about, or a DMX universe it doesn't want.
OSC is a much better fit for controlling an Arduino-based device, as it is command-based (Do this. Do that other thing), rather than streaming (be like this. be like this. be like this).
OSC over TCP means that the commands will arrive in order (better late than never) and (eventually) tells you if the other end vanishes, while UDP only promises to be fast (better never than late).
Finally: You must make absolutely certain that the system as a whole is safe using other means.Lighting consoles are not certified to control stage machinery or any other potentially hazardous devices, primarily because these network protocols are not designed for that.If the lights turn red at the wrong time it's an artistic problem but nobody gets hurt. If an actuator moves unexpectedly then somebody may end up in hospital or worse, and you're personally in court explaining why you did what you did - or didn't.
Sorry, I appreciate I am very late to the party but Artnet is a perfectly valid protocol. It is used in professional environments on a daily basis.Why do you think it is available on ETC desks if it's a No Go?
The protocol is implement because there are many products which uses ArtNet because it was the only open protocol before sACN.The NoGo's:- the use of 2.x.x.x can be illegal. Some people uses ArtNet on a system with router to the internet (this will block only valid private IPs) and get problems with lawyers because some people paid for the use of this IP range.- It is a broadcast protocol, so it floats your whole network system with DMX data that you don't need.sACN works with multicast, only devices that needs DMX data will get them.- most vendors implemented only basic parts of the protocol so you have been aware of limitations of different versions.
None of that makes it a 'no go'. As I said, it is used in professional environments every day. I'm not going to get into an argument over it.