TCP to Eos

[Brendan]

I'm curious if anything has changed in the last 18 months allowing Qlab to initiate a TCP connection to ETC Eos software.

The last time I tried to trigger an Eos with OSC I had a lot of trouble with intermittent missed cues, and it seemed like the source of this was occasionally dropped UDP packets. At the time, though both platforms supported TCP, the official documentation from ETC stated to use UDP as "neither platform can initiate the TCP connection."

I am working on a project now where I'm being told TCP now works, but I can't find anything in a Qlab changelog or ETC documentation that would indicate so I'm skeptical. What are folks' experience these days?

[Richard Williamson]

Sadly - unless heads have been banged together - neither etc or qlab have built the capacity to connect to another TCP server (both are always servers), ideally qlab or etc would offer the ability to act as a tcp client which would solve this pain 

Sent from my iPhone

On 29 Jun 2024, at 08:35, Brendan <baa...@gmail.com> wrote:

I'm curious if anything has changed in the last 18 months allowing Qlab to initiate a TCP connection to ETC Eos software.

The last time I tried to trigger an Eos with OSC I had a lot of trouble with intermittent missed cues, and it seemed like the source of this was occasionally dropped UDP packets. At the time, though both platforms supported TCP, the official documentation from ETC stated to use UDP as "neither platform can initiate the TCP connection."

I am working on a project now where I'm being told TCP now works, but I can't find anything in a Qlab changelog or ETC documentation that would indicate so I'm skeptical. What are folks' experience these days?

--
Contact support anytime: sup...@figure53.com
Follow QLab on Threads: https://threads.net/@QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/76acd6e2-5bfb-4e0b-a813-965f5445b2b6n%40googlegroups.com.

[Ethan White]

Hi Brendan,

Yes! QLab 5 can act as a TCP client to connect out to an Eos console to trigger it via OSC. On the QLab side, all you need to do is set up a network patch with the "ETC Eos family" type and select TCP. I've attached a photo for your reference. You will then need to configure your Eos console to accept TCP OSC on that port. At this time Eos still is only a TCP server so the other direction (Eos triggering QLab over TCP) still requires some additional setup.

Thanks,

Ethan

QLab Developer

[Richard Williamson]

Ah apologies - I realised the issue I have previously faced (which still appears to be there) is that while QLab acts as a client and connects to Eos, it does not then act on the OSC received through that network patch. Although ETC is sending the requested data out via TCP there still appears to be no way to control QLab from Eos via TCP OSC without using some kind of middle-ware. Which to my mind is really silly and (since the TCP functionality is now there) also massively frustrating. 

Since this is something that is so massively used in the industry, and UDP has caused many significant issues in shows I do feel that ETC and F53 need to sort this out somehow. At the least QLab should have the option to accept incoming commands from a network patch which would solve the problem straight away.

--

Richard Williamson
www.richard-williamson.com
ric...@richard-williamson.com
07957 457 362

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/99e1205b-5e6a-4768-965b-d198a4bf90c9n%40googlegroups.com.

[Brendan Aanes]

Thanks Ethan! That is very helpful and now I understand the confusion around this issue. 

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/99e1205b-5e6a-4768-965b-d198a4bf90c9n%40googlegroups.com.

[Brendan Aanes]

One other question- are outgoing messages over TCP using OSC 1.1 or 1.0?

[Chris Ashworth]

v5 offers some OSC 1.1 arguments:

\T is a boolean true.

\F is a boolean false.

\I is an impulse.

\N is a Null.

https://qlab.app/docs/v5/networking/network-cues/

[Christopher Ashworth]

Hi Richard,

At present QLab closes the TCP connection it establishes shortly after it no longer has more messages to send, although this is certainly something that could be adjusted.

Can you say more about what messages you expect ETC to be sending on a new client connection and how you expect QLab to react to those messages?

C

(mobile)

On Jun 29, 2024, at 2:32 AM, Richard Williamson <ric...@theatre.support> wrote:



[Richard Williamson]

A (very) common use case is for Eos to fire qlab, eos has the ‘send string’ feature which allows you to define a dynamic osc message to send on every go. So generally people set it to /cue/%1/go which replaces the %1 with the cue number fired, meaning you can very quickly programme qlab to follow along to eos with little faff. 

At the moment this only however works with UDP - which can be unreliable (a problem which has been discussed much before) and so there is a danger of cues being lost - I’ve had this happen mid show more than once 

Currently the fix is to put oscRouter or similar in the middle - this then acts as a TCP client to both qlab and eos and bounces messages between the two. But adds more complexity and another point of failure to the mix 

Ideally between f53 and ETC a decent solution would be agreed that avoided middleware and allowed TCP to be the communication format 

Sent from my iPhone

On 30 Jun 2024, at 00:00, Christopher Ashworth <ch...@figure53.com> wrote:

Hi Richard,

--
Contact support anytime: sup...@figure53.com
Follow QLab on Threads: https://threads.net/@QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/E485D183-AB76-4C06-9571-2666C4996A08%40figure53.com.

[Christopher Ashworth]

Makes sense! 

Although that sounds like something I would expect to be configured on the EOS side, as the UDP version is, so the sender knows to whom and how it is sending messages, rather than just sending messages to any anonymous clients if they happen to connect. Seems like a feature request to ETC.

(mobile)

On Jun 29, 2024, at 12:21 PM, Richard Williamson <ric...@theatre.support> wrote:

A (very) common use case is for Eos to fire qlab, eos has the ‘send string’ feature which allows you to define a dynamic osc message to send on every go. So generally people set it to /cue/%1/go which replaces the %1 with the cue number fired, meaning you can very quickly programme qlab to follow along to eos with little faff. 

[Mike Post]

EOS software lets you configure to either TCP/IP or UDP but like Richard, I’ve never managed to get the TCP link to work.  I always assumed it was something on ETC’s end. 

Sam’s solution to get EOS to shut up sending random OSC messages all the time seems to have helped with UDP, but it’s always a “wait and see” game.

Mike Post

mdp...@mac.com

http://mdpostdesign.com

(601) 307-8657

--
Contact support anytime: sup...@figure53.com
Follow QLab on Threads: https://threads.net/@QLabApp
User Group Code of Conduct: https://qlab.app/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/212D9758-F9BE-44B4-91AB-3F06127ECFAE%40figure53.com.

[Paul]

Triggering EOS from QLab works fine over UDP or TCP. Here is my crib sheet for setting it up (it can be finicky! as the names EOS and Qlab use for things is not the same)

on earlier version of EOS the OSC TCP setting for SLIP was in the Shell.   I have found when running EOS on Mac or PC (Nomad) you sometimes have to restart EOS before it will pick up the network settings (IP address, netmask). Running EOS and Qlab on the same Mac also works fine (I have done this a lot on tour) and EOS will now listen to the the localhost address (127.0.0.1). On MacOS you can use the Terminal to run the command lsof -i :8000 to show what is listening on port 8000 which can be useful in debugging.

So although you can run over TCP I'm not sure if this would solve very much; you should never loose packets on a switched ethernet network; in my testing sending numbered UDP packets and checking they were recieved I could never get one packet dropped, even when running several universes of sACN  and NDI video (as a test) on the same network. Also remember if the underlying network is dropping packets this also affects TCP as much as UDP, as you have to exchange 3 packets before you can transfer any data with TCP, so if one of those gets lost it can be slower than UDP. The underlying OS will close TCP connections after a certain, as they take system resources; not something that the user should mess with.

[Andy Kanturek]

On our rig, EOS sends cue numbers to QLab to trigger video and sound cues over TCP.  In our simple wired network, only 1 switch, UDP packets from EOS are unpredictable. TCP only works reliably.

We use OSCRouter 

on Mac to overcome EOS OSC server to QLab OSC server issue. It works well with one caveat, EOS must boot up first before launching OSCRouter. Otherwise, OSCRouter configuration must be refreshed with apply button. This re-establishes TCP session between QLab and EOS. 

On Jul 5, 2024, at 8:37 AM, Paul <paulthom...@gmail.com> wrote:

Triggering EOS from QLab works fine over UDP or TCP. Here is my crib sheet for setting it up (it can be finicky! as the names EOS and Qlab use for things is not the same)

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/793dfca7-a2c5-44dd-94d6-661cd4cf10cen%40googlegroups.com.

[Paul]

As I understand it, OSC Router takes in OSC messages via UDP from EOS and outputs them over TCP to QLab. You are still using UDP out of EOS. I fail to see why this would be any more or less reliable than just using UDP all the way.  

[Richard Williamson]

OSCRouter can be set up to act as a TCP client to both Eos and QLab - creating a much more solid method than anything else. I’m not sure I think the current TCP implementation in QLab is very helpful since it only creates the TCP connection when a cue is fired (which I assume adds some latency) and also doesn’t show the cue as broken if the TCP connection fails to make, which rather defeats one of the best things about TCP (being “guaranteed” delivery).

For TCP to be useful in QLab I would contend that

• You should be able to set the connection as “constant” so that it connects as soon as the workspace is launched, and shows cues as broken if the connection cannot be made (in the same way as an audio patch behaves). This would be massively helpful since that link is often show critical
• There should be the option for it to be bi-directional - while I appreciate there is an argument that Eos should be able to act as a client to QLab when Eos is the controller, since you often want things firing in both directions it would be much better to only have a single connection required rather than two when TCP is already a bi-directional protocol
• If being very clever some extra metadata would be added to the OSC definitions to include the “ping format” where available, meaning that QLab could then constantly ping the remote client, and show that not just is the connection open, but the data channel is functioning as expected

I regularly use QLab as the “brain” in a show control system, and in some circumstances have a machine running QLab for only this purpose, and the lack of proper TCP support does rather restrict what is possible, so if the above could be considered it would be very helpful! At present OSCRouter is one of the best options which seems silly when it’s a free, not fully supported, piece of open source software!

Richard

--

Richard Williamson
www.richard-williamson.com
ric...@richard-williamson.com
07957 457 362

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/877e0021-fc8a-4dfd-b216-187e67d7cb72n%40googlegroups.com.

[Paul]

What you're describing sounds like a new protocol, more at the application or session level.  Something that would "link" EOS and QLab and thus require some co-operation between ETC and Figure 53 to develop.  It could be built on top of OSC or directly on UDP or TCP.  I agree it could be a useful addition in some situations. TCP connections are handled by the operating system and will be kept open while data is being sent, otherwise closed after a time out. (and yes they are always bi-directional). So if you were going to implement some "reliable" session connection, with re-transmission, that could be built on TCP or equally on UDP.  

From my experience of running lots of shows, doing a daily rig check and a  check at house open (of OSC, DMX, Timecode, video and whatever other technologies are in use)  is usually sufficient and I've not had a show stop or disruption as a result of such a technical issue. So I'm not sure the development effort would be justified.

[blindeye 1995]

i use an Eos snd Qlab setup for 2 years now in my theatre and yes they both Speak OSC with one another. i have found the issue mostly being udp packed loss. i reccomend to run OSC router as TCP client on the qlab Machine. also an trick to improve OSC send from qlab side is to set the frame rate to 120fps and the duration for all network cues by default to 00:00:25 this adds a little often not noticable latency but helps to ensure that the packets arrive. My oberservation shows dropped packets happens only when your switch (assuming you use ethernet) has an energy saving option build in like mine has (cant turn it off its annoying). so my solution to this is a little overkill but i addet an network traffic generator to the mix ( an PI with kali Linux) that DDOS all important show Equipment with 100Mbit of garbage data all the time so the switch dosnt go to energy saving bs. By DDOSing my equipment i improved the rate of failed cues from like 1 every 1000 to like 1 every 5000 Go Presses with is not ideal but it helps.

Greetungs 

Max

[Paul]

Sounds like you need to get a different switch (to avoid this horrible kludge). Unmanaged switches without energy saving are hard to find these days, but any managed switch will allow you to turn off EEE.  You could check out the Netgear AV range https://www.netgear.com/uk/business/solutions/av-over-ip/

Also worth checking where you are dropping packets; on the host, at the switch or at the receiver. It is should be rare to drop packets on a LAN unless there is some problem (damaged cable, misconfigured device etc).

[blindeye 1995]

There is only one Switch in my Network and its an unmaneged one but with EEE bs 

Greetings

Max 

Am 16.07.2024 um 13:57 schrieb Paul <paulthom...@gmail.com>:

Sounds like you need to get a different switch (to avoid this horrible kludge). Unmanaged switches without energy saving are hard to find these days, but any managed switch will allow you to turn off EEE.  You could check out the Netgear AV range https://www.netgear.com/uk/business/solutions/av-over-ip/

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/daf485f5-4cd4-4691-b3f8-50c2f8ca7c2cn%40googlegroups.com.