News:

  • February 01, 2023, 10:20:38 AM

Login with username, password and session length

Author Topic: Communication issue  (Read 17069 times)

Henryp

  • Hero Member
  • *****
  • Posts: 161
Communication issue
« on: May 10, 2016, 05:41:37 PM »
I’m using a Modbus gateway to talk to a few multi-dropped RS485 VFDs and other devices in a motor control center. The units have device IDs of 1 to 5. It appears that when one of the devices gets turned off for maintenance it causes the other devices to stop communicating. I was able to duplicate the problem by creating two Kepware OPC devices, one with a valid device ID and the other one with an invalid device ID. When I turn on data collection for the invalid device ID, I see the valid device error out.

Gummi Ben

  • Jr. Member
  • **
  • Posts: 18
Re: Communication issue
« Reply #1 on: June 19, 2017, 05:45:42 AM »
Hello, I have the same issu, did you get any solution to your problem ?

Best regards

Guðmundur

Henryp

  • Hero Member
  • *****
  • Posts: 161
Re: Communication issue
« Reply #2 on: July 20, 2017, 01:43:19 PM »
No I didn't find a solution.
« Last Edit: August 25, 2017, 10:18:48 AM by Henryp »

Garyhlucas

  • Hero Member
  • *****
  • Posts: 383
Re: Communication issue
« Reply #3 on: July 20, 2017, 07:45:33 PM »
I have 8 VFDs on Modbus and the communications are done via a series of stages. When a drive is intentionally off I skip the appropriates stages. Every stage with a Modbus block ends on the success bit AND the error bit, so communication continues to all the other drives. The difference between success and error bits is that errors generate alarms too.

Hope this helps.

Mike Nash

  • Hero Member
  • *****
  • Posts: 632
Re: Communication issue
« Reply #4 on: July 21, 2017, 03:31:01 PM »
If a timeout occurs, I set a bit to disable talking to that device for awhile (timer), then try again later. You do get the one long delay, but then the rest get updated quickly while the one that stopped talking sits in the timeout corner. I watch for awhile to see how long all good communications takes then set the timeout a bit longer than that.

Henryp

  • Hero Member
  • *****
  • Posts: 161
Re: Communication issue
« Reply #5 on: February 14, 2019, 12:06:41 PM »
I'm using a Modbus gateway to talk to a few multi-dropped RS485 VFDs. The units have device IDs of 1 to 3. When one of the devices is offline for whatever reason it causes the other devices to stop communicating or makes communications intermittent. I have done a new install in a another location and have the exact same problem. Has Host made any progress into this issue?

Greg

  • HostTech
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 660
  • Hmmm...
    • Host Engineering, Inc.
Re: Communication issue
« Reply #6 on: February 15, 2019, 10:40:33 AM »
I'm not sure we have a problem. Reason being, you must control your timeouts, retries, and comms by your programming. It seems the others above have done this to solve the issue of a device dropping off the RS-485 network. Have you tried any of their suggestions?
There are two types of people in the world; those that can extrapolate from incomplete data sets.

stoic-one

  • Full Member
  • ***
  • Posts: 33
Re: Communication issue
« Reply #7 on: February 18, 2019, 12:44:51 PM »
I had this same problem, reduce the timeout value in the configuration so the gateway doesn't get bogged down talking to a missing node.

Henryp

  • Hero Member
  • *****
  • Posts: 161
Re: Communication issue
« Reply #8 on: February 26, 2019, 07:29:16 PM »
I'm polling the data directly from an OPC server. I setup a few tags for device id 1,  no communication problems. I setup a few more tags for device id 2,  no communication problems. I power down device id 2 and I get intermittent data and bad OPC data quality with device id 1.  Adjusting the timeout and retry in the gateway makes no difference. I don't see how this can be an issue on my side.

jgreenewv

  • Newbie
  • *
  • Posts: 7
Re: Communication issue
« Reply #9 on: February 27, 2019, 08:24:00 AM »
I'm polling the data directly from an OPC server...
Adjusting the timeout and retry in the gateway makes no difference.

You may need to adjust the timeout and retry in your OPC server.  I've run into issues in the past where the OPC server is waiting for a response from a device and it causes other tags to temporarily switch to bad quality.