Modbus fix

[Archie]

Now we are getting somewhere. The ClickPLC is not responding all the time to the request. For instance, if you look at this packet:

1/10/2017 2:26:32 PM Send 1,3,112,2,0,6,126,200,

If does not respond, therefore the driver waits for the Timeout period of 3 seconds and tries again.

We now need to find why the PLC ignores the request. I made a patch that will display the data in ms resolution. Download Path1V399t from here:

https://sourceforge.net/projects/advancedhmi/files/advancedhmi/3.5/Patches/

- Extract the file
- Open your project in Visual Studio
- In Solution Explorer, under the AdvancedHMIDrivers project, right click the Support folder and select Add-Existing
- Browse to the file you downloaded and extracted
- Run the application again and make sure the log file show time stamps to ms resolution, then post the result

[vitico bon]

Interesting, I don't know if it was because in on my last testing I slowdown the bps to 9600 or because you modification of the driver slow it also but now I see less error, still every couple of minutes you can see the communication stoping on both units (nothing in, nothing out) I still can't get the log for my application but here is the one from your sample.

Did you saw the last pic I sent you of the analizer, it seem that the program is the one that is not sending command evenly.

Thanks.

[Archie]

May be getting somewhere now. Try Patch 2:

https://sourceforge.net/projects/advancedhmi/files/advancedhmi/3.5/Patches/

[vitico bon]

Good morning Archie, I see you are getting somewhere, both applications (your temp. controller and my click) are acting similar now,  you can see activity in both PLCs for a few seconds, then stop and restart again. Here I am attaching two files, the Driverlog.txt that your Temp sample generated, and then in the post below this the log of my application generated by HHD device monitoring since my application still refuses to generate the Driverlog.txt. 

victor.

[vitico bon]

And this is the log from my application.

[Archie]

I was suspecting the ClickPLC needed a long delay between packets, but this does not seem to be the case. Looking here:

09:05:02.253 RCVD 1,3,12,106,5,66,18,176,0,70,179,86,160,64,170,
09:05:02.294 Send 2,3,112,2,0,6,126,251,
09:05:02.398 Send 1,3,112,2,0,6,126,200,
09:05:05.148 Send 2,3,112,2,0,6,126,251,
09:05:05.569 RCVD 2,3,12,58,154,66,23,0,0,0,0,152,252,64,176,

There is a 41ms delay between receipt and next request. At 38400 baud, the Modbus requirement is only 1.75ms. When one node does not respond, it looks like the other node does not respond either in every case. What are you using for an RS-485 adapter?

[Archie]

And this is the log from my application.

In your exported log file, something I can't make sense of is why the 5th column alternates UP/DOWN , then suddenly only shows UP. It seems to stop showing the request packets.

[vitico bon]

Archie,
 
Now that I found and installed the analyzer yesterday I went back to test with the Cimplicity (GE HMI) and found out that at this point your program and Cimplicity are acting very similar, the amount of timeouts (UP and DOWM) that I am getting in Cimplicity is horrendous.

When I started having problem, I was able to communicate with one device at the time, and Cimplicity appeared to be doing a better job, but now after all the reviews that you have done I can communicate with both devices, intermittent but is talking to both of them as well as Cimplicity so I can say that you have done you part and now if up to me since appears that my problems now are related to the communication adapters that I am using.

At the present I have an inexpensive RS-232 to RS-485 converter model # XS201A from USconverter.com  connected to a USB to Serial converter model # TU-S9 from Trendnet, somewhere in there seem to reside my most recent problems. I am going to get something from B&B electronic, a brand that I always trusted to continue my test, I will then test with all your patch (including the original release of version t and will let you know the result here or in a new post. I think that at this point I can say your help had being outstanding.

Just before I close this until new development. Can you tell me what kind of adapters are you using for your test? I may want to get the same one.

Thank you for your help and patient dealing with this issue. 

Victor.

[Archie]

At the present I have an inexpensive RS-232 to RS-485 converter model # XS201A from USconverter.com  connected to a USB to Serial converter model # TU-S9 from Trendnet, somewhere in there seem to reside my most recent problems. I am going to get something from B&B electronic, a brand that I always trusted to continue my test, I will then test with all your patch (including the original release of version t and will let you know the result here or in a new post. I think that at this point I can say your help had being outstanding.

Just before I close this until new development. Can you tell me what kind of adapters are you using for your test? I may want to get the same one.

I have been doing my testing with the USB to RS-485 Adapter from AutomationDirect:

https://www.automationdirect.com/adc/Shopping/Catalog/Communications/Serial/Serial_Isolators_-a-_Converters/USB-485M

[vitico bon]

I just place the order to see if I can get it before the week end. (better price than B&B).
Will let you know what happen then.
Once again, Thanks for your help.

[bachphi]

USConverters.com ( with the 's')  .  I was really impressed with their USB to RS232 converters XS880. Best in class , I think

http://www.usconverters.com/usb-serial-adapter-xs880

[vitico bon]

Ok Archie,
I own you this response. (good news)

I have being running tests after receiving the Automation direct adapter. Unfortunately I lost track of all the various patch that you prepare so I only was able to run test with the original release "t" and the last one you made.  With the original I continued having problems, but with the last patch the program communicated with the two Clicks, from time to time I can see that there is a pause of a second or two in communication but it catch right away, witch I think that at the moment is acceptable. My original objective was  to be able to communicate with more than two devices, but I don't have at the moment the necessary hardware to test.

During the test I change the BPS to various rates and find out that the hugest reliable speed that I can use is 38400, also it is clear now that the model and USB port of the converter have a huge importance, If I connect the adapter to one of the USB ports on my computer screen I get a tremendous amount of missing communication packages, but connected directly to my computer USB port then I get acceptable results.

I will still keep testing whenever I have the time to improve it as much as possible. If and whenever I have new issues I will place them in a new post since I am assuming that this case was satisfactory closes. 

Thanks you for your help.

[Archie]

Thanks for the feedback. I do have one more patch for you to try. After I did some testing and debugging with the patches, I found the original version t would only give 1ms of silence between packets at 38400 baud. According to the Modbus specification, the minimum time is 1.75ms. So I made that adjustment and will have another patch for you to try later today.

[Archie]

I posted patch 3 that more closely complies with the Modbus specification:

https://sourceforge.net/projects/advancedhmi/files/advancedhmi/3.5/Patches/

[vitico bon]

When running your new patch the following error starter to come immediately after I try to connect to the second PLC

"A first chance exception of type 'MfgControl.AdvancedHMI.Drivers.Common.PLCDriverException' occurred in MfgControl.AdvancedHMI.Drivers.dll"

So I went back to the one that is working because I want to run a test for several days.