AdvancedHMI Software
General Category => Support Questions => Topic started by: AabeckControls on July 11, 2015, 09:27:08 AM
-
Yesterday my project was 90% completed, only one screen left to do, all others were working reliably.
This morning when I opened the solution I immediately got a bunch of errors. A lot of the errors went away after I deleted a couple of MessageListByValue entries, rebuilt, then added them back.
Now I get a lot of other errors when I rebuilt the project - and I didn't change anything other than the above Message List's.
-
Can you send me your solution?
-
I noticed FormChangeButton was not in my toolbox and all the buttons on every page was gone - but it was in the Solutions window so I went to Add/Existing the selected the FormChange in the original folder I extracted the download to, yes to overwrite & then rebuilt. Now I re-added the buttons & when I rebuilt & got a lot of FormChangeButton errors but also a list of 118 errors for every object on the page (BasicLabel, BasicIndicator, StackLight, PilotLight, MomentaryButton) as "either undeclared or never assigned."
Then I decided to delete the entire project folder & copy a backup I made last night. Then almost everything was OK. On forms 5 & 12 I got errors for MessageListByValue & all 3 entries on the pages had empty collections.
-
I would need the complete solution. It will be 15-20Mb, so you would have to put it on an FTP or something like DropBox.
-
Zipped it, it's 22MEG.
Had to delete & re insert the Message's, re-add the collections, then saved, rebuilt - all succeeded, no failed's. But when the page tried to re-open a lot of errors, with the collections being empty again - after I saved them when full (one had 52 entries).
Put on WeTransfer: http://we.tl/DWNi4y3ttg
-
Just re-entered both the list collections on Form5, saved, did NOT do a rebuild to cause any problems until this is resolved, opened Form 7 to do the collection there, got a lot of errors, then when I tried to go back to Form5 to copy the list - again I got a bunch of errors & the just-saved collections were now empty again.
-
I downloaded and extracted the solution, opened it is VS, then immediately did a Build without changing anything and it did not give me any errors. I then opened every form and still no errors.
Before closing Visual Studio, try closing all the Design Views of your forms. If you have a design view open, and there is a problem with the controls, then it will generate similar errors. Do the same thing before performing a Rebuild All. The Rebuild All will delete all of the controls before regenerating them. If a form is open during this process, then it will generate errors also. This is just a caveat of having the controls in open source form.
-
To keep from having to re-enter all of the messages, you can use an INI file.
- Right Click the AdvancedHMI project in Solution Explorer and Select Add New Item
- Add a text file
- In that text file, list your messages in this format:
1, My message 1
2, The second message
3, The next for 3
- Click on your text file once in Solution Explorer to select it
- In the Properties Window, change CopyToOutputDirectory to CopyIfNewer
- Now Select your MessageDisplayByValue
- In the Properties Window, set INIFileName to the name of the text file you added above
-
Re-entered everything, closed all windows, did a rebuild with no errors, but when I tried to reopen any of the pages with a MessageList on them (all others opened fine) it error'd & the collection was again empty. Entered just 2 items in a collection, saved, closed the window, rebuilt, re-opened with errors & empty collections. Re-entered 2 more lines (also - now instead of starting a line 0 it starts at line 154, so obviously the collection is occupied somewhere), saved, copied the object, went to another screen & pasted it, but it pasted with an empty collection. Went back to the other page with the object & it's collection was now empty. Tried this without saving or rebuilding & the collections were always empty when re-opened.
-
It's working better now, I saved the whole project w/out any message lists, then closed the solution, then closed Visual Basic. When I reopened the solution I was able to keep the entries in the message lists between windows & after closing & re-opening them. Now going to try the text file option for the message lists.
-
Tried the .txt file method, even tried the full path & name, but get an empty collection, even after rebuild successfully with all windows closed. When reopen it shows message 0 empty, still shows the .txt file as ini, when I start debugging it everything else works (project is complete except for this one list on 2 screens) but the list shows as:
-
Am I doing this right? It seems to want a line 0, do I need to make it:
1 0 Error
2 1 Begin ... ?
When debugging the PLC is set to value 1 which should state "Begin"
-
It needs to be comma separated and without spaces:
1,Error
2,Begin....
3,Next message
-
Attached is a sample INI file from a project I recently did
-
I just tried your solution and it works fine on my computer.
I only made 1 small change: give MainForm name "MainForm" instead of "k" as it was showing.
Also, I had to disable subscriptions for all DF1Com1 drivers so I could go from form to form without delay (used OpcDaCom1 driver to assign values to MessageByValue components).
Collections on forms 5, 7 and 12 still show all messages and when a value is assigned it does show that particular message.
You have 2 MessageByValue controls, 1 and 3, on top of each other on Form12 "Hoist".
Form11 "Outputs" has 2 instances of DF1Com driver.
Not all your forms have "Home" button to return to the MainForm, only closing this form would end program properly while closing any other form would still leave program running in Debug mode (might be behaving differently with your setup). <-- Edit: Just noticed that "Home" button is there but AutoScroll property is not enabled on all forms.
My suggestion to you is: create a small test project from scratch and test your computer.
-
Godra,
Thanks, I deleted the 2nd DF1 on form 11 & changed all reads to DF1Com1.
I checked the properties on DF1 on all forms & disabled the data subscriptions - didn't know about that.
I accidentally typed in the wrong spot in MainForm properties & changed the name to 'k', just never bothered changing it back until now. I knew I would have to rebuild after the name change & then check the properties on the home button on all other screens.
My current project does have a Home button on every form - I think at the time I zipped the project the I was getting a FormChangeButton error & the forms were appearing without any buttons, so I was adding them back. (On some forms the Home button is larger & a different color).
I saw earlier the 2 MessageByValue's stacked on form 12 & deleted the copy already.
The only thing I can't do now (I'm home & don't have the PLC here) is test the messages to make sure they work - still keep getting "Undefined Message For 0" every time I open either form 5 or 7. Forms 12 & 13 have small collections so I'm not using a .txt file as an INI file - just the collection entries.
If the messages work Monday I can finish this & reinstall an HMI - the unit has been running in a "Manual Bypass HMI" mode since the old computer running PanelmatePC fried the motherboard & the IT Dep't damaged the hard drive's booting trying to get a new computer to work, and could never get the SST DH+ ISA card to work - then it became my problem. (Never had a high opinion of IT Dept's ;)) Hope this is done.
-
Just to respond to what you have done and clarify why I had to do some things:
1) All together, in my opinion, you seem to be having issues with the computer and not necessary your project
2) You should enable all subscriptions for each DF1Com driver on each form (I had to disable those since the project, when run, was looking to communicate with PLC which I don't have. This way I was only testing your forms without obtaining any data from the PLC. Also see remark in point 5) as well for the testing that you might perform).
3) Changing the form name was something I did to make things simpler (I am not sure if the name "k" was affecting the project at all)
4) I did edit my previous post suggesting that I found your "Home" buttons but the AutoScroll property was not enabled on all forms and that was the reason I didn't see those buttons. You should check this AutoScroll property on every form and make changes if you need it.
5) The simplest way to test your message collections would be the following (I will use only one of your forms as example):
In the DesignMode:
--- In VS just open your Form5 and if it doesn't show as the attached picture then there is something wrong with your computer
--- Click on the MessageDisplayByValue1 and then in the Value property just keep changing numbers to see what message shows (it should show "Error" for value 0 as the picture shows, it should show "Begin" for value 1 ... etc).
To see it changing at Runtime:
--- On your Form5 click the MessageDisplayByValue and remove the PLCAddressValue (it should be N7:58 that shows currently)
--- Add NumericUpDown box to your Form5 and then double click it to get to the ValueChanged sub and just add the following code:
Me.MessageDisplayByValue1.Value = Me.NumericUpDown1.Value
Run the project and manually change the value in the NumericUpDown box.
You can currently keep all subscriptions disabled to move faster from one form to another but remember to enable them after you finish testing. Also remember to remove NumericUpDown box, remove the code/sub that was created and set the PLCAddressValue back to N7:58.
-
I re-enabled all subscriptions - thought you were suggesting that for the project, not testing.
Since I accidentally changed the MainForm name I wanted to change it back, just didn't until you mentioned it. So I finally did.
I don't need the Autoscroll, the pages are the size they need to be for the machine's (non-widescreen) monitor (1280x1024).
On the MessageDisplayByValue's that I have entered a collection for they are responding proper during debugging, the issue I am having (and can't test until I connect to the spare PLC with the project in it I have on my desk) is the Status messages that I have used an IniFile instead of typing in the collection. If I add a few entries in the collection those values do show the collection test message I entered (different from the IniFile message so I know which is appearing) with an empty collection it doesn't look at the IniFile.
-
To put this project to bed I removed the StatusValues1.txt from the MessagedisplayByValue for the Step display & repopulated the collection with the 52 entries. Copied & pasted it to the other form it's on (and changed the Fore Color) and this project is now complete. Also thought that the Clock form was a little plain & missing something so I added 6 vertical meters from the Purchased Controls for the month, day, year, hour, minute & seconds. (See below)
Going to try the IniFile method later on a test PLC to figure out how to do that.
-
Another recommendation if you have not done so yet. In the code behind every form, insert this code snippet:
'*******************************************************************************
'* Stop polling when the form is not visible in order to reduce communications
'* Copy this section of code to every new form created
'*******************************************************************************
Dim 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
This will speed up the update rate for the forms that are visible by pausing communications when a form is hidden.
-
Archie,
That was already in the MainForm code, but I had to add it to all the other forms.
Now, what is the trick to getting the IniFileName to display the text file? I entered the lines as you showed:
-
You need to make sure the file gets copied with the executable during a Build. This is done by selecting the file in Solution Explorer, then looking in the Properties window for CopyToOutputDirectory. Change the value to CopyIfNewer
The next step is to put the name of your file in the INIFileName property of the MessageDisplayByValue
- Select the MessageDisplayByValue on your form
- In the properties window go to INIFileName
- Enter StatusValues1.txt
-
I did exactly those steps (you mentioned them before) & when I go to the screen it always shows "Undefined message for value 0" or whatever value is current.
I tried the wholepath/filename in the IniFileName & that didn't matter.
I renamed the file removing a space (old = Status Values1.txt) but no change (did a rebuild).
I tried entering an empty collection from 0 to 51 with no messages to see if it needed that, but only displayed an empty line for all values.
I tried the file name StatusValues1 without the .txt & then got a file not found error - so it's seeing the file, it's just not using it.
-
Check PLCAddressValue for your MessageDisplay to make sure you still have an address in that.
Set the Value property to 5, then run your application and see if the message changes.
If you still can't get it to work, download the sample project AdvancedHMICLXSample.xip from here:
https://sourceforge.net/projects/advancedhmi/files/advancedhmi/3.5/SampleProjects/
It has a working example of the MessageDisplayByValue using an INIFile
-
Got a test 5/04 in a rack, created a new project in RSLogix to populate all the integer & bit files. Set some of the bits read on, some of the integers used to values in range. Did a SysComms download (twice - the first time I forgot to set DF1 comms to 19200 from the default 1200). Added some EQU's N7:58 to 0 to 51, then XIC S:4/7 through 4/4 in groups to outputs so every change of N7:58 will result in a change of flash rate of an output or a change in which output is flashing. That provides me proof that N7:58 is being changed.
On form 5 I added a second MessageDisplayByValue for N7:58 but inserted the INIFileName with no collection. When programming (before & after debugging) the display with no collection always shows an error - only while debugging does it read & display the message. See attached:
The only problem is when I close debugging a long list of errors shows up for "System.ArgumentOutOfRangeException" but everything seemed OK during debugging. All forms showed the bits on I set on & the right analog value for the entries I entered.
-
Instead of wasting the message using the txt file & put it on the MainForm with the step# & Data (dwell delay).
Degugged it for a while & a few times it paused before changing pages or the PLC outputs changed. Took up to 10 seconds after clicking on the FormChangeButton or entering the keypad value. When I exited debugging this time I didn't get the long list of errors - just a few listings in the report saying it couldn't find a file.
-
What you were describing above for "Undefined message for 0" sounds like normal control behavior to me.
The control seems to be designed to read Message collection at DesignTime and to read INI file, if specified, only at Runtime.
Archie can correct me if this is wrong.
Also, when at home and without access to a PLC, if you leave subscriptions enabled it will take long time for any action (going from form to form or entering passcode in the keypad or any other action). That was the reason I suggested to disable subscriptions while testing it at home.
-
When I was just testing it & had the long delays it was connected to a PLC in a test rack running a simple program with all the data files expanded on it so the HMI could read & write without faulting on something like Unable To Access Data File B53, etc.
-
What you were describing above for "Undefined message for 0" sounds like normal control behavior to me.
The control seems to be designed to read Message collection at DesignTime and to read INI file, if specified, only at Runtime.
This is correct behavior. The INI file will not be read and the message collection populated until the application is started, therefor you cannot see the messages in Design View.
Are you seeing the delay the very first time you show any of the forms?
-
I did notice you mentioning testing 5/04 but I was more generalizing and stated "when at home and without access to a PLC".
Your project is rather graphic intensive and on my laptop computer, even with all subscriptions disabled, it would take a few seconds to draw almost any of your forms (especially Controls) and it was also a bit slow to close forms. Not that my laptop is any special (it's old 2GHz Turion64 with 4GB RAM).
Since you were experiencing delays while connected to a PLC, I would generally blame serial DF1 connection but could be something else. I did manage to set the serial speed to 38400 on my MicroLogix 1000 PLC but every now and then it still seemed a bit slow to respond.
-
Unfortunately, only the SLC5/05 supports 38400, the 5/04 max's out at 19200.
It doesn't seem to be a graphics problem though - I can load pages quickly most of the time, just occasionally it takes a while. And sometimes just entering a new keypad value that doesn't change any graphics and the Programming page (that isn't graphics intensive) & changing the step number should only change one BasicLabel and one MessageDisplayByValue.
And it doesn't happen every time, most of the time new step #'s are updated in both objects within a second or less, then suddenly it takes 10 seconds. Same thing with changing forms - which shouldn't rely on the DF1 comm's at all.
-
Archie, a question for you:
Even with subscriptions disabled on all instances of DF1 driver, BarLevel and BasicIndicator controls are still showing "Failed to get processor type" message.
Is this expected behavior?
-
Just to let you know that after removing a comment from "Return &H78" in GetProcessorType function (AllenBradleySLCMicro.vb) testing of this project was far faster and smoother on my end (besides for the Controls form, which still took a bit longer than other forms to initially load).
Everything else I could do was flawless including switching between and closing of the forms.
This still might not mean much in case of enabling subscriptions and connecting to a PLC.
-
Even with subscriptions disabled on all instances of DF1 driver, BarLevel and BasicIndicator controls are still showing "Failed to get processor type" message.
Is this expected behavior?
This is a known behavior in some of the drivers. It has been fixed in some, but not all of the drivers. What is happening is that on startup, it is essentially trying to get the information about the PLC address. The DisableSubscriptions just stops it from reading updates of its values. In order to get the address information, it must know whether it is a PLC5 or SLC/Micro and that is where it is trying to get the processor type.
The line you uncommented will force it to always use SLC/Micro style commands and essential disable PLC5 compatibility. This also keeps it from trying to go to the processor to get the processor information.
You figure that for each item on the form, it will try to send a packet to the processor then wait for a response. This will cause the long delays when it is not connected to a processor.
-
This is what I had to do in older versions of AHMI to make them work with MicroLogix 1000 (since the driver at the time just couldn't get proper information, possibly because of ENI module).
Aabeck has nothing to loose by trying to set the type of processor to either &H5B or &H6F depending of what type of 5/04 he is using. If that doesn't improve the performance then he can always comment it out again.
-
Godra,
The 5/04 in the machine is a 1747-L543C, the 5/04 copy on my desk for development is a -L543 (Not C). Which of the two hex numbers should I use for each or the same number?
I want to test this fully, then change the number if needed for the install.
EDIT: I asked before I opened the code in VS, there was a list of hex numbers for each processor. The 5/04 (except -L541) is &H5B. set it to that & removed the comment. It should be the same for both PLC's.
EDIT2: Just tried it & it does make a difference, also in DF1 changed the Baud from Auto to 19200, so it doesn't take time to try the other baud rates before starting comm's.
RE-EDIT: To make the Controls page load a little faster I removed 7 green Start PB's, added the Click bits from them to the 7 Pilot Lights & moved the Pilot Lights to where the PB's were.
Also, by a suggestion in a PM I got, for liability all the E-Stops were renamed All-Stop, and I deleted the two directory forms & put all FormChangeButtons on MainForm & on most other forms (except the button that would call the form on presently).