Skip to main content
Submitted by mlotosky on Mon, 02/13/2017 - 15:07

I have a DMC-30011 (used as a slave) communicating with a computer running LabVIEW (master) using TCP/IP over WiFi. The code on the DMC is state based so that the master knows at all times what custom state I put it in (step/jog/find home etc) instead of the master just issuing native DMC commands (because prior to this new state based architecture, Stop messages during a jog were being lost so our motors were running away). The LabVIEW computer is connected on one handle only to send my custom commands as well as receive the unsolicited messages. The DMC's main loop sends the unsolicited message with its current state information at the end of its loop. My issue is when the unsolicited messages are being sent via a TCP connection and that connection gets dropped unexpectedly (as is the case with WiFi), a spike occurs in the main loop's run time, going from between 2-6ms to over 1s. I have isolated it down to it occurring only on TCP connections for the unsolicited messages because I can replicate this behavior in GalilTools (by disconnecting the UDP handle and redirecting the unsolicited messages to the TCP handle). I was running firmware 1.2b but just ran a test using 1.2h firmware since it had notes of some type of TCP/Ethernet fixes and this problem still occurs in the 1.2h firmware. I have not seen anything in the documentation stating that the DMC will lag upon an expected disconnect with a TCP handle sending the unsolicited messages, only a warning stating "It is NOT recommended to use one Ethernet handle for both command-and-response, and unsolicited messages." I have also been running tests where a different LabVIEW VI on a separate computer is only performing TCP reads during the main computers main LabVIEW program/GalilTools TCP unsolicited messages testing (where I unplug the ethernet cable on the DMC to simulate a WiFi drop), and the secondary computer and LabVIEW program runs fine without being disconnected but does not receive any data during the disconnect since the DMC's main loop is hung up during this time. Has anyone else noticed this issue and aware of a fix for it?

Comments 1

MattK on 02/23/2017 - 15:15

Hi Mike, I understand that you've been corresponding with another one of our Applications Engineers on this topic. For the quickest service, we like to keep a single Engineer on a case to minimize having to 're learn' the application.

 

For completeness I'll restate Galil's recommendations for Ethernet communications with our controllers: Industrial Control and especially Motion Control Systems demand determinism and data integrity. The assumption is that when a move command is sent, it is received and processed in a time frame that is either iconsequential to the overall response of the system OR the communication takes place at a known regular interval that can be relied on for timing. 100 MBit Ethernet communication with our controllers relies on the former qualification, sending a move command over Ethernet takes far less time than is relevant in most motion control systems. We call this 'virtual' determinism.

 

Both requirements however are at odds with the nature of wireless communication. On a wireless network, your data and timing is exposed to any potential noise or intermittent signals (think of a forklift driving between your wireless router and the controller for instance). In this situation, using the TCP protocol ensures data integrity with Sync/Ack bits and retransmits if data is lost. The tradeoff for this though is communication overhead and a loss of determinism due to lost packets. This applies to all Ethernet Wireless Communication. To avoid this, Galil strongly recommends communicating with our controllers on a closed network (not exposed to the internet or broadcast traffic) through a dedicated Network Interface Card with a static IP assigned.

 

Please continue to work with my colleague on your specific application requirements.