AdvancedHMI Software
General Category => Support Questions => Topic started by: vitico bon on January 09, 2017, 09:58:53 AM
-
Archie/Godra,
Fist I would like to pass my recognition for the time and effort that you guy are putting helping me, I hope that the result of all that will be a better and more robust product that is already amazing.
Today I spent some time testing modbus, I did a fresh download of the 399r version and rebuild the applications. For my test, according to Archie he the 399r version already have the fix. And here is what I found.
Keeping in mind that I am working on a PC application, the goal is to be able to open two identical windows showing/controlling data in two (or more) devices simultaneously, also I use a MDI form as startup that dynamically load as many instances of ModbusRTUCom to collect data for trending and alarms, so I am hitting each device at a frequency of about 2 seconds.
Now here is what I found with the revised version, I can open one window and all my data comes, then I open another instance of the window to the other device, the data to the second window start coming but the data to the first instance stop coming until I close the second one. Better than before but not quite as I need it, I would like the customer to be able to see data simultaneously in the two windows, also the data collection get affected by this.
Thank you guys.
-
Are you using 3.99r or 3.99t?
-
I am using the version that I just downloaded from the link in the home page, Now that I double check that is version t.
-
The way I understand this, you can only communicate to 1 station at the time (unless you establish some sort of timed switching).
-
When I did my testing, I used 2 driver instances and 2 BasicLabels to show values from 2 controllers simultaneously
-
From Victor's other topic, he seems to be looking to use 2 instances of the same form and just changing the driver's StationAddress.
If he doesn't keep on switching the StationAddress back and forth then the driver will be communicating with 1 station only.
-
In that case let me try to do a test with as many drivers as devices I intent to control here (no more than 8) and use the DisableSubcription to enable only the one I need. No idea how this is going to go since I will have to change also the ComComponet on each one of the controls in the code. but it worth the try. There also be a issue with a few direct read and write that I do in the program.
Ideally, since the device ID is part of the command and have nothing to do with the port itself you should be able to change the device ID on the fly so commands can be send to any device, but maybe this is not possible because of the way the hole driver was put together trying to accommodate several protocols.
-
You are correct Godra, let me see if by the end of the day I can make a small movie of the system and load it here, else I will put it in youtube and will give you the link.
-
Here is the clip on YouTube.
https://www.youtube.com/watch?v=kNLvmLrwJvg&feature=youtu.be
-
I created a simple app that uses multiple instances of the same form. I can open both forms simultaneously and I still get updates from both controllers. I posted the project in the sample project section under the name ModbusRTUMultiNodev399t
https://sourceforge.net/projects/advancedhmi/files/advancedhmi/3.5/SampleProjects/
-
Were you using a real hardware or a simulator?. I just run your program with same result, when windows are open one at the time everything seem ok, but is you open both windows at the same time only one control is updating his values (only one tx LED is blinking)
I do not believe this have to do with hardware since I already tested it with a GE product.
-
Were you using a real hardware or a simulator?. I just run your program with same result, when windows are open one at the time everything seem ok, but is you open both windows at the same time only one control is updating his values (only one tx LED is blinking)
I tested this with 2 Solo temperature controllers. Try setting the EnableLogging property of the driver to True. Then run the test and post the log file that was generated.
-
Will do, but also, and keeping in mind that I am new to .net I had to recompile your program to adjust to the port setting of my hardware. Is it possible that I am missing some project settings here?
-
Ok this must tell you something! Using your test the only data in the DriverLog.txt was the one collected during your test, then just to doublecheck I deleted it and open the program again, and no new log file was created. I think I have something grown in my setup.
BTW I am using Visual Studio 2010 R1.
-
I started the test application and immediately clicked both buttons to open both windows. Attached is the DriverLog.txt file that it generated. You can see that it alternates between address 1 and 2.
-
Yes, I saw that log in your project, but then I have to build it with my port parameters and records stop coming into the log. Just to try, I am installing now the Visual Studio Express 2015 in another machine to see what happen. Don't know if that version will be compatible with your product though. Let see.
-
The version of Visual Studio shouldn't make the difference. Double check the driver instance and make sure you have EnableLogging set to True.
-
Here I am putting everything into the same pic. The numbers on the controller 1 are the last it got after I popped the second window. returns are coming only from PLC2 and no log file. ???
-
Put a button on your form, then double click and add this code:
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
MsgBox("EnableLogging=" & ModbusRTUCom1.EnableLogging)
End Sub
This will verify that your logging is enabled during run time.
-
Had problems with size. Here goes the pic.
-
Still not getting the LOG but I was able to get the two controllers working by bringing the PllRateOverrrite to 1000. In your test.
-
Still not getting the LOG but I was able to get the two controllers working by bringing the PllRateOverrrite to 1000. In your test.
Did you try the button test?
-
Yes I try the button and the Msg was "True".
I also went back to my application and increase the time to 1 second, now I can see how data return is sort of intermittent between the units PLC 1 return data for a few seconds, then switch over to PLC 2, and so on, but never the two of them, I will increase it even more to see if I reach a point where data come to both. Remember someone mentioning before that perhaps finding a way of enable/disable subscription in a fashion that the command don't go out almost simultaneously could be a solution. Obviously I have way more data in each window instance of my application than in your test.
I also set the EnableLogging to True in my application and no data is being logged.
-
I can't figure out why you are not getting a log file. That would give me a good insight to the problem. I have a feeling the data request is flooding the PLC and it is possibly ignoring the requests. Or the required silence period between packets is not long enough. But didn't you say the same test application with only 2 values is not working for you?
-
Yes the same test (your test) was not working until I increased the Rate Override to 1000 then started to work. Here is the port configuration of the CLICK.
I also try increasing the rate on my app, but went all the way to 3000 and it is better but still intermittent between PLCs.
Not much to do with the log when not working it is just an enable/disable flag, nothing else, still will keep trying from time to time.
-
Are you by any chance using a 32 bit operating system that will allow you to run Free Serial Port Monitor?
-
Win 7 64.
-
I'm running out of ideas since I do not have a ClickPLC with RS-485 and the logging is not working for you. I even increased my baud rate to 38400 and set PollRateOverride to 0 in order to really stress the communications. Both controllers work without missing a beat.
I even changed the log time stamp to include milliseconds to see how fast it was communicating. I'm getting about 40-60ms updates from each controller.
-
Well after installing the Visual Studio Express 2015 I was able to run your test and here is the DriverLog running at your original rate override of 50 As you can see it pulls from one and then after a while it switches over.
-
I got a analyzer demo and this is what I saw, it appears that is the program that start sending to one of the PLC then for couples of commands sent to both and then switches to the other PLC.
-
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
-
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.
-
May be getting somewhere now. Try Patch 2:
https://sourceforge.net/projects/advancedhmi/files/advancedhmi/3.5/Patches/
-
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.
-
And this is the log from my application.
-
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?
-
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.
-
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.
-
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
-
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.
-
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
-
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.
-
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.
-
I posted patch 3 that more closely complies with the Modbus specification:
https://sourceforge.net/projects/advancedhmi/files/advancedhmi/3.5/Patches/
-
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.
-
Something else you can do to reduce the pause when there is no response to a packet is to change the Timeout property from 3000 to 1000
-
Will try today, thanks.