Tag: Debug

Posts related to debugging.

Posted on

Debugging MS Outlook 2010 VB script used in a rule

I wanted to run a VB script in MS-Outlook 2010, in a rule applied to every incoming messages, but I was not sure what was the cause of the issue preventing it to run as I expected.

It meant to find e-mails that contain a desired word in its body, but in various upper/lower letter combination, e.g. “Sometext”, “sometext”, or “SOMETEXT”. Then make them “Unreaded” and then move them to “Deleted Items” folder.

So I tried the following way to pinpoint the point of error, as I was not able to find out a way to use the debug option of VB (I am not quite sure if it is even possible).

  1. I added “On Error GoTo” statement to the VB script, to find out where and why  this error ever happen.
  2. I added an error “Handler” part to the VB script, and run the script against  some sample e-mails.
  3. Thanks to “Pinpointing the Exact Line Where A Crash Occurs in VB6 or VBA” that has made finding the line of error possible for me, using “Erl”, knowing where the error occurred is just to read the error message of the “MsgBox”.

The following is the complete VB code. Pay attention to line numbers, in fact they are the trick to make “Erl” shows the error line number.

Sub CheckSpam(Item As Outlook.MailItem)
Dim deletedFolder As Outlook.Folder

10 On Error GoTo Handler

20 If InStr(LCase(Item.Body), "sometext") > 0 Then ' "sometext" all in lower case
30 Set deletedFolder = Application.GetNamespace("MAPI"). _
GetDefaultFolder(olFolderDeletedItems)
40 Item.UnRead = False
50 Item.Move (deletedFolder)
60 Set deletedFolder = Nothing
760 End If
80 Exit Sub
Handler:
90 MsgBox "Error Line: " & Erl & vbCrLf & _
"Error: (" & Err.Number & ") " & Err.Description, vbCritical
End Sub

  1. Then after running on sample e-mail message, I realized that line 50 give the following error:

“Object is required”.

  1. By replacing line 50 with the following the issue has been removed.

50 Item.Move deletedFolder

I don’t know why the parenthesis should be removed but by looking at some examples I have realized that this is the cause of error.

Posted on

Using model-based simulation in automation.

Using computer to model a P&ID to its closest level to the reality is not a new concept in industrial control. There are many applications and devices especially developed to fulfill this goal, to simulate the actual pumps, valves, tanks, and even physical and chemical processes defining the real behavior of the different parts of the process to make it as real as possible. In some situation the communication processes are also simulated to minimize the effort needed to get to a successful control system.

I am currently using a very simple environment using Siemens PLCSIM, to simulate the actual PLC device, and a self developed environment in Delphi that communicate with the PLCSIM, to mimic the various parts of the process, including various kind of pumps, valves, level transmitters, analog values, switches, and likes, to simulate as close as possible to reality before deploying the system control at site. Some parts of process are simulated in the background code, to simulate other parts of process that needs more sophisticated models involving some sort of mathematical modeling of physical and chemical behavior of that element. The complexity of the model depends of many factors, but usually some very simple assumptions eliminate the use of complex parts, and let me to concentrate more on the behavior of the control system itself. But it doesn’t prevent me to use complex algorithms when they are available and necessary.

The processes I usually worked with are mostly very simple in nature, involving only simple conditions that can be simulated with very simple physical laws, and even this simple and none mathematical simulation environment has its own benefits.

  1. Allowing the process expert of the contractor to see what their designed system will look like from an automatic control system point of view. It will help them to apply the final touch before even turning on/off an actual device.
  2. Allow us to test the control system, and to test various working and error scenarios with the designed control system.
  3. It will help us to find errors and correct them, in a very peaceful environment, without worrying about the issues if this would happen in a real place with real devices. In some situation the control sequences can be very complex, and testing and debugging this algorithm, and finding implementation bugs, in real circumstances can be very hard, if not impossible.
  4. This will help us to be open to apply changes even after the system has been deployed in the site, and to test the new needs, that usually arise in fields from an operator point of view, because of the new conditions that no one has been faced with it before.
  5. All the above benefits decrease the time, effort and negative effects on devices and experts involving in all steps of design, implementation and deployment. This will minimize the time and financial impact that is inherited in situation that these modifications and debugging would be done in the site with real operators and devices.
  6. My own simulating system doesn’t have automatic code generation ability, but I have compensated it with writing and using pre-built components in the Delphi programming environment to be able to use these blocks as building brick of the model-based simulated process. In future effort this approach can be diverted as close as possible to a real model-based simulation.