Pass multiple devices in DEFINE_MODULE

mstocummstocum Junior MemberPosts: 119
Is there an easy way to pass multiple devices to a single Duet module in the DEFINE_MODULE() statement? I fully understand how to modify the MODULE_NAME line in the generated AXS file in Cafe Duet. What I'm looking for is if there are additional properties I can set in DUET_PROPERTIES to support additional devices (or some other method which would achieve the same result), and how they'd be exposed on the Duet side.

Comments

  • AMXJeffAMXJeff Senior Member Posts: 450
    mstocum wrote: »
    Is there an easy way to pass multiple devices to a single Duet module in the DEFINE_MODULE() statement? I fully understand how to modify the MODULE_NAME line in the generated AXS file in Cafe Duet. What I'm looking for is if there are additional properties I can set in DUET_PROPERTIES to support additional devices (or some other method which would achieve the same result), and how they'd be exposed on the Duet side.

    First the answer is yes! But you have to be writing the duet module, are you? If not, the question that comes to mind is, why? What are you trying to do?
  • mstocummstocum Junior Member Posts: 119
    AMXJeff wrote: »
    First the answer is yes! But you have to be writing the duet module, are you? If not, the question that comes to mind is, why? What are you trying to do?

    I'm just getting started with Duet, and I was looking to replicate a NetLinx classroom module I currently use. We have multiple classrooms running off a single controller, so I just have a classroom module per room, which gets the vdvs for all of the various devices (projectors, DVD player, touch panel, etc.) and to provide an RMS interface for remote management and reporting. I also mimic certain SNAPI behaviors for the classroom, channel 255 can be used to start up or shutdown the classroom, level 1 exposes is the main program audio level for them room.

    So now, I'm looking for the best way to recreate that behavior in Duet. Doing this all in Duet compared to NetLinx may not be the best idea, but I thought it would be a good project to learn with.
  • AMXJeffAMXJeff Senior Member Posts: 450
    Hmmm... Duet modules' strength lie in creating individual communication modules for equipment, like projectors. What you want to do is provide both UI and communication functionality in a duet module. A duet module is fully capable of doing this, but since you are new to this it maybe a little far-reaching for your first module.

    But... to answer your question... in order to pass in multiple devices in to a duet module, you got to create additional properties in the NetLinx wrapper module.

    Add DEV to the module header
    MODULE_NAME='Classroom_dr1_0_0' (DEV dvDuetDevice, DEV dvPhysicalDevice, DEV dvProjector)
    

    Increase size of the array and provide a placeholder for the new device
    CHAR DUET_PROPERTIES[10][47] = 
    {
    	'Physical-Device',
    	'Duet-Device',
    	'Projector',
    	'Duet-Module=Classroom_dr1_0_0',
    	'Bundle-Version=1.0.0',
    	'Device-Category=ip',
    	'Device-Make=Classroom',
    	'Device-Model=Classroom',
    	'Device-SDKClass=com.amx.duet.devicesdk.Utility',
    	'Device-Revision=1.0.0'
    }
    

    Assign the DPS the properties array.
    DUET_PROPERTIES[3] = "'Projector',FORMAT('%d:',dvProjector.NUMBER),FORMAT('%d:',dvProjector.PORT),FORMAT('%d',dvProjector.SYSTEM)";
    

    The device list will show up in the "props" of the contructor to your module.
    public Classroom(BundleContext bctxt, NetLinxDevice nd, Properties props) 
    

    You can also for go all of this, and send commands into your duet module, after the module is loaded, setting the device addresses.
    SEND_COMMAND dvDuetDevice,'PROPERTY-Projector,5001:1:0'
    SEND_COMMAND dvDuetDevice,'PROPERTY-TouchPanel,10001:1:0'
    
  • JasonSJasonS If I had known it was going to be that kind of party... Posts: 228
    And after you have modified your module stub, DO NOT choose the regenerate project option, as this will over write your module stub. You might think about passing them thru send commands to the module. You don't have to deal with a lot of the limitations we have become accustomed to in NetLinx when you program in Java. My first Duet "module" was not a traditional module either, it is a learning experience. Be prepared for very little to no support from AMX in this endeavor. I learned much more from people in the forums than I did from AMX. Do not limit yourself to the "module" mentality. I find that I learn the most when pushing the boundaries. Good luck!
  • mstocummstocum Junior Member Posts: 119
    AMXJeff wrote: »
    You can also for go all of this, and send commands into your duet module, after the module is loaded, setting the device addresses.
    SEND_COMMAND dvDuetDevice,'PROPERTY-Projector,5001:1:0'
    SEND_COMMAND dvDuetDevice,'PROPERTY-TouchPanel,10001:1:0'
    

    I think that might be my approach. I do realize this is an extremely ambitious project where I am right now, and I have some other smaller projects I'm working on first. With that said, are there any good getting started with Duet documents out there? The tutorial that comes with Cafe Duet is rather, shall we say, simplistic. It's going to be a while before I can get out to Texas for training.
  • sonnysonny Junior Member Posts: 208
    mstocum wrote: »
    So now, I'm looking for the best way to recreate that behavior in Duet. Doing this all in Duet compared to NetLinx may not be the best idea, but I thought it would be a good project to learn with.

    Personally I would probably avoid this. I do a lot of stuff in Duet but have kept all UI on the Netlinx side for several reasons. First, it's just too easy to do in Netlinx given all the built-in plumbing. It wouldn't be an issue to build this on the Java side, but the lack of documentation on how to work with all the event handling classes would make it laborious and frustrating. Second, I've started implementing everything on the Java side to be as portable as possible, so I want as few AMX-specific classes as possible. For example, my serial drivers now reference a SerialPort interface vs. talking directly to a Netlinx port. I use a serial-port factory class to provide a platform-specific serial port class to the driver class. This allows me to easily move to another platform, which I've done for both Modbus and Aprilaire.

    As far as adding devices to DEFINE_MODULE, I've stayed away from this as well. Using custom commands to add functionality at run-time gives you a more flexible approach, IMO. I've got an Aprilaire driver that can poll devices on 1..n serial ports. Instead of passing these in through properties I created an "add-port" command that my driver responds to. To me this better fits an object-oriented approach vs. parsing through properties at startup.
  • sonnysonny Junior Member Posts: 208
    mstocum wrote: »
    With that said, are there any good getting started with Duet documents out there? The tutorial that comes with Cafe Duet is rather, shall we say, simplistic. It's going to be a while before I can get out to Texas for training.

    Nothing that I have seen, I got Cafe Duet the day it shipped originally and had a very difficult time getting information/help. There were parts of the sub-system that were broken that I had to find work-arounds for and it was very frustrating. When I have issues now I send an email to tech support asking them to please route my question to the appropriate person.

    I'm not sure how strong the community is, but something like a wiki or GitHub account where examples, work-arounds, etc. could be shared. This forum is nice, but not really the best format, mainly due to the weak search and categorization.

    I would also recommend getting a good primer on OSGi. I have OSGi in Action from Manning Press.
  • mstocummstocum Junior Member Posts: 119
    sonny wrote: »
    I would also recommend getting a good primer on OSGi. I have OSGi in Action from Manning Press.

    I'm reading OSGi in Practice now.
  • JasonSJasonS If I had known it was going to be that kind of party... Posts: 228
    sonny wrote: »
    Personally I would probably avoid this. I do a lot of stuff in Duet but have kept all UI on the Netlinx side for several reasons. First, it's just too easy to do in Netlinx given all the built-in plumbing. It wouldn't be an issue to build this on the Java side, but the lack of documentation on how to work with all the event handling classes would make it laborious and frustrating.

    I have implemented UIs in Duet, and I like it! I have found the UI to be noticeably faster! It is also easy to do Mainline loop style feedback in a separate thread using an inner class that implements Runnable. One of the UIs I wrote uses a 10 item list using 10 buttons, scrolling thru the list is so fast you don't even see the individual button text updating. It is also very easy to scroll thru an ArrayList using the sublist method to return a List interface. Everything is in there you just have to do some digging and make some educated guesses.
    sonny wrote: »
    Second, I've started implementing everything on the Java side to be as portable as possible, so I want as few AMX-specific classes as possible.

    I see this opinion a lot in reference to Duet but I disagree for two reasons. First, anything else I write in Java is not going to be written in JDK 1.4, of course code written for JDK 1.4 can be used in newer JDK's, but this brings me to my next reason. If you code using OO concepts, i.e MVC (Model View Controller) it will be easy to reuse the classes that pertain to what you want to do on another platform without having any AMX specific classes required. Besides, a lot of the AMX classes are helper classes that you may want to avoid anyway. There are many classes that try to emulate how things are done in NetLinx, i.e. File IO, that actually limit the power and flexibility available in Java.

    I also highly recommend "Head First Design Patterns" to anyone who has not read it yet.
  • sonnysonny Junior Member Posts: 208
    JasonS wrote: »
    I see this opinion a lot in reference to Duet but I disagree for two reasons. First, anything else I write in Java is not going to be written in JDK 1.4, of course code written for JDK 1.4 can be used in newer JDK's, but this brings me to my next reason. If you code using OO concepts, i.e MVC (Model View Controller) it will be easy to reuse the classes that pertain to what you want to do on another platform without having any AMX specific classes required. Besides, a lot of the AMX classes are helper classes that you may want to avoid anyway. There are many classes that try to emulate how things are done in NetLinx, i.e. File IO, that actually limit the power and flexibility available in Java.

    I also highly recommend "Head First Design Patterns" to anyone who has not read it yet.

    That's a great book, the format is awesome. It basically led me to pulling AMX specific stuff out of the "model/controller" classes into classes that implement an interface. My thermostat class, for example, receives an "adapter" class that it uses to interact with the view side. In the AMX version this is a class that implements all the various NetLinx event handlers.
  • PhreaKPhreaK Senior Member Posts: 966
    First of all, nice work on getting started with Duet. Rather than thinking about having one module to rule them all you may find it much simpler to keep your modules, well... modular. Duet runs the OSGi framework which lets you do some awesome things when it comes to inter-module communication.

    This enables you to still build a module for interaction with a single device, making this simple and self contained. Even more importantly you can grab a module for device X that has already been build by someone else. From here you connect your modules together using the OSGi services registry. This way you can still have a 'core system' and/or UI module built in Duet if you like, but dynamically wire it to your device control modules as required.

    One of the super nice things here is that RMS will be plug and play for you to. Just point it at your device modules using the RMS SDK and you are done.

    For some Duet examples keep an eye on the AMX Australia GitHub page. We'll be putting up some projects there over the next couple of months.

    Also, nice idea on the wiki sonny. I've put up a shiny new one just for this. If anyone you like to contribute any nuggets of awesome I've left this publicly editable. Feel free to add in links to your own projects, any approaches to specific problems that you've had success with other other general Duet guff.
  • I added AMX's "building java modules" training power point to Kim's Documentation Wiki
  • HARMAN_icraigieHARMAN_icraigie Technical Trainer II, Harman Professional University Posts: 469
    "A subscription for this thread has been added..."
  • sonnysonny Junior Member Posts: 208
    PhreaK wrote: »
    Also, nice idea on the wiki sonny. I've put up a shiny new one just for this. If anyone you like to contribute any nuggets of awesome I've left this publicly editable. Feel free to add in links to your own projects, any approaches to specific problems that you've had success with other other general Duet guff.


    Cool!!! As I get time I'll upload some stuff I've done.
Sign In or Register to comment.