I´m using a 1415 controller with 1.0i Firmware and direct TCP connection without Library (direct Linux socket communication).
I try to 'reset' the controller sending 'RS\r\n' ('\r\n' being CRLF) and expect '\r\:' as is working on three controllers already out.
Now I have two new controllers that simply respond ':'.
Same firmware.
Now the strange part comes: Connecting to the controller via a slower SSH connection (tunnel), the response suddenly is '\r\n:'.
(All recorded with wireshark.)
I tried to update to Version 1.0j, but that made things worse, now the 'RS' command causes network connection to toally drop and I´m not able to connect again until Power cycle.
Any hints how to proceed ?
Thank you
Thomas Widmaier, Munich, Germay
MattK on 03/03/2015 - 15:32
ThomasWidmaier on 03/05/2015 - 23:06
I found out that the connection problems only happen during the start up of the application software.
I see a lot of ARP request/reply during that time, so maby that is causing the trouble.
Also I have two Galil connected to the same network with neighbouring addresses.
Also the problems are affecting another device which is in the same network. There, the traffic is also erratic.
I´ll have to keep looking into this. It might be the switch or the Linux-PC itself having problems with the traffic.
ThomasWidmaier on 03/11/2015 - 03:14
Update: Firmware 1.0j is working now, maby there was a data corruption on first try. All controllers are on 1.0j now, but it did not improve behaviour concerning network problems.
ThomasWidmaier on 03/03/2015 - 23:40
Hi Matt,
Thanks for looking over my issue.
I´m not using the libraries because I´m not having the Motor in every product. It´s configurable.
Using the library would force me to have the shared libraries shipped with every software.
Also, simple TCP connection I have a good implementation already which I use with various
thrid party hardware being accessed.
MattK on 03/25/2015 - 09:19
Broadcast traffic on the network was causing the controllers communications buffer overflow, slowing responses to commands from the host PC via socket connection.
In our current generation controllers we have implemented the IK command which blocks all connections to the controller on ports numbers below 1000. This of course excludes ports 0,23,68 and 502 which are used for standard connections to the controller.
Additionally, this type of behavior in socket programming is why Galil strongly recommends communicating with the controller via our communications libraries. The functions within the libraries are implemented with error and timeout checking in order to avoid these kinds of complications. A full list of our programming APIs and supported languages can be found here: http://www.galil.com/learn/api-examples