AdvancedHMI Software

General Category => Support Questions => Topic started by: vitico bon on December 22, 2016, 01:40:33 PM

Title: Problem with multidrop Modbus
Post by: vitico bon on December 22, 2016, 01:40:33 PM
Ok here I am again asking for help.

I got my application about 99% done so I am ready to run some test, I had only small issues until I decide to test it using a RS-485 port with two units. (Modbus RTU)

I can connect to unit 1 or 2 with no problem, but when I connect to the two of them the communication  basically stops (keep timing out).  The program was build  using a MDI form. Each time that I click on a system in the menu an instance of a form with some animation comes on, get the unit ID for that particular units and set it on the station address variable “ModbusRTUCom1.StationAddress = CByte(MBaddres)”.  As I said, it works fine one at the time but not when two instances are open.

I ran a test using Cimplicity from GE and I was able to read from both units at the same time with no problem so is not a hardware or wiring problem.

Any suggestion from the experts?

Regards,
Happy holidays.
Victor.
Title: Re: Problem with multidrop Modbus
Post by: Godra on December 22, 2016, 07:23:33 PM
Check replies #3 and #10 here to see if that helps:

http://advancedhmi.com/forum/index.php?topic=765.msg4720#msg4720

You might as well read all other replies there since eventually any of these might help.

All these kind of suggest to use simulators for testing and maybe try using 2 drivers instead of 1 ....

Archie could possibly suggest something else related to the driver itself.
Title: Re: Problem with multidrop Modbus
Post by: vitico bon on December 23, 2016, 05:44:47 PM
Thanks you for your fast response Godra, I look at the tread you recommended but don't see mush help there, let see if Archie can put some light on this. I understand that in the same form I will need to use two driver, but in my case I have two instances of the same form and set the driver to the corresponding address, Also I am connecting to two identical PLCs, not a simulation.

Anyway I will keep testing to see if I can find the problem on my own.
Title: Re: Problem with multidrop Modbus
Post by: Godra on December 23, 2016, 06:29:50 PM
I have no experience with RS-485 but could suggest one more thing to try:

Instead of using 2 instances of the same form, can you try using 1 instance of the form with 1 driver on it and create a separate new form with another instance of the same driver but with different StationAddress?

This would be for testing only.
Title: Re: Problem with multidrop Modbus
Post by: vitico bon on December 23, 2016, 06:57:25 PM
Just tested with two independent form, one to device 1 the other to 2 with same result, it have to be something I am missing here.

Thanks once again
Title: Re: Problem with multidrop Modbus
Post by: vitico bon on December 23, 2016, 09:02:56 PM
I spend some time watching the behavior of the program with the MDI form pulling one word from each unit every 3 sec. and one child form that that pull some more data from one of the units, it seam that each time the program request data from a different unit there is a delay in the initialization or response of that the data, so from time to time I see the child form freeze for a second or two and then continue working normally.

It may have something to do with the way the driver was written and how it handle communication with two or more devices at the same time.   
Title: Re: Problem with multidrop Modbus
Post by: ShriramPendse on December 24, 2016, 05:16:38 AM
@It may have something to do with the way the driver was written and how it handle communication with two or more devices at the same time.  /// You are right .

While using ModbusRTU (means on serial lines , not ethernet) , you will have issues to use Adv HMI controls directly talking to RTU slaves .

I use a timer on form and read required addresses from slaves . The values received are passed on to the controls on form . This way you have total control on what registers are read , from which slave,  at what interval etc.
It complicates the matters, but works .
Title: Re: Problem with multidrop Modbus
Post by: vitico bon on December 24, 2016, 02:08:58 PM
ShiriamPendse, on second thoughts the unit ID is passed in the query message follow by the function code so I don't see how can this have something to do with the driver, It should grab whatever message is put and just send it, unless two  messages to different devices can have some kind of collision. Also is possible that for some reason, when the unit ID is changed the port get closed and reinitialized although I don't see reason for that.

That is why I would like Archie to put his two cents on this if possible. By now I am out of  ideas. Nevertheless will keep investigating.
Title: Re: Problem with multidrop Modbus
Post by: Archie on January 03, 2017, 02:46:10 PM
I did some testing with the upcoming version 3.99t and so far it looks like it resolves the issues. Using 2 temperature controllers on RS485, I was able to view values from both controllers simultaneously. I also disconnected 1 controller and the other controller continues to update without delays.
Title: Re: Problem with multidrop Modbus
Post by: Archie on January 04, 2017, 09:34:22 AM
I created a patch that works with version 3.99s for anyone to test to see if it fixes the ModbusRTU multi-drop issue.

http://www.advancedhmi.com/MfgControl.AdvancedHMI.DriversPatch3V399s.zip

- Download and extract the file
- Open AdvancedHMI in Visual Studio
- In Solution Explorer, expand down the AdvancedHMIDrivers project
- Right click the Support folder and select Add->Existing Item
- Browse to and select the extracted file from above
- Rebuild the solution
Title: Re: Problem with multidrop Modbus
Post by: Godra on January 06, 2017, 09:30:59 AM
Thanks to DougLyons, I found out that MOD RSSim program supports multiple modbus slave devices behind a single COM port.

That's how I tested the new patch and all seems to be working (even when one of the devices is disabled).

The only thing I had to pay attention to was timing in the scenarios I used, which were:

- Single driver instance on the form and then changing its StationAddress
- 2 instances of the driver on the same form, each with a different StationAddress, and then disabling/enabling subscriptions of the drivers as needed
- Single driver instance on each form, each driver with a different StationAddress, and then switching between the forms
Title: Problem with multidrop Modbus
Post by: DougLyons on January 06, 2017, 04:10:33 PM
Godra,

I'm glad that you found another useful feature of the ModRSsim2 program. I believe that the original author, Conrad Braam, did an excellent job when he created it's structure. I see that you referred to the program as "MOD RSSim" which is not exactly correct and might make it more difficult to locate if someone were searching for it on the Internet. For simplicity, here is the website for my fork. https://sourceforge.net/projects/modrssim2/ (https://sourceforge.net/projects/modrssim2/)

To further clarify how this is used, you can refer to the <F1> - Help instructions and look under the "Protocols" section. By default a common set of registers are used for all station numbers, but by changing an advanced setting you can have separate register sets for each station. This unfortunately works in a somewhat confusing manner and limits you to only a subset of the whole range of addresses, but it does work.

Thanks,

Doug Lyons
Title: Re: Problem with multidrop Modbus
Post by: Godra on January 06, 2017, 04:42:13 PM
Doug,

You are correct. Whenever I mention the program I just omit to put number 2 at the end (will be more considerate the next time I mention it).

I do have another question for you, related to the attached picture:

At one point in time I was trying to resize some items but eventually got the program to look the way it looks in the picture.
Buttons on the right side are cut off and I'm not sure how to restore it back (even copying the file from another computer still doesn't restore these).

Would these settings be stored somewhere in the registry?

This is happening on a 10" netbook screen (1024x600 resolution). It is quite possible that the program normally shows on this small of a screen as the picture shows and that my re-sizing didn't cause any changes (I just don't recall the way it looked when I first run it on this computer).
Title: Re: Problem with multidrop Modbus
Post by: vitico bon on January 06, 2017, 07:58:10 PM
Today by the time I read this message I was already at home with no hardware to test, nevertheless I was able to do a TeamVierer session and run some test in the office setup, it appears to be working ok now, but with a remote connection I don't have a good feeling of timing, still it appears to be working now. Monday I will know for sure.

Thanks!
Title: Re: Problem with multidrop Modbus
Post by: Archie on January 08, 2017, 09:02:31 PM
Version 3.99t is now available with a fix to the driver for this issue.
Title: Problem with multidrop Modbus & ModRSsim2
Post by: DougLyons on January 09, 2017, 11:30:13 PM
Godra,

All settings for the ModRSsim2 program are stored in the registry here:
[HKEY_CURRENT_USER\Software\Adroit Technologies\Adroit\Simulators\ModbusRTUSim]

There is a later version of the software available for download that may work better on small screen sizes.

Thanks,

Doug Lyons
Title: Re: Problem with multidrop Modbus
Post by: Godra on January 10, 2017, 12:22:02 AM
Thank you Doug.

Just to let you know that this latest version 8.21.2.4 is still hiding 2 and a half buttons in the top right corner (even on a bigger screen with 1280x800 resolution).

For the small screen, version 8.21.1.9 shows properly.

EDIT: Just tried version 8.21.2.4 on the small screen again and now it shows all the buttons. Attached is the picture of this new version on the bigger screen with 2.5 buttons hidden (which was the case with the initial run on the small screen but is now changed).
Title: Problem with multidrop Modbus & ModRSsim2
Post by: DougLyons on January 10, 2017, 02:21:38 AM
Godra,

Thanks for your testing and updates.

After my initial SourceForge upload of version 8.21.2.4 I continued testing at lower screen resolutions.
What I found was the hidden buttons as you noted on 1280 and 800 pixel width screens.
I added a check for the Screen Width and made a correction of the Toolbar's position based on my findings.
Afterwards, I did another upload to SourceForge. It showed no downloads at that time, but this may be broken right now.
So, there was about a 4 hour window with slightly different code and you must had gotten a copy of the original code.
Now when you tested again, you were able to download the later code, so it works better for you.

Thanks again,
Doug Lyons