Chapter 16 - Testing Your Progress of Day 2

At this point, you are ready to see and test what you have done for today's lesson.

Run Your Station and Review it From Workbench

Open a Niagara Console. You typically do this by clicking the Windows Start menu, hovering over programs, then hovering over Niagara 3.2.8 (or whatever version of Niagara AX you are using), and selecting Console.

In the Niagara Console type station <NewStation> but replace <NewStation> with the name that you assigned to your station in the lesson for Day 1. Press enter after you type this text.


d:\Niagara-3.2.x> station TestStation
MESSAGE [12:27:06 22-Mar-07 EDT][sys.registry] Up-to-date [140ms]
MESSAGE [12:27:07 22-Mar-07 EDT][sys] Baja runtime booted ("d:\niagara\niagara-3.2.8")
MESSAGE [12:27:07 22-Mar-07 EDT][sys.registry] Loaded [390ms]
MESSAGE [12:27:08 22-Mar-07 EDT][sys] Loading "d:\niagara\niagara-3.2.8\stations\TestStation\config.bog"...
MESSAGE [12:27:12 22-Mar-07 EDT][sys] Loaded (4166ms)
MESSAGE [12:27:16 22-Mar-07 EDT][alarm.database] Created
MESSAGE [12:27:16 22-Mar-07 EDT][sys] Services Initialized (210ms)
MESSAGE [12:27:16 22-Mar-07 EDT][sys.mixin] Updated [0ms]
WARNING [12:27:16 22-Mar-07 EDT][platform] Local daemon session not available, station not started by niagarad
MESSAGE [12:27:16 22-Mar-07 EDT][web.server] HTTP Server started on port 80
MESSAGE [12:27:16 22-Mar-07 EDT][fox] Service started on port 1911
MESSAGE [12:27:16 22-Mar-07 EDT][sys] nre.version: 3.2.8
MESSAGE [12:27:16 22-Mar-07 EDT][sys] *** Station Started (832ms) [11938ms total] ***
niagara>

Your station program should begin executing. Your station is now online (again)!
Run Niagara AX Workbench.
Use Niagara AX Workbench to connect to the Niagara AX station that is running in your console window.
- Click File on the main menu
- Click Open
- Click Open Station (fox).
- A window will appear with the title Open Station.
- Leave the Host i.p. address blank (it will then resolve to the local host)
- For User enter admin (all lower case)
- For Password either leave empty or enter the administrator password that you entered back when you created the station.
- By default this is likely to be user name admin with no password.
- Now your station has been opened. Your workstation now appears in the navigation tree with an icon next to it that looks like a desktop PC.
  
  NOTE: For illustrations of this procedure, please review the conclusion for Day 1's lesson.

Visit Your New Point Manager

Locate your workstation in the Nav tree. Expand your workstation by clicking the plus sign that is next to it in the Nav tree.
Click the plus sign next to the station (the station will likely have an icon of a fox next to it) that is underneath your workstation.
Click the plus sign next to the Config component that is under the station. Watch it expand.
Click the plus sign next to the Drivers component that is under the Config component. Watch it expand.
Click the plus-sign that is next to the network component that you created in day 1's lesson. Watch the network expand.
Click the plus-sign that is next to the device component that you created in day 1's lesson. Watch the device expand.
Double-click the special points folder under your device. It's title will be Your Driver Point Manager where Your Driver is the name of your driver module.
The Dev Point Manager is displayed in right-most two-thirds or so of the Workbench.
Notice that there are columns in the Dev Point Manager for each property on your read parameters structure and point id on which you added the MGR_INCLUDE facet.

Create A Sample Control Point

Click the New button to add a control point using the Dev Point Manager,
Choose a control point type, such as Numeric Point, in the window that pops up.
Click ok, and then ok again.
Notice that the driver control point appears in the Dev Point Manager database list.
Whenever you view this driver control point, such as right now, the station program will attempt to communicate to the field-device by instantiating an instance of your read request, calling your toByteArray method, sending out the resulting byte array, receiving data frames, matching up the data frames to your read request, instantiating a read response, and updating the driver control point with the value returned by the parseReadValue method of your driver's read response.
Also notice that the driver control point appears in the Niagara AX navigation tree.
Double-click the control point itself from within the Niagara AX navigation tree.
Notice that you now see the property sheet of your new control point.
Click the plus-sign that is next to the property named proxyExt.
You should now see your read parameters structure and your point id!

Verify That Your Driver is Trying to Perform Communication to Read Your Control Point's Value

Right click the station icon in the Navigation tree.
Click Spy. The main Workbench area changes to become the Spy page.
Click logSetup in the Spy page located in the main Workbench area. The main Workbench area displays the Logs table.
Locate a row for your network or device's communicator and click the circle with a line under it [O] that is in the Trace column of the table.
Click the Save to File link that is located near the top of the Log table.
Restore your station's Niagara AX console (DOS window) (this is a separate windows application that you have running on your workstation).
Verify that the station is printing the bytes to the Niagara AX console (DOS) window that it is trying to send and also those that it is receiving.
Repeat any of the steps from today's lesson, if you desire, to test other data points in your driver.

At this point, if you have not already connected your equipment to your Workstation, we encourage you to do so. If your equipment is serial then you should follow your equipment's wiring and set-up instructions to hook your Workstation's serial port onto your equipment's field-bus.
If your equipment communicates wirelessly, such as over a mesh network, you will likely need to connect a serial-to-wireless radio to the serial port. Please consult the documentation for your equipment (or consult the equipment manufacturer directly) if you do not know how to connect your PC to the wireless network. In summary though, you will usually plug a serial-to-wireless radio into your PC's serial port.
If your equipment communicates over Tcp/Ip or Udp/Ip then connect it to the same local area network (LAN) as your PC. Please also make sure that you follow the manufacturer's instructions for configuring the Udp/Ip or Tcp/Ip settings of your equipment. This is necessary so that your equipment can truly communicate over your LAN. As a first step towards troubleshooting the connection you can open a DOS console and attempt to ping your equipment's i.p. address. However, please keep in mind that not all equipment supports the standard ping mechanism used by the DOS console's ping utility. So, pinging your equipment from DOS is just one suggestion that may or may not help.
Another way to troubleshoot a Tcp/Ip or Udp/Ip connection is to place your personal computer and your Tcp/Ip or Udp/Ip equipment onto an Ethernet hub and possibly assigning one or both a static i.p. address. This can help eliminate many of the variables involved in troubleshooting Tcp/Ip connectivity issues. You can also ask your equipment manufacturer if they provide any software that can connect to the equipment. If so, you can install the manufacturer's software on your PC. If your manufacturer's software truly uses Tcp/Ip or Udp/Ip and if you can connect to the equipment using their software on your PC then your Dev Tcp or Dev Udp driver (running in a station on your PC) should be able to connect to the same equipment as well.
Nevertheless, troubleshooting Tcp/Ip or Udp/Ip connections can be rather challenging due to the many possible configurations of a local area network (LAN). For that reason, any further discussion about troubleshooting Tcp/Ip or Udp/Ip connections is beyond the scope of this tutorial.

WARNING:Depending on how well documented and straight-forward your equipment's protocol is, it could take days or weeks for you to test all possible data points. We hope that the developer driver framework alleviates your concerns about the inner workings of Niagara and allows you, instead, to stay focused on your equipment and on your equipment's communication protocol.