Home AMX User Forum Duet/Cafe Duet

Duet training materials.

Hi,

I'm AMX programmer since 2008. I write code using Netlinx and Duet modules from AMX webpage.I decided to use my own Duet modules. I bought Cafe Duet and...
Honestly I've no idea how to write own module. First of all I tried to contact with Europe support and I asked about training materials because there isn't duet training in Europe. They haven't those materials, a that first time heard that AMX doesn't support duet programming.
I looked through the whole forum, found some examples (source code) that great but still have no idea how to start.
Does anyone has a short/sample description (ex. step by step) how to write duet module or any materials from that trainig?

Comments

  • vincenvincen Posts: 526
    Don't expect any help from tech support, they are not trained about Duet and AMX doesn't offer any support about it :( All the more Caf? Duet is completely outdated and unusable with new NX controlers ! I attach you a document I got to update by yourself Duet to make it compatible with NX controlers but it's definitively not easy !!!
  • ericmedleyericmedley Posts: 4,177
    We touched on the issue of Cafe Duet's JAVA version base being outdated at Developers Conference. There was some discussion and questions that I feel clued us in that there was something coming down the pipe. Obviously with the new NX platform we need to be working in the current JAVA platform. The question also came up asking us what we thought of JAVA vs. C# That got the expected response of people dividing into their respective camps. There are advantages to both ideas as well as disadvantages.

    Either way, it's pretty clear that something has to change and soon. Netlinx has served us quite well on balance over hte years. It doesn't even have to go away for 90% of what we do. But, the world is moving on and most other control platforms (that are programmed) are moving towards syncing up with whatever flavor being supported by the major players. (JAVA, C#, VBASIC, .NET, etc...) We just have to do it to stay relevant. Not to mention - it will really propel the AMX product into a whole new level of market footprint.

    I don't have a crystal ball nor do I have any kind of inside track. But, I would guess that soon we'll all be looking at a completely different development environment. I'm cool with either JAVA or C#. My personal choice would be C# just because my mind thinks more in that way. But, JAVA is fine too and is pretty much already there inside the box anyway.
  • vincenvincen Posts: 526
    ericmedley wrote: »
    Either way, it's pretty clear that something has to change and soon. Netlinx has served us quite well on balance over hte years. It doesn't even have to go away for 90% of what we do. But, the world is moving on and most other control platforms (that are programmed) are moving towards syncing up with whatever flavor being supported by the major players. (JAVA, C#, VBASIC, .NET, etc...) We just have to do it to stay relevant. Not to mention - it will really propel the AMX product into a whole new level of market footprint.
    Whatever you like we need in all matters more powerful tools like Java for some programming works as it's either a pain in the ass or impossible to do with NetLinx langage and opens lot more opportunities of control !
    ericmedley wrote: »
    I don't have a crystal ball nor do I have any kind of inside track. But, I would guess that soon we'll all be looking at a completely different development environment. I'm cool with either JAVA or C#. My personal choice would be C# just because my mind thinks more in that way. But, JAVA is fine too and is pretty much already there inside the box anyway.
    Well a new development environment might be nice and not Windows centered would be nice, done in QT for example so it could be used on any platform but it frightens me that we'll have to wait one on two years before it's enough stable to be usable...
  • ericmedleyericmedley Posts: 4,177
    vincen wrote: »
    Whatever you like we need in all matters more powerful tools like Java for some programming works as it's either a pain in the *** or impossible to do with NetLinx langage and opens lot more opportunities of control !


    Well a new development environment might be nice and not Windows centered would be nice, done in QT for example so it could be used on any platform but it frightens me that we'll have to wait one on two years before it's enough stable to be usable...



    I agree - If I were to pile on in any area as far as the road map AMX has taken it would be in this area: Development Environment. I spent the last part of the 2000s engineering in a company we started developing a box and software. I felt like we spent an inordinate amount of time working on a box that eventually was obsolete the moment we started shipping. Meanwhile we were having our arses handed to us on the software side because there is an endless supply of teenage programmers perfectly willing to code for free and develop software that does exactly what yours does.

    I'm still of the belief that ultimately what AMX did that was truly innovative was provide a platform for development of UX products; products they ultimately didn't create at AMX but were created by its mid-users (in other words: Us) Unfortunately, they kind of lived and died by us too. Bad programmers made them look bad.

    I feel that by letting the development environment die on the vine, they have quite a bit of catching up to do. Otherwise they are just going to continue to chase their tails trying to keep up in the black box environment. A word of warning in that arena: Even Intel has fallen prey to this. Consider their brand new chip factory in Arizona. Over 5 million square feet of state of the art factory floor space to make the next generation of chips; and they cannot open it due to loss of market.

    I am not throwing AMX under bus here. The whole mess is actually pretty complicated. The main issue is, unlike other technology verticles, most AMX programmers were not raised as computer programmers. They tend to be AV technicians/AV integrators who had to learn it to do what they do. Most programmers I run into fall into this category. I came from a programming background and have always operated in this way. If AMX were a software company, they would have just hired lock-stock-and-barrel a whole new bunch of programmers to do whatever flavor they wanted to run with. But, instead they would have had an all out bloody war from their dealers who were just barely hanging on by their finger tips.

    I know a lot of us programming wonks on the forum here would cheer and shed tears of joy if over night we had a new java and/or C# development environment chock full of publically available libraries etc.... But, I can assure you the vast majority of AMX dealers would look at their technicians and just say, "Screw it! I'm going over to Craptoron. I don't have to retrain anyone for that."

    I personally hope we just bite the bullet and do it because I know within a short time period we could be making new AMX based UX products that would blow the doors of the other players out there who are realistically only a few steps ahead of us.
  • mstocummstocum Posts: 120
    ericmedley wrote: »
    I am not throwing AMX under bus here. The whole mess is actually pretty complicated. The main issue is, unlike other technology verticles, most AMX programmers were not raised as computer programmers. They tend to be AV technicians/AV integrators who had to learn it to do what they do. Most programmers I run into fall into this category

    I really feel like this is the biggest issue I see as an end user. I've gotten to the point where I just put in my RFPs that I'll be doing all of the AMX programming, because I've had to rewrite every project in the past. It's complicated, AMX is clearly trying to provide a system non-programmers can use with RPM, and I applaud their efforts. But every time I've tried to use it myself, I just start looking at what I'm losing, and give up.

    If I were going to give a list of what I'd want to see from AMX in the future, any updated programming environment would be at the top of my list. I don't care if it's Java 8, C#, hell, I'd be fine with PHP, just something that has support for all these neat features programming languages have picked up since 2002. I'd have to say next on my list though would be HTML based touch panels and support for just pointing a web browser at a master to open touch panel.
  • imsocoimsoco Posts: 46
    The last thing I would want to see is something that is radically different that would require more training to do the same job we did last year. I agree AMX needs to keep up, but when my clients are asking for less control, NEST type devices might be out biggest competitor.
    Even worse would be a new release with failed documentation and support. Changes in the NX series made a simple swap out a nightmare of return service calls without a real solution except to buy a matching old processor from eBay. If the documentation was more clear and tech support agents trained better on the changes I would not have taken that path to upgrade. The tech support call I made was reversed with me educating the the tech. The tech support crew are great guys, but they were let down as well.
  • a_riot42a_riot42 Posts: 1,624
    imsoco wrote: »
    NEST type devices might be out biggest competitor.

    I sincerely doubt it. Most of these type products will be flash in the pan things that come and go. I hate the NEST tstat, and their API sucks. I really can't find one good thing about it other than its a product marketing people like since they can tag it with all the buzzwords of the day.
    Paul
  • ericmedleyericmedley Posts: 4,177
    imsoco wrote: »
    The last thing I would want to see is something that is radically different that would require more training to do the same job we did last year. I agree AMX needs to keep up, but when my clients are asking for less control, NEST type devices might be out biggest competitor.
    Even worse would be a new release with failed documentation and support. Changes in the NX series made a simple swap out a nightmare of return service calls without a real solution except to buy a matching old processor from eBay. If the documentation was more clear and tech support agents trained better on the changes I would not have taken that path to upgrade. The tech support call I made was reversed with me educating the the tech. The tech support crew are great guys, but they were let down as well.


    I guess that's pretty much the nut of the problem: Where does our business fit into the overall picture of the market? I know in my case the Resi market vanished in about one business cycle. We've beat the reasons for this dead horse into hamburger on the forum here. But, there are always exceptions to the rule. (as it may be in your case) I'm not one who likes to stay on a sinking ship until it sinks. I saw how things like Savant were gaining a foothold in the market space. However, I also saw that all the bottom-feeders were also gaining a foothold. So, if Savant wants to be the biggest fish in a rapidly evaporating pond, have at it. It was easy for me to see (first hand in some of my ventures) that even though we had some good ideas, it was nothing for a larger company to come in with 10 times the resources and recreate what I'd come up with in a tenth the time. To make matters even worse, they were not pouring all they had into it - thus making it an "all or nothing" proposition for them. if the thing went obsolete in 18 months, no biggie. Just move on to the next thing... This is the NEST/Control 4/etc environment.

    In my opinion AVIT is by its very nature a technology-based enterprise. The rules are printed right on the box. The current technology cycle is running about 16 months from release to obsolescence. If what we do cannot keep up with this fact then we don't stand a chance. Part of that keeping up is and will be training and development in things we currently don't do, like standardized programming environments and so forth.

    There's an interesting concept known as "Jumping the gap" that I feel really applies to us and is also something from which we can benefit. The idea is that the typical way technology moves is 1) a technology is invented. 2) the initiators get the thing out there and either sell it for cash or make a lot doing it themselves. 3) others come along and steal/copy/alter/improve/etc.. the technology - thus nibbling away at the market share 4) some new technology comes along that doesn't seem to mean much but in the end replaces the old technology.

    In this cycle, some companies try to reinvent what they do or try out performing the new upstart. Quite often they invest so heavily in hanging on to their market that in the end they find that they cannot span the gap they've created by hanging on and end up shutting down. Meanwhile the little new company is safely standing on the other side of the gap ready to roll. Wash Rinse Repeat.

    It's just my opinion, but I honestly don't think there's much of a case to be made for Resi right now from a business standpoint. Admittedly, that's just the view from my little window of the market. I'm not in anyone else's shoes. My only defense in saying this is that I don't see a lot of folks on this forum or anywhere else I troll who rave about how well Resi is doing. This includes Savant/Craptron/Control 4/ etc... It's just a rough place to be what with every Tom, Dick and Harry who pulls wire in a house slapping a "Home Integration" wrapper on their van. The margins are just too tight to be profitable at the end of the year.
  • imsocoimsoco Posts: 46
    I mentioned NEST specifically because I also hate it. I met with the owners at their first exhibit at the CES inside another booth. (They had made a deal to stick it on the wall in the booth where we installed an AMX system for control.) I expected it to disappear by now. The key element they hit on was marketing. Consumers don't understand how to get what they want and will do what you tell them if you repeat the message enough.
  • rynandorynando Posts: 68
    Extron is, or is about to begin, allowing you to code for their control products in Python. It'll be interesting to watch that develop as Python is popular in the hobbyist embedded computing space, as well as just about every other space imaginable.

    On the AMX side of things, I'd be happy with a current version of Java and letting us leverage the IDE of our choice. I've written quite a few Duet modules and being able to use tests has been the biggest win for me there. Everything I've done in Duet I could have done in Netlinx but, for me at least, being able to execute and test code without having to push it to a Netlinx controller is a big, big deal. Being able to use other modern libraries would epic. Java's not my favorite language but its productive and there're no limit to the libraries and tooling available to Java devs.
  • vincenvincen Posts: 526
    rynando wrote: »
    Extron is, or is about to begin, allowing you to code for their control products in Python. It'll be interesting to watch that develop as Python is popular in the hobbyist embedded computing space, as well as just about every other space imaginable.

    On the AMX side of things, I'd be happy with a current version of Java and letting us leverage the IDE of our choice. I've written quite a few Duet modules and being able to use tests has been the biggest win for me there. Everything I've done in Duet I could have done in Netlinx but, for me at least, being able to execute and test code without having to push it to a Netlinx controller is a big, big deal. Being able to use other modern libraries would epic. Java's not my favorite language but its productive and there're no limit to the libraries and tooling available to Java devs.
    Fully agree with your last point about Duet, just so bad that AMX still has not updated it to be usable with current controllers released one year ago already !! Perhaps the competition of Extron will awake them !
  • AMXJeffAMXJeff Posts: 450
    vincen wrote: »
    Fully agree with your last point about Duet, just so bad that AMX still has not updated it to be usable with current controllers released one year ago already !! Perhaps the competition of Extron will awake them !

    Vncen, I really am not sure what you mean by saying that duet is not usable in the current controller? I write duet modules everyday, and I am not having issues with them not being usable in the new controllers.
  • vincenvincen Posts: 526
    AMXJeff wrote: »
    Vncen, I really am not sure what you mean by saying that duet is not usable in the current controller? I write duet modules everyday, and I am not having issues with them not being usable in the new controllers.
    very confused here as NX controlers use a new more standard Java Engine not supported by Caf? Duet (or you need to tweak it a lot to succeed to get it working with correct Java environment for NX). Am I wrong ?
  • JasonSJasonS Posts: 229
    Regardless of the fact that you can sill use Cafe Duet with the NX controllers, the fact that we are still stuck at JDK 1.4 is REALLY FRUSTRATING!!! There have been so many improvements to Java since 1.4, Generics alone make the update absolutely necessary. This is just another one of those instances where the AMX community feels that AMX is letting us down, and making our jobs more difficult than necessary.
  • GregGGregG Posts: 251
    vincen wrote: »
    very confused here as NX controlers use a new more standard Java Engine not supported by Caf? Duet (or you need to tweak it a lot to succeed to get it working with correct Java environment for NX). Am I wrong ?


    The newer standard java is not supported by cafe duet, yet (without hacking a bit). However, the old java level that cafe duet can generate is supported by the NX master. It's like running a basic windows 7 program on windows 10, you can expect it will probably just work.
  • vincen wrote: »
    very confused here as NX controlers use a new more standard Java Engine not supported by Caf? Duet (or you need to tweak it a lot to succeed to get it working with correct Java environment for NX). Am I wrong ?

    Supported with Caf? Duet without issue.
  • AMXJeffAMXJeff Posts: 450
    vincen wrote: »
    very confused here as NX controlers use a new more standard Java Engine not supported by Caf? Duet (or you need to tweak it a lot to succeed to get it working with correct Java environment for NX). Am I wrong ?

    I do not need to tweak the duet module to work in the NX. I test the modules in the NX and NI and it.s rare that they act differently,
  • vincenvincen Posts: 526
    JasonS wrote: »
    This is just another one of those instances where the AMX community feels that AMX is letting us down, and making our jobs more difficult than necessary.
    It's not "feel", it's reality ! bugs that last since ages without being corrected clearly confirms that :(
  • vincenvincen Posts: 526
    GregG wrote: »
    The newer standard java is not supported by cafe duet, yet (without hacking a bit). However, the old java level that cafe duet can generate is supported by the NX master. It's like running a basic windows 7 program on windows 10, you can expect it will probably just work.
    Yep but we loose all interest of updated Java Engine in NX that gives lot more capabilities !
  • AMXJeffAMXJeff Posts: 450
    vincen wrote: »
    Yep but we loose all interest of updated Java Engine in NX that gives lot more capabilities !

    To be honest, the modules my company (not AMX) creates need to be compatible with all the current controllers (NI and NX). It does us no good to start using features that the updated Java Engine offer, if only the NX controllers can use. We create modules for the "other" control company, and although we would love to do more with the SIMPL# platform, our customers still want old an new controllers supported, which is a bummer there too.

    To JasonS point, somethings would make our lives easier, and nice to have. But until the NI are not available and the customer are actually removing them from services, we need to stay on 1.4.
  • JasonSJasonS Posts: 229
    AMXJeff wrote: »

    To be honest, the modules my company (not AMX) creates need to be compatible with all the current controllers (NI and NX). It does us no good to start using features that the updated Java Engine offer, if only the NX controllers can use. We create modules for the "other" control company, and although we would love to do more with the SIMPL# platform, our customers still want old an new controllers supported, which is a bummer there too.

    To JasonS point, somethings would make our lives easier, and nice to have. But until the NI are not available and the customer are actually removing them from services, we need to stay on 1.4.


    I understand what you are saying but I disagree. When the 4.x series of firmware came out with an updated Java (SE vs. ME), you could choose which version you wanted to use. Maybe "choose" is the wrong word. if you wanted to use the Updated version you had to go thru a very laborious process to make it work. It can be the same way with the NX processors, when AMX updates Cafe Duet (ROFL), they need to have multiple "project templates" so you can choose your level of compatibility for older processors/firmware. Everyone shouldn't be limited to one version for compatibility sake. The second thing is that NI processors are End of Life, even if there are plenty of them hanging around their serial ports will be dead pretty soon anyway!
  • PhreaKPhreaK Posts: 966
    Amen to that! When products with new capabilities are released, appropriate tooling should be an essential part of that release.
  • vincenvincen Posts: 526
    PhreaK wrote: »
    Amen to that! When products with new capabilities are released, appropriate tooling should be an essential part of that release.
    definitively but AMX doesn't hear it this way with Duet :(
Sign In or Register to comment.