Results 1 to 2 of 2

Thread: Developing a component, some questions

  1. #1

    Thread Starter
    Frenzied Member
    Join Date
    May 2002
    Posts
    1,602

    Developing a component, some questions

    Hi!

    We are currently developing a vb.net component (class library) that wraps a serialport that communicates to some hardware through modbus. The basic features of this api should be:

    1) Provide a set of API functions to invoke certain operations on the hardware (startprocess, stopprocess, changefrequency, getcurrenttemperature)

    2) Provide continuous error monitoring and error reporting.

    We have 1) already implemented, and we have a rather large set of custom exceptions designed and implemented to catch errors in serial port, modbus etc.

    The trick is #2, continous error monitoring. The hardware has built in error monitoring, and writes certain registrys whenever something is wrong, for example the temperature is too high. It then writes an error code and an error status. The component should poll this registry every 1 second and report back if there is an error, then we should handle this and maybe stop the process, change the UI of the calling application, log the error etc.

    What is the best way to implement this? Our idea is to have two methods on the API

    await myAPI.StartErrorMonitoring()
    await myAPI.EndErrorMonitoring()

    The first method starts an async task and also exposes an event EquipmentErrorEvent. The caller subscribes to this event, and whenever an error has occured, gets notified through an event handler and can take action. We have numerous issues with this:

    * Should the API keep raising events or what should happen after an error event has been raised the first time? Should the API raise an error event for the exact same error?

    * If we perform some kind of action (ChangeProcess) and this raises an exception due to a hardware error, we get both an exception from ChangeProcess and an event from the monitoring process. We get a lot of error reporting to orchestrate. Are we making things too complicated for us?

    * Should we use the "old" eventhandlers for this? I have read that it doesn't work too well with async/await

    Do please provide some input on the current design of the component, and if it can be simplified further?

    /H
    Last edited by MrNorth; Feb 3rd, 2016 at 04:17 AM.

  2. #2
    PowerPoster SJWhiteley's Avatar
    Join Date
    Feb 2009
    Location
    South of the Mason-Dixon Line
    Posts
    2,256

    Re: Developing a component, some questions

    Simply, it's up to you. It depends on the hardware you are communicating with, and how your application will be used, and how that application communicates with your component.

    I'd, personally, have the component raise an event when an error is raised, reporting the status/code/data as appropriate. Each time an error occurs then raise the event. You may want to have a method which returns the status of any given error, so the application has a choice on how to get notified of an error.

    Do you really mean 'exception', or do you mean the hardware has a problem? There should be no reason for your component to necessarily raise exceptions, unless that's how you want to notify the application of any problems (personally, I receive exception raising for actual code issues, not 'machine status' issues).
    "Ok, my response to that is pending a Google search" - Bucky Katt.
    "There are two types of people in the world: Those who can extrapolate from incomplete data sets." - Unk.
    "Before you can 'think outside the box' you need to understand where the box is."

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width