如果捕捉DLL错误，以及同步发送命令？？？（机器人控制设计 找进销存管理系统
我估计可能是程序是串行执行的缘故，所以就将主程序改为多线程。我的思路是由主程序直接调用控制维修界面中的Button.Click过程来实现，可是发现主程序只会执行第一个线程而对下面的线程不执行，也就是说在第一个线程中死循环。
然后我又将各个分部控制部分写成单独的DLL来让主程序调动，但是发现在DLL内动作出错时。（为了安全每个控制部分均会对运行状态进行监测，当发现异常时会报错中止电机动作。）可是类似的这些错误有时并不会传递给主程序，有时因错误过于严重而直接关闭了DLL，主程序只得到了一个在xx地址什么寄存器无效等类似错误。如何捕捉DLL中的任意错误呢？
写成了多个DLL后发现，主程序一调用多个DLL后。当一个DLL在执行时如果有另一个DLL被调用，则该DLL被挂起，执行后一个DLL。当后一个DLL执行完毕方会继续执行前一个DLL，可我希望的是同时两个DLL执行呀！如何做到呢？
静等佳音，如有好点子还可加分！！[^]
2楼: 无人明白吗，高手何在？？ 如金蝶财务软件
3楼: 好像弄复杂了，2个线程就应该够用，一个线程负责采集电机运行状态，另一个线程负责
发布控制命令。
另外，分部控制部分DLL不应该由于设备状态异常而关闭，问题应该是你对设备状态的数据
异常考虑不充分
4楼: 您说得完全正确，我也是这么认为的。第一我对线程不熟能推荐我些相关好用的控件吗？
第二的确我可以处理一些设备的异常，但是有些随机的不可控的异常就会发生DLL关闭报错。如我上次不小心在编程时把数据控件给关闭了，那自然做任何相关表的操作就会报错。可是我愣是只看到DLL在写内存XX地址出错这样的报警，最后由我把DLL改为EXE才发现这个低级错误。我的意思是如何避免类似的问题呢？
另外多问一句如果把DLL改为EXE是不是好处理一些，毕竟每个EXE都能自己报错的！但是EXE调用EXE与DLL用法区别在何处，谢谢！
5楼: 1 我一直从TThread类继承, 或者就用API直接CreateThread, 用起来很方便
2 程序中关于如何避免出错, 我也没甚么好办法, 就是编程习惯而已, 凡是
有返回值的都检查, 利用try...except...end来俘获异常，再就是编程时
经常利用Assert，不过最关键的是思路一定要清晰，逻辑要正确，充分考
虑各种可能，不要随便假设某种情况不会发生
3 其实DLL和EXE没甚么太大的区别，用DLL就行了。如果你想用EXE也没甚么
不可以，但是你要考虑好主控程序和个分控程序之间的通信问题，比如用
内存映射文件或者命名管道等。
6楼: 谢谢！
1、好的我会试试。
2、我所指一些捕捉DLL错误，是指在编程时不一定全部的错误都预计到的。虽然有人会对我说这样写不健康，但是工作量实在太大了。对于一些非商业化的程序，如果有些系统自己的报错无关大雅。比如我在正常处理错误的同时，直接在ApplicationEvents的onexception中加入Showmessage（E.Message）也挺好用，我的意思是在处理DLL系统错误中有没有类似的用法。
3、对与EXE与EXE通信除了您所说的方法，好像我听说过可以向调用DLL一样直接调用EXE中函数的方法，但是我在大富翁上找到的那个试过并不成功。
销售管理软件版7楼: 我觉得你的设计方向出现了路线错误。你现在重要的不是考虑是调用 dll 还是 exe 这样的枝节问题，你现在最重要的是搞明白你自己在做什么！控制本身分为轮询和中断，我还头一次看到有人一边在设计机器人一边连基本控制原理都不懂的。程序不会写、控制原理又不懂，最好的办法是赶紧撒手，让能做这个事的人去琢磨吧。
8楼: Flamingo 非常感谢您的提点，看来您不只歌唱得好脾气也不小。的确对于这个项目我不是思路非常清晰，可是我们不是应该在工作中不断的学习吗？如果只是做自己所熟悉的与有把握的事情，这样我们的学习进度又如何得到快速的提高呢？
另外可能是我的表达不是太清晰，所以导致Flaming如此勃然大怒。我的思路是先设计好一个非线程的调试程序，可以通过点击From上的Button来分别实现机器人的部分动作。因为机器的许多随机的动作是可以拆解成单个的动作单元，而将这些动作单元分别不同的组合就可实现许多的随机动作。当然这些控制过程基本是基于轮询的原理，因为WinX系统并不是一个实时操作系统所以大量的使用中断是困难的。我采用WinX主要是处理界面、发送动作单元指令、错误记录等功能，而实时控制部分主要由六片单片机控制，它们之间的通信主要通过I2C＋PC104进行。我想我表达清楚了吗？如果还不清楚请提出。
我目前所目前把每个控制单元封装到了多个DLL中，分别由主程序调用其中Form的Button.click过程。目前的主要问题是发生部分未预计的DLL系统错误时，如何让主程序得到这些错误信息？
因为有时这些错误会导致DLL直接关闭，甚至FreeLibrary都会错误。所以我就想到了调用EXE，因为EXE的错误都会出现对话框，而且关键的是对话框中显示的都是比较直接的信息。这样无论是操作者还是编程者都可以较快速的发现问题所在不是吗？
在论坛之中水平高低有别，如果水平高的人能够豁达些。利用自己的高招指点一二这不正是大富翁论坛原创之意吗？而且这样不更容易让菜鸟们更图生仰慕之情吗？
9楼: 你无非就是这样一个代码结构：
UNIT dispose(code)
{
switch (code)
{
case 0: return (func)table[code];
....
case n: return (func)table[code];
default: return NO_ACT;
}
}
WinX系统在NT下每0.18ms可以提供一次稳定的反馈，如果你的子系统象你说的那样全部都有自己的处理中心，你的子程序无非也就是返回一个动作指令而已，你以为要多长时间？你如果搞明白了控制原理，没准大多数时间，你的WinX系统下的控制程序都可以sleep一大觉！还罗里罗索这么多干什么？怕人家不知道你一个搞工控的连一点控制原理都不懂？
10楼: 谢谢！
您所提及的“WinX系统在NT下每0.18ms可以提供一次稳定的反馈，如果你的子系统象你说的那样全部都有自己的处理中心，你的子程序无非也就是返回一个动作指令而已，你以为要多长时间？”我的确是采用这种方式进行控制的，可是我没有觉得这个时间很长呀？我的问题是我将这些代码封装进了DLL中由主程序来调用，这个思路有问题吗？
“没准大多数时间，你的WinX系统下的控制程序都可以sleep一大觉！”我的程序必须是这样的，否则在主机客户端就无法做任何别的操作了（如数据库读写、数据计算），如果这样这个程序就是个废物了。而且我也实现了这点了！
我的问题是在DLL发生系统错误时如何将错误传送给主程序，当然是指没有事先所预计到的错误，由此我才想起调用EXE。为何“高手”Flamingo一直不回答这一关键问题呢？
恕我愚笨，您的意思不会是：因为NT 0.18ms的稳定反馈，所有通讯以及处理代码应该全部封装在一起，这样就不会出现我所提及的问题了吧。其实NT是可以提供0.18的反馈，但不稳定。您不知NT的时间是可以被程序干扰而中止以及延迟的吗？这样的程序明显不够健康，而且您估计没参加过大项目开发，这样做也不有利于代码保护与在事后做到程序升级与人员无关的工作。这点在控制领域极少看到WinX系统就说明了，即使是WinCE也是比重较少原因也与此有关。
额外话：我浏览了您在论坛的一些大作与积分，估计您年龄应该在25岁以下。因为与我25岁时的情况很像，而且建议去检查一下（FT3、FT4、T3、T4、TSH）诚恳的提醒。
11楼: 首先声明：我是外行（虽然偶的专业是自动控制），不过，还是想说两句。
>>让计算机按照定制程序进行运作时，各马达不能并行同时工作
是不是你的定制程序或者计算机的逻辑设计有问题？我以为要控制马达，只要发送类似启
动、停止之类的硬件指令就可以了，我怀疑是不是你的指令序列已经将电机的启动和停止绑
定成了不可分割的原子操作对？——只有在这种设计的情况下，在任何一个电机动作完毕之
前，针对其它电机的控制指令根本不可能被发出。如果真是这样的话，只要将原子操作对拆
散，变成离散的开关等信号即可（讨论中提到硬件的响应时间是毫秒级，应该不会造成指令
队列的阻塞）。
您提到了“任意按Button控制我的设备”——各个电机的启动和停止按钮是分开的吗？如
果是分开的，就要请您细谈一下您到底是怎么控制多个电机的了。
一般的异常应该是能够捕获的，如果是内存访问甚至更加低级的错误嘛...——我是没办
法。我觉得这是DLL设计的问题——停工就停工罢了，就算要报错，也应该是高级一点错误
吧（高级指的是类似Delphi中用raise语句抛出的异常，而不是因为程序本身的逻辑错误—
—例如试图向一个未初始化的指针所指向的地址写入数据）。
能够导致DLL关闭的异常我还真没遇到过...在主程序还没有崩溃的的情况下，试试重新加
载？
12楼: 从任何角度，倒是你该去查一下你的脑筋有没有问题。一个控制代码本身只要一加一就可以完成的，到了你手里非要搬出微分积分，我替你解了这个结你倒说我有毛病。DLL死掉没这么容易的！它会先把你的EXE弄死！你连基本的内存管理都不懂，胡吹海吹个屁啊！要解决你上面所发生的DLL问题，我都不用看到你的代码，就知道是你在DLL没有执行完代码前你就把你的DLL给枪毙了！要怎么解决是吧？我当然知道！但如果你正确地设计了程序逻辑，你根本就不用这样去碰一鼻子灰，为什么要舍本求末地告诉你枝节呢？你希望我不负责任地胡灌一通水，告诉你线程要开信号灯或者干脆象楼上那样告诉你1个线程或2个线程什么的，有价值吗？我直接告诉你及时改变到正确的设计方向来，莫非还害了你？你以为我说你不会写程序是在瞎说啊？我上面每一句话都是很明确地知道你问题所在而说的，看不看得懂是你的事情，甚至我上面列出的看似十分简单的代码结构，真正明白控制原理和数据结构的人都会很认真地对待它！你要俘获DLL错误是吧？你知道这个是什么东西吗？告诉你你会懂吗？我告诉你说ExceptObjProc是一个函数，它的第一个参数是一个指针，你会信吗？你连代码都不会写，我告诉你这么多做什么呢？等你继续在程序设计领域钻研十年后再回头来看看我今天说的东西吧！别不识好歹！居然还扯到了大项目、年龄、大作，你都知道个屁啊！对于你这种菜鸟都不是的草鸟，拜拜了吧！ 如进销存管理系统
13楼: 大过年的没必要这么大火气，[:D]
有时候，没有问题，制造问题，去解决问题也是一种手段，[8D]
说正题
1 你使用单片机来控制电机，那么按照一般的设计思路应该是，单片机通过串口
什么的接受上位机的指令，然后根据设定的参数 [b]独立地[/b] 控制电机的启动、停
止、转速调整、状态检测，所有结果也都通过串口什么的反馈到上位机。
2 你说你的不能够并行控制，我不知道是因为单片机的程序有问题还是上位机的
程序有问题，如果是因为你单片机的程序设计问题，如creation-zy所说的原因
那只能修改单片机程序了，单片机也是有“思想”的，不要什么事情都让上位机
越俎代庖。
3 你想把每一个分控部分做成一个DLL的思想不错，但是既然能想到“分解因式”，
为什么想不到“合并同类项”？做设计实际上就是一个折衷的过程，该合就合
该分就分。
4 DLL中异常怎么办，还是那句话，没什么好办法，尽量检测返回值，没办法检测的
对输入参数进行监控，反正是不能因为数据造成DLL崩溃。
5 NT能不能做实时系统的问题没必要作讨论，因为按照IEEE的定义，这个问题完全
取决于你要求你的系统有多快的响应时间，如果你要求秒级响应，用它来作系统
也没什么不可以的，什么事情都不能绝对化。
销售管理软件版14楼: 各位，控制领域好像很有发展，大家不要搞人身攻击，一起聊点技术好不好。
我本身没做过硬件近制，但是经常做数据采集程序。
基本上也都是与硬件打交道。
与硬件通讯一般都有个握手过程
我想楼主与机器的通讯也应该只有一个接口吧
其实不用把它拆成DLL
那样太麻烦了
你只要在程序内部把所有的功能都独立地设计成功能模块，然后用到什么就调用什么就可以了
像你所说的出错处理
其实很简单
在DLL中一样可以使用Try except end 结构来捕获通常的错误
但是前提是你的DLL没有部一些其它因素强制卸载
如果你想在DLl中弹出提示框
那你可以在调用DLL的功能时将Application.Handle传给DLL
DLL检查到错误后使用MessageBox API函数将Application.Handle传入来报错
不过这些确实复杂了
一般与硬件通讯出错都是时序不匹配造成的
由于上位机的速度不同，与硬件的速度差异很大
可能上位机边续发了很多命令，而下位机只执行了一条
要解决这个问题
可以在各个命令之间插入造当的延时，应该可以解决问题
15楼: 帮顶！
╭=========================================╮
80G海量源代码,控件，书籍全免费狂下不停！
http://www.source520.com
╰=========================================╯
16楼: 感谢 creation-zy、kaoleoloi、mike1234567890、tseug各位，我已基本理清了我的思路。对于creation-zy您所提及的问题，其它几位已经回答了，我就是用这种做法实现的。其实我使用多个DLL分拆，主要是考虑到程序保密以及多人合作的目的。因为我让每个人负着一部分DLL的工作，当然也有负着电子等的人，而我是项目管理者。可是别怪我固执！如果通过exe调用exe中的函数是不是应该可以实现的？如何做到呢？那位费神提供些Demo代码好吗？然后我想这个问题就可以结束了。
联系我们
