Monitoring DATAKOM DKM 409 Data RS485 modbus output

[erfan_sh]

Thanks dear chembo & K C for your clear comments

1-Yes, when I set my device id to 1 to work

2-So thanks about your guide, it’s very important for me. Is there any complete guide for modbus that explain all of this?

Sincerelly

Shahsavari

[K C]

At ModBus.org you can find a lot of information about ModBus. But the ModBus link with DCS is something different. In my environment if work with DCS and safety PLC guys. Our own system talks ModBus with these systems. So that is way I know this.

Kees

[erfan_sh]

Thanks a lots guys
IM USING MODBUS LIBRARY AND IT WORK GOOD BUT AFTER SOME READING DATA AN ERROR OCCURRED. SOMETIMES AFTER 17 READS AND SOMETIMES AFTER 15 OR 31 OR MORE.....

Error 56 occurred at RTU Data Unit.lvclass:Read ADU Packet.vi:1
Possible reason(s):
LabVIEW: The network operation exceeded the user-specified or system time limit.

In modbus library, timeout is not adjustable and in device or modbus library I can't find a parameter for specify how many times read from my slave. So how it’s possible to fix this error?

[erfan_sh]

Thanks for your time.

[smithd]

The timeout is set using a property node or one of the additional utility methods on the palette. However, for serial the timeout is automatically set to a reasonably long wait. For RTU modbus you'll find that it does time out occationally. The correct solution is to retry the read. The library does not retry for you.

[K C]

Hi,

A retry is nice to have a more robust interface. If a slave does not respond at the first request and it does on a second one the link stays up.

But if you have errors every few reads (once every 100 or 1000) it is an error. I don't think you should solve this with retries but search for the cause of this error.

How does your RS-485 network looks like ?

- Terminators at both ends (preferably a failsafe-one at one side)

- Use RS-485 twisted pair cable

- Connect the 0V (something else than ground or earth)

Can you show us your VI to see how you communicate with your device.

Kees

[smithd]

It does retain the link, it just flushes the buffer. Retrying within the API means that you are stuck with that behavior even if you don't want it. Letting higher level code handle the retry is a better design, as you can retry in whatever way you would like.

The errors can be from any number of sources. Some devices don't respond consistently. Other times the issue is timing related. The most common situation in which I've seen errors is with USB-to-serial converters with iffy drivers. Serial RTU requires a very precise timing which is almost impossible to verify on modern high-level driver APIs. For example, neither NI VISA or the .net serial API has a mechanism for waiting on a silent period (which is exactly what RTU requires). With USB-serial devices, I believe the USB driver packetizes the serial stream in a weird way, which can cause long periods of silence on the serial line. These long periods of silence are interpreted per the spec as invalid/incomplete packets. Other drivers ignore the spec and manually inspect each packet to determine an expected length, and then wait for that number of bytes. This is honestly probably the better solution but it wasn't how the library was designed.