Show Posts
1
Support Questions / Issue on implementation of AdvancedHMI
« on: September 28, 2020, 01:39:59 PM »
Good day!
I am encountering an issue that I believe is not being caused by AdvancedHMI,
but rather my method of implementing it. If possible is there a recommendation to
a solution to the issue I am having. Any insight to a solution is much appreciated.
Let me know if there is any more information I can provide.
Thanks.
I am compiling my solutiion with .NET Framework 4.7.2
Visual Studio Professional version 16.7.3
AdvancedHMI Assembly Version 3.9.9.24
I have a solution that connects to an AllenBradley MicroLogix 1400 using
the EthernetIPforSLCMicroCom driver. I have the PollRateOverride set to 100 ms.
There are several AdvancedHMI controls I am using in the solution,
MomentaryButtons, PilotLights, DigitalPanelMeter and several BasicLabel controls.
The buttons and DigitalPanelMeters all work as expected.
The problem I am running into is the BasicLabel is not updating values from L registers
from the PLC. If I change the address to a valid N register address, it reads the value.
If I try to step through this source, after a minute, the program exits to Visual Studio
and states the application has entered break mode.
I created a program with a fresh copy of AdvancedHMI, added the PLC driver and a BasicLabel
and the BasicLabel reads the L value properly.
The error in debug is:
Managed Debugging Assistant 'ContextSwitchDeadlock'
Message=Managed Debugging Assistant 'ContextSwitchDeadlock' :
'The CLR has been unable to transition from COM context 0x1577c60 to COM context 0x1577ba8 for 60 seconds.
The thread that owns the destination context/apartment is most likely either doing a non pumping wait or
processing a very long running operation without pumping Windows messages. This situation generally has a
negative performance impact and may even lead to the application becoming non responsive or memory usage
accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads
should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during
long running operations.'
I am encountering an issue that I believe is not being caused by AdvancedHMI,
but rather my method of implementing it. If possible is there a recommendation to
a solution to the issue I am having. Any insight to a solution is much appreciated.
Let me know if there is any more information I can provide.
Thanks.
I am compiling my solutiion with .NET Framework 4.7.2
Visual Studio Professional version 16.7.3
AdvancedHMI Assembly Version 3.9.9.24
I have a solution that connects to an AllenBradley MicroLogix 1400 using
the EthernetIPforSLCMicroCom driver. I have the PollRateOverride set to 100 ms.
There are several AdvancedHMI controls I am using in the solution,
MomentaryButtons, PilotLights, DigitalPanelMeter and several BasicLabel controls.
The buttons and DigitalPanelMeters all work as expected.
The problem I am running into is the BasicLabel is not updating values from L registers
from the PLC. If I change the address to a valid N register address, it reads the value.
If I try to step through this source, after a minute, the program exits to Visual Studio
and states the application has entered break mode.
I created a program with a fresh copy of AdvancedHMI, added the PLC driver and a BasicLabel
and the BasicLabel reads the L value properly.
The error in debug is:
Managed Debugging Assistant 'ContextSwitchDeadlock'
Message=Managed Debugging Assistant 'ContextSwitchDeadlock' :
'The CLR has been unable to transition from COM context 0x1577c60 to COM context 0x1577ba8 for 60 seconds.
The thread that owns the destination context/apartment is most likely either doing a non pumping wait or
processing a very long running operation without pumping Windows messages. This situation generally has a
negative performance impact and may even lead to the application becoming non responsive or memory usage
accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads
should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during
long running operations.'
