在不打开端口的情况下确定设备是否连接/断开到 RS232 端口

发布于 2024-07-18 06:34:55 字数 636 浏览 7 评论 0原文

我正在开发一个 C++ Win32 应用程序,我试图本质上“自动检测”设备是否已插入 RS232 端口之一,然后是否已断开连接。

检查连接的设备非常简单因为我的用例允许我假设这个特定线程将是第一个尝试启动与端口通信的线程,一旦我找到设备打开的端口,我就能够每隔一分钟左右扫描可用端口。我标记该端口有一个设备,关闭该端口,然后设置一个事件,以便实际使用该设备的进程知道它现在可以在该端口上连接,

当我遇到麻烦时。在扫描连接的设备时,我实际上可以将数据发送到端口,以确保如果有设备,它就是我正在寻找的特定设备,但是一旦连接,该端口将已经被其他进程打开,并且。我无法再从检测线程打开该端口,因此我正在寻找一种以“侦听模式”或类似方式打开端口的方法,以便我可以查看设备是否仍然存在。

我短暂地遇到过一些关于观看 DSR 或 DTR 线路或其他内容的内容...但找不到更多内容或如何实际执行此操作。

有什么建议么?

编辑:看起来我需要澄清一点...为了检测断开连接,我无法以任何方式向 RS232 端口发送数据。 em> 另外,我不能假设另一个应用程序实际上打开了该端口。 该设备可能已物理连接,但没有开放连接......但我仍然不能冒险向其发送数据。 我希望有一种方法可以检查该端口是否仍然有电或类似的东西。

I"m working on a C++ Win32 application for which I'm trying to essentially "auto detect" if a device has been plugged into one of the RS232 ports and then if it has been disconnected.

The checking for a connected device is easy enough because my use case allows me to assume that this particular thread will be the first to try to initiate communication with the port. I'm able to scan the available ports every minute or so and once I've found a port with the device on it I flag that port has having a device, close the port, then set an event so that the process that actually will use the device knows it can now connect on that port.

The disconnect detect is where I run into trouble. When I'm scanning for connected devices I can actually send data to the port to be sure that, if there is a device, it's the specific device I'm looking for. But once it's connected, that port will already be open by the other process and I can no longer open that port from the detect thread. So I am looking for a way to either open the port in a "listen mode" or something like that so I can just see if the device is still there.

I briefly came across something about watching the DSR or DTR line or something...but couldn't find any more or how to actually do it.

Any suggestions?

Edit: Looks like I need to clarify a little more... For detecting the disconnect, I cannot send data to the RS232 port in any way. Also, I cannot assume that another application actually has the port open. The device may be physically connected, but without and open connection...but I still can't risk sending data to it. I was hoping there was a way to just check that there was still power on that port or something like that.

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

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

发布评论

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

评论(3

桃酥萝莉 2024-07-25 06:34:55

当您断开硬件连接时,调制解调器状态寄存器是否会发生变化取决于所连接的硬件,但如果有变化,您可以使用 GetCommModemStatus() 函数。

然而,存在一个问题,您需要 COM 端口的文件句柄来调用任何 API 函数,这是唯一的文档 CreateFile() 状态:

CreateFile函数可以创建通信资源的句柄,例如串行端口COM1。 对于通信资源,dwCreationDisposition 参数必须为 OPEN_EXISTING,dwShareMode 参数必须为零(独占访问)

因此,当另一个进程打开 COM 端口进行通信时,您无法打开 COM 端口来观察线路状态。

有很多方法可以做到这一点,但它们涉及驱动程序。 SysInternals 有 Portmon 工具,Google 搜索会找到一些公司销售用于在应用程序之间共享 COM 端口访问的软件,但据我所知,使用标准 API 不可能同时访问。

It depends on the connected hardware whether there will be a change in the modem state registers when you disconnect the hardware, but if there is then you could check the state of for example the CTS or DSR line using the GetCommModemStatus() function.

There is however the problem that you need a file handle to the COM port to call any API function, and this is exclusive as the documentation of CreateFile() states:

The CreateFile function can create a handle to a communications resource, such as the serial port COM1. For communications resources, the dwCreationDisposition parameter must be OPEN_EXISTING, the dwShareMode parameter must be zero (exclusive access)

So you can not open the COM port to watch the line state while another process has the port opened for communication.

There are ways to do this, but they involve a driver. SysInternals has the Portmon tool, and a Google search will turn up some companies selling software for sharing COM port access between applications, but AFAIK simultaneous access is impossible using the standard API.

七色彩虹 2024-07-25 06:34:55

听起来好像让该进程发出连接和断开连接事件通知并将数据中继到其他进程可能是个好主意。 让您的应用程序分层工作,以便有一个进程控制 RS232 连接并发送上层应用程序事件:连接、断开连接、数据可用等。

Sounds like it might be a good idea to have that process that will give notification of connected and disconnected events also relay the data to the other process. Have your app work in layers such that there is a process that takes control of the RS232 connection and sends your upper layer app events: connected, disconnected, data available, etc.

时光瘦了 2024-07-25 06:34:55

我已经完成了这样的应用程序,它并不是真正的特定于语言的问题(除非您没有您的语言的串行端口访问权限)。

我的首选解决方案始终是根据您的配置,每个端口有一个线程,并且线程维护一种可从某种控制器访问的状态。

默认情况是线程每隔几秒轮询一次端口,如果没有答案,则假设没有连接设备。 一旦设备似乎有响应,请更改状态以表明确实如此。

我设计了一个具有多个队列的应用程序:一个具有断开连接的线程,一个具有已连接但空闲的线程,另一个具有已连接且繁忙的线程。 当线程改变状态时,控制器在队列之间移动线程。

I have done applications like this and its not really a language specific problem (unless you have no serial port access in your language).

My preferred solution has always been to have one thread per port, according to your configuration and the thread maintains a state which is accessible from some sort of controller.

The default condition is that the thread polls the port every few seconds and while there is no answer assume there is no device connected. Once a device seems to respond, change the state to indicate this is so.

I designed an application that had a number of queues: One with disconnected threads, one with connected, but idle threads and another with connected and busy threads. The controller moved threads between queues as they changed state.

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