Home AMX User Forum AMXForums Archive Threads Residential Forum

question about modules

gentlemen,
i have a very elemetary question and please forgive my ignorance on netlinx as i will be posting several of these to come. I try and use the technotes etc. to the best of my ability but it dosent always explain or ilustrate things in a way that i understand them. (i require real step by step baby talk until i get it) So please bare with me, i wasnt a programmer before this , and ive been working on this netlinx thing going on 2 years now. I think ive developed enough of a programmer background now to finally do this right. here goes:

its a best practice to utilize modules when adding a device to a system be they pre-written or done on your own.
modules are seperate "mini" programs" in seperate files that work within the netlinx main program.
if i have 3 devices;
DVD player
media server
tivo
I use 3 modules. How do these modules work with each other if i have to create a macro to turn on TV, power on DVD, media server and Tivo?

Thanks in advance.

Comments

  • Good question. The individual modules are generic and know all about their individual boxes and nothing about your system as a whole. You need to create "glue code" to hold it all together - that is, a separate control module, which in a complex system is *much* larger than the device driver modules.

    Your touchpanel typically has three classes of button:

    (a) Device transport - play, pause etc - pass these directly to the driver modules to action.

    (b) Navigation - do this locally in the touchpanel if it's real simple.

    (c) Device selection, etc - the control module handles these, and sends the appropriate collection of button pushes (power on/off, source selection etc) to the other modules.

    I note that you don't have a TV module - you need one. I presume that switching is happening in the TV?
  • jisaacjisaac Posts: 34
    Thanks NmarkRoberts.
    the devices i mentioned were just an imaginary example.
    i suppose when you say control module, you mean everything thats not a "device" module ie, all your automation macros , subroutines , functions etc. The real program?

    but if i had to create a macro to turn on 3 imaginary devices that each used netlinx modules , would my code say "hey module for DVD, execute your power on command" , "hey module for Media Server, execute your power on command", and so on.
    how would this look?

    thanks.
  • jisaac wrote:
    would my code say "hey module for DVD, execute your power on command" , "hey module for Media Server, execute your power on command", and so on.
    how would this look?
    do_push(vDVD,tpDVDPowerOn)
    do_push(vMediaServer,tpMediaServerPowerOn)
    

    vDVD and vMediaServer are virtual devices passed from the mainline into the control module header and the relevant module headers.

    tpXXX are the channel numbers used in the driver modules.
  • Joe HebertJoe Hebert Posts: 2,159
    jisasc wrote:
    would my code say "hey module for DVD, execute your power on command" , "hey module for Media Server, execute your power on command", and so on. how would this look?
    do_push(vDVD,tpDVDPowerOn)
    do_push(vMediaServer,tpMediaServerPowerOn)
    
    vDVD and vMediaServer are virtual devices passed from the mainline into the control module header and the relevant module headers.

    tpXXX are the channel numbers used in the driver modules
    I very rarely ever use DO_PUSH and only do so if I have to. The only instance I can think of off hand is the Audio Request module:
    DO_PUSH[arqTP1,200] //connect to zone 1

    All modules that I write use ON, OFF, PULSE, and TO. I try to stick to the AMX standard whenever possible for channels. Power on is always channel 27, Power off is always channel 28, etc. If simple channels aren?t enough then I?ll SEND_COMMANDs to the virtual device passed into the module. Some examples of what you would see are:

    PULSE[vdvDVD,nPowerOn] //power on the dvd
    PULSE[vdvMediaServer,nPowerOn] //power on the media server
    TO[vdvReceiver,nVolUp] //ramp volume up while channel is held high
    ON[vdvReceiver,nDebugChan] //turn module debugging on
    OFF[vdvReceiver,nDebugChan] //turn module debugging off
    SEND_COMMAND vdvReceiver,?VOL=25? //set volume to 25%

    Curious as to why you recommend DO_PUSH to interface with modules?
    wrote:
    I try and use the technotes etc. to the best of my ability but it dosent always explain or ilustrate things in a way that i understand them.
    Try doing a search for modules in the forum. There are some good examples and several enlightening discussions covering the topic as this forum has become a wealthy depository of valuable information. And of course you if don?t find what you?re looking for, feel free to post away.
  • Joe Hebert wrote:
    Curious as to why you recommend DO_PUSH to interface with modules?

    NetLinx programming of device drivers appears to be a process of finding what does and doesn't work.

    To be honest I actually use do_push_timed(xx,xx,1) and the comment I wrote some while ago says that the .1s timing prevents a hold from activating; it works and has worked for a while. When I wrote that post I couldn't thoroughly justify that choice so I didn't go there. If you reckon PULSE works that's fine by me.
  • DHawthorneDHawthorne Posts: 4,584
    I have noticed that there are cases where PULSE will not work, when DO_PUSH will. Not having the source for the modules where this happens (the NetLinx modules for the Phast audio switches is a good example), I can't say why this is. I have come, however, to standardize on using DO_PUSH. Back in my original programming class, we were told this was bad programming - sort of like GOTO in BASIC, but like GOTO, there are times when it really is the best way to do things. Triggering a button push in an otherwise self-contained module is one of them.
  • Joe HebertJoe Hebert Posts: 2,159
    DHawthorne wrote:
    Triggering a button push in an otherwise self-contained module is one of them.
    Maybe we?re not talking apples to apples. I don?t use BUTTON_EVENTs in my Comm modules. I?ve standardized on CHANNEL_EVENTs and I haven?t come across an instance yet where ON,OFF, TO, and PULSE didn?t behave as expected.

    If I have a UI module or a UI Comm combo module then I do use BUTTON_EVENTs, however, if necessary, I?ll also setup channels that call the same functions as some of the BUTTON_EVENTs to avoid the whole DO_PUSH thing. For example, let?s say I have a UI module that has a BUTTON_EVENT to do a refresh of some data (perhaps weather.) If the TP generates the BUTTON_EVENT for a refresh then all is good. But there may be times where I?ll want to generate a refresh via code in the main program. In that instance I?ll PULSE the refresh CHANNEL rather than DO_PUSH the refresh BUTTON.

    I also find it much easier to TO a CHANNEL then to DO_PUSH/DO_RELEASE.a BUTTON.

    I?ll use DO_PUSH if I have no other alternative as in the case you stated. I just never liked DO_PUSH, it doesn?t sit right with me. Maybe it?s partly because of the old Axcess days. It?s been a long time but I?m pretty sure DO_PUSH didn?t behave the same as a PUSH. Or maybe I?m just being pig headed. :)

    To do the DO or not do the DO, that is the question.

    Good topic of conversation?
  • GSLogicGSLogic Posts: 562
    Joe Hebert wrote:
    I just never liked DO_PUSH, it doesn?t sit right with me. Maybe it?s partly because of the old Axcess days.

    I don't know why but I feel the same why too!
  • mpullinmpullin Posts: 949
    DHawthorne wrote:
    Triggering a button push in an otherwise self-contained module is one of them.
    I'm going to agree with Dave here, especially in the case of modules that are too complicated to mess with, such as the VRQ. The VRQ has no parental controls built into it, but I was able to reassign the play button on the touchpanel to a button that I designed in my main program, and if the user logged into the touchpanel is an adult, I call the original play button with a DO_PUSH. This technique doesn't require me to know how the VRQ's module works at all. (although I did have to learn the vrq protocol for other reasons)
  • alexanboalexanbo Posts: 282
    Just to add a bit to the discussion, I also use channel events to trigger stuff in my modules and stay away from button events. Additionally I also usually implement the SP command so that my control code doesn't care if the device it's talking to is IR or Serial.

    For example if you send "'SP',27" to the DVD, if I have a serially controlled DVD player the module will interpret that command and send the correct string.
  • jisaacjisaac Posts: 34
    thanks for the lively discussions guys.
    im trying to load a module for the Escient FP1 (can be had here):
    http://www.escient.com/support/intamx.html (its the first one.)

    i figure its a good way to learn modules. I opened NLS and put files where they are supposed to go, Main file in the main folder in the work space, Module file in the module folder in the work space, 800x600 TP4 file in the UI folder in the work space.

    when i hit "build active system" i get the following errors:

    Starting NetLinx Compile - Version[2.3.0.0] [03-20-2007 13:33:02]
    \\.PSF\XP Shared\amx\EscientFireBallAMXDemov5\FireBall Module v5_0_1.axs
    WARNING: \\.PSF\XP Shared\amx\EscientFireBallAMXDemov5\FireBall Module v5_0_1.axs(0)The pre-processor is unable to find the directory \XP Shared\amx\EscientFireBallAMXDemov5\ in the Library path. Ignoring directory and continuing...
    WARNING: \\.PSF\XP Shared\amx\EscientFireBallAMXDemov5\FireBall Module v5_0_1.axs(0)The pre-processor is unable to find the directory \XP Shared\amx\EscientFireBallAMXDemov5\ in the given path. Ignoring directory and continuing...
    ERROR: (0): C10580: Internal Error: Major system error occurred during code generation
    \\.PSF\XP Shared\amx\EscientFireBallAMXDemov5\FireBall Module v5_0_1.axs - 1 error(s), 2 warning(s)
    NetLinx Compile Complete [03-20-2007 13:33:02]

    Starting NetLinx Compile - Version[2.3.0.0] [03-20-2007 13:33:02]
    \\.PSF\XP Shared\amx\EscientFireBallAMXDemov5\Escient FireBall v5.0.1.axs
    WARNING: \\.PSF\XP Shared\amx\EscientFireBallAMXDemov5\Escient FireBall v5.0.1.axs(0)The pre-processor is unable to find the directory \XP Shared\amx\EscientFireBallAMXDemov5\ in the Library path. Ignoring directory and continuing...
    WARNING: \\.PSF\XP Shared\amx\EscientFireBallAMXDemov5\Escient FireBall v5.0.1.axs(0)The pre-processor is unable to find the directory \XP Shared\amx\EscientFireBallAMXDemov5\ in the given path. Ignoring directory and continuing...
    ERROR: (0): C10580: Internal Error: Major system error occurred during code generation
    \\.PSF\XP Shared\amx\EscientFireBallAMXDemov5\Escient FireBall v5.0.1.axs - 1 error(s), 2 warning(s)
    NetLinx Compile Complete [03-20-2007 13:33:03]

    >>>>--- NetLinx Compiles: 2 Files 2 Total Error(s) 4 Total Warnings(s) ---<<<<
  • DHawthorneDHawthorne Posts: 4,584
    The "main" file for the Escient module is not a module, It is an example of how to implement the module in your code. You have to cut and paste (and edit, if necessary) the components into your own master code.

    It also looks like you have some bad paths in your workspace. Double check the properties and make sure they point to actual files.
  • jisaacjisaac Posts: 34
    Thanks DHawthorne,
    i dont have any programming to do other than the escient. I just want to get one device up and running for practice. I did put a file labeled module in the module folder, and im sure i would have to edit the main file (Example to cut and paste from) and put that in the main folder (this module was written for 6 panels, i only want one 8400 setup).

    as for the errors, i am using a Mac with a parallels session of XP. the "psf" directory stands for "parallels shared folder". This way its visible to both the windows session and mac. I think ill just put that escient file i downloaded into another folder all together.

    Thanks!
Sign In or Register to comment.