• Date
    Linus DT Bln
  • Date
  • Replies 9 replies
  • Subscribers 106 subscribers
  • Views 6348 views
  • Users 0 members are here

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.

Parents

  • 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.

  • in reply to dsmurfin

    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.

Reply
  • in reply to dsmurfin

    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.

Children
Related

www.etcconnect.com