控制器与PC的连接通过EtherNet方式，控制器端默认配置为服务器，PC端通过调用所提供dll配置为客户端且能够调用提供函数对控制器发送指令，实现控制。
所提供win32动态链接库静态调用成功，导出类CMMCTCP中包含用于建立TCP连接所需的Create(),Accept(),Send(),Receive(),Connect()等函数，调用Create()等函数正常，当调用Connect()函数时发生错误，程序执行到此就自动退出，故希望帮忙找出调用Connect()函数时为什么错误，怎么能成功调用，实现与服务器连接。所提供示例程序位于文件夹Documentation下的G-MAS Administrative and Motion API的1364页void TCPDemoClient()函数，错误在rc = tcpClient.Connect(g_szIpAddress, g_usPort, iSock, bWait);语句。所需.h.dll.lib文件因比较大故放在百度网盘：https://pan.baidu.com/disk/home#list/path=%2F，十分感谢。

---

C++技术网解答：

    这是实际的项目开发的问题，我们这里只是回答问题，不会去帮你调程序，没有那个时间和精力。请你理解。不过会给你一些建议，供你调试分析参考。

    这个应该叫做上位机程序，PC端通过网络来控制下位机。控制器为服务器，被动等待连接。PC端的上位机软件作为客户端，主动去连接服务器端。而在开发时，服务端即控制器端给你提供好了dll,方便上层来写业务逻辑控制代码，屏蔽底层通信方面的技术细节。当然，这个dll是经过测试的，至少不会出现连接不成功这些问题的，所以问题在上位机软件的代码中。

    控制器端一般是linux系统，也就是说的嵌入式系统。而客户端使用的是Windows程序，所以是win32的dll。两者通过标准的TCP来通信。在dll提供的函数中，Create(),Accept(),Send(),Receive(),Connect()已经是写好的，只需要调用即可。但是如果在调用函数时发生错误，说明是上位机程序没有按照给定的dll的规定来写代码，所以才导致错误的发生。这里主要考虑的是，上位机代码执行的逻辑和提供的dll的逻辑不匹配，可能导致基础环境没有初始化好，或者相关的参数没有设置好，反正就是前面的基础性工作没有做好，才导致后续的错误的发生。

   所以，调用他人提供的dll，不等同于系统的dll，你一定要考虑提供dll的人的感受，不要忽略他们的话。一定要严格遵守他们的文档说明，很可能dll的容错能力很小，遇到错误就崩溃了。这里说的程序自动退出，就是dll内部检测到状态没有初始化好，所以往后执行必然会行不通，所以在内部的函数返回失败，然后导致一系列的链式反应，程序就退出了。问题是，没有任何错误提示，这是不好的。但是作为上位机开发人员，应该要了解到这样的情况，不要觉得自动退出就毫无概念，摸不着头脑了。

    所以，这个问题我不用看任何代码，可以肯定，问题就是前期的准备工作没有做好。请仔细检查代码，和阅读相关文档，最好可以咨询提供dll的人，看看要准备什么，而你却忽略了。

    当然还有一个可能就是Connect函数传递的参数也可能有问题。这是很好检查的，断点跟踪一下即可。而在客户端对象内部，一定要确保套接字正确的创建好。所以你可以断点之后，看看对象的各个成员状态，确保都是正常的。

    要知道，TCP通信中基础而重要的就是套接字socket了，如果这个东西没有准备好，那就没得玩了。所以，请在Connect函数执行的位置，按F9打一个断点，然后检查对象的各个状态，和函数的参数，来分析前期工作是否都做好了。如果出现无法计算的值、或者空指针等情况，必然是有问题的。

    接下来就是你自己仔细去检查代码了。项目开发调试找Bug是最基本的技能，不要期望他人来帮自己完成，否则永远无法提供编程能力。事实上，编程最麻烦的就是找bug，找到Bug后，解决办法通常是比较容易的。

    希望在思想思路和方法以及精神上给你足够的指导，找Bug，你行的，只是时间问题，每一个程序员都需要过关的。加油吧。