LabVIEW
stop bit for 485 Modbus with Modbus library
Take a look at this code.
It shows the general idea on how to configure the port to work with a single stop bit instead of 2.
There are many devices that use Modbus and do not care about stop bits at all. Those would be modbus devices that are using TCP/IP.
True. But, they have nothing to do with this conversation. We've been talking about Modbus over serial. Anything I've said has been within this context. As we'd use a different instance of the polymorphic VI for TCP, the decision to leave that piece of code in or not wouldn't make sense in the context of Modbus over TCP/IP.
The main part of modbus is the protocol for how the packet of data for commands and responses are structured. The number of stop bits, parity bits, baud rate are all details that relate to a lower level of the communication protocol that has nothing to do with the packet structure, which is the primary purpose of the modbus standard.
I'd agree with this.
While it would be nice if every modbus device that used serial ports used exactly the stop bit definition the modbus spec calls out , the fact is that in the real world, there are still many devices that used the modbus protcol definition of communication packets that the 99% of the code in the NI modbus libraries will work with just fine, and the code needs to be adjusted to account for this deviation from the modbus spec that is pretty much a insignficant and I'd argue that the number of stop bits should never have been defined by the protocol anyway. But it was decades ago that the spec was written and somebody must have felt adding that aspect was important at that time.
Here's where we start to disagree. Yes, devices in the real world don't adhere to the standard. Let's look at the DS0. It's the basic communication block used by both T1 and E1 standards. Do both methods work? Absolutely. Is it safe to say T1 is E1 compliant because the primary purpose of the DS0 is to structure the packet of data and the signaling details are too low level to really impact that compliance? Not at all. That's where we are in this discussion. The code I posted prior is Rube Goldberg code. From a logical standpoint, it's no different than:
The code I added, and later suggested we delete after digging deeper into the Modbus API, is identical to code already run in a subVI taking place when the Serial Master is created. If you configure the port and follow that by configuring the port, you're doing the logical equivalent of taking an answer an multiplying it by one. In the times you're working with a device that doesn't comply to the standard, you can build an API to work with that device. If the difference is something as small as the stop bits, it'd make sense to include the port configuration in the API. But, it absolutely does NOT make sense to include it in every application just as it doesn't make sense to include the multiply by one in every application because some day you may want to double that value instead.
Saying a modbus device is no longer modbus because it used the wrong number of stop bits is ridiculous. It is still follows the Modbus standard, but with an exception to it.
The entire point of standards is so we can avoid conversations like these. Adhering to the standard makes it easy to communicate between two devices and doesn't require strange additions to code to make things work. Saying a modbus device is no longer a modbus device is ridiculous. However, it's no more ridiculous than saying something that mostly adheres to the standard is compliant. The value in saying something is a Modbus device is that you're telling the user they can use the same rules everyone else uses without having to worry about complications. When you take that away, it's pointless to call it a Modbus device. You've not met the standard and you've created the exact complications standards are meant to avoid.
I'm sure we could have a rather long conversation back and forth and both learn bits and pieces from the other. But, we're getting pretty far away from Mike originally was asking. If you'd like to continue the conversation, you're more than welcome to send me a message. But, I won't be checking the thread going forward.
