Author Topic: Error handling in form controls  (Read 2429 times)

joseph_e2

  • Newbie
  • *
  • Posts: 21
    • View Profile
Error handling in form controls
« on: September 11, 2023, 01:51:28 PM »
I found this thread about using try/catch to handle things when a PLC drops offline:
https://www.advancedhmi.com/forum/index.php?topic=440.msg1653#msg1653
How do you handle it when the PLC driver is referenced directly in a form control? I have a BasicIndicator on my main form that is tied to a flasher bit in the PLC, just as a sort of visual handshake. When I unplug the PLC, I get a runtime error. Do I need to add try/catch structures to the driver? The exception is "No response from Forward Open" in the BeginRead Function of EthernetIPforSLCMicroCom.

Archie

  • Administrator
  • Hero Member
  • *****
  • Posts: 5322
    • View Profile
    • AdvancedHMI
Re: Error handling in form controls
« Reply #1 on: September 12, 2023, 12:09:59 AM »
Can you post more detais on the error you get, such as the stack trace that shows the file and line number. The driver and built in controls should handle any expeception and show the exception on the control without crashing the program.

joseph_e2

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: Error handling in form controls
« Reply #2 on: September 12, 2023, 10:03:34 AM »
I've attached a screenshot. I commented out the places inside MainForm.vb where I'm referring to the driver to read out of the PLC. Here are the details from "Copy Details", in case that's helpful:
Quote
MfgControl.AdvancedHMI.Drivers.Common.PLCDriverException
  HResult=0x80131500
  Message=No response from Forward Open
  Source=MfgControl.AdvancedHMI.Drivers
  StackTrace:
   at MfgControl.AdvancedHMI.Drivers.CIP.CommonIndustrialProtocol.ForwardOpen(Int32 sendSequence)
   at MfgControl.AdvancedHMI.Drivers.CIP.CommonIndustrialProtocol.ConnectedSend(MessageRouterRequest MRR, Int32 sequenceNumber, Int64 ownerObjectID)
   at MfgControl.AdvancedHMI.Drivers.CIP.CommonIndustrialProtocol.ConnectedSend(Int32 serviceCode, IEPath path, Byte[] data, Int32 sequenceNumber, Int64 ownerObjectID)
   at MfgControl.AdvancedHMI.Drivers.CIP.CIPforPCCC.a(PCCCCommandPacket A_0, Int32 A_1, Int64 A_2)
   at MfgControl.AdvancedHMI.Drivers.AllenBradley.PCCC.EthernetIPforSLCMicroPLC5.SendData(PCCCCommandPacket pccc, Int32 TNS)
   at MfgControl.AdvancedHMI.Drivers.AllenBradley.PCCC.EthernetIPforSLCMicroPLC5.SendPCCCPacket(PCCCCommandPacket packet)
   at MfgControl.AdvancedHMI.Drivers.AllenBradley.PCCC.BasicCommands.ProtectedTypeLogicalRead(Byte byteSize, Byte fileNumber, Byte fileType, Byte elementNumber, Byte subElementNumber, Int32 TNS)
   at MfgControl.AdvancedHMI.Drivers.AllenBradley.PCCC.PCCCResponseHandling.DataFileRead(PCCCAddress PAddress, Int32 TNS)
   at MfgControl.AdvancedHMI.Drivers.AllenBradley.PCCC.PCCCforHMI.BeginRead(String startAddress, Int32 numberOfElements)
   at AdvancedHMIDrivers.EthernetIPforSLCMicroCom.BeginRead(String startAddress, Int32 numberOfElements) in C:\Documents\VisualStudioProjects\Presses-905\AdvancedHMIDrivers\AllenBradley\EthernetIPforSLCMicroCom.vb:line 357
   at MfgControl.AdvancedHMI.Drivers.AllenBradley.PCCC.PCCCforHMI.a()

edit to add:
To double check I hadn't forgotten/missed some code, I moved the basic indicator that refers to this driver to page 2 and the error has stopped with that PLC unplugged. I also put a try/catch block around the code that reads from the CompactLogix and unplugged it. No error from that driver and the BasicLabel controls that also display data from that PLC show the error inside the control without throwing a runtime error.
« Last Edit: September 12, 2023, 10:14:13 AM by joseph_e2 »

joseph_e2

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: Error handling in form controls
« Reply #3 on: September 13, 2023, 11:58:05 AM »
I'm still struggling with getting this to work. Until I sort out the runtime error with the MicroLogix, I'm just using the CompactLogix driver. I have a basic indicator tied to a PLC flasher bit and some basic labels tied to different numeric tags (a string, some reals, some dints). When the form first loads, if the PLC is powered up and running, it all works. If I unplug the PLC, they all stop and display the error message (as expected). When the PLC resumes, they seem start working again, but it sometimes takes a bit, especially if the PLC has been off more than a minute or two. That's fine as long as "a bit" isn't too long. So far, it seems ok.

But, if the PLC is off when the program starts, the form controls don't start working when the PLC connects. I have a command button that reads data from the PLC into a local variable. That works fine once the PLC is talking. As a test, I added a timer control that's enabled by the driver's .ComError event. It's tick event has a try/catch that reads a PLC tag. If the read succeeds, it checks a checkbox that's unchecked by the .ComError event and disables the timer. That all works (as long as the timer interval is a lot longer than the driver's timeout), but I can't get the basic indicator or basic labels to start working.

I've tried different things, like <control>.disable when there's a .ComError followed by a <control>.enable when comms are restored, <control>.refresh, <control>.update, <control>.hide/show, nothing gets the form control working. How can I trigger a refresh/restart/whatever of the form controls so they start updating? It's a virtual certainty that at least one of the machines will be powered off any time this program is started. They also tend to spend a long time turned off (during change-overs, when they're not running it that shift, etc.). It's not ideal, but I can add a button to refresh communications for each driver. I'd rather have it automatic, though.

Archie

  • Administrator
  • Hero Member
  • *****
  • Posts: 5322
    • View Profile
    • AdvancedHMI
Re: Error handling in form controls
« Reply #4 on: September 18, 2023, 08:52:31 AM »
What version of AdvancedHMI are you using? I tried this with 3.99y Beta and unable to replicate it.

bachphi

  • Hero Member
  • *****
  • Posts: 671
    • View Profile
Re: Error handling in form controls
« Reply #5 on: September 18, 2023, 09:09:07 AM »
"Until I sort out the runtime error with the MicroLogix, I'm just using the CompactLogix driver."

what is the actual PLC?
===================================================
This is NOT alt.read.my.mind.
No such thing is sh^t-for-brains unless you are posting to alt.read.my.mind.
===================================================

joseph_e2

  • Newbie
  • *
  • Posts: 21
    • View Profile
Re: Error handling in form controls
« Reply #6 on: September 19, 2023, 02:15:33 PM »
What version of AdvancedHMI are you using? I tried this with 3.99y Beta and unable to replicate it.

I'm using v399y Beta 38.
The first PLC is a CompactLogix 1769-L33ER, v34
The second is a MicroLogix 1400 1766-L32BWA, Series C
Both are just sitting on my desk (not in production) and connected to my USB NIC via an unmanaged switch along with an HMI, a safety controller, another ML1400, and a SLC 5/05.

I'm testing a comm failure by unplugging the network cable at the PLC.

To prevent the runtime error when I unplug the ML1400, I added a try/catch as shown in the attached screenshot.

bachphi

  • Hero Member
  • *****
  • Posts: 671
    • View Profile
Re: Error handling in form controls
« Reply #7 on: September 19, 2023, 04:09:17 PM »
I am sorry that I had to ask.
There were some crazy posts recently where they have a micrologix PLC and use the Compactlogix driver.



I tested with v3.99y Beta38 and a ML1400, have a basic indicator tie to flasher timer T4:0/TT.
I then unplug the cable and saw the same error.

MfgControl.AdvancedHMI.Drivers.Common.PLCDriverException: 'No response from Forward Open'

You can also see this error by using a wrong IP address as well.

Next,  I tested w a CLGX, unplug and I only see the normal 'No response from PLC'
« Last Edit: September 19, 2023, 07:59:15 PM by bachphi »
===================================================
This is NOT alt.read.my.mind.
No such thing is sh^t-for-brains unless you are posting to alt.read.my.mind.
===================================================