• Date
    MCDELTAT
  • Date
  • Replies 6 replies
  • Subscribers 67 subscribers
  • Views 9164 views
  • Users 0 members are here

Additional Data Byte for Sensor Installation Rack Communication?

Hey guys. I have a question for you guys that I need to figure out. I've been going through the process of building an open-source lighting application in MaxMSP that (for now) is being output through an Arduino USB to DMX512 converter. Images and details here: http://iad.projects.zhdk.ch/physicalcomputing/hardware/arduino/dmx-shield-fur-arduino/

I finally got a code that worked perfectly with several Chauvet min Spot Fixtures that I was testing with. I could use my software to control those particular fixtures sending straight DMX512 protocol, I.E. Channel, Value (0-255)

When I went to go test on my rack though it didn't work. I'm using an older Sensor 48+ Installation Rack from about 6 years ago with the necessary analog converter with 5 Pin wall jacks. To get an idea of it's age, rather than the newer CEM+ Control Module I have a module with the blue button keypads (0-9, Dimmer, Thru, etc.).  I didn't get an error message when I pressed reset, rather it just said the same thing "Port A1 Ready." I had all my virtual faders up so that I could verify if it was doing anything at all. I verified with my Leprecon LP-X console that the rack was working and that was able to dim fixtures just like i normally would from the same wall jack and that was fine. 

Thus the question is: 1. Is there any additional data byte that I need to know about when trying to communicate with these racks, as in setting a com port or sending a binary 1 to tell the rack that a console is plugged into it? It seems that what data was working on my Chauvet fixtures should also work on the rack. 

2. Is there a potential problem since I'm using a converter cable to go from 3-Pin DMX to 5-Pin for my wall jack? I made sure they were all connected, but it certainly does add a variable I didn't have to worry about with my Chauvet fixtures. 

Thanks in advance for any help that you can give me. 

-Aaron C.
MCDELTAT Productions

P.S. It was recommended that I purchase the PDF or hardcopy of the ANSI DMX512-A Protocol Specifications. Are there any developers that have found this handy? I didn't want to purchase it just yet because I don't believe it would address the issue that  I'm having above. 

Parents

  • In addition to Tom's response, I would suggest using a DMX tester to verify that you are sending valid DMX from your device.

    I'm not sure what you mean when you say the Sensor rack has the "necessary analog converter"- the rack should accept DMX directly.

    What version of software is on your Sensor CEM module?  Does the CEM display change when your device is connected?  Does it display the same thing when your Leprecon console is connected?

    On the CEM, press [About] [2](rack) and press the right arrow until it displays "DMX Port A" status. It should read "OK" if the rack is getting valid DMX, "No Input" if it is not connected, and "Data Err" if there is a problem with the DMX input. Press the right arrow again to check port B status.

    If the rack is seeing valid DMX with your device connected, then it might be a softpatch issue in your software or addressing of the rack.

    -Todd

     

     

  • in reply to tdrga

    Any specific DMX tester you use or recommend? I scoured the internet real briefly and saw some that decent and some that look atrocious and don't want to waste my money. 

    I'm not sure if the pins are correct but I'm assuming they are. It's a Neutrik 3pin male to 5pin female connector. 

    Not sure about the software version either, I looked through all the pages using the "about" button and didn't find what looked like a version number. 

    I do however have more information for you on what happens when I plug my device in. When I plug my console in I get the "OK" in the about page for DMX Port A. When I plug in my custom Arduino USB to DMX converter it says "No Input" it doesn't even create an error, it just says it's not there. Since I'm building my own software in MaxMSP do I have to send out a message to address port A before beginning to send DMX data to the rack.

    Once I get a DMX tester I'll check my cable. I'll probably buy a different converter as well just to try my luck. That seems to me like it is the problem right now. 

  • in reply to MCDELTAT

    Doug Fleenor and Goddard Design both make good testers, though they're not the only ones who do.  They'll give you detailed information about the DMX packet you're sending and whether or not you've got all the timing and formatting correct.

    You should be able to check the 3-5 pin adapter pretty easily if you have a continuity tester.  Pin 1 should connect to pin 1, 2 to 2, and 3 to 3. 

    There is no special signal that must be sent to a Sensor rack.  If it doesn't recognize the data you're sending it, it's because the Sensor rack doesn't think the data is formatted correctly (assuming you've got the wiring right).  A DMX tester will help you track down this kind of problem.

  • in reply to MCDELTAT

    I'm not shy about it…I love The Gizmo by Doug Fleener. Been using DMX testers for years and wish I had a Gizmo a long time ago….just my 2 cents..there are other good testers



    [edited by: mmeskill at 6:57 PM (GMT -6) on Mon, Sep 13 2010]
  • in reply to mmeskill

    I've had a 'Lil DMXer for years.  Its an older version, so it does not have the RDM or show-saver functions.  That said:

    Pro: useful functions for both field and bench work.  It is able to look and display packet information such as timing and start codes.  It also has a scope trigger output to allow easy syncing of the start of the DMX string to a scope.  It is able to modify packet specs for transmitting, such as number of dimmers, and timing specs.  This is very useful for proving out dimmers (did you ever notice that not all dimmers actually work with all legal flavors of DMX?)  You can also see the packet.  It also flags out of spec problems, such as wiring and timing.  The cable tester injects signal down the first pair, not just a continuity tester.

    Con: large form-factor, i.e its big.  The battery is not cheap(sealed lead-acid) and I only get a few years out of them.  The battery issue may not exist anymore...mine is an older one.

    I, of course, have no connection to Goddard Design...but a little swag for the good word is never un-appreciated....should Robert or anyone see this....

Reply
  • in reply to mmeskill

    I've had a 'Lil DMXer for years.  Its an older version, so it does not have the RDM or show-saver functions.  That said:

    Pro: useful functions for both field and bench work.  It is able to look and display packet information such as timing and start codes.  It also has a scope trigger output to allow easy syncing of the start of the DMX string to a scope.  It is able to modify packet specs for transmitting, such as number of dimmers, and timing specs.  This is very useful for proving out dimmers (did you ever notice that not all dimmers actually work with all legal flavors of DMX?)  You can also see the packet.  It also flags out of spec problems, such as wiring and timing.  The cable tester injects signal down the first pair, not just a continuity tester.

    Con: large form-factor, i.e its big.  The battery is not cheap(sealed lead-acid) and I only get a few years out of them.  The battery issue may not exist anymore...mine is an older one.

    I, of course, have no connection to Goddard Design...but a little swag for the good word is never un-appreciated....should Robert or anyone see this....

Children
No Data
Related

www.etcconnect.com