AdvancedHMI Software
General Category => Support Questions => Topic started by: iamjer76 on October 28, 2015, 10:18:07 AM
-
I have a project that I had built in version 398s, but I was having some issues with too many items being written at once that were addressed in 399a. Everything was working last week, but today when I open the project in VS2013 to make some additional changes, most of my forms are no longer able to be opened in design mode. I am getting the following message:
Missing Components from AdvancedHMI. C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\
Instances of this error (1)
1. Hide Call Stack
at MfgControl.AdvancedHMI.Drivers.CIP..ctor()
at MfgControl.AdvancedHMI.Drivers.CIPforPCCC..ctor()
at AdvancedHMIDrivers.EthernetIPforSLCMicroCom.CreateDLLInstance() in C:\Office_Stuff\AdvancedHMI\PrebuiltStartPackage\AdvancedHMIDrivers\AllenBradley\EthernetIPforSLCMicroCom.vb:line 103
at AdvancedHMIDrivers.EthernetIPforSLCMicroCom.set_IPAddress(String value) in C:\Office_Stuff\AdvancedHMI\PrebuiltStartPackage\AdvancedHMIDrivers\AllenBradley\EthernetIPforSLCMicroCom.vb:line 196
at MfgControl.AdvancedHMI.frmControls.InitializeComponent() in C:\Office_Stuff\ALR_Cutter\PB_AllRubberCutter_2_0\AdvancedHMI\frmControls.Designer.vb:line 235
at MfgControl.AdvancedHMI.frmControls..ctor()
In my project there are 6 forms, 2 of which open without any errors and 4 give this same error. The forms that are giving the errors all are built to inherit one of the working forms. The reason for this is the main PLC I am connecting to has a very limited number of connections that it will accept, so to reduce the number of connections that are being made as well as keep it from lagging as it tries to make a new connection while it changes forms, I have my PLC Connection (ModbusTCP for a TrioPLC) made on one form that has the majority of the controls that need to be on the other forms and then the other forms just inherit that form so only the one connection is being made. There is also a second PLC connection (EthernetIPforSLCMicroCom for a MicroLogix PLC) on this same form. This appeared to work fine in 398s (although the second connection in 399 had to be recreated as it was EthernetIPforPLCSLCMicroCom in the the previous version) and like I said, this worked fine in 399a originally as it worked the last time I had the project opened. Now I am getting these errors.
I tried adding the
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\" into my project reference paths, but this did not help.
Something just doesn't seem to be right with the inheriting forms, but I have no idea why it would just stop.
Thoughts?
Thanks,
Jeremiah
-
Sometimes VS gets messed up since it is an open source project. This usually fixes things:
- Close Visual Studio
- With Windows Explorer, go to the folder of the project
- The project contains 3 folders (AdvancedHMI, AdvancedHMIControls, AdvancedHMIDrivers)
- Go into each one of those folder and delete both the \bin and \obj folder
- Open again in Visual Studio and Rebuild Solution
-
I did as suggested. Same results.
-
Do you have Windows Explorer showing hidden files? There is an .sou file that also saves settings of the VS environment and it can be deleted too.
-
Still no dice
-
The reason for this is the main PLC I am connecting to has a very limited number of connections that it will accept, so to reduce the number of connections that are being made.
This is actually not necessary because all of the driver instances with the same com properties use a shared DLL for a single connection.
-
In Solution Explorer, do you see all 3 projects (AdvancedHMI, AdvancedHMIControls, and AdvancedHMIDrivers)?
-
Yes I do
-
Even I'm facing the same problems Archie. My VS2010 Ultimate tells me that all the instances of Digital Panel meter on my 8 forms have been missing component. Due to which I'm unable to make any changes to the existing systems GUI. Please help us out of this.
-
Try this:
http://advancedhmi.com/forum/index.php?topic=1062.msg5555#msg5555
-
I'm getting the same error message here with an iis .net project - no issues with a command line application but the same call stack when trying to set the IPAddress of a new EthernetIPforSLCMicroCom on an api I'm working on. Tried all steps including the ones in the linked post.
-
I'm getting the same error message here with an iis .net project - no issues with a command line application but the same call stack when trying to set the IPAddress of a new EthernetIPforSLCMicroCom on an api I'm working on. Tried all steps including the ones in the linked post.
What list of files is in the directory with your exe file?
-
Just came back to this project.
The list of files in my directory that are from AdvancedHMI are:
AdvancedHMIContros.dll
AdvancedHMIControls.pdb
AdvancedHMIControls.xml
AdvancedHMIDrivers.dll
AdvancedHMIDrivers.pdb
AdvancedHMIDrivers.xml
MfgControl.AdvancedHMI.Controls.dll
MfgControl.AdvancedHMI.Driver.dll
OpcComRcw.dll
OpcNetApi.Com.dll
OpcNetApi.Com.xml
OpcNetApi.dll
OpcNetApi.xml
-
Add this to your code and see what the result is:
Console.WriteLine(AppDomain.CurrentDomain.BaseDirectory)
It should be the directory of your exe file.
-
I added it and get C:\apps\ctsapi which is the root directory of the application - not the bin folder, but the directory that contains the bin.
This is apparently correct behavior in asp.net as per http://stackoverflow.com/questions/8669833/why-appdomain-currentdomain-basedirectory-not-contains-bin-in-asp-net-app
I've also had a bit of a play and found that the place where it fails. The line "Dim NewDLL As New MfgControl.AdvancedHMI.Drivers.CIPforPCCC" in EthernetIPforSLCMicroCom.vb is where the exception occurs. I assume this is where the closed-source DLL comes into play?
-
I added it and get C:\apps\ctsapi which is the root directory of the application - not the bin folder, but the directory that contains the bin.
This is apparently correct behavior in asp.net as per http://stackoverflow.com/questions/8669833/why-appdomain-currentdomain-basedirectory-not-contains-bin-in-asp-net-app
I've also had a bit of a play and found that the place where it fails. The line "Dim NewDLL As New MfgControl.AdvancedHMI.Drivers.CIPforPCCC" in EthernetIPforSLCMicroCom.vb is where the exception occurs. I assume this is where the closed-source DLL comes into play?
This is being addresses and should work in the next version.