是否有处理串行端口通信的设计模式?

发布于 2024-07-09 21:12:22 字数 584 浏览 5 评论 0原文

我们正在使用一些新的切割工具,这些工具可以通过串行端口而不仅仅是控制面板来更改其硬件参数。

当硬件参数改变时,硬件将花费几秒钟的时间来重新配置自身,然后发出信号表明它已准备好使用。

在此之前,我们的设置涉及操作员单击“切割板”或“零件”命令。 软件将显示一个对话框,允许操作员更改与运动相关的任何内容(速度、延迟等),并显示硬件应采用的配置。操作员验证所有内容后,单击“确定”,机器开始切割。

对于新硬件,如果我们传输了更改,我们会提取当前配置,并弹出一个对话框,显示新配置是什么,以及显示硬件是否准备就绪的指示器。 并非所有事情都是通过串行端口自动化的,因此有时该对话框必须保留在那里,直到操作员单击“确定”。 其他时候,当硬件发出正确信号时,它可以自行卸载。

我的问题(和问题)是通过串行端口执行此操作非常慢。 这也是我们第一次做此类工作。 我担心我缺少一些解决方案来使整个事情更具响应性。 由于我们从第三方购买切割硬件,因此无法选择使用串行替代品。

我想做的另一件事是可以选择显示状态对话框并使其保持运行,而不会导致串行通信阻碍系统的其余部分。

我正在寻找有关 Win32 API 或 .NET 的提示。

We are working with some new Cutting Tools that can have it's hardware parameters altered through the serial port instead of just a control panel.

When the hardware parameters are altered the hardware will take a few seconds to reconfigure itself and then signal that it is ready to be used.

Our setup before this involved the operator clicking on a Cut Plate or Part command. The software will display a dialog allowing the operator change anything that is motion related (speed, delays, etc) as well as display what configuration the hardware should be in. After the operator verifies everything he click OK and the machine starts cutting.

For the new Hardware we pull out the current configuration if there is a change we transmit and throw up a dialog showing what the new configuration is along with a indicator showing whether the hardware is ready. Not everything is automated through the serial port so sometime the dialog has to stay up there until the operator clicks OK. Other times it can unload itself when the hardware signals it is right.

My problem (and question) is that doing this through the serial ports is all painfully slow. It also the first time we done this type of work. I am concerned that I missing some solution to make the whole thing more responsive. It is not an option to use an alternative to serial as we buy the cutting hardware from a third party.

Another thing I would like to do is have the option of displaying a status dialog and leave it running without the serial communication bogging down the rest of the system.

Tips for the Win32 API, or .NET are what I am looking for.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

潦草背影 2024-07-16 21:12:22

这取决于机器控制的交互程度 - 您可以只发送 moveto xy、cutto xy 还是需要持续监控机器并启动和停止电机?

如果机器相对智能,那么我会把它当作绘图仪。 在 GUI 中构建命令列表,然后提交它们。 这样就可以很容易地测试独立于机器的 GUI。

您还可以有一个测试应用程序,它获取命令列表并将其绘制在屏幕上,作为切割昂贵材料之前的检查。 甚至可以将命令转换为 HPGL 或 SVG 等格式并直接显示它们。

It depends on how interactive the control of the machine is - can you just send a moveto xy, cutto xy or do you need to constantly monitor the machine and start and stop motors?

If the machine is relatively smart then I would treat it like a plotter. Build up a list of commands in your gui and then submit them. This way it is easy to test the gui independant of the machine.

You can also have a test app that takes the command list and plots it on a screen as a check before cutting expensive material. It might even be possible to convert the commands into something like HPGL or SVG and display them directly.

醉殇 2024-07-16 21:12:22

一种选择是在单独的线程中运行串行端口通信,并让该线程将其状态报告回 GUI 线程。 (调用)

这就是我最近编写 HID 刷卡系统的方法。 一个线程记录卡片刷到列表的操作。 另一个线程将这些写入数据库系统。 每个都向 GUI 线程报告。

One option would be to run the serial port communication in a separate thread and have that thread report it's status back to the gui thread. (Invoke)

This is how I recently coded a HID card swiping system. One thread records card swipes to a list. Another thread writes these to a database system. Each reports to the GUI thread.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文