AdvancedHMI Software
General Category => Support Questions => Topic started by: eci on July 14, 2016, 10:23:03 AM
-
I have been getting the object does not match target type error for some reason in my project. I am making a Human Interface using AdvancedHMI on Microsoft Visual Studios. I made a template for each of my forms hoping this would solve some of the issues I've been having. Tried many different things and have no clue how to fix the issue. The project will run for a short time period, then just quit and give me this Object does not match target type error.
I am new to this program and don't really know how to code in C#.
Any recommendations on what to do?
Thank you
-
What version of AdvancedHMI are you using and what driver and controls?
-
Version 399k for the AdvancedHMI. We are using and Allen Bradley PLC and connected using the serialDF1foSLCMicroCom. There are several Digital Panel meters, stack lights, pilot lights, switches, check boxes, and form change buttons.
-
When you get the exception, you should see a link for "Show Details". Click on that , then post the stack trace that it shows.
-
The problem has been fixed oddly. Rebuilding the solution about 3 or 4 times cleared up the problem.
The new problem that is occurring now is that the CPU usage is at 100% most of the time for some reason. Specifically when the mainform is open. Any suggestions?
Thank You
-
What is the PollRateOverride setting on your driver? Do you have any code behind the form?
-
The PollRateOverride = 5000. I apologize for the ignorance but don't know what you mean by behind the form?
-
I have uploaded my entire project here: https://drive.google.com/open?id=0B3ksYA15iAfManFjcEtIQ0NveG8
For some background I am trying to use the SerialDF1forSLCMicroCom driver. I have 8 Forms in all including the main form. This is the first time I've used visual studio, so I've been trying to learn as I go.
When I did a Performance Profile on CPU usage the following function was shown to be utilizing near 100% of my CPU after opening all of the forms and going back to the main form.
MfgControl.AdvanceHMI.DriversAllenBradely.PCCC.PCCCforHMI.a
I believe it's either a polling issue or something to do with forms not actually closing when switching to a different form.
Your help is greatly appreciated. Thank you!
-
It looks like your PollRateOverride is 500 (0.5 seconds). So it is trying to refresh all of your values every 500ms. This may be a bit much for a serial connection unless you have a 38400 baud rate. I would try changing the PollRateOverride to 2000
-
I changed the PollRateOverride to 2000 and it had only a small effect on the CPU usage.
-
If I try to open your solution as it is, it is missing HMI.vb file and the MainForm doesn't show either (even though it is present in the AdvancedHMI folder).
Once I added the MainForm to the project then I could see the controls you have on that form (including EthernetIPforCLXCom1 driver). This form is set as startup form for your project.
Can you post HMI.vb file?
-
Didn't realize that was saved elsewhere on my computer. I've attached them to this post.
I do not know how well visual studio handles references (I'm used to the difficulties of solidworks), but these files were located at C:\Rockwell\Ovens on my system if that is where visual studio is going to look for them.
On a side note I am not sure why it added the EthernetIPforCLXCom1 driver on your system. The driver I am using is the SerialDF1forSLCMicroCom1.
Thank you.
-
The project opens properly now that I put those files in the C:\Rockwell\Ovens folder.
You can try a few simple things:
1) If you already don't have it then create a working copy of your project and use it for testing
2) Delete MainForm files from AdvancedHMI folder (MainForm.vb, MainFormDesigner.vb and MainForm.resx)
3) Disable subscriptions for the driver on each form and test the project (it works OK on my end since I don't have your PLC to connect to). Your pages do take a few moments to load since they are graphics intensive. If your CPU usage remains high while testing then there is something else causing the issue.
** Remember to enable subscriptions once you are done with this step **
4) If you know the exact baud rate of your connection then set it on each driver (also set the PollRateOverride to 2000 for each driver on each form). As Archie suggested, anything below 38400 might need additional adjusting.
Somewhat similar issue was discussed in this topic http://advancedhmi.com/forum/index.php?topic=861.0.
The driver architecture has changed since but the gist of the conversation could apply in your case.
What is the exact PLC that you are using?
-
I am using a Allen Bradley SLC 500. I have a SLC 5/03 processor, a 115 VAC input card, TRIAC output card and two thermocouple input cards.
Thank you for the assistance, I will let you know if it works.
-
When the Subscripts are disabled the program runs without using a lot of the processor and also won't connect to the PLC, but once I re-enable the subscripts it does the same thing again.
-
Try setting your PollRateOverride on every driver instance to 10000 just to see if it begins to have any effect.
I don't have access to a SLC/Micro with a serial connection right now, so I won't be able to test this until next week.
-
I just tested it and it still runs at 100% once you get 4 to 5 of the forms open. It jumps up in percentage significantly when each form is opened.
-
Do you actually get readings on every form that you open?
-
Yes, everything works as expected in the HMI. I have 3 ovens hooked up to the PLC and am able to control them as I want. All other forms are reading correctly from the PLC.
The only reason I noticed that the CPU in my computer was being over-worked is because the pilot lights started to change color from the top to the bottom slowly enough to easily see.
-
It appears as if everything on your end is working properly in "small amounts".
Out of curiosity, what is the actual baud rate of your communication?
-
RSLinx auto-configures it to 19200. I am not too familiar with serial connections though and do not know what the limiting factor is for baud rates are.
-
According to some websites, the max baud rate for your PLC is 19200 (which these days is considered slow).
If you do read the topic I mentioned in one of my previous posts then you will see what AabeckControls did in his project to improve the performance (the same changes made to the driver might not be possible in your case unless Archie comes with some solution but shuffling things on your forms might help).
Maybe, if your project had only 3 forms then it could possibly be working OK.
-
The problem was narrowed down to a driver problem with the SLCMicro drivers. This will be fixed in an updated that will be availbale in the next couple days.
-
Version 3.99n is now available that fixes this problem causing high CPU usage.
-
That seems to have fixed the problem.
Thank you!