|
ArtNet sendHello! I've got the 7 day demo of the Art-Net tools installed and am already on day 5 so I'm short on time and have been pulling my hair out for about 3 of those. Oh no! I've got an Artistic Licence NetLynx O/P on loan from the manufacturers to test my setup and I've configured my Ethernet port in Mac OS X to 2.0.0.0/8 and 10.0.0.0/8 and neither work, regardless of my system config and patch parameters. In both cases I used a netmask of 255.0.0.0. The device is powered up and Mac OS X reports the interface active when it's plugged in, and inactive when not so I believe my Ethernet settings are right. The ArtNet-SendReceive.qtz tester only works if have my second Ethernet connection active (currently configured for 192.168.5.0/24) and the COM (for communication) light never flashes on the device, which makes me suspicious that the UDP packets are never actually making it to the box. I'm speaking to the manufacturers to get any support from their side but they are pretty much unable to help with anything non-Windows based so I'm kind of on my own unless I can get some support here. I'm about to go to bed right now but I'll perform a tcpdump tomorrow. Incidentally, we do have a working solution using an Enttec USB DMX Pro box and Kineme's Serial Output patch, but like others have expressed here, I'm not convinced by the FTDI driver and the results, whilst mostly working occasionally flicker unexpectedly. Hence I'd really like to get the Artistic Licence box working. They're also really friendly local people so I really want to use their kit instead of Enttec's. Has anyone else got Art-Net Tools working with Artistic Licence hardware? Cheers, Ade. Clay Interactive Ltd.
|
Hi, Adrian!
Some thoughts:
2.0.0.1
as the IP address, and specify255.0.0.0
as the netmask.Do let us know how the tcpdumping goes, and please post the
ifconfig
output and/or screenshots of your Network System Preferences panes.worst case scenario if nothing works but you ABSOLUTELY need DMX output for QC: exchange your Enttec DMX USB pro for a Enttec Open DMX (over ethernet). It works out of the box and you don't have to worry about FTDI as it is ethernet based...
note to smokris: maybe you should add on the KnM Artnet page the different interfaces the patch has been reported to work with.
Hi and thanks for all the comments. Here's an update...
I found out the Net-Lynx IP by using tcpdump whilst cycling it's power... when it's LEDs flash on power up, three packets are sent:
I've captured these packets to a dump using
sudo tcpdump -i en0 -vvv -K -n -s 0 -w ~/ArtNet-tcpdump-AdeMacPro-20090319-PowerUp.dmp ip host 2.23.4.113
and they can be downloaded from http://services.clayinteractive.co.uk/13/01/01/01Tech/ArtNet-tcpdump-Ade...Thus the device's IP is 2.23.4.113. I disconnected all network connections and plugged the Net-Lynx into my Mac Pro ethernet port 1, and configured it to be 2.23.4.1, mask 255.0.0.0.
I've used tcpdump again to capture some of the packets whilst running the ArtNet-SendReceive.qtz demo (which is no longer working since I've unplugged my LAN) and can show that the UDP packets are atleast being sent out by the Kineme patch:
So I know that the Kineme patch is sending UDP packets. Still no flashing COM light on the Net-Lynx though!
If anyone is interested in the actual dump, it can be obtained from http://services.clayinteractive.co.uk/13/01/01/01Tech/ArtNet-tcpdump-Ade...
Any further thoughts or diagnosis would be most welcomed.
Thanks!
Ade.
Good point. I've added a known hardware compatibility section.
Adrian -
Could you try connecting an ethernet switch between the Mac and the Net-Lynx, to see if the switch's lights flash when ArtDmx packets are theoretically being sent? This'll help us determine if the packets actually make it out of the Mac.
Also could you post a
tcpdump
capture of packets from some other device that successfully sends ArtDmx packets to the Net-Lynx? We can then compare these packets to those sent by our plugin, to see if there is some protocol incompatibility.I've connected a switch between the two and can confirm the lights are blinking when QC is sending out packets, so it's not an Ethernet setup problem.
Artistic Licence support are saying that the COM light will flash every time a valid ArtNet packet is received so it's likely the packets are not recognised as valid, indicating a protocol problem. Since Artistic Licence developed the standard, I'm assuming you guys used their specification when authoring the plug-in?
Unfortunately I don't have any other ArtNet capable devices so I couldn't packet sniff anything else to provide it.I am providing a packet sniff of the packets coming out of QC to Artistic Licence, hopefully that will help them analyse what the problem is. If that's the case, I'll feedback here.Update: I've installed Artistic Licence's DMX-Workshop software on a Windows XP software and confirmed it can operate the RGB lights I've got with the Net-Lynx, so I've ruled out any hardware issues.
I've also used the same software to dump some output diagnostics about the UDP packets that it is sending.
This dump doesn't give the full packet contents but it does give the header bytes and a quick comparison between this and the packets coming out of Kineme's plug-in suggests byte 13 is 00 when output by the plug-in but 02 when output by DMX-Workshop. Is this significant?
A typical packet coming out of Kineme ArtNet Sender:
Interesting (and thanks for the analysis) -- byte 13 is the "Physical" byte -- according to their specs, it's informational only, and they don't describe what it should be. All other header information is identical.
I'll make a build that lets you set this arbitrarily, so you can set it to 2 and see if that makes it work.
I was going to edit my original post to avoid using decimal bytes but was too slow! For clarity, the "physical" byte is at offset 0x0D (right?).
Also - just quickly - I noticed that offset 0x12 appears be the first DMX data byte according to DMX-Workshop but in Kineme's implementation is seems to be offset 0x13.
This packet has come out from Kineme ArtNet Sender. Note how the first DMX channel is at offset 0x13.
It is sporadic but DMX-Workshop on a PC is recognising ArtDMX packets being generated from the Kineme plug-in (beta2). It's built-in logger is noting that the source port might be an issue but I can see the index offset issue is now resolved.
The regression with beta2 is that these packets are only appearing at random intervals.
Alas, still no activity on the Net-Lynx.
I noted the random-send problem too -- not sure exactly why it happened, but a make-clean/recompile seemed to bring it back to life on my machine. I'm making some more changes/fixes, and will get you another beta shortly.
Very quickly - the Artistic Licence support has clarified the problem:
So, thanks to Simon Hobday at Artistic Licence for clarifying this.
Hi, would you be able to give me a little detail of how you did this? I'd be very interested in this... I probably can live with a little flicker..
Other than using teh serial output patch, did you have to do anything else?
regards
A.
Sure, we used a JavaScript patch to compute the DMX channel values, and at the same time build a string containing the packet data that the Enttec box understands (we wrangled with their poor documentation for a long time to get this right!). The packet is spat out as a hex string, which is fed to the Serial Output's "Binary Data" input, and the "Binary Send Signal" is oscillated every other frame to cause it to output the bytes.
For reference, the packet format for Enttec USB DMX Pro boxes is formed like so:
The wrangle we had was that the first byte of the data bytes must always be 00, since this doesn't map to DMX channel 1.
A typical packet might look like:
To make the hex bytes you can use a simple Javascript function:
Hope that helps!
A.
Thanks!! I'll ahve a play with this and see how i get on.
Hi I was wondering if the ArtNet patch had been modified to work with Artistic License equipment I have a Ether-Lynx box I would like to work with QC but I cannot get it to work, so was wondering if this issue still existed. I have fully tested it and I can get the Ether-Lynx receiving data from MagicQ in X11 environment but nothing with QC. Cheers Steve
Note on this old thread for posterity: the sending-port issue was "corrected" as of Art-Net Tools version 1.2.
("Corrected", as in, our plugin now adheres to the letter of the Art-Net specification, however the specification itself violates how IP networks conventionally work.)