Home AMX User Forum AMXForums Archive Threads Tips and Tricks

Clean Disk,et al

I had to switch out an NI-3000 that was being slaved in a system, and was subbing in my own NI-3000 that I use as a loaner. After configuring D:P:S and IP, wasn't sure what program was previously on the unit, so I ran a clean disk, loaded ir files, confirmed url connection on the main master and started testing. Serials and IR's worked fine, but Relays and I/O's would not function until I loaded a empty template program on the controller and rebooted. Just an FYI in case anyone runs across this issue.

Comments

  • ericmedleyericmedley Posts: 4,177
    I pretty much always put some kind of program on any and all masters in a system. I too have found some goofiness if I don't.
  • ppdkppdk Posts: 31
    And if i am not mistaken, a simple program containing only the devices needed to intercom between systems must be downloaded in the M2M Masters.
  • banobano Posts: 173
    ppdk wrote: »
    And if i am not mistaken, a simple program containing only the devices needed to intercom between systems must be downloaded in the M2M Masters.

    I did not define any devices in the shell program I down loaded, just used an existing NetLinx template, compiled and loaded into the controller, which enabled the relays and I/O's to start functioning.
  • TurnipTruckTurnipTruck Posts: 1,485
    I was taught that at least one local device must be defined in a "blank" program.

    Sent from my MB865 using Tapatalk
  • viningvining Posts: 4,368
    I also seem to recall there needing to be 1 non-volatile variable declared in the program but that didn't seem to be needed in bano's case.
  • banobano Posts: 173
    vining wrote: »
    I also seem to recall there needing to be 1 non-volatile variable declared in the program but that didn't seem to be needed in bano's case.

    This was pretty much why I started this thread. In the past, I always load a blank template along with ir files, if needed, on all "slaves" and let the master do all the heavy lifting. Never been a fan of code distribution among controllers, but I'm a resi guy and I'm sure there are compelling reasons to do so in the commercial realm. Maybe AMX Engineering can weigh in on this topic.
  • ericmedleyericmedley Posts: 4,177
    Vining, I think this is still true. I still put one in like this

    DEFINE_VARIABLE

    _Bandaid
  • jjamesjjames Posts: 2,908
    I too was taught that you need a "running" program in there. Here's what I compile - and throw in a system that needs to be "blank":
    PROGRAM_NAME='Clean Program'
    DEFINE_CONSTANT
    INTEGER SystemRunning = 1;
    
    And that's it. I put the constant in there so I can debug into it and make sure this particular program is running.

    As far the non-volatile thing, this has in been in Netlinx.axi for a while now:
    (* Added v1.47, to suppress debug error *)
    DEFINE_VARIABLE
    INTEGER ___RESERVED___;
    

    So, I guess it depends what version of Studio you're running.
  • mushmush Posts: 287
    bano wrote: »
    I had to switch out an NI-3000 that was being slaved in a system, and was subbing in my own NI-3000 that I use as a loaner. After configuring D:P:S and IP, wasn't sure what program was previously on the unit, so I ran a clean disk, loaded ir files, confirmed url connection on the main master and started testing. Serials and IR's worked fine, but Relays and I/O's would not function until I loaded a empty template program on the controller and rebooted. Just an FYI in case anyone runs across this issue.

    From the AMX NetLink language reference guide, in the M2M section.
    The second thing to consider is the code requirements for each master:
    1. Masters that are only being used to add device ports must have an empty ".tkn" file loaded,
    otherwise the devices will not be accessible.
  • Running code in remote processors

    If you have very chatty RS232 devices that are being polled on a regular basis, it is often best to install that code (duet module) in the processor where the RS232 cable is connected. M2M traffic is greatly reduced with this method.

    The goal is to achieve efficient and more reliable network utilization by using virtual device communication between processors.
  • Clean disk

    When using clean disk, use the the command clean disk -f (using the full switch) to erase all hidden files. After that, you can load a blank program. Typical I use:
    PROGRAM_NAME='Empty Program'
    // No other statements are required after this line.
    

    Base upon my previous post, there is usually some code running in all my M2M systems.
  • jjamesjjames Posts: 2,908
    While I agree with nearly everything Brian said, I have to disagree on the Duet module.

    If you want your processor to run efficiently - do not load up a Duet module. While they claim it's lighter on the CPU, before and after comparisons of deploying a Duet module and writing your own NetLinx module tells a completely different story.
  • banobano Posts: 173
    jjames wrote: »
    While I agree with nearly everything Brian said, I have to disagree on the Duet module.

    If you want your processor to run efficiently - do not load up a Duet module. While they claim it's lighter on the CPU, before and after comparisons of deploying a Duet module and writing your own NetLinx module tells a completely different story.

    Have to agree, do not use Duet mods unless I have to, which usually means that the client (dealer) doesn't want to pay me to write my own.
  • PhreaKPhreaK Posts: 966
    jjames wrote: »
    If you want your processor to run efficiently - do not load up a Duet module. While they claim it's lighter on the CPU, before and after comparisons of deploying a Duet module and writing your own NetLinx module tells a completely different story.

    I couldn't disagree more. Don't place the blame on a technology for a poor usage of it. The perceived performance increase gained by using a NetLinx modules vs a Duet module is purely due to your module being optimized for the task it has to perform. Write your own Duet module that provides the same functionality as your NetLinx one and you won't have any issues.
  • jjamesjjames Posts: 2,908
    Okay - I'll clarify . . . stay away from AMX's Duet modules.

    Since that accounts for probably 99% of them out there . . . what do you suggest for us who don't want to spend 1) the many man hours learning Java and 2) the thousand dollars on the Duet license? :)
  • PhreaKPhreaK Posts: 966
    Simple - if NetLinx modules work for you use them. There is absolutely nothing wrong with that. Just don't be scared of Duet just because AMX's modules suck.
  • banobano Posts: 173
    PhreaK wrote: »
    Simple - if NetLinx modules work for you use them. There is absolutely nothing wrong with that. Just don't be scared of Duet just because AMX's modules suck.

    I truly love the passion expressed in these posts. Although you all may do your jobs a little or a lot differently, you all do them very well, as evidenced by their content. Thanks for all the impassioned responses. You all help me do my job better!
  • Duet Modules
    jjames wrote: »
    While I agree with nearly everything Brian said, I have to disagree on the Duet module.

    If you want your processor to run efficiently - do not load up a Duet module. While they claim it's lighter on the CPU, before and after comparisons of deploying a Duet module and writing your own NetLinx module tells a completely different story.

    Please reread my post in the context of M2M implementation. A single Duet module in a remote M2M system is very efficient and will save project development time as well as reduce network traffic.

    As far as Duet module use, I highly recommend learning Java based on the category of this forum, Tips and Tricks.
  • Have you tried modules latey?
    PhreaK wrote: »
    Simple - if NetLinx modules work for you use them. There is absolutely nothing wrong with that. Just don't be scared of Duet just because AMX's modules suck.

    Be careful of interpreting an earlier module experience with what we are delivering today. You just might be pleased, even though it is hard to please everyone based upon their system requirements.

    As someone said, coding skills gets better with experience and time.
  • PhreaKPhreaK Posts: 966
    B_Clements wrote: »
    Be careful of interpreting an earlier module experience with what we are delivering today. You just might be pleased, even though it is hard to please everyone based upon their system requirements.

    As someone said, coding skills gets better with experience and time.

    Very true. Just as some people have been scarred by Duet completely, I've been scarred by AMX's use of it. If they're better now I really should take another look and get over that. If there's already a functional wheel re-inventing it is stupid.
  • DHawthorneDHawthorne Posts: 4,584
    The biggest problem, IMO, with AMX Duet modules is that they must conform to a hideously bloated API that was designed to work with things like device discovery, AMX.home, and VA. I wished they had branched the releases ... a streamlined comm module, a functional UI module, and then a full-blown API-compliant set. Having to have a separate power module along with my tuner module (plus the others that come with a typical Duet module, with absolutely no documentation on which are actually needed for what) on the same device just strikes me as necessarily convoluted.
  • the8thstthe8thst Posts: 470
    I was under the impression that most of the performance hit was related to the SNAPI router layer.

    Are you guys saying the new duet modules are accessing that translation layer differently? I was told that the performance increase of a 100% java program over netlinx would be in the 10x range, but that is all lost within the SNAPI router.

    I know that I am down to using a single duet module (DSC IT100 Security Comm) and the systems reboot about 3 minutes faster with the comm module commented out, but I don't see any real runtime performance issues with the duet comm module loaded.

    My other big problem with duet is that NS requires transferring the SNAPI router and associated Duet modules with EVERY program upload. This isn't so bad when on the local network, but is a huge pain in the butt using a VPN connection to a remote network while installers are on site.
  • jjamesjjames Posts: 2,908
    the8thst wrote: »
    My other big problem with duet is that NS requires transferring the SNAPI router and associated Duet modules with EVERY program upload. This isn't so bad when on the local network, but is a huge pain in the butt using a VPN connection to a remote network while installers are on site.
    This was a problem for me too, but if you right click on the program and select options, you can disable the sending of Duet files. Send once, and you don't have to send again and will only send the program.

  • a_riot42a_riot42 Posts: 1,624
    jjames wrote: »
    This was a problem for me too, but if you right click on the program and select options, you can disable the sending of Duet files. Send once, and you don't have to send again and will only send the program.

    Nice, thanks for posting that. I didn't know that was possible to do.
    Paul
  • the8thstthe8thst Posts: 470
    Thanks.
    I wasn't aware of that option.
  • PhreaKPhreaK Posts: 966
    DHawthorne wrote: »
    The biggest problem, IMO, with AMX Duet modules is that they must conform to a hideously bloated API that was designed to work with things like device discovery, AMX.home, and VA. I wished they had branched the releases ... a streamlined comm module, a functional UI module, and then a full-blown API-compliant set. Having to have a separate power module along with my tuner module (plus the others that come with a typical Duet module, with absolutely no documentation on which are actually needed for what) on the same device just strikes me as necessarily convoluted.

    When you write the modules you don't have to make them do everything defined by the API. The AMX ones do so that they can be used in as many situations as possible but if you're rolling your own just make them do what ever is needed. Personally I then find it good practice to write a netlinx api doc accompanies the module, or even better, define the API doc for the functionality you need, then implement the module. Here's an example of one.

    The SNAPI router translates the API calls into method invocations within the modules so if you're not going to use it don't bother writing it. You can also then edit the components.xml file to remove the components you're not using. This will then prevent SNAPI from routing those parts of the API to the module. All the auxiliary modules that come with the ones you'll find on the AMX site are purely for tying it to an interface. The only one you need is the *_comm module.
Sign In or Register to comment.