Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - usapatriotforlife

Pages: 1 [2] 3
16
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!

17
Thank you so much for the example.  That goes a long way towards helping me understand how to use subscriptions in code. 


18
I would definitely appreciate it if someone would post a short code section showing how to asynchronously read three or four registers on a PLC using a datasubscriber object connected to a one of the ethernet comm drivers.  I'm completely confused on how to add the registers, say for a SLCMicro of N17:0, N17:1, B16:0/0 and then how to add the event handlers when data comes back.  Thanks in advance. 

19
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".

20
Open Discussion / Re: What controls are there that I don't know about?
« on: August 23, 2013, 04:44:22 AM »
Fantastic, thanks for the teases!  I'd love to see a Richter scale type control or maybe one like on a lie detector or EEG where the paper moves under the pen making a continuous trail.  I look forward to more expansion packs and taking your class one day soon.

21
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.

22
Open Discussion / What controls are there that I don't know about?
« on: August 23, 2013, 12:34:49 AM »
I purchased the Meter Pack 1 expansion pack and love it.  Then I read a thread where you discussed a FAN control that is available to those who take your class.  This got me to wondering what other controls are out there that we don't know about and if you'll ever put them in another expansion pack for purchase.  I hope so!

23
Is sure will.  It'll be a few days, but I definitely will test and let you  know.  Thanks again.

24
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:
Quote
<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).

25
Support Questions / Re: Meter Pack
« on: August 22, 2013, 02:09:20 AM »
The meter pack rocks.  It looks great.  The Digital Panel Blue Meter and the Horizontal Linear Meter are my favorites.  This pack is worth every penny.

26
I noticed the port property field for the  EthernetIPforPLCSLCMicroCom control in version 3.5.7 !!

Thank you so much for putting that in! 

27
Support Questions / Re: v3.5.6 cpu utilization issues??
« on: August 22, 2013, 02:03:21 AM »
3.5.7 tested and confirmed to definitely fix the CPU utilization and sluggishness issue reported in this thread.  AWESOME!!  :)  Thank you so much.

28
Support Questions / Re: v3.5.6 cpu utilization issues??
« on: August 21, 2013, 09:56:03 AM »
You are amazing, I don't see how you manage to do all of this.   Thank you so much.

29
Support Questions / v3.5.6 cpu utilization issues??
« on: August 21, 2013, 03:10:04 AM »
It could be just me and my development platform, but I'm experiencing the following issue with v356:  I can take a brand new solution directly from the website, add a panelmeter and and an EthernetIPforPLCSLCMicroCom1 driver.  Set the PLC Address value and the IP address in the control, build and run and my cpu goes to about 40% and stays their as long as the program is running.  If I add a couple of these drivers, the CPU pegs at 100%.  Also, data doesn't seem to read in as snappy in this release.

I tried the identical setting with a version 341 of AHMI and the cpu barely budged on my computer. 

I get the same results copying the files out and running them on a different workstation from my dev computer as well.

Any ideas on what to try to fix this?  Thanks!

30
Thank you!  That's what I suspected by looking at the code, but I wanted to be sure. 

Pages: 1 [2] 3