Page 2 of 6 FirstFirst 1234 ... LastLast
Results 11 to 20 of 53

Thread: DIYC official DMX Manufacturer ID

  1. #11
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    Some more thoughts on this. My "can't remember" proposal is based on the model that I take down all my equipment, (some of which looks very similar) and store it in a heap for 10 months, and then try to remember which unit is which. From my own experience, and perhaps this is simply OMS speaking (old man syndrome), I quickly lose track of which is which when they are stored in a box together.

    *for arguments sake I'm saying PIC and PIC Programmer, but this could apply to other micro's as well*

    I can only think of two scenarios when you would change the serial number on a device.
    1. First time the device is being programmed.
    2. You have forgotten the serial number and must program a new one, so that you can program a DMX address.


    I think it's safe to argue that in the first case you would already have the device connected to a pickit (or similar), and thus the device is unlikely to be connected to the rest of the DMX chain. It could also be argued that you could use the pickit to write the serial number to begin with as well. But if you have the option to write the number afterwards, I'm sure that it would be used. The point here being that I think it unlikely that the device would still be connected to the DMX universe at this point in time, thus the use of the NEW serial number message, minus the old serial number would be safe.

    In the second case, if don't know the existing serial number, the "program NEW serial number" command would be useless if it required the presence of the old (unknown) serial number to do so. So you would be forced to pull out the PIC programmer again. This is my bigger concern.

    I can't think of any other scenario where we would re-program the serial number.

    As to the old DMX address as part of the new DMX address message. If the serial number is used to uniquely identify the device, I don't see what role/function there is in sending the old address, other than to reduce false positives. The checksum will prevent this. As such, I think it only likely to get in the way for those times when the DMX address is not known. In *those* scenarios, the operator would be stuck, doing a binary search of the Universe to figure out the old address, or forced to pulling out the PIC programmer and mucking with the EEPROM directly.


    In general I'm much better with a whiteboard, for this type of discussion. If anything in here reads of sarcasm, snarkyness (is that a word?), or rudeness. Please go back and read it again, but choosing a different "voice in your head". Trying to keep this level and technical. It's a good discussion so far, and precisely the sort of thing I expect while we decide how a new protocol should work.
    Standard Disclaimers apply:
    "Product may not appear as shown, your mileage may vary, I'm not a doctor nor do I play one on television, these are not the droids you seek"

  2. #12
    Join Date
    Feb 2010
    Posts
    54
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    Quote Originally Posted by LabRat View Post
    The DMX stream then becomes
    0x91 <MFID-HIGH> <MFID-LOW> <PAYLOAD>

    (note MFID= 0x586D )

    For ProgAddress (CMD=<0x01>)
    0x91 <MFID-HIGH> <MFID-LOW> <0x01> <SERIAL-HI> <SERIAL-LOW> <DMXADDR-H> <DMXADDR-L> <CHECKSUM>

    For ProgSerialNo (CMD=<0x02>)
    0x91 <MFID-HIGH> <MFID-LOW> <0x02> <NEW_SERIAL-HI> <NEW_SERIAL-LOW> <CHECKSUM>
    (typically used in a point-to-point communication - as it would cause *ALL* devices connected to the stream
    to reprogram to the same Serial Number. Suitable warnings to prevent the user doing this inadvertently must be included.)

    Why on earth are you inventing your own mechanism and not using RDM???

  3. #13
    Join Date
    Jun 2007
    Location
    WI
    Posts
    2,611
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    Quote Originally Posted by nomis52 View Post
    Why on earth are you inventing your own mechanism and not using RDM???
    I agree with your position but also realize that implementing RDM in a uC is not a trivial task. In addition before the days of RDM a number of vendors would use special start codes to update firmware and change addressing so really this isn't all that odd.
    DMX, RDM, ArtNet, sACN, and RDMnet...the future of DIY Christmas.
    Designer of the PropController an open source single-board hardware platform designed for lighting and prop control.

  4. #14
    Join Date
    Feb 2010
    Posts
    54
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    Quote Originally Posted by DynamoBen View Post
    I agree with your position but also realize that implementing RDM in a uC is not a trivial task.
    I didn't claim it was trivial , a decent number of people have done it though.

    Also if you actually design this to solve the problems people have, you're going to end up with something that looks like RDM. For instance people will want discovery, no one wants to have to remember all the device ids in their rig.

    Quote Originally Posted by DynamoBen View Post
    In addition before the days of RDM a number of vendors would use special start codes to update firmware and change addressing so really this isn't all that odd.
    Yes, and since RDM was standardized more and more of them are dropping their proprietary start codes and using RDM simply because it *is* a standard.

    Simon

  5. #15
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    My understanding of RDM is that it is a bi-directional protocol. We don't have that capability in most the hardware that I had thought to fit this into.
    Standard Disclaimers apply:
    "Product may not appear as shown, your mileage may vary, I'm not a doctor nor do I play one on television, these are not the droids you seek"

  6. #16
    Join Date
    Jun 2007
    Location
    WI
    Posts
    2,611
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    Quote Originally Posted by LabRat View Post
    My understanding of RDM is that it is a bi-directional protocol. We don't have that capability in most the hardware that I had thought to fit this into.
    Good point. With that said it is worth while to design for this in the future.
    DMX, RDM, ArtNet, sACN, and RDMnet...the future of DIY Christmas.
    Designer of the PropController an open source single-board hardware platform designed for lighting and prop control.

  7. #17
    Join Date
    Feb 2010
    Posts
    54
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    Quote Originally Posted by LabRat View Post
    My understanding of RDM is that it is a bi-directional protocol. We don't have that capability in most the hardware that I had thought to fit this into.
    Realistically unidirectional communication is next to useless for transactional messages (which is what you're trying to build here). What good is it to set the start address if you can't confirm that the action has taken place? This model will work fine for one device, but at 10 and beyond it's a pain to deal with.

  8. #18
    Join Date
    Jun 2009
    Location
    Ottawa, Ontario, Canada
    Posts
    2,845
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    Set address to 10

    Bring device 10 up to 50% brightness..

    I'd say it's pretty easy to check if the functionality has worked.

    (No sarcasm intended... it truly is how I would go about doing this)
    Frankly we could add an automatic "flash when completed" option to the programming dialog, or
    the pop-up window could include two fields "SerialNO""DMX Address", and two buttons "PROGRAM" and "TEST".


    Yes.. this is not how a commercial system would do it. There's no question about that. But this is DIYC hobbyist land, not commercial solutions with bells/whistles and bi-directional communications. Our task is to push our existing hardware to the limits. Occasionally we have breakthroughs that puts us ahead of the commercial folks, but they tend to catch up quickly. Most of the time we trail behind with "best efforts to achieve near same behaviour".

    The problem at hand.. existing devices (REN series) to which some people want to convert to DMX. These devices don't have dip-switches, and don't have the ability talk back to the server, and the thought of using a PICKIT to reprogram the DMX start address sends people screaming back into their tinsel coated workshops. There's a solution on the table that seems to address the need.

    Now comes the tricky bit, as I don't want this to sound all "pissy etc", so I'm trying very hard to word this correctly.
    If you think this solution won't work, then please point out the flaws. I realize that postings and emails can so often sound combative, and that isn't my intent. I believe that I have given reasons/evidence as to why the "you should just use RDM" counter proposals won't work for this particular use/situation. RDM is a better choice *IF* you have two way communication. We don't. So what's the alternative for these existing products?




    Quote Originally Posted by nomis52 View Post
    Realistically unidirectional communication is next to useless for transactional messages (which is what you're trying to build here). What good is it to set the start address if you can't confirm that the action has taken place? This model will work fine for one device, but at 10 and beyond it's a pain to deal with.
    Standard Disclaimers apply:
    "Product may not appear as shown, your mileage may vary, I'm not a doctor nor do I play one on television, these are not the droids you seek"

  9. #19
    Join Date
    Feb 2010
    Posts
    54
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    Quote Originally Posted by LabRat View Post
    The problem at hand.. existing devices (REN series) to which some people want to convert to DMX. These devices don't have dip-switches, and don't have the ability talk back to the server, and the thought of using a PICKIT to reprogram the DMX start address sends people screaming back into their tinsel coated workshops. There's a solution on the table that seems to address the need.

    Now comes the tricky bit, as I don't want this to sound all "pissy etc", so I'm trying very hard to word this correctly.
    If you think this solution won't work, then please point out the flaws. I realize that postings and emails can so often sound combative, and that isn't my intent. I believe that I have given reasons/evidence as to why the "you should just use RDM" counter proposals won't work for this particular use/situation. RDM is a better choice *IF* you have two way communication. We don't. So what's the alternative for these existing products?
    This is the answer to my original question. Like you say, if you don't have bidirectional communication this is the best you've got.

  10. #20
    Join Date
    Mar 2010
    Location
    Leesburg Florida
    Posts
    2,490
    Post Thanks / Like

    Default Re: DIYC official DMX Manufacturer ID

    Anything that can be done to make things a bit easier sounds good to me,,,
    just my 2 cents..

Page 2 of 6 FirstFirst 1234 ... LastLast

Bookmarks

Posting Permissions

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