RDMNet (GDTF & PSN)

Hi,

after another six months I wanted to find out more about the current state of affairs in RDMNet.

Is it likely that RDMNet will soon be implemented in the main ETC products (gateways, Eos family)? An early implementation would be really desirable.

I would also be interested in what the status looks like in the case of GDTF and whether there are plans to implement PSN.

Such protocols are becoming more and more important in our industry than they already are and unfortunately, in my eyes, ETC is now a bit behind in these points, as one concentrates more on other competencies and thus neglects the important basis of the system a little.

Of course you can help yourself by integrating third-party solutions in the system to cope with tasks, but that is actually not the "sense and purpose of the exercise" ...

Please do not get me wrong, I see what has been achieved in all this time and I am very grateful for it, but, in my opinion, important topics should not be too neglected.

[Moderator Note: This post was joined from a duplicate posting]

I don't know anything official, but I think you can take something from the fact that ETC currently has one of the most complete implementations of RDMnet available here: https://github.com/ETCLabs/RDMnet. The RDMnet standard was only ratified about a year ago, and I'm interested which other products you are using that support RDMnet and which this is causing you issues with?

As far as GDTF goes, I'm intrigued what the value you think this gives you. Eos has an extensive fixture library already, as does Hog. The GDTF share site currently only has about 300 fixtures available, and I expect you'll find every single one of those is already in the Eos and Hog libraries.

If you're interested in PSN, you should check out the OTP https://otprotocol.org which is an ESTA ANSI ratified tracking protocol. Augment3d only released about 6 months ago, and prior to that there was little practical use for tracking in Eos. I'm sure ETC has exciting plans coming.

Many thanks for your response.


On the subject of RDMNet:

I know github.com/.../RDMnet, but RDMNet is not officially implemented in the products.

To answer the question about the application:

For example when using the RoboSpot system. This requires an RDM connection from the base station to the individual MLs on the corresponding universe. (short and a little simplified, I think you know the system;))

RDMNet would be there so you can flexibly use the existing infrastructure (we use around 40 Net3 gateways) to distribute a universe for the RoboSpot system over the network and not have to commit to MLs which one takes from the gateways and thus also loses in concert.

However, this would only work if the gateways supported RDM-In.

The nature of the RDM and DMX is such that a significant amount of data could be funneled via RDM down to a single port and cause issues with DMX.
RDMNET /"RDM proxying" would create this possibility.

Of course, using Luminex nodes that support RDM-IN would also be a way of solving this problem, but I don't want to mess up my system with third-party manufacturers nodes and it would be a solution that would not be 100% satisfactory.

In principle, you are right about GDTF and there are almost all devices in the library, BUT unfortunately they are not always set up correctly or are incomplete. This would be avoided by GDTF.

On the subject of PSN:

I have often come across situations where one Tracking possibility would have been good.

Of course I also dealt with your www.dsmurfin.co.uk/lightstrike, but this is again an additional component.
I thank you for the tip OTP which I didn't quite have on my screen.

As already written:
I don't want to sound ungrateful and I know that Augment3D eats up capacities, but I want to fight that the other construction sites don't take a back seat.

Hi Linus, we are still committed to an RDMNet development. Unfortunately, ratification was just the first step in a implementation path. Like everyone else the pandemic has caused some delays and forced us to redirect our efforts in some of areas. It is our hope to have some preliminary RDMNet version for testing early this summer and will be looking for some help as soon as that's ready. Thanks for your continued support and patience. 

-Lowell

Hi Lowell,

thank you for your answer and the info.

Then I'll keep my fingers crossed and look forward to the test phase :)

Linus

GDTF is more then just a fixturelibrary. We have a fantastic color picker in EOS, but if the lights are not calibrated against this, then unfortunately this is just a... color picker.

GDTF should, if I understand it, also contain data even for the colors that the lamp can produce and this should then be able to be used in the color picker so that the lamp's output matches what we see on the screen. Biggest question, is this something that could be implemented in EOS color picker easily or is the years of years working with the color picker hard to implement on so It takes years before we see it in consoles by ETC? Pandemic or not, softwareupdates could be done outside the office. ;)

If the manufacturers of new lamps work with GDTF, then with each new fixture you will have calibrated colors in the system together with a correct fixture setup and no bad fast-loading library that you have to redo to make it to work when the fxtures is new and not implemented in the large fixture library.

If manufacture make a GDTF-file when they produce new fixtures an upload it to the GDTF-library you can at a demo download it and start testing the fixture whitout asking ETC for a fixturefile or making one of your own... more  intresting... RDMnet... let the fixture keep the file into the fixture and send the GDTF-.file via RDMnet to the console. Just plug in the new fixture on network and consoles get the right fixture setup from the light, patch it and you are up and running whitout hunting the right library. :)

The presence of GDTF doesn't actually impact calibration, it just provides an open method of defining calibration. Someone still has to do the calibration and then provide that data in the GDTF format. There's no reason why manufacturers can't already do that, and provide the data in a text format which could then be added into the Eos library, but they don't.

All you need to do is go and take a look at the pdfs most fixture manufacturers provide for their fixtures to realise the information is severely lacking. They don't always even explain correctly how the DMX profile actually functions.

The issue is that GDTF doesn't solve any of this, it is just a data format which make it easier to read/write the data. What we actually need is for manufacturers of fixtures to start taking responsibility for providing accurate full information about their fixtures.

After two years I wanted to bring up the question regarding RDMNEt / RDM-in/RDM-proxy again and ask how things are now..

I think two more years of patience will allow this demand LowellOlcott 

BR

Hi Linus,

Lowell is recovering from a well-earned break so I wanted to reply quick on this topic.

I think there's a couple of separate things here so I will break them out.

RDMnet

We have published code for RDMNet on our Gitlab page and are successfully interacting with other manufacturers equipment. We are working on implementing RDMnet into our Concert and Gateway softwares, and are hopeful that we will be releasing those by the end of this year.

RDMnet Tunnelling
Although RDMnet *allows for* tunneling between one physical RDM port and other physical RDM ports via the network, it is technically pretty complex to do. It remains on our wishlist for now, I think we will potentially get to it once we start seeing more uptake of RDMnet, but no definite timeline currently.

Hope that helps,

Tom