Home AMX User Forum NetLinx Studio
Options

Constant to Module

Is it possible to send a constant in a module (directly in the define_module line). ]

This is what I have:
define_module 'ClearOneModule' Mic1 (dvClearOne, vdvClearOne_Mic1, nMutes[1], nGain[1], nInstance[1], cInstance[1])

This is what I would like:
define_module 'ClearOneModule' Mic1 (dvClearOne, vdvClearOne_Mic1, nMutes[1], nGain[1], 1, "'I'")

I tried this but it throws an error about constants. I'm not sure if it isn't possible or if I'm doing it wrong. Seems silly to define a variable for a module that never changes

Comments

  • Options
    ericmedleyericmedley Posts: 4,177
    Nope, but you can do a variable. (Which is kinda the same thing as long as you don't change it.)

    I used to do this but all my modules now only pass in the real device for whatever's being controlled and a virtual device for control and messages back to the main program.

    What are you wanting to pass in that has to be a constant?
  • Options
    jabramsonjabramson Posts: 106
    These are keeping track of faders. I've set up 3 modules, each assigned to a fader. The Instance is the numerical ID of the fader, as well as it saying Input, Output, Mix, etc.

    I'm trying to build the module to tracj each type of fader with one set of commands. The gains and mutes are the only variable that is changed.
  • Options
    From Netlinx Help; Constants and expressions cannot be used as arguments in the parameter list.


    Defining A Module

    entry on the first line of the file.

    Syntax:

    MODULE_NAME = '<module name>' [(<parameter list>)]

    The MODULE_NAME entry identifies the file as containing a NetLinx module, as opposed to a standard NetLinx source code file. The module name is any valid string literal not to exceed 64 characters. A file can contain only one module and the file name must be the same as the module name with the addition of the ".AXS" extension.

    Module parameters behave exactly like subroutine parameters; the parameter list is optional. The value for each parameter is set either by the main program or another module. If the value of a parameter is changed, both the main program and the module see the change.

    Constants and expressions cannot be used as arguments in the parameter list.

    Persistent variables do not work in Modules.

    All parameters to a module must be on of the intrinsic types: CHAR, INTEGER, SINTEGER, LONG, SLONG, FLOAT, DOUBLE, DEV, DEVCHAN or DEVLEV. Also, any array of any of the intrinsic types can be used.
  • Options
    ericmedleyericmedley Posts: 4,177
    You could pas in a DEVLEV then. I would personally probably do this in one module but this is from limited information.
  • Options
    viningvining Posts: 4,368
    You can pass constants to modules if they are constant arrays or elements of a constant array.
    DEFINE_CONSTANT //
    
    CHAR NUM_SBS_DEVICES	= 5 ;
    
    CHAR NUM_SBS_1		= 1 ;
    CHAR NUM_SBS_2		= 2 ;
    CHAR NUM_SBS_3		= 3 ;
    CHAR NUM_SBS_4		= 4 ;
    CHAR NUM_SBS_5		= 5 ;
    
    DEV dvSBS_Arry[NUM_SBS_DEVICES]= 
         {
          dvSBS_1
         ,dvSBS_2
         ,dvSBS_3
         ,dvSBS_4
         ,dvSBS_5
         }
    DEV dvSBS_2_Arry[NUM_SBS_DEVICES]= 
         {
          dvSBS_1_2
         ,dvSBS_2_2
         ,dvSBS_3_2
         ,dvSBS_4_2
         ,dvSBS_5_2
         }
    
    DEV vSBS_Arry[NUM_SBS_DEVICES]= 
    
         {
          vSBS_1
         ,vSBS_2
         ,vSBS_3
         ,vSBS_4
         ,vSBS_5
         }
    
    INTEGER INSTANCE_SBS_BOX_ARRY[NUM_SBS_DEVICES] = 
    
         {
          NUM_SBS_1
         ,NUM_SBS_2
         ,NUM_SBS_3
         ,NUM_SBS_4
         ,NUM_SBS_5
         }
    
    CHAR SBS_IPs[NUM_SBS_DEVICES][21]=
         
         {
          '192.168.1.47:9090'	//NUM_SBS_1  blue
         ,'192.168.1.47:9090'  	//NUM_SBS_2  green
         ,'192.168.1.47:9090' 	//NUM_SBS_2  pink..
         ,'192.168.1.47:9090'
         ,'192.168.1.37:9090'
         }
    
    CHAR SBS_MACs[NUM_SBS_DEVICES][17]= 
         
         { 
          '00:04:20:A0:77:59'     //NUM_SBS_1  green
         ,'00:04:20:CF:A7:5E'	//NUM_SBS_2  pink
         ,'00:04:20:58:E0:8F' 	//NUM_SBS_3  gray
         ,'00:04:20:C7:8D:53'     //NUM_SBS_4  black
         ,'00:04:20:23:C5:7A'
         }
    
    
    
    DEFINE_MODULE 'VAV_SBS_Mod' SBS_Mod1(vSBS_Arry[NUM_SBS_1],dvSBS_Arry[NUM_SBS_1],dvSBS_2_Arry[NUM_SBS_1],dvUI_SBSArry,		 
    					     SBS_IPs[NUM_SBS_1],SBS_MACs[NUM_SBS_1],SBS_ArtHost[NUM_SBS_1],
    					     nUI_TypeArry,nUI_SBSActiveArry,INSTANCE_SBS_BOX_ARRY[NUM_SBS_1],
    					     nSBS_Persistent[NUM_SBS_1],nSBS_DeBug);
    
    DEFINE_MODULE 'VAV_SBS_Mod' SBS_Mod2(vSBS_Arry[NUM_SBS_2],dvSBS_Arry[NUM_SBS_2],dvSBS_2_Arry[NUM_SBS_2],dvUI_SBSArry,		 
    					     SBS_IPs[NUM_SBS_2],SBS_MACs[NUM_SBS_2],SBS_ArtHost[NUM_SBS_2],
    					     nUI_TypeArry,nUI_SBSActiveArry,INSTANCE_SBS_BOX_ARRY[NUM_SBS_2],
    					     nSBS_Persistent[NUM_SBS_2],nSBS_DeBug);
    etc....
    
  • Options
    travistravis Posts: 180
    ericmedley wrote: »

    I used to do this but all my modules now only pass in the real device for whatever's being controlled and a virtual device for control and messages back to the main program.

    How do you get the IP address and port in there?
  • Options
    travis wrote: »
    How do you get the IP address and port in there?

    Send_commands to the virtual. This can go in the virtual online event, or elsewhere.
  • Options
    ericmedleyericmedley Posts: 4,177
    travis wrote: »
    How do you get the IP address and port in there?

    As said in the previous post: I create a command routine and send in all the vitals with commands. My commands might look like send_command vdvVirtual, 'IP_ADRESS:192.168.1.25'

    I've already developed a set of routines for handling commands and just copy/paste them into any new modules I write complete with buffering and so forth.

    Why do this instead of just passing values in via the module declaration?

    1). There's a bit of under-the-hood overhead that gets eaten up when you pass values through that are not really necessary.

    2). Values passed through at startup are not as easily changeable on the fly.

    3). Passing what are essentially operating values and setup vial module declaration tends to make the modules less changeable over their lifetime. Example your old module was an rs232 only module but the new one does IP. It is much more difficult to pop the newer IP based module in your old RS232 a system without a serious rewrite. You either need to put a baud rate variable on the IP module that doesn't need to be there and/or and IP Address sting on an RS232 module that doesn't need to be there. In the command-based setup you can even put in some programming to say, " if I get an IP Adress then run the module th IP way, if a baud rate command then run the module the RS232 way. To the main program it's all the same.
  • Options
    jabramsonjabramson Posts: 106
    From the feedback, I made something that works.

    I created a variable that is essentially a constant and assigned that.

    Works for my needs, thanks everyone.
  • Options
    travistravis Posts: 180
    ericmedley wrote: »
    As said in the previous post: I create a command routine and send in all the vitals with commands. My commands might look like send_command vdvVirtual, 'IP_ADRESS:192.168.1.25'

    I've already developed a set of routines for handling commands and just copy/paste them into any new modules I write complete with buffering and so forth.

    .
    Probably should start a new thread.
    All valuable points, but the tradeoff is:
    I can't think of a way to send all that config on startup that isn't way more code than passing in the IP.

    my module section looks like
    define_module 'pjMod'mldPJ1(dv1,vdv1,...ip1)
    define_module 'pjMod'mldPJ1(dv2,vdv2,...ip2)
    ... snip ...
    define_module 'pjMod'mldPJ50(dv50,vdv50,...ip50)

    I'm curious how you go about defining then looking up all the values you need and sending them off to the proper module instance

    Shoot, maybe I could have the list of IPs/Ports/etc in a text file that get's parsed...
  • Options
    Maybe I am doing it wrong, but it works for me.....

    Module
    MODULE_NAME='Tivo_IP_Module' (DEV dvTIVO, DEV dvTPTIVO[], DEV dvTPTIVOFAV[], CHAR cTIVOIP[])
    


    Main code
    DEFINE_CONSTANT
    
    //TIVO MODULE CONSTANTS
    cTIVO1IP[]		=	{'192.168.64.151'}	//IP ADDRESS OF TIVO 1
    
    DEFINE_START
    INCLUDE 'Imerge Include.axi'
    INCLUDE 'i!-EquipmentMonitorOut.axi' // Include to send email
    
    DEFINE_MODULE 'Tivo_IP_Module' TIVO1MODULE (dvTIVO_1, dvTPTIVO_1_ARRAY, dvTPTIVO_1_FAVARRAY, cTIVO1IP)
    

    I was onsite today for an R3 issue and the module works fine.

    Even works with multiple instances:
    //TIVO MODULE CONSTANTS
    cTIVO1IP[]		=	{'192.168.80.188'}	//IP ADDRESS OF TIVO 1
    cTIVO2IP[]		=	{'192.168.80.189'}	//IP ADDRESS OF TIVO 2
    cTIVO3IP[]		=	{'192.168.80.190'}	//IP ADDRESS OF TIVO 3
    cTIVO4IP[]		=	{'192.168.80.191'}	//IP ADDRESS OF TIVO 4
    
    
    DEFINE_START
    DEFINE_MODULE 'Tivo_IP_Module' TIVO1MODULE (dvTIVO1, devTPTIVO1, devTPTIVO1FAV, cTIVO1IP)
    DEFINE_MODULE 'Tivo_IP_Module' TIVO2MODULE (dvTIVO2, devTPTIVO2, devTPTIVO2FAV, cTIVO2IP)
    DEFINE_MODULE 'Tivo_IP_Module' TIVO3MODULE (dvTIVO3, devTPTIVO3, devTPTIVO3FAV, cTIVO3IP)
    DEFINE_MODULE 'Tivo_IP_Module' TIVO4MODULE (dvTIVO4, devTPTIVO4, devTPTIVO4FAV, cTIVO4IP)
    
  • Options
    ericmedleyericmedley Posts: 4,177
    That's an array and that is legal.
    PHSJason wrote: »
    Maybe I am doing it wrong, but it works for me.....

    Module
    MODULE_NAME='Tivo_IP_Module' (DEV dvTIVO, DEV dvTPTIVO[], DEV dvTPTIVOFAV[], CHAR cTIVOIP[])
    


    Main code
    DEFINE_CONSTANT
    
    //TIVO MODULE CONSTANTS
    cTIVO1IP[]		=	{'192.168.64.151'}	//IP ADDRESS OF TIVO 1
    
    DEFINE_START
    INCLUDE 'Imerge Include.axi'
    INCLUDE 'i!-EquipmentMonitorOut.axi' // Include to send email
    
    DEFINE_MODULE 'Tivo_IP_Module' TIVO1MODULE (dvTIVO_1, dvTPTIVO_1_ARRAY, dvTPTIVO_1_FAVARRAY, cTIVO1IP)
    

    I was onsite today for an R3 issue and the module works fine.

    Even works with multiple instances:
    //TIVO MODULE CONSTANTS
    cTIVO1IP[]		=	{'192.168.80.188'}	//IP ADDRESS OF TIVO 1
    cTIVO2IP[]		=	{'192.168.80.189'}	//IP ADDRESS OF TIVO 2
    cTIVO3IP[]		=	{'192.168.80.190'}	//IP ADDRESS OF TIVO 3
    cTIVO4IP[]		=	{'192.168.80.191'}	//IP ADDRESS OF TIVO 4
    
    
    DEFINE_START
    DEFINE_MODULE 'Tivo_IP_Module' TIVO1MODULE (dvTIVO1, devTPTIVO1, devTPTIVO1FAV, cTIVO1IP)
    DEFINE_MODULE 'Tivo_IP_Module' TIVO2MODULE (dvTIVO2, devTPTIVO2, devTPTIVO2FAV, cTIVO2IP)
    DEFINE_MODULE 'Tivo_IP_Module' TIVO3MODULE (dvTIVO3, devTPTIVO3, devTPTIVO3FAV, cTIVO3IP)
    DEFINE_MODULE 'Tivo_IP_Module' TIVO4MODULE (dvTIVO4, devTPTIVO4, devTPTIVO4FAV, cTIVO4IP)
    
  • Options
    GregGGregG Posts: 251
    Not really about using constants either, more about helping with code reuse...
    PHSJason wrote: »
    Maybe I am doing it wrong, but it works for me.....
    Module
    MODULE_NAME='Tivo_IP_Module' (DEV dvTIVO, DEV dvTPTIVO[], DEV dvTPTIVOFAV[], CHAR cTIVOIP[])
    

    Our TV presets module passes variable arrays for the favorite channels (and icons), so we can use those directly in the code and the UI, but it is a separate module from the control for any particular device. That way we can do presets on every device that tunes "0123456789-." in their stations without writing that specifically into any control module. Just include a "TUNE-" command in the control module.

    ericmedley wrote: »
    Example your old module was an rs232 only module but the new one does IP. It is much more difficult to pop the newer IP based module in your old RS232 a system without a serious rewrite.

    For this specific case, we have an "IP connector" module (as long as the protocol is the same) which will control all the needed setup for any kind of IP link, and you can chain the serial module(s) into it. (Warning to programmers who do not know about it, a module like needs to use the TRANSLATE_DEVICE() netlinx function to make the virtual act more like a normal port rather than the broadcasting/reflection normally seen with virtuals - it's a semi-undocumented voodoo command).

    Then we can just do something like this first line to switch a serial module over to IP:
    Define_Module 'IPDeviceConnector' mdlBiAmp(vdvBiAmpIPMod,dvBiampPort)
    
    Define_Module 'BiampVolumes' mdlVols(vdvVol, vdvBiAmpIPMod)
    Define_Module 'BiampATC' mdlATC(vdvATC, vdvBiAmpIPMod)
    Define_Module 'PhonebookStorageUI' mdlPB(dvaAllPanelA,vdvPB,nListNames,nListNumbers,nControls)
    
    Define_Event
    
    Data_Event[vdvBiAmpIPMod]
    {
    	send_command vdvBiAmpIPMod,'IP-192.168.0.102'
    	send_command vdvBiAmpIPMod,'PORT-23'
    	send_command vdvBiAmpIPMod,'DEBUG-1'
    	send_command vdvBiAmpIPMod,'IDLE_OFFLINE-0'
    	send_command vdvBiAmpIPMod,'ENABLE-1'
    }
    // Dial messages from the phonebook module:
    Data_Event[vdvPB]
    {
    	String:
    	{
    	Stack_var Char cDialString[400]
    		cDialString = data.text
    		If(Find_String(cDialString,'DIAL-',1))
    			Send_Command vdvATC,cDialString
    	}
    }
    
Sign In or Register to comment.