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 - ASF

Pages: [1] 2
1
Support Questions / Re: Application loses comms to PLC when pump runs
« on: April 02, 2018, 01:22:28 AM »
Thanks Archie. I'll try those things and report back.

I don't suspect that the UI itself is frozen, because most of the graphics show some sort of comms issue message ("no response from [IP Address]" or something similar), and I have a PLC connection status bar that goes from green (healthy) to red (error) when this happens. So most likely it is an issue with the comms - not sure whether it's a software-related issue or a hardware-related issue, hopefully wireshark can tell me something.

2
Support Questions / Application loses comms to PLC when pump runs
« on: April 01, 2018, 03:14:25 AM »
I have an Advanced HMI application running my garden watering system. It all works as desired, but whenever the pump runs, the comms to the PLC (Click Koyo using Modbus TCP) drop out until the pump stops. Since the pump only runs for a minute or so every other day, it's not a major drama, but I'd like to get to the bottom of why it's happening - especially since my "stop pump" button doesn't work while the pump is running.

I've ruled out as best I can any physical-level problems - my ethernet infrastructure is very well segregated from the power to the pump, and the pump is just a little single phase DOL unit, so there's no funny business going on with VSD's and interference.

On my main display, there are a few things that happen when the pump starts. There is a water pump object which animates to green. There are some graphics that become visible to indicate watering. There is a basic label which may or may not animate a different colour, depending on which zones are being watered (comms problems exist regardless of which zones are being watered). Various level readings and a tank graphic will update as the tank level changes.

When the pump stops, some VBA runs to log the watering details, which includes data gathered from the PLC. This all happens fine, so apparently the comms come back pretty well immediately once the pump stops.

I'm assuming that there must be some object on the display causing problems when it becomes visible or animates. How might I start trying to track down the culprit? Is there any datalogging/event logging that goes on behind the scenes that I can look at to try and narrow down my search?

3
Support Questions / Re: Store file path in application
« on: October 05, 2017, 10:29:54 PM »
Ah, no I changed it from User to Application. I'll change it back and try again.

What's the difference between the two? I assumed that it was a case of "this setting is specific to the currently logged in Windows user" vs "this setting is the same across the whole application, no matter who is logged in". I don't want each user to have to set this up each time if possible.

4
Support Questions / Re: Store file path in application
« on: October 05, 2017, 09:45:35 PM »
I can't get that to work for me - I get the error 'Property "SelectedFilePath" is read-only'

Good to know about the saving settings though - I'll make sure to integrate that

5
Support Questions / Re: Store file path in application
« on: October 05, 2017, 08:32:37 PM »
That looks like what I'm after. It's not quite working, but I'm probably just missing one thing.

I'm using the FolderBrowserDialog object to select the file path. I have created an application setting called SelectedFilePath, and bound the SelectedPath property of FolderBrowserDialog1 to the SelectedFilePath application setting.

To do a simple test, I've set up two buttons and a label:

Select File Path Button - when clicked, runs the command "FolderBrowserDialog1.ShowDialog()". This brings up the path select dialog.

Check File Path Button - when clicked, runs the command "BasicLabel1.Value = My.Settings.SelectedFilePath"

So when I click the first button, I can select a file path. When I click the second, it should show me the filepath on the label. It doesn't work; it just shows me the default selected path of the FolderBrowserDialog1

If I change the command on the second button to "BasicLabel1.Value = FolderBrowserDialog1.SelectedPath", it works - I can use the first button to select a file path, and then if I click the second button, it shows the path I just selected. So it seems that the folder browser dialog has recorded the selected path and is "remembering" it just fine - but it's not updating the application setting. The application setting just sees the default "SelectedPath" value.

What am I missing?

6
Support Questions / Store file path in application
« on: October 05, 2017, 06:52:06 PM »
Hi all,

I have an AHMI application which runs some external scripts from a folder, and logs to some CSV files in another folder. Because the application is running on a Compute Stick (very lightweight PC), I have to do the development on a different machine and then copy the files across.

When I want to test my changes, I just plug in the development PC and get my changes debugged, and then copy over to the runtime PC. The only problem is, if I want to make changes to the data logging or script calling, I can't do that, because the file structure is different on the development PC to the runtime PC, so all my code points to non-existent directories.

What I'd like to do is have the code more generic, and have it retrieve the required filepath from a settings screen, so that when I run it up on the development machine to test, I just have to change the filepath on the settings screen, and it will run fine. Then when I transfer it to the runtime PC, I change it back.

I have no problems with using VB to call the file select dialog to select my filepath, and I can probably then integrate that filepath into my code without too much trouble - but what I don't know is how the selected filepath can be "saved" within the application, so that if the PC gets rebooted, it's still got that filepath saved somewhere, and I don't have to re-select it every time the PC boots up.

Is there a way to do this?

7
Support Questions / Re: Detect PLC connection lost in VB
« on: April 21, 2017, 03:11:48 AM »
Perhaps I'd be better to ask some more specific questions...

I've had a look through the different items I can get from the comms driver:

- Com Error
- Connection Closed
- Connection Established
- Data Received
- Disposed
- Subscription Data Received

...and here's my guess as to when each of them trigger. Can anyone correct my mistakes, and fill in the blanks? Just trying to get an overall picture so I can describe how best to construct my code.

- Com Error: will execute once only when communications to the PLC are lost. Will not re-trigger until communications are restored, and then lost again (question - if I were to add a button linked to a tag that doesn't exist in the PLC, and click that button, would the Com Error code execute? What if one object on the display momentarily loses it's value, and then comes back? Or is it only if I lose the entire link?)
- Connection Closed: will execute once when AHMI closes the connection to the PLC (question: what causes this? Does a com error trigger the connection to close? Or is it only on application shutdown?)
- Connection Established: will execute once when a connection to the configured PLC is established. Will not execute again until the connection is lost (or closed???) and restored (question: does "connection established" mean data transfer has started, or just that the PLC has been contacted and is ready to exchange data?)
- Data Received: will execute every time any data is received from the PLC (or is it just once, after the connection is established, when the data exchange actually starts?)
- Disposed: ???
- Subscription Data Received: ???

8
Support Questions / Re: Detect PLC connection lost in VB
« on: April 21, 2017, 02:53:07 AM »
I'm already monitoring the RTC, which changes every second - the problem is, how do I trigger a sub to check if it has been updated?

The error status in the comms driver sounds promising...I'll have a look into that. Anyone got an example of how they've implemented it?

9
Support Questions / Detect PLC connection lost in VB
« on: April 21, 2017, 01:19:17 AM »
I have a PC running AdvancedHMI, connected to my PLC via USB-Ethernet adaptor, which is turning out to be quite flaky. I'm going to replace it, but while I have a more or less constant stream of comms failures, I'd like to find a way to programatically detect that comms failure, and take appropriate action.

For the most part, the action I want to take is to prevent certain subs from running until the connection to the PLC is restored again, and all of the tag data has been updated.

Is there any way I can address the comms driver directly, to detect a change in the connection status and take action accordingly?

I'm using the Modbus TCP driver.

10
Support Questions / Re: Debug message
« on: April 16, 2017, 10:42:54 PM »
I worked it out in the end. It seems that I'm trying to do something with it before it's had a chance to read all of the "last value" items from the collection.

I put this check at the start, and it solved the problem:
Code: [Select]
If e.ErrorId = 0 And DataSubscriber21.PLCAddressValueItems(DataSubscriber21.PLCAddressValueItems.Count - 1).LastValue IsNot Nothing Then
This way it doesn't try to do anything until it has retrieved a "last value" value from the last item in the collection. I'm assuming that the data subscriber gets the values in the order they appear in the collection (i.e. from (0) to (count-1) ) so that if it has the last one, it must have all the previous ones as well.

In any case, it's stopped the error.

11
Support Questions / Re: Debug message
« on: March 24, 2017, 02:46:31 AM »
With my code wrapped in "If e.Values IsNot Nothing AndAlso e.Values.Count > 0 Then", I still get an exception...

Code: [Select]
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
   at MfgControl.AdvancedHMI.Display_SystemSettings.DataSubscriber21_DataChanged(Object sender, PlcComEventArgs e) in Z:\Alan\2205 Watering System\Programs\SCADA\AdvancedHMI\Display_SystemSettings.vb:line 23
   at AdvancedHMIControls.DataSubscriber2.DataChangedSync(Object sender, PlcComEventArgs e) in Z:\Alan\2205 Watering System\Programs\SCADA\AdvancedHMIControls\Components\DataSubscriber2.vb:line 253


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
AdvancedHMI
    Assembly Version: 3.9.9.18
    Win32 Version: 3.9.9.18
    CodeBase: file:///C:/Watering%20System/Programs/SCADA/AdvancedHMI/bin/Debug/AdvancedHMI.exe
----------------------------------------
Microsoft.VisualBasic
    Assembly Version: 10.0.0.0
    Win32 Version: 14.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
System
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Core
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Windows.Forms
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Runtime.Remoting
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
System.Configuration
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
MfgControl.AdvancedHMI.Drivers
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Watering%20System/Programs/SCADA/AdvancedHMI/bin/Debug/MfgControl.AdvancedHMI.Drivers.DLL
----------------------------------------
AdvancedHMIControls
    Assembly Version: 3.9.9.18
    Win32 Version: 3.9.9.18
    CodeBase: file:///C:/Watering%20System/Programs/SCADA/AdvancedHMI/bin/Debug/AdvancedHMIControls.DLL
----------------------------------------
MfgControl.AdvancedHMI.Controls
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Watering%20System/Programs/SCADA/AdvancedHMI/bin/Debug/MfgControl.AdvancedHMI.Controls.DLL
----------------------------------------
AdvancedHMIDrivers
    Assembly Version: 3.9.9.18
    Win32 Version: 3.9.9.18
    CodeBase: file:///C:/Watering%20System/Programs/SCADA/AdvancedHMI/bin/Debug/AdvancedHMIDrivers.DLL
----------------------------------------
Accessibility
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

12
Support Questions / Re: Debug message
« on: March 19, 2017, 05:23:46 PM »
Yep, that's what I was after! Thanks!

And yes, using Visual Studio 2015.

I'll report back on the fix when I get a chance to drop my modified code in.

13
Support Questions / Re: Debug message
« on: March 17, 2017, 01:30:51 AM »
Thanks Archie, I'll give that a try. Do you have any idea how to re-enable the "break" on that error condition?

14
Support Questions / Debug message
« on: March 15, 2017, 01:18:07 AM »
I have a page with a DataSubscriber2 on it, and each time I open this page at runtime I get a VBA error, which points to this object. The error details are copied below. I have checked and double checked the setup of the object to make sure I've entered all my address details correctly, and written the VBA correctly, and I can't find a fault. Also - if I click Continue, the code continues to work. I know this, because the DataSubscriber is monitoring all of the date/time data from the PLC, and updating some text on the page to show the current PLC date/time. While the error is on the screen, and after I click continue, it continues to count up the seconds and minutes just fine.

I tried running the page from within the development environment, and I get the same error. If I click continue, it dumps out of the runtime with another error. While playing with this, I accidentally unchecked the "break when this type of error is encountered", and now it goes straight to dumping out of runtime as soon as I try and load this page.

So, a couple of things I'm trying to work out:
- How do I get that box re-checked, so it "breaks" on this type of error again?
- What's going on with the error in the first place, and how do I fix it?

Error data:
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an object.
   at MfgControl.AdvancedHMI.Display_SystemSettings.DataSubscriber21_DataChanged(Object sender, PlcComEventArgs e) in Z:\Alan\2205 Watering System\Programs\SCADA\AdvancedHMI\Display_SystemSettings.vb:line 18
   at AdvancedHMIControls.DataSubscriber2.DataChangedSync(Object sender, PlcComEventArgs e) in Z:\Alan\2205 Watering System\Programs\SCADA\AdvancedHMIControls\Components\DataSubscriber2.vb:line 253


************** Loaded Assemblies **************
mscorlib
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
----------------------------------------
AdvancedHMI
    Assembly Version: 3.9.9.18
    Win32 Version: 3.9.9.18
    CodeBase: file:///C:/Watering%20System/Programs/SCADA/AdvancedHMI/bin/Debug/AdvancedHMI.exe
----------------------------------------
Microsoft.VisualBasic
    Assembly Version: 10.0.0.0
    Win32 Version: 14.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
System
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Core
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Windows.Forms
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Runtime.Remoting
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
System.Configuration
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
MfgControl.AdvancedHMI.Drivers
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Watering%20System/Programs/SCADA/AdvancedHMI/bin/Debug/MfgControl.AdvancedHMI.Drivers.DLL
----------------------------------------
AdvancedHMIControls
    Assembly Version: 3.9.9.18
    Win32 Version: 3.9.9.18
    CodeBase: file:///C:/Watering%20System/Programs/SCADA/AdvancedHMI/bin/Debug/AdvancedHMIControls.DLL
----------------------------------------
MfgControl.AdvancedHMI.Controls
    Assembly Version: 1.0.0.0
    Win32 Version: 1.0.0.0
    CodeBase: file:///C:/Watering%20System/Programs/SCADA/AdvancedHMI/bin/Debug/MfgControl.AdvancedHMI.Controls.DLL
----------------------------------------
AdvancedHMIDrivers
    Assembly Version: 3.9.9.18
    Win32 Version: 3.9.9.18
    CodeBase: file:///C:/Watering%20System/Programs/SCADA/AdvancedHMI/bin/Debug/AdvancedHMIDrivers.DLL
----------------------------------------
Accessibility
    Assembly Version: 4.0.0.0
    Win32 Version: 4.6.1586.0 built by: NETFXREL2
    CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.



15
Support Questions / Re: Trigger VBA sub at certain time of day
« on: March 15, 2017, 01:09:47 AM »
Thanks Archie, that works.

Pages: [1] 2