Keeping my module clean

travis

I made a module for a sensor that tells how far away something is. When something gets too close, I want to trigger something; I don't know what yet, but it will be in a different module.

What are some nice ways to trigger something in another module? Right now thinking about using a virtual device.

vining

You could just pass it a variable so its value can be used on both sides of the module.

You can pass it a virtual device and use SEND_STRINGs/COMMANDs to pass info back and forth.

You can pass it a virtual device and track channels or levels.

You can use unused channels and levels on the real device.

Something where the value changes quickly and you want constant real time updates I'd just pass it a variable or a variable array and be done with it.

DHawthorne

My modules pretty much all have a virtual device as an interface, defined as a parameter. I use the virtual with channel and levels for status tracking, and have it handle SEND_COMMANDs for control.

travis

Thanks guys.

what kind of SEND_COMMANDS do you send? Smoething easy to parse...

dthorson

I like to use some of what AMX already does.

Like POWER=1, and that way if you have to add some RMS code into the mix, your virtual device will work seamlessly with their compiled modules.

//in module
DEFINE_CALL 'SEND_STRING_FEEDBACK'(DEV vDev, CHAR cCommand[], CHAR cParameter[])
{
  SEND_STRING vDev,"cCommand,'=',cParameter";
}


CALL 'SEND_STRING_FEEDBACK'(vdvPLASMA,'POWER',ITOA(iPlasmaPower));

DHawthorne

travis wrote: »

Thanks guys.

what kind of SEND_COMMANDS do you send? Something easy to parse...

Whatever you like; like David T does, I mimic the format AMX uses in many of their modules, something on the order of COMMAND=ZONE:PARAMETER .

Spire_Jeff

travis wrote: »

I made a module for a sensor that tells how far away something is. When something gets too close, I want to trigger something; I don't know what yet, but it will be in a different module.

What are some nice ways to trigger something in another module? Right now thinking about using a virtual device.

One approach you could consider is using channel events on the virtual device for the module (or level events). This means that when you want to sound the alarm, you could either Pulse channel 1 (as an example) or simply turn it on. Then in your main code, you create a channel_event[dvVirtual,1] and in the ON: handler, you sound the alarm (This could mean either a send_command to another module, or simply turning on a channel on the virtual device associated with the alarm sounder)

Given that you are tracking distance, you could also use a level event on the virtual device and then in the level handler use a switch..case or a select..active routine to play different audio files depending on the distance.

That's how I would start to approach it. As of late, I've been moving away from sending commands and parsing them and transitioning to channel and level events when possible. Not only is it faster to execute for the processor, it's easier to code (if you have a standard you use for channels).

My 5 cents (the value of the dollar is down, so I didn't want my opinion returned due to insufficient payment )

Jeff

travis

I'm using channel events at it is working well. Thanks.

How do I go about triggering Level Events?

To trigger a channel event I'm using:
PULSE [virtualDevice, channelNumber]

whoops, edit: i'm guessing it has something to do with SEND_LEVEL.

travis

One more thing: Buttons.

Pass arrays of button channel numbers to the module, or just define them in the module?

It's kind of annoying that you can't pass a constant, so you need to make the array a variable. Going into the module and changing things per project is also annoying.

Any other clever ways for the module to know what to do with a button press?

John Gonzales

travis wrote: »

One more thing: Buttons.

Pass arrays of button channel numbers to the module, or just define them in the module?

I personally pass button arrays. For me it's nicer to have the stuff that changes in the main code so I can just do all my editing in one spot. I like to change the modules as little as possible once they're written. Just define and go. I like JJames' way of using DEFINE_VARIABLE multiple times so you can open and close them in the NS2 -- I never used to do that before but I find it very convenient now and it keeps things nicely organized (thanks Jeremiah).

--John

DHawthorne

If it makes sense for the device to handle it's own buttons, I'll pass buttons as an array. I like keeping everything all in one spot.

vining

travise wrote:

Pass arrays of button channel numbers to the module, or just define them in the module?

I do it both ways. Since we have so many ports available to us there's not really a need to shift button channels around for a module so anything that's not likely to change or likely be combined on a port with something else which would require channel changes I say leave it in the module. For devices like TV and cable boxes and simple stuff that you may want to consolidate onto one port and just change the indexed values for the button then I would delcare them outside and then pass them in.

Or if I need to reference the button channel array outside of the module I'll declare it outside and pass it in.

DHawthorne

I don't like to hard code button channels into a module; you never know when you might need to be able to change them. I suppose this is because I will frequently share ports between device modules; I don't like to tie up an entire port, for example, with a 5-button lighting keypad. I've never agreed with the philosophy that just because resources are cheap, it's OK to squander them without due cause. However, when it really does make my life easier, that's due cause enough as long as it doesn't kick it over the performance limiting threshold (pretty hard to do unless the project is huge, but not impossible).

It comes, I suppose, of having started my programming career with having to jam every last bit of resource into a 64K memory footprint. I still find myself using bit fields (sometimes ) where I could as easily make a separate variable for each, and things like that. Younger programmers may scoff, but I think the habit of conserving resources when possible (and when it doesn't require code contortions) makes things run more efficiently.