Home AMX Resource Management Suite Software

General Direction for Newbie Adding RMS to Large Installed AMX Base

This major fortune 500 client has a large installed base of AMX systems programmed with non-snapi compliant code and non-AMX modules. The code is somewhat unique in that the client deploys one or more DGX's per building which support 10 - 25 independent conference rooms of various configurations. With help from an AMX sales engineer I have basic RMS monitoring running in several buildings. The client wants to move forward with full RMS monitoring and remote control, perhaps adding scheduling later. I'm looking for general recommendations from those with experience on how to allocate limited programming resources to accomplish this. Should the existing code be updated to full SNAPI compliance? Would you eliminate the non-AMX device modules and replace them with AMX modules with built-in RMS support, or is a SNAPI compliant non-AMX module sufficient? Other general suggestions on approaching this project are greatly appreciated.

Thanks

Comments

  • cmatkincmatkin Senior Member Posts: 86
    Hi there,

    My preference when visiting older site to add rms to would be to write custom monitors for the Comms modules as this would have the less chance in breaking the existing code.

    Over time, I would create snapi Comms modules and monitors that could be rolled out if needed.

    If a system is working, I'll try to minimise the chances of breaking it or introducing unwanted features as possible.
  • PhreaKPhreaK Senior Member Posts: 966
    Yep, definitely agree with Craig's sentiments regarding 'don't break things in order to implement a monitoring and analytics systems that will alert you if things are broken'.

    Working towards SNAPI compliance (where it makes sense) is definitely a process worth undertaking IMHO. As a bridging solution I have also seen people instantiate NetLinx virtual devices which they attach the RMS monitors to then flick the appropriate channels / send relevant commands from within the existing code to push info into RMS. This approach lets you keep some modularity between your core system code and your monitoring code. You're then also free to roll custom monitors based on your SNAPI shell devices and simply swap this out for real module without having to re-write any of your monitoring system.
  • drcampbelldrcampbell Junior Member Posts: 8
    I greatly appreciate the input!

    Thanks
  • fogled@mizzou[email protected] h4x354x0r Posts: 549
    HELLO: I am another person with a fairly large installed base of AMX systems - about 50 of them but only one of them true multi-room system - that all need modified / upgraded to work with RMS. My code is pretty darned custom, definitely not SNAPI compliant. I've got about 2 weeks to figure all this out and get this working, and quite frankly it's been awhile since I've done anything more than tweak my existing code here or there. I'm feeling really, REALLY lost. Lost as in, "Why does the example have a device at 5001:23:0? There's no physical port like that in an NI-3101 is there?" And, "Great RMS uses port 7 on the touchpanel as default, that's the port I usually use for camera 1 control. Which is easier to change?"

    I'm not sure which modules I really need to load, for what functionality, where. In other words, LOST like I've never even programmed an AMX system before. The last time I looked at RMS was version 3.x; at that time it appeared I could load a module and just add an extra text-formattted SEND_COMMAND to the RMS module, wherever needed for tracking, for it chew on. Now it looks to be a bit more complicated, although I haven't wrapped my head around exactly how.

    Unfortunately I'm so lost I can't even formulate a specific question right now, besides, "which modules do I really need, where do they go?". Any general guidance would be appreciated. Hopefully as I work through this I can formulate and ask some more specific questions.

    Thanks!
  • fogled@mizzou[email protected] h4x354x0r Posts: 549
    FYI I'm not trying to do anything with Duet, everything I've got is straight Netlinx code. But I'm feeling just a bit confused because in some places in the docs and examples it seems really unclear what's applicable to Duet vs. procedural Netlinx code.
  • fogled@mizzou[email protected] h4x354x0r Posts: 549
    OK, I seem to have successfully updated my base code and moved my cameras to different logical device ports. I've gotten a good compile on the code with the following .jar modules (I'm just trying to get basic logging working first, then go from there):

    RmsNetLinxAdapter_dr4_0_0 (THIS MODULE IS THE ONLY ONE EXPLICITLY LOADED)
    commons-codec-1.4-AMX-01 (These had to be added to avoid compile errors after loading above)
    commons-httpclient-3.1-AMX-01
    commons-lang-2.5-AMX-01
    commons-logging-1.1.1-AMX-01
    rmsclient-osgi
    rmsclient
    rmsnlplatform

    Does this look right for a Netlinx-based (not duet) RMS platform tie-in? Of course the RMS server itself isn't up and running yet, so it's hard to test against it right now. Just trying to get *somewhere* on this.

    Thanks,
  • RMSDevRMSDev Junior Member Posts: 7
    The RFID and GUI .jar files are the only ones that are optional. Every other .jar file included with the RMS SDK is required. The NetLinx Adapter, GUI Adapter and RFID Adapter .jar files are the only ones that you'll ever actually have to reference in your code.
Sign In or Register to comment.