Problem in command execution from dcs on modbus

V

Thread Starter

vk

Dear Experts,

I have a problem in command execution from dcs on Modbus.

We have a data concentrator, which is polling serial devices and transferring data to Hmi and DCS.

problem is ...while we give command from the dcs, it is getting delayed by 2-3 min. but from hmi it is getting executed with in 10 sec.

While investigating further we found that hmi is scanning status of start and stop coil on func code 1, although i have not configured func code 1 in hmi. when i give command from the hmi it write start coil on func code 5 and again started scanning of coil in fuc code1. in this case motor starts in 10 sec.

Now, in dcs in normal condition (no command issued from dcs), dcs is writing 0 in start and stop coil of each motor with func code 5 during every scanning cycle. when i give command it writes 1 with func code 5. and again started writing 0 in each motor with func code 5. in this case command execute in motor after 2-3 min.

Please help!

Thanks,
VK
 
L

Lynn August Linse

Probably your HMI is being greedy & building up an excess queue of requests, while the DCS is 'being polite' and only talking when required. So when the DCS does its write, there are 30 or 40 HMI requests waiting in queue ... but that's just a guess based on 18 years of working with Modbus/TCP to RTU.

The core problem is Ethernet allows hundreds of a requests per second, while serial only allows a few (maybe up to 10 if short & devices answers fast).

So check with the 'data concentrator' vendor, see if there is some way to at least detect the queue issue and maybe control it. And/or check with the HMI and see if there is a way to slow it down, prevent it from typing to use 100% of available bandwidth.
 
I have used a similar architecture. in my case the command executed from the hmi is from the server of hmi software.

when executing from DCS it goes perhaps through a PLC (FO link) and then via modbus to the device.

try using modscan in parallel to dcs and check if exactly the command reaches to the device in 2 minutes,you can also try executing the command from modscan and see if there is any change in the time.
 
Here, in this case, HMI is not building excess queue of requests. because if i stop HMi, i found same problem with DCS.

Problem is with DCS, who is writing 0 to all coils in every scan which put actual command in long queue of writing.

My question is: is it necessary to write 0 in every coil in each scan???

As per my knowledge in each scan, modbus driver checks the status of coils (func code 1) and when actually command arrive it writes 1 in respective coil. correct ??

thanx

> Probably your HMI is being greedy & building up an excess queue of requests, while the DCS is 'being polite' and only
> talking when required. So when the DCS does its write, there are 30 or 40 HMI requests waiting in queue ... but that's
> just a guess based on 18 years of working with Modbus/TCP to RTU.

> The core problem is Ethernet allows hundreds of a requests per second, while serial only allows a few (maybe up to 10
> if short & devices answers fast).

> So check with the 'data concentrator' vendor, see if there is some way to at least detect the queue issue and maybe
> control it. And/or check with the HMI and see if there is a way to slow it down, prevent it from typing to use 100%
> of available bandwidth.
 
I have already checked on Modscan, it doesn't take 2 min. it takes 2-5 sec only.

Again this is because, modscan doesn't write 0 to every coil in every scan and therefore doesn't have a long queue.

Regards,

> I have used a similar architecture. in my case the command executed from the hmi is from the server of hmi software.

> when executing from DCS it goes perhaps through a PLC (FO link) and then via modbus to the device.

> try using modscan in parallel to dcs and check if exactly the command reaches to the device in 2 minutes, you can also
> try executing the command from modscan and see if there is any change in the time.
 
Top