The first line under 3.7 states,
"For a viual diagnosis, communiction status and device status must be indicated by LED's." The
last line in the table indicates that the Device
status is optional. Anyone know which is correct?
Also, should the required communication LED that is switched on during "frame sending" reflect the status of the slave transmit lines (any slave
transmitting would turn it on) or the status of
the particular slave on which it is located? The
former would place the LED after the slave transmit driver and the latter would place it
before the slave transmit driver.

 

Are we splitting hairs here? Providing indications to the user it's a device design issue - how friendly your box is to help the poor user troubleshoot the system when things go wrong.

Frame sending implies the device that sends it - your first interpretation actually means frame being received (sent by another device). Here also you are the judge of how much usable to the end user is the indication you
designed in the device - complemented with legend on the LED and the explanation in the device documentation.

Meir

 

RE: Modbus LED for transmit

Which document are you quoting? Modbus cannot really enforce any LED standard - I mean how many Windows PC even have any LED related to a serial port? I think this is up to you - decide which is most useful for your customers.

Options include:
1) external hardware idiot light - blinks when any line activity. As you point out this means it also blinks when any OTHER slave transmits.
2) internal hardware idiot light - blinks when this node transmits. Unless you add some filter, the LEDs hard to see at high baud rates.
3) software controlled 'send' LED - software can send signals to user plus hold LED on long enough for a clear view - could even do a bi-color with RED meaning returning exception response (or NO response because request had CRC error) and Green for normal response.

#1 will be of little use & you'll have the most support headaches. I like #3 (maybe just green though) but #2 works Ok also.

- LynnL, www.digi.com

 

From a customer perspective, I like smart idiot lights (contradiction noted), kinda like what Lynn has recommended by choice #3, i.e., two separate lights or one two-color light: one for RX and one for TX. On a point to multi-point circuit I want the RX light to signal that the slave is getting a valid request from the Modbus master. That is, the UART didn't sense a framing, parity, or data-overrun, and the software didn't find a check-sum error. This provides information beyond what is offered by LEDs on a DCE. For extra credit, the comm driver should make sure the message is not too long. Please ignore the Modbus address. I just want to see the RX light blink every time the master sends a good Modbus message. On the slave's TX side, I only want to know if it is transmitting. This should be a bit simpler. It is implicit that the slave would not xmit without first receiving a valid message to his address. Lynn's recommends a time-off delay to make sure the human eye and the LED can make contact. Right. It has to be that way or lights would serve no practical purpose.

I'm not in the hardware business, but it seems to me that two lights are easier to package than one two-color light or whatever's really behind the glass. The lights have to be labelled. Two lights, in this case, offer plenty of room to emboss an RX and TX label under the respective lights. I don't think the label "Green RX Red TX" is going to be as compact as two lights with short labels. And the one-light construction makes a motor-mouthed slave hard to recognize on a point-to-point circuit. Automation accountants should note that I will pay an extra $25 for these two LEDs that cost them only pennies to include. And they should also come to terms with the market and recognize that they are not going sell a zillion of these units. To this customer, of pair of useful diagnostic LEDs has significant value.

jk