Issue on implementation of AdvancedHMI

[mlefebvre64]

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.'

[Godra]

Start a fresh AdvancedHMI project, don't make any changes to it and just add the driver and controls to the form.

If that works then it's definitely your implementation that is causing the problem.

[mlefebvre64]

Yeah.
I did do that and the label was getting the correct value.

I am using a timer to query the addresses and write to a WinForm label and I am getting correct values.
Is there anything to look out for besides assigning the BasicLabel control a valid address?

Thanks for the quick response.

[MajorFault]

Don't use timers.  Use events.  Use a value change event on the BasicLabel and then write to another control.

[mlefebvre64]

That is what I plan to use in the end. 
I used the timer just as a quick test to confirm the I can access the register 'L' values and I am getting values from all the addresses.
It's just odd that I can't read the 'L' register values using just the BasicLabel properties.
All the other controls are working as expected. I'll just trigger my read off another value change event and see how that goes.
Thanks.