Options
Dynamic Modules
PhreaK
Posts: 966
I'm aware that this topic has been sort of discussed before (http://www.amxforums.com/showpost.php?p=19494&postcount=12) however I just wondering what experiences others have had with this. I'm currently in the processes of rolling my own device discovery-esk type thing. It's to be used in a standardised system that uses a few different plasma's depending on the installation. Basically the method I'm currently taking is a selection of code that runs when the master comes online and will step through a list of possible baud rates and check the ports in order to grab a make, model and serial number (where available) of the attached devices. In an ideal world I'd love to be able to dynamically load the required control modules from a selection already on the controller (or even better - on a local ftp server), all of which use a standardised interface and behaviour. However it's looking like I'm going to have to just have a standardised funtion set (eg fnPlasmaSetPower, fnPlasmaSetInput etc) which will fire of the required commands. Just fishing for other ideas or even different ways others have approached similar challenges.
0
Comments
I'd talked about doing something like this in the past, too. I think it would be fun. The problem was (in my situation) we never had enough similar systems to warrant the time needed to invest in the programming side of things. It was always much quicker (and easier) to program each system.
The closest thing I came to what you are talking about is I created a common code base that had one of two dvd players. I had a structure array for the rooms to specify which dvd player was in the room (definitely not an "on the fly" setup). I had a module for each dvd mfg (232 controlled), and in the module signature I passed a flag to indicate if the module was active or not. Both modules used the same virtual device for communication with the master file, but at run time one module did stuff while the other module did nothing.
It worked (quite well, actually) but it never felt good having to completely include modules that half the time were not used. I'm not sure there is any way to have the master, at run time, add any additional code to the system.
Off the top of my head, though, you could have a "shell" module for each device type that could determine the mfg/model, then pull a text file (xml?) from an FTP server that had all the correct control strings, then just load them into variables in the module. One-way this wouldn't be that bad (once the mfg/model was determined). The hairy part would be how to handle the device feedback.....
For example I've written an include file that deals with the TVs in our installations. In our typical installations we might have anywhere from 10-20 TVs that need controlling. They range from full-bore Home Theaters to simple TV with a cable box. Sometimes they share distributed sources throughtout the installation. Sometimes they have Surround recievers for sound. Sometimes they use the Distributed House Audio system for sound. Sometimes they're controlled by IR, by RS-232, by IP. (you get the picture)
Keeping tabs on this and on which touch panels were able to control which TV was getting to be a nightmare. So, I spent some time creating an include file that has set of functions that deal with all that stuff.
The TP interface for all TVs is basically the same. (three popups) 1 popup comes out with the possible sources for that TV. antoher comes out to control the volume/mute/preset volume and a fader to show the current volume level. the third popup is the controls for whatever source is selected. The buttons are the same from touch panel to touch panel.(example 101 is always 'shut down the system')
TVs are simply given an ID number that is referenced in the code. So, if the room is a Man Cave and has 4 TVs, I don't get into the whole craziness of which tV is which and when they should be on or off. They are just numbers.
A butotn event simply sends a command to the function. TV_Funtion(ID1,Button101) The function then translates what needs to happen to make it so.
Nothing that fancy or revolutionary. I've thought about doing device discovery before from this. It would be a fairly simple thing to do. But, since I'm the only programmer here, it's much easier for me to just say, "TV 1 is a Runco 65" with DHD processor controlled by rs-232. It's audio processor is a Classe' controlled by RS-232. Cable is source 1. Kaleidescape is source 2, etc..."
The search for the Unifying Code For Everything continues....
Thats not a bad idea. I've started heading down a similar path. At the moment I'm working on a 'Device Sense' module which basically allows me to instanciate it with a virtual and the d:p:s where the device to interrogate is located. Once that it has got the device talking it will pass back the make, model and serial number for use in the control logic and RMS. Thankfully the system this is intended for have a standardised control port layout (eg port 1 is a VC unit, ports 2 is an switcher, ports 3 through 5 are displays etc) so as you mentioned, grabbing an XML file may be the way to go after this as with a bit of planning I should be able to come up with a standard shell file for each category of device which will utilize the XML for control strings, and some basic behavioural info (ie how long the device takes to warm up etc). On the feedback side I'm starting to think that it may be easier to seperate this so that I basically end up with a generic 'Device Sense' module, a control module and a feedback module which via the main program updates a tracking structure. With this rig I should be able to control the devices and when information is returned that informs we a device is not in the state the code is wanting it to be in (ie someone has used a hard button on the device) I can fire back the required control to set it to where it needs to be.
Sometimes I wonder why whats wrong with just having a whiteboard and some phones that support video calls