Home› AMX User Forum› AMX Technical Discussion

What is the best way to test code, without a device?

PKennedyPKennedy Posts: 7
in AMX Technical Discussion
Well I'm new to the forums and also new to the AV world on top of that. I was just wondering what are some of the best ways to test out your code, especially when you don't have the device right in front of you...
Right now I'm having to work with some Polycom systems (VSX 7000s) and they are not exactly user friendly.

Does anyone have any ideas on ways to getting around these challenges?

Thanks,

Paul

Comments

  • ericmedleyericmedley Posts: 4,177
    I have to admit...

    I will not take on many situations that require me to work on gear that does not exist in some fashion that I can test. If I'm pressed into doing something like that with a complex piece of gear, I'll put in a disclaimer that I am not in control of the costs of programming the device and switch to time and materials.

    I have my standards. If you don't like them, I have others.
  • PKennedyPKennedy Posts: 7
    ericmedley wrote: »
    I have to admit...

    I will not take on many situations that require me to work on gear that does not exist in some fashion that I can test. If I'm pressed into doing something like that with a complex piece of gear, I'll put in a disclaimer that I am not in control of the costs of programming the device and switch to time and materials.

    I have my standards. If you don't like them, I have others.

    Oh I agree,
    My thing is that since it's a user owned device and we have the rest of the system it just turns out to be one of those jobs that I'm going to have to program when I get to the field. Still its a little scary taking on something like this for the first time.
  • TurnipTruckTurnipTruck Posts: 1,485
    You can use emulate incoming string from inside NS to see how your code behaves. I do that sometimes even when I have the equipment.
  • PKennedyPKennedy Posts: 7
    TurnipTruck wrote: »
    You can use emulate incoming string from inside NS to see how your code behaves. I do that sometimes even when I have the equipment.

    Nice, I didn't know that I could do that...I'll try it out and see how it goes. Thanks
  • jjamesjjames Posts: 2,908
    If you REALLY wanted to go through the trouble, you could connect one serial port to another. In essence, you'd write the brains of the receiving device based off of the documentation. While this would be a pain, it might be useful if it's a complex device - at least cutting down on time you'd spend writing code in the field.
  • HedbergHedberg Posts: 671
    It can be a pain to test without the device -- just have to examine the strings you send out and the response to strings coming back in which you can simulate. As suggested, you can program one serial port to simulate the device which is always fun. Unfortunately, until you get the actual device, you can't be sure.

    The Polycom VSX7000 codecs really aren't too bad. The documentation pretty much describes how they work. The Visual Concert thing (in order to select a VGA input) is a tad strange, in my opinion, and setting up multiple cameras may be a bit tricky. Most of the problems that we have with these are a result of setup issues, not programming issues. Though, most of the setup can be done through the RS232 port which means that I usually get blamed even if it has to do with ISDN setup or something.

    You might consider the AMX module for this thing though that might make testing impossible without the device. Lots of AMX modules seem to depend on some sort of inscrutable secret handshake before they'll send out proper strings and parse proper responses.
  • a_riot42a_riot42 Posts: 1,624
    PKennedy wrote: »
    Well I'm new to the forums and also new to the AV world on top of that. I was just wondering what are some of the best ways to test out your code, especially when you don't have the device right in front of you...
    Right now I'm having to work with some Polycom systems (VSX 7000s) and they are not exactly user friendly.

    Does anyone have any ideas on ways to getting around these challenges?

    Thanks,

    Paul

    I'm often put in this position unfortunately, as our sales staff have a large variety of old and new gear they will integrate, and after a while you get better at it. At first, for some devices with hairy protocols, I wrote a test driver that repsonded the same way the device was supposed to, or sent unsolicited feedback when I hit virtual buttons. This way you can make test cases and include incomplete strings to mimic real life connections or error conditions.

    These days, as long as I have the command document, I pretty much just write it without testing it and it will usually require only minor timing modifications on site, or perhaps a workaround for a firmware bug. I would suggest doing this as well, and think it out without testing it. It takes longer but the rewards are worthwhile. The Polycom has a prewritten Duet module so I would just use that and simulate feedback with a virtual device, or make a button event that will send whatever string you want to your module using Control a Device and test it that way if need be. The constant type/compile/test routine is a habit to get out of if you can.
    Paul
  • PKennedyPKennedy Posts: 7
    a_riot42 wrote: »
    I'm often put in this position unfortunately, as our sales staff have a large variety of old and new gear they will integrate, and after a while you get better at it. At first, for some devices with hairy protocols, I wrote a test driver that repsonded the same way the device was supposed to, or sent unsolicited feedback when I hit virtual buttons. This way you can make test cases and include incomplete strings to mimic real life connections or error conditions.

    These days, as long as I have the command document, I pretty much just write it without testing it and it will usually require only minor timing modifications on site, or perhaps a workaround for a firmware bug. I would suggest doing this as well, and think it out without testing it. It takes longer but the rewards are worthwhile. The Polycom has a prewritten Duet module so I would just use that and simulate feedback with a virtual device, or make a button event that will send whatever string you want to your module using Control a Device and test it that way if need be. The constant type/compile/test routine is a habit to get out of if you can.
    Paul

    Yeah that's what I just came across was the Java Duet Module for the 8000 series and Polycom told me that it should work with the 7000 series model, since the commands are the same. So I'm hoping that it'll work, that would save me a lot of time. I just wish I could crack open their module and see how they did it, cause I know Java and that would be sweet to see.

    Thanks : D
  • a_riot42a_riot42 Posts: 1,624
    PKennedy wrote: »
    Yeah that's what I just came across was the Java Duet Module for the 8000 series and Polycom told me that it should work with the 7000 series model, since the commands are the same. So I'm hoping that it'll work, that would save me a lot of time. I just wish I could crack open their module and see how they did it, cause I know Java and that would be sweet to see.

    Thanks : D

    Java code is boring to look at. All the cool stuff is done behind the scenes in the libraries.
    Paul
  • DHawthorneDHawthorne Posts: 4,584
    I'll sometimes just used Hyperterminal to make sure my commands are going back and forth the way I expect them to, or any of a number of other utilities if it's not plain ASCII. But that's about the limit of it's usefulness. It won't help if the documentation is unclear, or if you are sure you got it right, but it still doesn't work ... you need the real device then to be able to check your ideas and poke around.
  • travistravis Posts: 180
    I've been using netcat as a fake device server. It's probably already installed on your mac or linux. It runs on windows too but you have to google around to find it.

    tcp server listening on port 1001:
    netcat -l -p 1001
  • John NagyJohn Nagy Posts: 1,742
    HEX COM TOOL. The most versatile and valuable serial comms software I've seen. Get it. Will transcode ascii and hex bidirectionally to manage the worst protocols. And lots of features.
    They sell various great hardware bits for sniffing and emulation too.

    http://www.rs232pro.com/
  • Thomas HayesThomas Hayes Posts: 1,164
    I just did a very sim. type job and most of the stuff worked. There are are few things that you will need to use the passthru command with. I use a program called dataviewer which allows me to capture various commands and see what I'm getting back matches what the manual says. BTW, I run across many times where the manual says one thing and the code says another.
  • John GonzalesJohn Gonzales Posts: 609
    PKennedy wrote: »
    Nice, I didn't know that I could do that...I'll try it out and see how it goes. Thanks

    Here's a thread that discusses testing your parsing routines with emulate a device if there's no real device handy...
    http://www.amxforums.com/showthread.php?6199-Using-Emulate-a-Device-to-test-your-parsing-routines
    -John
  • travistravis Posts: 180
    Any way to emulate channel events from input relays / IO?

    Just trying combine_device and fiddling the on/off of the virtual device, it didn't trigger any events on the combined device.
    Tried DO_PUSH too. Didn't think it would work and it didn't.
  • ericmedleyericmedley Posts: 4,177
    travis wrote: »
    Any way to emulate channel events from input relays / IO?

    Just trying combine_device and fiddling the on/off of the virtual device, it didn't trigger any events on the combined device.
    Tried DO_PUSH too. Didn't think it would work and it didn't.

    Emulate Device doesn't work for you?
  • travistravis Posts: 180
    wanted to automate some testing...
    I'd run wires from one port to another, but the NI-700 I have doesn't have enough ports.
  • ProgressiveCodeProgressiveCode Posts: 64
    travis wrote: »
    Any way to emulate channel events from input relays / IO?

    Just trying combine_device and fiddling the on/off of the virtual device, it didn't trigger any events on the combined device.
    Tried DO_PUSH too. Didn't think it would work and it didn't.

    As Eric said, "Emulate a Device" in NetLinx Studio does exactly what you are asking.
  • HedbergHedberg Posts: 671
    travis wrote: »
    wanted to automate some testing...
    I'd run wires from one port to another, but the NI-700 I have doesn't have enough ports.

    Here are some cheap ports guaranteed not DOA:
    http://cgi.ebay.com/Panja-AMX-Axcent-3-Integrated-Axcess-Controller-/120740858336?pt=LH_DefaultDomain_0&hash=item1c1cb749e0
  • travistravis Posts: 180
    travis wrote: »
    I've been using netcat as a fake device server. It's probably already installed on your mac or linux. It runs on windows too but you have to google around to find it.

    tcp server listening on port 1001:
    netcat -l -p 1001

    http://nmap.org/ncat/

    Made a batch file that says:
    start ncat.exe -l 5000
    start ncat.exe -l 6101
    start ncat.exe -l 6103
    start ncat.exe -l 6102

    4 instant fake tcp servers (for testing multiple instances of the same module, or a bunch of different modules)
Sign In or Register to comment.