Clean Disk,et al
bano
Posts: 173
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.
0
Comments
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.
Sent from my MB865 using Tapatalk
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.
DEFINE_VARIABLE
_Bandaid
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:
So, I guess it depends what version of Studio you're running.
From the AMX NetLink language reference guide, in the M2M section.
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.
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:
Base upon my previous post, there is usually some code running in all my M2M systems.
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.
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.
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?
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!
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.
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.
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.
Nice, thanks for posting that. I didn't know that was possible to do.
Paul
I wasn't aware of that option.
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.