Module communication

a_riot42

Just wondering how others do this. If you write a module for a basic switch or other device that doesn't have a UI, what method do you use to trigger commands? The options typically are do_pushed_timed, send_command, send_string and pulse or on, off. For a simple module with simple commands and no levels, parameters etc, which method do you tend to employ?
Paul

jjames

send_commands & on/off is typically what I use for all, regardless of size or type of module. I use commands to control the module, and strings from the module as feedback. I try to stick with the typical AMX module model.

a_riot42

jjames wrote: »

send_commands & on/off is typically what I use for all, regardless of size or type of module. I use commands to control the module, and strings from the module as feedback. I try to stick with the typical AMX module model.

Yes that seems to be the standard, although I've seen do_pushes on the virtual as well to trigger a button event. Not sure if there are any advantages to using do_push or not.
Paul

papadouk

Once i tried to use both send_command and on/off in a comm module but it looked to me more straight forward to stick with the send_command only.

On the other hand in my UI modules i use the on/off or button types of input.

jjames

Just expanding on some thoughts...

I'll use on/off with channels with displays for example, so when I do an entire system off, it's as simple as pulse[dv_display,28], and that'll take care of all displays, and no need for an additional send_command dvDisplay1,"'POWER=0'". I'll agree that at first it seemed even redundant, but when I realized I could pulse an entire array's power-off-channel and have everything turn off I was sold.

I look at UI modules as just an extension of the main code, and in fact I definitely stay away from doing any type of page flips. UI modules, in my opinion, are for feedback handling only that's within its own file and not for panel navigation as that should be done in main code. I absolutely detest any UI module that takes the liberty of trying to page flip for me, and most likely that page doesn't exist. In fact, that's the first thing I remove when going through UI modules if I have to use them from AMX.

a_riot42

jjames wrote: »

I'll agree that at first it seemed even redundant, but when I realized I could pulse an entire array's power-off-channel and have everything turn off I was sold.

You can do the same with send_command so I don't see that as a huge advantage in and of itself, but POWER=0 does seem a bit much when pulsing a channel accomplishes the same thing.

jjames wrote: »

I look at UI modules as just an extension of the main code, and in fact I definitely stay away from doing any type of page flips. UI modules, in my opinion, are for feedback handling only that's within its own file and not for panel navigation as that should be done in main code. I absolutely detest any UI module that takes the liberty of trying to page flip for me, and most likely that page doesn't exist. In fact, that's the first thing I remove when going through UI modules if I have to use them from AMX.

Agreed. I don't use AMX UI modules, and write that part myself. Their comm modules tend to be well written though.
Paul

jjames

a_riot42 wrote: »

You can do the same with send_command so I don't see that as a huge advantage in and of itself, but POWER=0 does seem a bit much when pulsing a channel accomplishes the same thing.

My comparison should have been clearer - I meant when combining different types of controls, i.e. RS-232 projectors and IR televisions, it'd be easier to just pulse a channel, rather than programming to parse the 'SP' command in your module.

Another consideration *might* be that between sending a command and pulsing a channel to a remote master, it could be more advantageous sending one send_command vs. a pulse command because a pulse would send two ICSP messages (one for on, and another for off) to the remote master whereas the send_command would send one ICSP message. A pulse would send two packets totaling 62 bytes, where as a single send_command of 'POWER=0' would only be 39 bytes. Granted, it's only a difference of 23 bytes, but if you really wanted to split hairs, that'd be a difference worth noting.

So - programmatically it might be easier to pulse a channel (let's face it, channel_events are a bit easier than having to parse text), but in terms of message lengths and number of internal messages - send_command would be a better alternative.

a_riot42

jjames wrote: »

Another consideration *might* be that between sending a command and pulsing a channel to a remote master, it could be more advantageous sending one send_command vs. a pulse command because a pulse would send two ICSP messages (one for on, and another for off) to the remote master whereas the send_command would send one ICSP message. A pulse would send two packets totaling 62 bytes, where as a single send_command of 'POWER=0' would only be 39 bytes. Granted, it's only a difference of 23 bytes, but if you really wanted to split hairs, that'd be a difference worth noting.

Hmm, yes something to consider. I have a feeling pulses are easier on the CPU than send_commands although I have no proof of that so it might end up being a wash. I would consider that less important than the programming ease though. I find writing send_command code tedious and prefer the shortcut of:

button_event[vdvDevice, 0]
{
  sendCmd(sCmds[button.input.channel])
}

but it depends on what the device has to do. Some devices have a different command for each function ie: DOLBYHD, DTSHD, etc, where the above will work and other have a few commands with lots of parameters ie SURR,4 and SURR,5 where it won't as well.
Paul

DHawthorne

I've toyed around with channels and button presses, but I usually go back to SEND_COMMAND. Functionally, they both work, but the SEND_COMMAND is more readable, and if I go back to it 6 months later, I know what "SEND_COMMAND dvReceiver, 'SOURCE=DVD'" means, where "PULSE[dvReceiver, 31]" is not so self-explanatory.

the8thst

90% of my code is using the 'SP' command for controlling IR devices, so I use that for the basic/standard functions that correspond with IR events.

My standard routines are all setup to use

send_command dvDevicesArray[index], "'SP',<IR Chan Number"

I then use specialized send_commands for proprietary functions (ie setting a route in a switcher, setting surround modes, etc).

SURR=ALL_CHANNEL
CONNECT[<input>,<output>] (additional outputs are separated by spaces and kept inside the brackets)
RATIO=16:9

It works for me and and 'SP' parsing is really simple and quick to put in a switch..case or select..active that is already in place for parsing the specialized commands.

All feedback is in the form of string vents from the virtual that gets handled in a UI module. The UI modules only handle button events and text feedback events and popup pages for the one specific device. The main code handles all of the other page flips (which accounts for about 95% of the page flips/popup control in the system).