AdvancedHMI Software

General Category => Support Questions => Topic started by: needhmi on June 01, 2017, 05:09:20 PM

Title: ModbusRTU driver not closing?
Post by: needhmi on June 01, 2017, 05:09:20 PM
My solution has two forms, and both need the ModbusRTU driver.  I put the BasicDataLogger21 on page 2 and for some reason the pollrate seems much slower.  It seems that the slowness is caused from the mainform's driver remaining active.  When I go back to the main form, there is no normal delay for the driver to connect. 

I'm using a FormChangeButton to change forms.  Is there a different button I need to use or a setting I possibly have missed to close the mainform when I open page 2?

Thanks! 
Title: Re: ModbusRTU driver not closing?
Post by: Archie on June 01, 2017, 05:19:21 PM
Do you have the following code behind both forms:
Code: [Select]
   '*******************************************************************************
    '* Stop polling when the form is not visible in order to reduce communications
    '* Copy this section of code to every new form created
    '*******************************************************************************
    Private NotFirstShow As Boolean

    Private Sub Form_VisibleChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.VisibleChanged
        '* Do not start comms on first show in case it was set to disable in design mode
        If NotFirstShow Then
            AdvancedHMIDrivers.Utilities.StopComsOnHidden(components, Me)
        Else
            NotFirstShow = True
        End If
    End Sub
Title: Re: ModbusRTU driver not closing?
Post by: Phrog30 on June 01, 2017, 05:44:49 PM
Archie, off topic, but how do you safe your code snippets?
Title: Re: ModbusRTU driver not closing?
Post by: Archie on June 01, 2017, 05:50:41 PM
Archie, off topic, but how do you safe your code snippets?
Do you mean incorporating them into the Visual Studio code snippet tool like this:

https://docs.microsoft.com/en-us/visualstudio/ide/walkthrough-creating-a-code-snippet
Title: Re: ModbusRTU driver not closing?
Post by: needhmi on June 01, 2017, 06:13:58 PM
I do have that- I didn't change any of that- sorry I didn't mention that before. 
Title: Re: ModbusRTU driver not closing?
Post by: Phrog30 on June 01, 2017, 06:15:29 PM
Archie, off topic, but how do you safe your code snippets?
Do you mean incorporating them into the Visual Studio code snippet tool like this:

https://docs.microsoft.com/en-us/visualstudio/ide/walkthrough-creating-a-code-snippet

Yes, just curious if you use that or something else as a repository.
Title: Re: ModbusRTU driver not closing?
Post by: Archie on June 01, 2017, 06:24:17 PM
I do have that- I didn't change any of that- sorry I didn't mention that before.
What do you have the PollRateOverride set to for the driver instance on the second form.
Title: Re: ModbusRTU driver not closing?
Post by: Archie on June 01, 2017, 06:24:57 PM
Yes, just curious if you use that or something else as a repository.
I do not have a formal repository that I use for code snippets.
Title: Re: ModbusRTU driver not closing?
Post by: needhmi on June 01, 2017, 07:05:19 PM
I have the poll rate set to zero on the second form.  If I cut and paste the BasicDataLogger21 onto the main form it's better before I open form 2, but if I open form 2 it is still slow even just viewing data, without the datalogger tied to the form.  I'm logging 20 addresses at a 40ms time interval. 

The only reason I am using it on page 2 is because I wanted the HMI to open in a not logging state and I could not get the pause logging feature to work.  Two forms set up like this works fine with less addresses, and it works fine with all 20 when just using a single form. 

I cleaned the project after the changes and rebuilt if that is a good practice.

Thanks for the help.
Title: Re: ModbusRTU driver not closing?
Post by: Archie on June 01, 2017, 08:56:44 PM
Try setting the PollRateOverride to 40 and set your BasicDataLogger2 property of LogTriggerType to EverySample
Title: Re: ModbusRTU driver not closing?
Post by: needhmi on June 06, 2017, 12:37:08 PM
Thanks for that suggestion - even though it did not improve things much if any, it obviously was worth a try - I wasn't very confident the way I had it set up was the best way. 

I set up a datalogger in the main page as well and the proof of it disposing after a form change is in the log, still not sure the driver is closing however. 

Is the lack of connection delay when navigating to another form evidence that the driver is not closing?  I looked in my event logs on my computer to see if it was listed- didn't see it but I am no expert looking at those. 

I'll just have to use one form for now until this is solved so it's not too big of a deal, but would be nice to get both forms working. 
Title: Re: ModbusRTU driver not closing?
Post by: Archie on June 06, 2017, 12:46:12 PM
Something else to try..... For every driver instance, set the EnableLogging property to True. It should then create a log file of all communications.
Title: Re: ModbusRTU driver not closing?
Post by: needhmi on June 06, 2017, 08:20:32 PM
I forgot about that function.  For some reason the app crashes with that enabled- it does log for a few seconds. 
Title: Re: ModbusRTU driver not closing?
Post by: Archie on June 06, 2017, 08:29:55 PM
Do you get a file within those few seconds? My guess is the data is coming faster than it can open and close the file, so it causes a crash.
Title: Re: ModbusRTU driver not closing?
Post by: needhmi on June 07, 2017, 04:35:00 PM
Yeah I do get a file with quite a few lines.  Will it tell me if both driver instances are active?  I don't have quite enough time to change forms before it crashes so I just assumed it wasn't enough of a log.  Could I change something temporarily just to test?
Title: Re: ModbusRTU driver not closing?
Post by: Archie on June 07, 2017, 05:00:38 PM
Can you post the file? The only real way of knowing if both drivers are communicating is by looking at the data requested.
Title: Re: ModbusRTU driver not closing?
Post by: needhmi on June 07, 2017, 06:50:35 PM
Here is one, attached.
Title: Re: ModbusRTU driver not closing?
Post by: Archie on June 07, 2017, 08:57:06 PM
The driver is sending a second request before the first response was received. I will have to setup a test to see if I get this same thing.

Are you using the latest version of 3.99w ?
Title: Re: ModbusRTU driver not closing?
Post by: needhmi on June 07, 2017, 09:24:05 PM
I am using 3.99w, that's on the first line of the release notes.  During that log I did manage to change forms just before it crashed.  I can send another one staying on the same form if you want me to.

Thanks!
Title: Re: ModbusRTU driver not closing?
Post by: Archie on June 07, 2017, 09:54:44 PM
That capture tells me enough to know what to look for. There is supposed to be a minimum of 100ms in between sends if no response is received. In the capture there are 2 consecutive sends that are only 16ms apart.
Title: Re: ModbusRTU driver not closing?
Post by: needhmi on June 08, 2017, 11:21:23 AM
Ok, thanks for your help and work on it as you have time. 
Title: Re: ModbusRTU driver not closing?
Post by: Archie on June 08, 2017, 05:05:41 PM
I'm not able to replicate this. Attached is the log file and you can see I am getting alternating Send/Receive.

I'm wondering if your device can handle the 0 poll rate. Try increasing to PollRateOverride to 100 at first, then decrease by increments of 20 to see if the problem starts occurring at any particular rate.
Title: Re: ModbusRTU driver not closing?
Post by: needhmi on June 08, 2017, 06:59:20 PM
I set that up with 100 ms for pollrate override and it is still strange it seems, it is sending or receiving faster than 100 ms (see attached) and sends and receives at the same time- which is not the case with yours I see.  A few times I see two sends and two receives.

I may have something fouled up in the datalogger properties, I still have it set up to trigger every sample.  I set Log Interval to 0 and pollrate to 100.   I should confirm - I don't need to worry about the interval or pollrate since the trigger is set to every sample?   It sounds like the pollrate override in the driver properties will override anything else so I was assuming the datalogger properties don't matter in regard to pollrate or interval.

You could be right about the plc, to complicate things more it is getting some of it's data via RS-232.  The actual data stream is much more accurate when the datalogger is only set up on the main form, even so after a close look the data recorded by the basicdatalogger21 tool only changes about every 160 ms even though the HMI stamps the log about every 40 ms (when set up to do so), give or take a few 1000ths of a second...

I also logged the driver with a single form set up and it is also attached.  It looks better in that for the most part it alternates send and receive except for the end but still stamps send and receive at the same time.

I think I'll try a different laptop and see if that helps, the one I am using is old with Vista. 
Title: Re: ModbusRTU driver not closing?
Post by: Archie on June 08, 2017, 08:00:28 PM
As I look closer to the data, I can see where the time stamps are the same, the RCVD actually comes before the SEND. If those are switched then the SEND/RCVD will alternate properly. I am unsure why that is happening.

Even with a PollRate of 100, you can see requests coming faster. This is because it may take 2 requests to get all of the data, therefore splitting the PollRate. In other words, the 100ms will be for the same packet to request again. For example, take this packet:

03:41:38.318 Send 1,3,0,7,0,1,53,203,

Looking for the very next time it requests that particular data you will find:

03:41:38.411 Send 1,3,0,7,0,1,53,203,

Which happens to be 93ms later. So it appears it is taking 6 packets to get all of the data, therefore the time between requests should be 16-17ms. Other than the SEND/RCVD being time stamped at the same time, the data otherwise looks normal.

If your device supports large packets, you can potentially reduce that number of request by increasing MaxReadGroupSize to something like 50