Module Programming for the new guy...

TrikinCurt

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

DHawthorne

I haven't found (yet) that the overhead in time and learning has justified writing a Duet module. If one is already available from AMX, I'll use it, but that is as far as I have taken it. For most devices, writing them in NetLinx has been more than adequate.

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.

TrikinCurt

Thanks Dave. I am still wondering though, coming in at the time I am (now), if it is not better to go Java as it seems they are banking on that going forward. I am a Java certifed guy, so I have the advantage of knowing the language, it is a lot more comfortable for me than 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

[Deleted User]

refer to this

http://amx.com/techsupport/techNote.asp?id=375

TrikinCurt

Heh, perfect, thanks!

DHawthorne

That's NetLinx, not Duet.

TrikinCurt

Actually that is what i was looking for. I wanted to learn the NetLinX way first. Of course, now I realize there really isn't much to a module or to creating one, so no real worries. Been new to AMX it just took me a few hours to figure out sending out a serial port is as simple as send_string, no need to use any sort of connect statement or open or anything, sometimes the simple things are the hardest...

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

mpullin

TrikinCurt wrote:

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?

Correct. Usually in modules that have a Comm and UI part there is one Comm and as many UI modules as you have panels.

frthomas

TrikinCurt wrote:

So the idea of a UI module is to make it easier to have more than one touch panel, correct? tual touch panel you would be duplicating code for each touch, with you just instanWithout a virce the same module a few times, correct?

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

jjames

mpullin wrote:

Usually in modules that have a Comm and UI part there is one Comm and as many UI modules as you have panels.

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.

frthomas wrote:

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).

Unless it's already broken . . . then we're S.O.L. Luckily, that's rarely the case.

DHawthorne

jjames wrote:

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..

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).

jjames

DHawthorne wrote:

...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).

If you use other ports on a panel, does that really take up more memory on the panel? I've never noticed.

DHawthorne

jjames wrote:

If you use other ports on a panel, does that really take up more memory on the panel? I've never noticed.

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 .

alexanbo

For touchpanels the ports that show up are determined by the panel file not anything you declare in code. If a panel connects to your master with a file that has 8 ports in it, 8 ports will show up on the master regardless of what your code says.

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.

DHawthorne

alexanbo wrote:

For touchpanels the ports that show up are determined by the panel file not anything you declare in code. If a panel connects to your master with a file that has 8 ports in it, 8 ports will show up on the master regardless of what your code says.

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.

Joe Hebert

DHawthorne wrote:

I have accidentally put a channel number in the port field, and my code went and allocated resuorces for 200 panel ports ...

That's a pretty good trick considering there are only 100 ports max.

DHawthorne

Joe Hebert wrote:

That's a pretty good trick considering there are only 100 ports max.

Heh, I have no idea what the actual number was, except it was pretty high, so I guessed for the sake of the post. Forgot the actual limits ... Mea culpa.