DMX Out Not sending artnet sync

Bugs
1

I have tried any number of combinations of options in the network tab and on the DMX tab and I cannot get it to send a SYNC packet. I had this working sometime last year and now with the same project the SYNC packet is not sent.

I looked at the wireshark output as well and confirmed there are no SYNC packets sent.

I should say I am on windows with TD version 2023.12230

2

Hi @babsher,

do you have more info on any other settings in your project. I can’t replicate here and see ArtSync packages in Wireshark:

16	0.183294	192.168.178.24	255.255.255.255	ARTNET	46	ArtSync
17	0.199930	192.168.178.24	255.255.255.255	DMX Channels	562	ArtDMX Seq=28 Port=0 Univ=0
18	0.216381	192.168.178.24	255.255.255.255	ARTNET	46	ArtSync

cheers
Markus

3

It started sending but I am not sure what combination of changes made it work. I would like to better understand when they are sent.

It could have been something in the routing table. Maybe I put in a channel name that didn’t match up?

The other thing I changed was the remote address from the broadcast address to the specific IP of the destination.

I think I also enabled realtime on the application as well but I would not think that would change anything.

More broadly is there anything that would stop the SYNC packet from being sent?

4

ArtSync packets are only sent in Packet per Channel mode – were you using Packet per Sample mode before?

Other than that: the ArtSync packet is only sent once all the ArtDmx packets have been sent, so if for some reason the ArtDmx packets fail to send then so would the ArtSync packet. But if you see that the ArtDmx packets are successfully sent/received then that is indeed strange.

5

The only other thing I could think of would be that I switched from wifi to ethernet. But I did the wireshark check when it was connected to ethernet and I didnt see them.

I am not sure how a packet would fail to send because it is UDP correct? Could it be that the packet was not created correctly due to the channel mapping?

6

There are a lot of variables in this situation it would seem. Some things to keep in mind:

  • Sometimes UDP packets will not get sent if there is “no path to destination” or whatever it says when you try to ping an IP address that doesn’t exist at that moment. AKA Nothing would show up in WireShark in this case even though you are telling TD to send unicast packets.
  • Broadcast packets are treated differently with WiFi so they either might be sent at the lowest rate or not at all since if there’s a lot of clients connected, the WiFi access point would have to take that one broadcast packet and repeat it for every client connected. ArtNet in Broadcast mode basically creates a WiFi killing stream with not even a few universes of data.
  • UDP is not actually guaranteed delivery, there is no mechanism for re-transmission if a UDP packet gets lost because some network device in the chain (including your local computer’s network stack) overloaded it’s buffer and started shedding packets to keep up and there’s generally no error message for that either I think. I have had an issue recently where the incoming / outgoing data rate of a Windows computer was approaching the 900 mbps mark on a gigabit (1000 mbps) connection and we were losing random UDP packets.
  • Windows firewall I think by default will block broadcast packets? maybe not in LAN contexts, but if you have a NIC with a gateway filled out (even if it doesn’t go somewhere) it might not get routed correctly
  • If you have a lot of network adapters installed (try ipconfig /all in command line) because of lots of VMs or other weird devices, it could be that Windows was choosing a different NIC to send data to. That shouldn’t happen with broadcast, but I never trust Windows to send stuff out the correct NIC.

Notice how all of these caveats are outside of TouchDesigner. TD is maybe 10% of the equasion in your scenario, so I would be looking at the multitude of variables related to networking before I would be sure there is an obscure bug in the DMXout CHOP. I have caught a few TD related DMX networking bugs before, but I would say 99.999% of the time, networking issues are somewhere else in the computer or on the network and unless it’s easy to re-create (I can’t even trying all of the routing table stuff you mention) there’s no reason to believe it isn’t an issue somewhere in the 90% of overt complexity that is the wide world of Networking and the behemoth of all that is the Windows Networking Systems

7

So I was able to track it down to the routing table. I am using packet per channel and it looks like if all of the channels dont have routes then the sync is not sent. I had a smaller routing table I was using for testing that did not route all the channels.

When I switch from one to the other the sync packets stop sending.

I also created a small go program to push a bunch of DMX and sync packets across my wifi and all the packets got to the controller.

8

Interesting, so you mean there were channels in the CHOP that didn’t have an entry in the routing table? Or channels listed in the routing table that didn’t exist in the CHOP? Cause that seems like a bug.

Edit: ah yeah it’s the first one. sorry I thought I checked that combo but apparently not. if there is a CHOP channel that does not have a corresponding entry in the routing table, it will not send ArtSync packets. That seems to jibe with what eric was saying (that ArtSync only happens when all packets are sent) but I thought there used to be an error in the DMXout CHOP when it couldn’t find a corresponding entry in the routing table DAT? @eric.b am I hallucinating that?

9

It only errors if it’s missing one of the required columns: channel, net, subnet, universe.

It is allowed in the DMX Out CHOP to only send a subset of channels via the routing table, so ArtSync should accommodate that. I will fix that behavior.

1 Like
10

A warning would be great with the chops that are missing in the routing table. I had a lot of similar named channels and it was really tough to do the diff on 32 different universes and channels.