EXB COM over the internet
a_riot42
Posts: 1,624
I haven't seen one of the new ICSLan devices, but could you locate one at a remote site, and using port forwarding over 1319, use it to control a device at a remote location without having a local master at the remote location? I know they get a virtual device number from the master, but I'm not sure how it gets an IP address so that it can be identified across subnets .
Paul
Paul
0
Comments
The answer is YES.
Lol, did you just tell Paul to RTFM? "Yes" would have sounded a lot less snottier
Ah yes the manual. AMX TS told me they don't recommend using them in the way I described, so I didn't think the manual would clear that up. But if its just another IP device on the network that uses ICSP, there should be no theoretical reason why it can't be placed in a remote location and as long as the networking, DNS, etc is setup correctly it would work reliably. But often reality isn't so simple so I am curious if someone has set this up that way in the real world using the real internet with a chatty two way device.
Paul
I'm not sure why tech support would recommend against it, other than unfamiliarity with the scenario. Perhaps there are security concerns. ICSP security should help that. It should be as stable as the Internet connection itself. Note that an old product, the AXB-NET, was exactly for this remote linkage purpose, to provide "local" AXLINK at a location only reachable by network or Internet.
The manual does go on for pages about setup options and modes of communication, beyond those suggested by the telnet menu. It has a dropback mode for when there is no DHCP available, it sniffs the network map and tries to find a place that isn't in use, pretty cool. It defaults to DHCP as all AMX, indeed nearly all network devices, do... gotta start somewhere.
We all have been disappointed in documentation on occasions, but c'mon, if you want an answer, why not start with the answer document? I think it's just good advice to suggest that experienced AMX professionals consult the free and available documentation that is prepared in detail specifically to help use the product before calling tech support or waving a white flag in the forums. Even when that works as a shortcut, you often don't have the whole answer and breadth of options explained as the documentation MIGHT, giving you new and different ideas of how you might better accomplish your desired ends.
I know I always learn something new when I RTFM.
I wouldn't call a touch panel a chatty device, but then I don't send them 20,000 commands when they come online.
I have nothing against manuals I read them all day long. They don't give you the real world situation in all cases though. Whether this device can maintain a reliable connection across the internet over VPN with 2 way communication with a chatty device like a lighting system is something you tend to only find out by doing it. Even a little latency in a real time system can make it unusable.
After much hassle and customer/dealer angst due to a projector and an AVR working one day and not the next, using one of these for SERIAL... we find it reverts to 9600 baud on its own.
Combing the documentation, in a single notation in the BAUD section for all the ICSLAN products, it warns that the baud rate is NOT stored in any nonvolatile memory and will be lost on power failure (or in our case, moderate power bumps). So it's not safe to set and forget, you must actively renew the baud rate to keep it going.
Your choices:
* Set the device controlled to 9600 baud so you don't need to tend to it at all
* Frequently refresh the baud set initialization, perhaps every time you talk to the device (ugh)
* Actively watch for the device online event and renew the initialization each time
* Buy a different solution at 1/4 the price that just works like you expect. Nearly any other brand costs less and works without holding its hand.
The convenience of the devices showing up as native AMX devices is nice and eases coding, but is far offset by the burden of coding a reinitialization scheme.
I'm disappointed and kind of shocked that AMX would add such a needy product line (as such posh prices) to their commercial - focused lineup. This EXB-COM2 LAN unit replaces the AXB-232++ in a sense... that was designed 15 years ago or more, and a unit set up 15 years ago will still be running at the set baud today, come hell or high voltage.
Do you mean something else or do you just do it differently than I?
The "native" serial ports (5001) on the NetLinx, we've always initialized at power up and data reset. In 20 years with AMX and for 50 dealers using our stuff, that's been often enough until now. External serial ports on slaves, same. IP-to-Serial devices like DIGI-ONE and Global Cache, set them once in their internal settings. AXB-boxes or cards, set the dip switches and forget about it.
In the case at hand, it's not clear from logs that it even ever went offline, but still forgot its baud. We've never before encountered transitory serial ports that you must presume don't know what to do even if you told it a minute ago. I suppose there may be others, but this was new in our experience. Certainly unlike anything we've worked with from AMX to date. Maybe we've led a sheltered life.
As we don't believe we can trust watching for online events, we've added automatic reinitialization of all serial ports upon any room-on event for our solution. And recommending against use on unattended devices such as alarms or lighting control unless you can set them to 9600 baud.
Regardless, I conclude that there are better choices one might make than to buy these.