Home AMX User Forum Duet/Cafe Duet

Why to prefer a Duet Module?

Hello All...

During my relatively short period in AMX programming , I always see two types of modules
Netlinx and Duet... I knew (don't remember from where) that Duet modules are specificly written to work with VA.

With Radia dimmers , I tried to add its module to the device database, but it didn't.

Then Mr. Doug Hall said
Doug Hall wrote:
Sorry for your frustration but our timing was a little off with Radia Eclipse support. Our intention was to align release of Eclipse with VA 1.3 but it did not quite work out. The new release scheduled now for release on Aug 31 includes a new device type "Lighting System" which will allow you to include many Radias but will only show as one "Controller" in the UI view. This will allow you to have one page for lighting control where in the past you would have had one page for each Radia. This release also introduces UI Specific Event Programming that will allow you to have the same button doing different things on different panels. One more thing that you will find useful for lighting is support of user defined variables.
We appreciate your patience and apologize for any inconvenience this has caused you.

Then I used this module with Netlinx, and the only benefit I had is that I can configure the dimmer using a Configuration webpage.
anything else can be done. Add for this , The module doesn't have all the features of the dimmer so I have to use the PASSTHRU command.

Now my question is : What else can I duet module offer me?, What are they anyway? and Should I prefer it rather than the other Netlinx modules? What can be done with duet and not with anotther?

All I know about Duet is it's written in Java using Cafe Duet and written to work with VA.

Thank you
Sensiva

Comments

  • joelwjoelw Posts: 175
    Sensiva wrote:
    Now my question is : What else can I duet module offer me?, What are they anyway? and Should I prefer it rather than the other Netlinx modules? What can be done with duet and not with another?

    All I know about Duet is it's written in Java using Cafe Duet and written to work with VA.

    Duet modules can be written as generic modules for use with NetLinx. VA is not a requirement. So think of it as a generic module, just as NetLinx offers. It is just programmed in Java.

    If you implement the SNAPI classes it will be usable from VA. It will also be available via standard NetLinx, albeit more work.

    You can implement your entire control system programming in Java, right now if you like.

    Java offers features not available in NetLinx or %res$ron. It's up to the programmer to take advantage of the options.
  • SensivaSensiva Posts: 211
    :)
    joelw wrote:
    Duet modules can be written as generic modules for use with NetLinx. VA is not a requirement. So think of it as a generic module, just as NetLinx offers. It is just programmed in Java.

    If you implement the SNAPI classes it will be usable from VA. It will also be available via standard NetLinx, albeit more work.

    You can implement your entire control system programming in Java, right now if you like.

    Java offers features not available in NetLinx or %res$ron. It's up to the programmer to take advantage of the options.
    Well I knew that VA is not a requirement, just after knowing that the current version of Radia Duet module isn't compatible with VA.... So i started to ask.
  • DHawthorneDHawthorne Posts: 4,584
    At this stage of the game, I don't see a difference between using a properly written Duet or NetLinx module. In fact, Duet uses (typically) more memory and has more overhead. I still tend to use them in favor of NetLinx in case there is a performance edge, but so far I haven't seen it.
  • I prefer DUET modules, because of they have a well designed interface.

    Most of the functions are done using channels and levels instead of send_commands and string feedback in netlinx modules.
    Also you have a "device initialized" and "device online" channel to see if the device is there.

    Also you only have to know the "classes" your duet module has.
    If the device has a volume control, it is ALWAYS on the same channels.

    This benefit is also used by AMX itself to test most of the duet modules. If you look at the most recent duet modules, they have made a UI-Module for each class and a AXI file for the buttons. They simply include these files and the testprogram is ready :-)

    So you have "ITGModule" UI file to do the Version and module version stuff. Same for Volume or matrix switching.

    So the main part can be done without reading the manual of the module.
    The first time modules are realy exchangeable :-)

    The disadvantage is the high load of files to transfer after a compile :-(
  • DHawthorneDHawthorne Posts: 4,584
    Most of your reasons for using Duet modules are the same as my reasons for not using them.

    Interface design - I have to re-do it anyway, they don't match the rest of my panels. Most of the Duet modules use that horrible "Platinum" design.

    I absolutely cannot stand the paradigm of using channels to communicate with a module. I would much rather use a SEND_COMMAND. If the command syntax is consistent from device to device, I don't have to change my code at all if the device changes with SEND_COMMANDS. When it uses channels, you got to go through the whole thing to make sure they are the same. Channels were supposed to be standardized, but the implementation has not been perfect. Because I am not using an AMX panel design, and because I do things rather differently, I also cannot guarantee my button channels are going to work with theirs. SEND_COMMAND bypasses all that fuss.

    AMX UI modules are notorious for not working right in any system that has multiple panels or multiple devices. They make no effort to give variables unique names (every one I have seen uses TP_BUTTONS and TP_FEEDBACK ... what if you have 4 modules all requiring the same nomenclature? You have to go through them all and rename them ... mind you, this is in the INCLUDE file, not the module itself, so instancing doesn't apply). It's like they tested them alone on a master. What about working will with the rest of the system? They are getting better, and not all of their UI modules are bad, but I've been stung so many times, I tend to shy away from them.

    A good part of my issues, I admit, is because I don't follow the AMX paradigm for system control 100%. Standardization only woks if everyone does everything the same way. Because I do some things slightly differently, the standardization often doesn't work for me. This is []icustom[/i] control after all though. If I wanted cookie-cutter jobs, I'd be using C.
  • Spire_JeffSpire_Jeff Posts: 1,917
    I'm with Dave on the AMX UI, but I believe those are provided simply to test the module to verify communication and get an idea of the intent of the original coder. (Atleast that's how I use them :) )

    I don't necessarily have any problems integrating the duet modules into my existing code tho. (Part of it is a good sales staff that doesn't change brands and devices like the weather in Michigan, so I don't have to support 15 different DVD players and what not :) ). Any place I have existing code and I think the DUET module offers more reliable communication, I just replace my SEND_COMMANDs with PULSE[devchan]. It also gives me a chance to optimize and add new functionality to the code... if I have time :)

    Jeff
  • Non-Duet modules have been repeatedly and thoroughly bagged in this forum. That may or may not be fair, but most/many folk who have commented have said they won't use them, but will roll their own.

    So what's special about Duet modules? Maybe Duet modules are in some magical manner more reliable than the old non-Duet modules. Maybe they get more attention or more love.
  • SensivaSensiva Posts: 211
    Non-Duet modules have been repeatedly and thoroughly bagged in this forum. That may or may not be fair, but most/many folk who have commented have said they won't use them, but will roll their own.

    So what's special about Duet modules? Maybe Duet modules are in some magical manner more reliable than the old non-Duet modules. Maybe they get more attention or more love.

    PinGo AmiGo!!

    That's what I am talking about, till this moment I didn't get any replies that really say What in Duet better than Non-duet?
    Maybe they get more attention or more love
    Indeeeeeeeed.
  • joelwjoelw Posts: 175
    Sensiva wrote:
    That's what I am talking about, till this moment I didn't get any replies that really say What in Duet better than Non-duet?

    From what perspective?

    Module end user or developer?
  • SensivaSensiva Posts: 211
    Why a user would care about?

    Of course from Developer, I don't think end user would care what modules I am using.
  • joelwjoelw Posts: 175
    There are people who do not develop Duet modules, they just use them. Hence a "Duet module end-user".

    There are a number of possible topics.
    1. Dynamic loading of code at runtime.
    2. Why dynamically load drivers at runtime?
    3. SNAPI programming in Netlinx
    4. SNAPI programming in Duet
    5. Why have a standard API such as SNAPI?
    6. You can program solely in Netlinx or Java, and know zero about the other programming language.


    You cannot dynamically load Netlinx code at run time. This is why Duet exists. In Java one can dynamically load classes at runtime. OSGI - Open Services Gateway Initiative is the framework AMX uses to dynamically lookup/download/load drivers (bundles).

    Perhaps you can be more clear as to what you're looking for.
  • joelwjoelw Posts: 175
    I should also mention that the Duet examples I have posted/published to date will not show up in VA. This is by design. So the mention of Duet does not mean VA. If you utilize the SNAPI in Duet, your device can be used in VA.

    When AMX posts a Duet module, their goal is a VA compatible driver. This is accomplished by their Duet code implementing the SNAPI.
  • SensivaSensiva Posts: 211
    joelw wrote:
    There are people who do not develop Duet modules, they just use them. Hence a "Duet module end-user".
    I thought saying "end-user" means the Customer not programmer.

    So... as I don't get most of the possible topics , let's keep ourselves in discussing "What features can duet modules offer me - (as a Netlinx programmer not a Modules developer) - and Non-duet can't?

    And thanks for your NEAT answer.
  • jweatherjweather Posts: 320
    joelw wrote:
    You cannot dynamically load Netlinx code at run time. This is why Duet exists. In Java one can dynamically load classes at runtime. OSGI - Open Services Gateway Initiative is the framework AMX uses to dynamically lookup/download/load drivers (bundles).
    Do any existing AMX modules actually do this, or is this just a future-proofing kind of feature? I'm sure you've done it yourself, Joel, or even used it in production systems, but I'm talking about existing device-control modules that non-Duet programmers would be downloading from amx.com.

    My impression of why Duet exists (conveyed by my AMX instructor, I think) is that it allows manufacturers to provide modules for their own products, rather than needing a NetLinx programmer on staff or AMX themselves to create the module. Whether this actually happens in practice or not, I don't know...

    Jeremy
  • joelwjoelw Posts: 175
    jweather wrote:
    Do any existing AMX modules actually do this, or is this just a future-proofing kind of feature? I'm sure you've done it yourself, Joel, or even used it in production systems, but I'm talking about existing device-control modules that non-Duet programmers would be downloading from amx.com.

    Good question.

    All Duet modules are OSGI bundles.

    Duet firmware loads two bundles at start.
    http.jar
    morpheus.jar

    If your code defines a bundle that implements a SNAPI interface, then the snapirouter.jar bundle loads, followed by program specified bundles.

    This is based on the OSGI framwork. OSGI is implemented in Java, nothing else. C# does not support dynamic class loading.

    The point behind dynamic device discovery is to be able to uniquely identify a device, and load the appropriate driver. If the device implements the AMX unique id, then it is possible to develop a Duet driver that leverages the bundle search/resolution loading scheme. AMX implemented their own version of the OSGI search/load framework.

    So any Duet module uses all this. You can write a Duet module that does not implement SNAPI in any way. This is the case of my posted examples to date.

    VA leverages the SNAPI. This means Netlinx SNAPI compliant or Duet modules. You can also reference a DDP device in VA. A DDP device is implemented with Duet.

    By being a Duet device does not imply it implements the DDP.

    Why am I attracted to Duet?
    It provides a platform to do things that cannot be done on other control platforms. It also did not earn a "free" public encryption crack the week after it was released. AMX can look at your encrypted Duet code, which is an interesting arrangement.
    jweather wrote:
    My impression of why Duet exists (conveyed by my AMX instructor, I think) is that it allows manufacturers to provide modules for their own products, rather than needing a NetLinx programmer on staff or AMX themselves to create the module. Whether this actually happens in practice or not, I don't know...

    Is the learning curve steeper to pick up Netlinx and it's particulars, or Java J2ME CDC, or Standard Netlinx API (SNAPI) and it's particulars? The argument one could make is Java developers are a dime a dozen. In reality Duet does not implement a complete nor standard JVM implementation. The concepts of which are quite foreign to run of the mill Java developers.

    Use SNAPI if you want to leverage a common API and make your code available to use in VA. Coding against a common API is always a good idea. It allows code reuse on multiple levels, and allows better test coverage of your code.

    I have found SNAPI is best documented in Cafe Duet.

    If you plan to implement SNAPI, be sure to do your homework before you get to the jobsite.
Sign In or Register to comment.