Compact Framework 串行端口和天平
因此，要打开串口并通过串口成功传输天平数据，我需要确保serialPort对象上的设置与天平的实际设置相匹配。
现在的问题是，如何检测由于设置不同而尚未建立连接？ SerialPort.Open 不会抛出异常来表明连接已建立。 是的，设置有效，但如果与设备（平衡）设置不匹配； 我不知道为什么没有捕捉到失去平衡的重量。
这里有什么输入吗？
So, to open up a serial port and successfully transmit data from the balance through the serial port, i need to make sure that the settings on the serialPort object match the actual settings of the balance.
Now, the question is how do i detect that the connection hasn't been established due to the settings being different? No exception is thrown by serialPort.Open to indicate that the connection has been established. Yes, the settings are valid, but if they don't match the device (balance) settings; I am in the dark as to why the weight off the balance is not being captured.
Any input here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果不知道有关您期望从天平获得的数据格式的更多信息，则仅适用常规串行端口设置不匹配检测技术。
如果 UART 设置明显不正确，您可能会看到很多帧错误：当 UART 期望出现 1 停止位时，它实际上会看到 0。您可以使用 ErrorReceived 端口上的事件。
Without knowing any more information on the format of the data you expect from your balance, only general serial port settings mismatch detection techniques are applicable.
If the UART settings are significantly incorrect, you'll likely see a lot of framing errors: when the UART is expecting a 1 stop bit, it will in fact see a 0. You can detect this with the ErrorReceived event on the port.
如果情况很接近，但仍然不正确，.NET 串行端口对象甚至可能不会给您错误（即，直到发生灾难性事件）。
我最常见的串行端口通信故障是由于波特率不匹配造成的。 如果您知道一条消息可以得到“回声”，请尝试将其作为握手工作的一部分。 也许您正在连接的设备有“状态”消息。 提出请求不会造成任何损害，而且您会发现通信是否正常进行。
对于软件握手（xon xoff），您几乎无法检测其配置是否正确。 串行端口对象可以执行任何操作，从完全忽略它到出现线程异常错误，具体取决于底层串行端口驱动程序实现。 我的串行端口驱动程序完全忽略 xon/xoff，并将字符直接传递到程序中 - 哎呀！
对于硬件握手，波特率的基本回显策略可能会起作用，具体取决于您的设备的工作方式。 如果您知道它将进行硬件握手，您也许能够检测到它并打开它。 如果设备需要硬件握手并且它没有打开，您可能什么也得不到，反之亦然。
另一个很少使用的设置是 DTR 引脚 - 数据终端就绪。 某些串行设备要求将其置位（即设置为 true）以指示是时候开始发送数据了。 默认设置为 false； 尝试一下。
请注意，串行端口对象......很挑剔。 虽然不一定需要，但我会考虑在进行任何更改之前关闭端口。
编辑：
感谢您的评论，看起来这是您的设备。 它说默认设置应该是：
它没有指定多少数据位，但设备说它支持 7 和 8。我会尝试这两个。 它还表示它支持 600、1200、2400、4800、9600 和 19200 波特率。
如果您打开了硬件握手、启用了 DTR（不同的东西）并循环使用了所有不同的波特率，那么很可能这不是您的设置。 您的设备所使用的串行电缆可能连接不正确。 某些串行电缆是“直通”电缆，其中一侧的 1-9 引脚与另一侧的 1-9 引脚完全匹配。 然后，你有“交叉”电缆，其中“TX”和“RX”电缆被交换（这样当一侧发送时，另一侧接收，这是一种非常方便的电缆。）
考虑查看后面的命令表那里有手册； 您可以发出“打印软件版本”命令来获取某种类型的回显。
If things are close, but still incorrect, the .NET serial port object may not even give you an error (that is, until something catastrophic occurs).
My most common serial port communication failure occurs due to mismatched baud rates. If you have a message that you know you can get an 'echo' for, try that as part of a handshaking effort. Perhaps the device you're connecting to has a 'status' message. No harm will come from requesting it, and you will find out if communication is flowing correctly.
For software handshaking (xon xoff) There's very little you can do to detect whether or not it's configured right. The serial port object can do anything from ignore it completely to have thread exception errors, depending on the underlying serial port driver implementation. I've had serial port drivers that completely ignore xon/xoff, and pass the characters straight into the program - yikes!
For hardware handshaking, the basic echo strategy for baud rate may work, depending on how your device works. If you know that it will do hardware handshaking, you may be able to detect it and turn it on. If the device requires hardware handshaking and it's not on, you may get nothing, and vice versa.
Another setting that's more rarely used is the DTR pin - data terminal ready. Some serial devices require that this be asserted (ie, set to true) to indicate that it's time to start sending data. It's set to false by default; give toggling it a whirl.
Note that the serial port object is ... finicky. While not necessarily required, I would consider closing the port before you make any changes.
Edit:
Thanks to your comments, it looks like this is your device. It says the default settings should be:
It doesn't specify how many data bits, but the device says it supports 7 and 8. I'd try both of those. It also says it supports 600, 1200, 2400, 4800, 9600, and 19200 baud.
If you've turned on hardware handshaking, enabled DTR (different things) and cycled through all the different baud rates, there's a good chance that it's not your settings. It could be that the serial cable that's being used may be wired incorrectly for your device. Some serial cables are 'passthrough' cables, where the 1-9 pins on one side match exactly with the 1-9 pins on the other. Then, you have 'crossover' cables, where the "TX" and "RX" cables are switched (so that when one side transmits, the other side receives, a very handy cable.)
Consider looking at the command table in the back of the manual there; there's a "print software version" command you could issue to get some type of echo back.
串行端口使用一种非常非常古老的通信技术，该技术使用一种非常非常古老的协议，称为 RS-232 。 这非常简单...两个端点具有同步时钟，它们在每个时钟周期测试线路电压，看看它是高还是低（高表示 0，低表示 1，这是相反的）大多数约定......又是协议时代的产物）。 时钟同步是通过使用停止位来完成的，停止位实际上只是字节之间的休息时间。 还有一些其他东西被投入到协议的更高级用途中，例如奇偶校验位、XON/XOFF 等，但这些都建立在这个非常基本的通信层之上。 检测串行线路两端的时钟不匹配几乎是不可能的——您只会在接收端得到不正确的数据。 协议本身没有内置方法来识别这种情况。 我不知道有任何串行驱动程序足够聪明，可以注意到输入数据的时钟频率不合适。 如果您使用其中一种错误检测方案（例如奇偶校验位），则很可能每个字节都会被声明为错误。 简而言之，您能做的最好的事情就是检查传入数据是否有错误（奇偶校验错误应该由您的驱动程序/软件层检测到，而您的应用程序从该层接收到的数据中的错误则需要由您的程序进行检查 -后者可以通过使用校验和来帮助。
Serial ports use a very, very old communications technology that use a very, very old protocol called RS-232. This is pretty much as simple as it gets... the two end points have synchronized clocks and they test the line voltage every clock cycle to see if it is high or low (with high meaning 0 and low meaing 1, which is the opposite of most conventions... again an artifact of the protocol's age). The clock synchronization is accomplished through the use of stop bits, which are really just rest time in between bytes. There are also a few other things thrown into the more advanced uses of the protocol such as parity bits, XON/XOFF, etc, but those all ride on top of this very basic communication layer. Detecting a mismatch of the clocks on each end of the serial line is going to be nearly impossible -- you'll just get incorrect data on the recieving end. The protocol itself has no way built in to identify this situation. I am unaware of any serial driver that is smart enough to notice the input data being clocked an an inappropriate frequency. If you're using one of the error detection schemes such as parity bits, probabilistically every byte will be declared an error. In short, the best you can do is check the incoming data for errors (parity errors should be detected by your driver/software layer, whereas errors in the data received by your app from that layer will need to be checked by your program -- the latter can be assisted by the use of checksums).