Module Netlinx ?

HARMAN_Lanussinio

Hi,

I'm trying to doi a module SNAPI compliant in Netlinx and I want it toworks like a JAR module, but I'm facing issue for the VOL_UP and VOL_DN command.
With th JAR module I'm using a min_to for volume ramping and for the others commands a pulse.
In my netlinx module for the pulse I manage it with a channel event in the comm module but I don't find a way to manage the min_to ?
Any idea ?

ericmedley

Please post the code. Functionally there is no difference between a pulse and a min_to. They both produce a channel on event and a channel off event.

HARMAN_Lanussinio

// From the UI Module

button_event[dvTP,0]
{
push:
{
switch(button.input.channel)
{
case 1: pulse[vdvDevice,PWR_ON]
case 2: pulse[vdvDevice,PWR_OFF]
case 3: min_to[vdvDevice,VOL_UP]
case 4: min_to[vdvDevice,VOL_DN]
case 5: pulse[vdvDevice,VOL_MUTE]
}
}
}

// From the comm Module

channel_event[vdvDevice,0]
{
on:
{
local_var integer nChannel
nChannel = channel.channel
switch(nChannel)
{

case PWR_ON: fnSendCommandToDevice ("cZone,cChannelOn,cETX")
case PWR_OFF: fnSendCommandToDevice ("cZone,cChannelOff,cETX")
case VOL_UP: fnSendCommandToDevice ("cZone,cVolumeUp,cETX")
case VOL_DN: fnSendCommandToDevice ("cZone,cVolumeDn,cETX")
case VOL_MUTE: fnSendCommandToDevice ("cZone,cVolumeMuteToggle,cETX")
}
}
}

The command is only sent one time but I want it to repeat as long the min_to ?

tdewild

Just add this code to the button event in the UI module

HOLD [2,REPEAT]:
{
switch(button.input.channel)
{
case 1: // do your thing
case 2:
case 3:
case 4:
case 5:
}
}

HARMAN_Lanussinio

Thanks, but I wanted to know what is the trick to use min_to instead of the hold keyword.

ericmedley

In Netlinx Studio...
Double click or highlight the keyword Min_to and hit F1. This will bring up the help file for the command. That should give you all the answers you need.

But min_to will not do anything differently than a pulse with the code you show.. In both cases the send string will only fire once.

ericmedley

Here's some code to help you understand how this works. It is actually not the way I'd do it. (It's based on how we used to have to do it back in the Access days but it's helpful to at least understand)

channel_event[myDevice,MyChan]{
	on:{
		channel_on_flag=1
		}
	off:{
		channel_on_flag=0
		}
	}


DEFINE_PROGRAM

if(channel_on_flag){
	wait 3{
		// send the string.
		}
	} //

So, how this works is the statement in define_program is constantly looking for the flag to go positive. when you hit the channel the flag goes positive and the wait 3 loop begins to run over and over sending the string until you let go of the channel thus making the variable go to zero. then the last wait will go through and stop.

this would mimic the behavior of a DUET module as you wish.

A pulse is going to turn the channel on for the default hold time (usually 5/10ths of a second) and then off.

A TO command will turn the channel on when you hit the TP button and then off when you release the TP button (however long you hold it)

A MIN_TO operates like a TO with the exception that also include a parameter of maximum time. So if the person does not release the button within the allotted time, the program does it for them.

A TO or MIN_TO does not cause the channel to repeat it's action over and over again until you let go. It still only fires one 'ON' and one 'OFF'

HARMAN_Lanussinio

Thank's Eric, I thought there was another way to act like a duet module without having to use a variable and fire the event in define_program section when the variable is true.

ericmedley

Lanussinio wrote: »

Thank's Eric, I thought there was another way to act like a duet module without having to use a variable and fire the event in define_program section when the variable is true.

Well, yes there are quire a few ways to pull this off. I would probably use a timeline myself. The principle is still the same either way.

GregG

Lanussinio wrote: »

Thank's Eric, I thought there was another way to act like a duet module without having to use a variable and fire the event in define_program section when the variable is true.

Truth is, if a Duet module is connected to device that only has discreet serial commands for volume ramping, then internally it is doing the exact same thing you have to do here - it just hides it in a black box.