Options
Module Programming for the new guy...
TrikinCurt
Posts: 158
Ok, my first post, be gentle...
I have been through the designer and installer class, programming is over a month a way. I want to start writing my first module. The good news is I know how to program (C, C++, C#, anything that starts with C...). I can hack my way through Studio and get it to do what I want.
So, since modules tend to be written in Java now (I am ordering Cafe Duet today) I can't find a good example on how to write one in studio. Is there a good example with source code I can learn from out there? Everything I download is hidden in a TKO file so I am hoping I can get a starter from somewhere.
Thanks,
Curt
Trikin
I have been through the designer and installer class, programming is over a month a way. I want to start writing my first module. The good news is I know how to program (C, C++, C#, anything that starts with C...). I can hack my way through Studio and get it to do what I want.
So, since modules tend to be written in Java now (I am ordering Cafe Duet today) I can't find a good example on how to write one in studio. Is there a good example with source code I can learn from out there? Everything I download is hidden in a TKO file so I am hoping I can get a starter from somewhere.
Thanks,
Curt
Trikin
0
Comments
I expect the programming landscape to evolve so that this does not remain the case, but as of this moment I have a "if it ain't broken, don't fix it" attitude about writing modules in NetLinx.
With that said, is there a walk through or good example on how to write a module in Netlinx? A standard module with a COMM and UI, where do I start?
Curt
http://amx.com/techsupport/techNote.asp?id=375
So the idea of a UI module is to make it easier to have more than one touch panel, correct? Without a virtual touch panel you would be duplicating code for each touch, with you just instance the same module a few times, correct?
Curt
Trikin
Correct. Usually in modules that have a Comm and UI part there is one Comm and as many UI modules as you have panels.
Well, there is nothing that prevents you creating a single module that has a virtual touchpanel. So this is not the objective of the separation.
The objective of the separation is to be able to deliver in .tko form the module communication code (and f.e. obfuscate the controlled device API), while at the same time delivering functional UI code that is likely to require modification in actual use.
A novice user or simple usage can use both module as is.
Intermediate users or usages can do changes to the UI module
Advanced usages or users just forget the UI module completely
For AMX, doing it this way provides a lot of flexibility for module users while providing some assurance on communication (can't break it if you can't change it).
Fred
I wish that wasn't true. I'd rather see one UI module per group of touch panels (something I'm starting to do in my modules) that are controlling a single device by using DEV arrays. This would cut down on overhead and remove the need for creating a virtual touch panel and parse all the information sent to it (the virtual) to send to real panels that only need the information and queue it for a panel that will need it once it goes to a specific page; a practice that removes plenty of unnecessary network traffic and relieves the master of processing unneeded commands.
Unless it's already broken . . . then we're S.O.L. Luckily, that's rarely the case.
Agreed. I don't like at all the paradigm of adding a dozen modules to a program becasue I have a dozen panels. I can live with it though, and I am not about to re-invent the wheel, for example, with something like the MAX UI module. When rolling my own, I prefer to make the panels an array, and set a flag for any panel currently using the device to cut back on traffic. I lean away from combining to virtuals whenever I have the option; often alternative methods work as well without some of the weirdness associated with combines (for example, having to dedicate a port on the panel and all it's memory space to a singe device ... if you aren't running it off a combine, you can share those resources).
It uses master resources, I don't think the panel cares. If you declare a panel device, it sets aside resources to control and track all possible channels, address, and levels for that port, whether you use them or not. Furthermore, it allocates resources for any ports you haven't declared if you declared port numbers above it. We were warned in one of the programming classes to use contiguous port numbers, and start with port 1 for this reason. If you, for example, declare a panel with port 1 and port 100, the master allocates all the resources for ports 2-99 as well, even though you aren't using them.
In most applications, unless you go ape, it's not going to matter; I'm just of the "if you don't need it, don't allocate memory for it school" ... which comes from the old days of having to fit code into 64K memory blocks
The declaring ports thing using up memory had to do with declaring ports on the master only, ie 0:2:0. Note you were actually you were supposed to start on port 0:3:0 because 0:1:0 is the master and 0:2:0 was originally reserved by engineering for future use.
That's correct. I guess I misspoke using the word "declare;" I was refering to assigning the port in the panel file. But you still have to be careful; it's not limited to master ports. I have accidentally put a channel number in the port field, and my code went and allocated resuorces for 200 panel ports ... as I said, it doesn't seem to bother the panel that you have ports the code doesn't reference, but it does affect master resources. It will eventually affect performance as well, since the master does loop through all those references looking for events.