Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21

Thread: Artnet

  1. #11
    i think something is wrong in his software.

    this is my c struct for an artnet packet from their spec

    typedef struct ONE_ARTNETDMX_PACKET
    {
    char ID[ 8 ];
    unsigned short OpCode;
    unsigned short ProtVer;
    unsigned char Sequence;
    unsigned char PhysicalPortIndex;
    unsigned char Universe;
    unsigned char UniverseHi; //docs says this is unused
    unsigned short Length;
    unsigned char Data[ 512 ];
    };

  2. #12

    well....

    well,

    something wrong in my software, i wish I got to the point that I could find that one out..
    I sent a sample max patch to the lanbox people in Rotterdam (www.lanbox.com), they had to fill in their header, ip and port, and it worked immediately with their ethernet box. No problem.
    So I am positive that I'm sending proper utp out.

    this limits it to two things:

    A:

    my header or ip settings are wrong. This is a documentation issue, has nothing to do with my software. I follow the specs, some of the advice I got (an tried) on this forum is different, especiialy the port and ip settings. I find the specs are not unambiguous. The header for an artnetdmx packet I use is this (list of char values in decimal, so shorts are split in hi and lo byte):
    65 114 116 45 78 101 116 0
    0 80
    0 14
    0 0
    0 universe
    lengthHi lengthLo

    in the specs it says the bytes of the opcode are reversed (why would anyone do that ?), so I would be curious to see what the content of the 'opcode' field in your struct is.

    B:

    it is a hardware issue of some sort, faulty box (unlikely, true, but i start to doubt seriously) or some kind of ethernet incompatibilty I fail to understand.

    ok, this is what happens with the switch:
    1. ethernet switch on
    2. arnet box on
    3. plug in artnet box into switch: green light on switch comes on, no yellow light on artnet unit.
    4. plug in mac into switch: green light on switch comes on, mac sees the network.
    5. I send data: green light on switch for the artnet box dies. Nothing happens, leds go into chase mode.

    my issues are:

    - I will have to wait for at least an hour before I can try again: my experience is that if I just power the artnet box again, it will completly fail to respond to anything I send it. Only after a 'very cold' boot the switch (or the hub I used previously) will see the artnet box is there, I have never actually seen the artnet box with a yellow light on.
    I don't know what couses this behaviour, it is not mentioned anywhere, and makes any sort of testing basically impossible. Why would any device behave in this way ?

    - it is still not clear to me what the *exact* meaning of the yellow light is, Is it a light indicating the status of the network, like the green light next to ethernet port of my modem, which is always on, without blinking, OR is it a light indicating valid data traffic, like the activity lights on my hub and on my newly acquired switch ?
    so: if it is not on, does that mean that no data whatsoever arrives, or does it mean that I send the wrong data ?


    I am getting seriously annoyed at having to think about ethernet and about trivial headers, I want light !

    I am going to give it another try (in an hour..) with an 'unreversed' opcode (i think i tried that already before), then I'm going to give up wasting my time on this thing and buy a lanbox.

  3. #13
    [QUOTE=rekveld]well,

    in the specs it says the bytes of the opcode are reversed (why would anyone do that ?), so I would be curious to see what the content of the 'opcode' field in your struct is.
    QUOTE]

    well the key to any documentation, is reading it very very closely and do exactly what your are told.
    but even then documentation and ones interpretation can be incorrect.

    'Reversed' opcodes would be a sign of a little endian vs big endian byte order. same as all pentium pcs.

    are you sending to udp address 255.255.255.255 or 2.255.255.255?

  4. #14
    Quote:



    Originally Posted by samsc


    well the key to any documentation, is reading it very very closely and do exactly what your are told.
    but even then documentation and ones interpretation can be incorrect.




    I sure tried to read as closely as I could and do exactly what I understood ! The fact that I wonder why anyone would like to reverse bytes did not stop me from doing so myself...


    Quote:



    Originally Posted by samsc


    'Reversed' opcodes would be a sign of a little endian vs big endian byte order. same as all pentium pcs.




    that bit of information is new to me, only did programming on mac (and atari, way back), don't normally come close to pentium machines, but that has nothing to do with that I followed the specs, it says for every field whether hi or lo byte is first, that is pretty clear, although I don't understand why a protocol would mix both representations..
    I guess there must be some historical reasons of some sort, some hardware reasons.. ?


    Quote:



    Originally Posted by samsc


    are you sending to udp address 255.255.255.255 or 2.255.255.255?




    as listed in the specs (page 8) I send to 2.255.255.255 (or 10.255.255.255) with the jumper).
    255.255.255.255 is pretty crazy, no ?


    but what the about that first 8-char string, is that 'big endian' too ?

  5. #15
    i accidentally pressed edit rather than quote. so your post got broken

    i use 255.255.255.255...

    its the broadcast ip address. removes one more thing to go wrong.

    you might have to set the sub-net mask to 255.0.0.0 to use 2.255.255.255
    though i dont know...

  6. #16
    it is possible that your artnet box is broken.

    i did two installs in the last week, and at both one of the new boxes was broken.....

  7. #17
    Quote Originally Posted by rekveld
    but what the about that first 8-char string, is that 'big endian' too ?
    strings dont have endian ordering.
    but shorts and long integers do.

    on powerpc the number 0x1234 in hex is arranged in memory as 0x12 0x34 but on pentium its order in memory is 0x34 0x12

  8. #18

    light

    bought two lanbox-lce's and it took me 10 minutes to get them working !
    Finally, I think I deserved it, four days before my show..

    anyway, thanks a lot for all your help and suggestions over the last few days.

    Joost.

  9. #19
    Quote Originally Posted by rekveld
    bought two lanbox-lce's and it took me 10 minutes to get them working !
    Finally, I think I deserved it, four days before my show..

    anyway, thanks a lot for all your help and suggestions over the last few days.

    Joost.
    Do you lanboxes use UDP packets?

    R

  10. #20
    yes,

    they recently upgraded to a new firmware for their boxes (it could even still be in beta), and the new firmware allows to write dmx directly into the 'mix' buffer of the lanbox. The udp packet is a list of dmx values, and a header containing an instruction code, the start adress and the length of the list.
    This is how I used it yesterday, but these boxes can do much more: they are designed to be stand-alone controllers. I think with one lanbox-LCX and several lanbox-LCE's slaved to it you could even have a 'super-dmx-universe' of several thousand channels, the LCX keeping track of which channel should go to which box.

    and I'm very happy to say that my installation yesterday worked just fine (and people liked it too..)

    ciao,

    Joost.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •