AvancedHMI Application slow to start up -- uses up lots of RAM at first

[usapatriotforlife]

I have an advanced HMI 357 solution with three meters and 3 pilot lights and 1 PLCSLCMicroCom ethernet driver.  The pilot lights are set to "ENABLED=FALSE" and are not associated with any PLC driver.  The three meters all point to a single address of "N17:0".

I have noticed that it takes up to 30 seconds for the program window to display when running the program.  This happens in both "build" and "release" mode. It happens when I run the program from windows explorer or from within the VS2012.

I don't know if it has anything to do with it, but I notice the following message will appear multiple times in the debugger when the program exhibits this behavior:

The thread 'SendQueProcessor' (0x15c) has exited with code 0 (0x0).  (It always exits with a 0 code, but of course the thread ID is not 0x15c every time)

The other thing I noticed is that the the AdvancedHMI application starts to use up memory while it is paused and then once things settle down, the memory is released.

It is very repeatable on my system. 

• I run the app and see the process appear in "taskmanager"
• the process will take up around 10 to 20k of memory and there will be no window showing
• about 30 seconds later (sometimes longer than 30 seconds, every now and then, sometimes a lot shorter than 30 seconds) the application form window will display.
• memory utilization will jump from 20k to between 50k and 80k
• generally the controls have a message about not being able to contact the PLC
• in a few seconds, the controls will display the value from the PLC register
• and at the exact same time, all that extra memory will be released and it will back down at around 20k
• the program appears to act normally after that

Any ideas? 

Thanks!


here is the debug output of a sample run:

<PROGRAM START UP>
'AdvancedHMI.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Users\Ken\Documents\Visual Studio 2012\Projects\357\Development\WisPak01_AHMI.357\AdvancedHMI\bin\Release\AdvancedHMI.exe', Symbols loaded.
'AdvancedHMI.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Runtime.Remoting\v4.0_4.0.0.0__b77a5c561934e089\System.Runtime.Remoting.dll'
'AdvancedHMI.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
'AdvancedHMI.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Users\Ken\Documents\Visual Studio 2012\Projects\357\Development\WisPak01_AHMI.357\AdvancedHMI\bin\Release\MfgControl.AdvancedHMI.Controls.dll'
'AdvancedHMI.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Users\Ken\Documents\Visual Studio 2012\Projects\357\Development\WisPak01_AHMI.357\AdvancedHMI\bin\Release\AdvancedHMIDrivers.dll', Symbols loaded.
'AdvancedHMI.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\Users\Ken\Documents\Visual Studio 2012\Projects\357\Development\WisPak01_AHMI.357\AdvancedHMI\bin\Release\MfgControl.AdvancedHMI.Drivers.dll'
A first chance exception of type 'MfgControl.AdvancedHMI.Drivers.Common.PLCDriverException' occurred in MfgControl.AdvancedHMI.Drivers.dll
The thread 'SendQueProcessor' (0x3e0) has exited with code 0 (0x0).
A first chance exception of type 'MfgControl.AdvancedHMI.Drivers.Common.PLCDriverException' occurred in MfgControl.AdvancedHMI.Drivers.dll
The thread 'SendQueProcessor' (0x15c) has exited with code 0 (0x0).
<CLICK X TO CLOSE PROGRAM>
The thread '<No Name>' (0x28c) has exited with code 0 (0x0).
The thread '<No Name>' (0x630) has exited with code 0 (0x0).
The thread '<No Name>' (0xa4c) has exited with code 0 (0x0).

[Archie]

This sounds like there is a connection issue or a control with a PLCAddress that does not exist, The SendQueProcessor exiting with code 0, means the driver disconnected communications for what ever reason. The easiest way to see what is happening is to use Wireshark. You can start a packet capture then start the AdvancedHMI application. In the packet capture you should see a Register Session (EIP) followed by a Forward Open (CIP), then an unknown service(0x4b) which is the actual read.

I am guessing there is a connection problem or read problem and then there will be a Forward Close following by an Unregister Sesssion, The pattern may happen twice during that long startup period. If this is the case, the data contained in the unknown service(0x4b) and it's response will give the clue to what is happening.

[Archie]

The RAM usage is normal for a .NET application. As objects are created and destroyed the memory usage will climb. Once the garbage collector decides it is time, it will go through and release the memory of these unused objects.

If you are interested in more details of this process, you can read about it here:

http://msdn.microsoft.com/en-us/library/0xy59wtx.aspx

[usapatriotforlife]

Archie,

There is definitely a connection issue.  The program is reaching out to PLCs behind cellular modems and the very nature of cellular data is that the initial network connection takes some time to be created.  For example, in most cases, if I start a continuous ping to a cellular modem, the first few pings will fail, then they will start up and behave fairly normal.   

I'm used to the controls reporting connection issues on start up, but they settle down and start to work once the connection is fully established.  My most used cellular application is using Advanced HMI v 341.  The v 341 program does not seem to suffer from the start up display lag like my new app in v 356 does.  I understand that a lot of stuff has been revamped in these later versions, but the change in behavior made me believe that this might be a bug.

To test to see if it was a connection issue that is causing the behavior, I started up continuous pings to the cellular modems I'm developing with this week.  Once the pings settled down and began working, I fired up the application several times.  Each and every time, the app started almost immediately and my controls populated with data very fast.  I would say you are definitely correct in what is slowing down the screen display on start up.

Since the nature of my connections cannot be changed, what is the best way to ensure that my application window is fully visible before any PLC communication is attempted?  (I don't mind the delay once the form is displayed.)

Thanks for all of your help and advice.

[Archie]

I'm not completely sure what results to expect, but try this:

- On you startup form, set the driver property DisableSubscriptions to True
- Double click the form to get to the Load event handler
- EthernetIPforPLCSLCMicro1Com.DisableSubscriptions=False

This should allow the form to initially load become visible before attempting any connections to the PLC

[usapatriotforlife]

I tried as you suggested and it had no affect.  Even without me setting that value to "false", the controls still used the comm driver.  I next tried setting the plc comm drive to NONE on the controls, but after a compile, the IDE would show them attached to the very first comm driver.

I think I'll have to create the comm driver object manually at run time after the form loads and then assign each object to a comm driver.  I saw an example of doing that somewhere on here I believe.

Thank you so much for helping me with this.  Worst case scenario, I'll create a splash screen that loads the advanced HMI.  At least that way the user will have visual feedback that the program is "loading".

[Archie]

I don't have access to my Micro right now to test this, but give this a quick try. At line 223 in AllenBradleyPCCC.vb, change this line of code to this:

        Dim ParsedResult As New PCCCSubscription(PLCAddress, 1, 0)


By changing ProcessorType to 0 will keep the driver from trying to get the processor type when adding subscriptions.

[usapatriotforlife]

Hi, Archie,

A PLC that I communicate with using the EthernetIPforCLXComm driver went down tonight at one of the plants.  The AdvancedHMI program that I wrote reads data from that PLC as well as another PLC that uses the EthernetIPforPLCSLCMicroCom driver.  With the one PLC not responding, the program was very sluggish and wasn't working very well at all.  I implemented the change to PCCCSubscription that you suggested and the application is running like normal again!

This leads me to a few questions:

• Does the suggested change work for both types of PLC drivers I mentioned, or just the EthernetIPforCLXComm?
• Even with disabled subscriptions set to true on both drivers, I'm still getting data on the PLC that is up and running.  I must not be understanding what disabling subscriptions does.  Does it mean only disable new subscriptions but subscriptions ARE still created for controls that were built and assigned at design time?
• What is the benefit of getting the processor type? 
• My initial thoughts are to always put this change in all of my advancedhmi apps from here on out since it seems to make them more bullet proof.  So, to pose question #3 in a different way, would this be a bad thing?

(I'm using v 3.5.7)

Thanks!

[Archie]

The reason the SLC/PLC driver needs to get the processor is because there are different PCCC commands for accessing data depending on which processor it is. By disabling that, it defaults to SLC/Micro

The CLX driver does not get the processor type because EthernetIP/CIP commands are the same for all processors that support tag based data access.

The latest CLX driver will continue to try to read because there is a queue of commands it is trying to process. Once the subscriptions were disabled, no more commands are added to the queue, however it does not clear the queue because it does not know which reads were initiated by subscriptions.

With subscriptions disabled, data will still be read if you are reading data with your own code using the Read method.

[usapatriotforlife]

Hi, thank you for the clarification, Archie.  Since I can disable subscriptions for the IP comm driver during design time and I still see data flowing in to AdvancedHMI components also created at design time, I'm guessing that design time component subscriptions are added to the driver's queue irregardless of its disable subscriptions property.

I need a way to pause all I/O activity through a PLC Comm driver if a network problem is detected with its associated PLC.  I'm thinking that I ought to be able to figure out how to cycle through all the subscriptions associated with the PLC Comm driver and remove them manually.  Is there another method I can use that's already built?  For instance, a method that does this already when the program is shutting down?

PS:  This thread has morphed in to more of a support Q&A thread.  Do you want me to start over in the "Support Questions" group?

[Archie]

Since I can disable subscriptions for the IP comm driver during design time and I still see data flowing in to AdvancedHMI components also created at design time, I'm guessing that design time component subscriptions are added to the driver's queue irregardless of its disable subscriptions property.

You will see this when using the EthernetIPfofCLX driver. This is because the driver will perform a single read during the creations of a subscription in order to get the data type. This information is used for optimizing the subscription reads.

I cannot test this right now, but this may be a fix to resolve the problem. In EtherneIPforCLXCom.vb at about line 634, add this code:

Code: [Select]

    Public Function Subscribe(ByVal PLCAddress As String, ByVal numberOfElements As Int16, ByVal PollRate As Integer, ByVal CallBack As EventHandler(Of MfgControl.AdvancedHMI.Drivers.Common.PlcComEventArgs)) As Integer Implements IComComponent.Subscribe
        If m_DisableSubscriptions Then
            Throw New MfgControl.AdvancedHMI.Drivers.Common.PLCDriverException("Cannot create new subscription when DisableSubscriptions=True")
        End If


[usapatriotforlife]

Very interesting results: With "disablesubscriptions" set to true at design time and the change you suggested, the exception is thrown the first time through, then at what appears to be the next polling cycle, PLC values start to flow in and the exception is not thrown again.  Thanks for helping me with this.