I am having a heck of a time getting NCD Base to reliably communicate to TaraList relays.
I have 4 on the network but NCD Base fails to show any of them in the Discovered Network Devices group. I can enter the IP address of a controller and it will find it and show information about the controller, but if I go an try to update a time schedule or sync the time, I get a bunch of Connection errors and I have to kill NCD Base and restart it.
Since I have 4 TaraList relay boards on the network, do they need to be on thier own listen port?
Like 2101, 2102, etc. ? They are all using the Lantronix X-Port module and Im using the latest NCD Base thats downloadable.
Any suggestions from someone with experience with the TaraList?
Thanks
What is the subnet mask used by your network? The discovery mechanism used by the Ethernet and WiFi modules on these controllers uses a UDP broadcast so if there are multiple routers or sometimes even large subnets it can effect communications. i.e. your WiFi devices are on 192.168.1.x while your Ethernet devices are on 192.168.0.x etc.
If comms are dropping it will generally be one of two things: Network configurations on the Ethernet module: The Ethernet modules support a socket timeout functionality that will close a socket when no bytes have been passed in X amount of time. It appears you’re using the Lantronix XPort ethernet modules so the timeout settings should be found under Channel 1 Disconnect Mode from the device’s web page in the Inactivity Timeout field.
Firewall/Trash Collection on network: something on your network is looking for “dead” sockets that haven’t communicated in a while and subsequently blocking them. This is more vague because every network is different, but to test if this is the case the only thing you can really do is either contact your IT team or make sure that the Ethernet module has a static IP address, connect directly to the Ethernet module, and attempt to run Base Station. The Ethernet port on your PC will also need to have a static IP address assigned to it within the same subnet i.e. if the static ip address of your Ethernet module is 192.168.1.88 then you’ll need to assign a static IP address to your PC’s ethernet module of 192.168.1.89 or similar.
A less likely cause for dropped comms is inductive loads which would mean that either the relay switched an inductive load using one of its relays while the connection was active OR the power supply for the Taralist board that supplies the 12VDC is shared with an inductive load.
Thank you for your reply Jacob, you’ve given me much to consider here and will try a few things.
Our network subnet mask 255.255.252.0 and we use several VLANS as well. Currently the relay boards are on our management VLAN. The VLAN and routing could be my problem.
One major symptom Im seeing is that I will get connected to the board with NCD Base, issue one simple command like turn the relay on, It will respond and turn the relay on but then I totally lose connection with it and have to start over.
What is being switched by the relays? If its an inductive load and comms drop after switching it then that could be the cause?
It is odd when a socket connects and then dies for seemingly no reason. In my experience its one of the two things I mentioned above.
Its not impossible that there’s an issue with the Ethernet modules themselves, but its not very likely as generally if they go bad they don’t accept any sockets.
at the moment I have one board on my bench thats almost ready to deploy. Theres nothing connected to the relay (it will be passing 110v to an alarm buzzer eventually) RIght now Im attempting to upload a set of time schedules and this is how ive discovered the connection difficulties with NCD base.
One more weird thing I just realized now… On the board Im working with, when I log into the web interface the home page shows no data about the device.
Interesting Developement here. NCD Base works better if the pc with NCDbase and the taralist board itself are on the same subnet. Using firewall rules, My pc can talk to devices on VLAN 50 which is where the taralist boards sit. NCDbase has problems staying connected. Works much better now after moving the Taralist boards off the VLAN.
Do you have a suggestion as to why the home page is missing info about the taralist board?
I dont even know what firmware its on to compare with the other 3 boards I have.
So as to why the connection would drop over a VLAN is hard to say. It could be that there’s a duplicate IP address somewhere in the network route that causes packets to go to one device sometimes and another device at other times and general misrouting of packets. This would most likely be a duplicate IP address of the Ethernet module’s ip address as if it was something in the VLAN routing chain you would see this in other places assuming you had anything that connects to other devices on the VLAN regularly. Could be Stateful Firewall Timers on the network, could be some kind of green ethernet/power saving feature that thinks the small amount of data is low activity and kills the connection, a faulty ethernet cable, a dirty ethernet port/tarnished contact(s) on the RJ45 jack, could be an issue with the port connections between the switches, or a number of things realistically. Unfortunately I’m not enough of an expert on networking to help you pinpoint the exact issue. My approach to these issues is to generally simplify the connection as much as possible and then add variables until the issue is reintroduced to at least isolate it down to a family of issues that could cause it.
Does the Ethernet module still report blank data if the device is on the same VLAN? Does it still respond blank if the device is directly connected to the PC? Bear in mind your PC still has to be on the same subnet as the module for your PC to know how to route the traffic to the Ethernet module’s IP address.
We discontinued use of the lantronix xport modules I think around 2018 so I don’t have one in front of me to see if this missing data could also be indicative of an unreliable connection i.e. the web page loads first and the data loads afterwards over another network call which is failing.
All but one of our Taralist relay boards show no device info when directly logging into the xport device.
I moved them all off the vlan to simplify traffic and NCDbase and all taralist relays are on the same subnet now.
One of the taralist relay boards showed up in NCDbase search box and it reports a firmware version of v6.8.0.2G2
The one Taralist relay board that DOES show correct device data at the home screen is at firmware v6.10.0.3
I am able to communicate better with the modules after putting them all on the same subnet as the PC running Base Station. Im currently experimenting with the VLAN for these modules. The Xport modules showing an old firmware of 6.8.0.2G2 will show no identifying data on the home screen, however they still appear to function otherwise. Your link to the instructions on how to reset the modules to factory and resetting them helped greatly. I may get one of the new LAN modules anyway to see if they behave better on the lan. For now all seems to be working good.
