Skip to main content
Submitted by Warren on Thu, 12/18/2014 - 09:25

When using GalilTools (GalilClass1.dll 1.5.0.0) with LabVIEW according to the instructions found at http://www.galil.com/news/software/using-labview-galiltools-communicati… and with the examples found at http://www.galil.com/download/api-examples/getting-started/gt_lbv_86_co… as the starting point for a simple test VI, I find that the "command Invoke Node" will occasionally time out (one or two times an hour in response to lots of polls for various bits of information) and that if I make a subsequent call to the node without first closing and reestablishing communications with the Galil controller then the second call to the command invoke node will hang the program and my only recourse is to kill the program with the task manager. This is under Windows 7 (64 bit) and using Ethernet communications to a DMC-2143 over a private network. The timeout happens in response to any variety of commands.
The error response that is returned is Code = -2147467259
Exception occurred in Galil: 1011 TIMEOUT ERROR. Galil::command( various ) took longer than 2000 ms to read : response. Got : in (VI name)
<!--break-->
This strikes me as flawed behavior from the GalilTools library. A program hang requiring task manager intervention is never acceptable. Continuing to time out would be better if there was a problem. Saying that the comm link was down would be better still. Considerably better than that would be if the tools recognized that there was a problem and fixed it on its own. And of course the ideal solution would be if whatever was causing the random timeouts in the first place was repaired so they did not occur.
<!--break-->
Will you be able to provide a fix?

Comments 2

MattK on 12/19/2014 - 10:34

Hi Warren,

I note from your previous post that you are using controllers customized for your application(s). Please email me so we can further discuss the behavior you are seeing.

Warren on 03/16/2015 - 07:35

I finally go to the root of this problem. The Ethernet network interface was being shutdown as part of Windows power saving scheme and that in turn caused the timeout. The fix was to disable power management (cause it to remain on always) for the device.