Rfid Factotum

(Part 1) – Motorola XR450 and BizTalk RFID: Hands On

masimms — Mon, 29 Jun 2009 23:46:40 GMT

Continuing the (much delayed) postings on putting together basic end to end systems with RFID readers and BizTalk RFID, I’m going to delve into how to configure and deploy Motorola’s XR450 RFID reader. As usual, the primary steps covered are:

Setting up the reader (from the shipping box to the network)

Performing native firmware updates

Connectivity and configuration with Biztalk RFID

Building a basic business logic and reporting interface

Setting up the reader (from the shipping box to the network)

Every RFID reader is a little different in terms of power, network and antenna, so being familiar with the specifics of the readers you employ in your solutions is vitally important. While Biztalk RFID does an excellent job of abstracting away many of the software and management related details, all the software in the world won't help if you can't turn the reader on! :)

From Motorola’s web site:

Motorola’s XR450 RFID reader is an industrial-class, fixed RFID reader designed for business-critical, dense-reader deployments. With both mono-static and bi-static antenna operation capability, it has the flexibility to meet a wide range of application and environment needs.

The XR450 fixed reader provides ease of integration and rich application support while reading tags reliably and efficiently. It provides comprehensive application flexibility, including support for direct application hosting; standard back-end platforms from IBM, Microsoft, SAP and others; and the ability to interact with industrial automation equipment such as conveyors.

Some of the key features of this device include:

- Operation in bi-static or mono-static modes (this is fairly new in the XR series line, especially for North American targeted readers).
- Support for LLRP (Low Level Reader Protocol) as well as Motorola’s native API. Note: the XR450 can only support one concurrent interface type (i.e. either LLRP _or_ native API – but not both at the same time).
Documents and Software:
- Document and Software Download Site
- XR Series RFID Readers Integrator Guide

Connecting the Serial Connection

When setting up a reader for the first time, or performing low-level debugging a serial connection is invaluable. If your PC or laptop does not have a built-in serial port, I would highly recommend purchasing a USB-to-serial adapter such as this one. Note that most big-box retailers or computer stores will carry a similar product in stock. In addition to the physical connection, you'll need a terminal adapter program. Note that since Hyperterminal is not a part of Windows Vista, you likely don't have a built-in one available. I like a number of different (freeware) products, such as TeraTerm Pro. After downloading and installing Tera Term Pro, start the application.

Select the appropriate COM port (if using a USB-to-serial converter see the manufacturer documentation for details), and click OK. Built-in COM ports are usually COM1. Click on Setup, then Serial port to configure the serial port settings.

The serial communication settings for the Motorola XR450 are 38400 8N1 (or, 38400 baud rate, 8 bit data, none parity, 1 bit stop, none flow control).

Powering the Reader

If we can’t successfully power the reader, this is going to be a very short blog post. The XR series readers use a 24 VDC @ 2.5 A transformer “brick” with an connector that securely fastens to the reader by way of turn-and-lock mechanism. As of the time this article was written, the adapter is a GlobTek Inc ITE Power Supply.

Connect an Ethernet cable between an available network hub, and the 10/100 Base-T port on the XR450 reader.
Connect a serial cable between the SERIAL port (not the GPIO port) on the Speedway Reader and your computer’s serial port.
Connect an antenna to one of the available antenna ports (TX1 - TX4).
1. Note: this assumes that we’ll be using the reader in mono-static or single TX/RX port configuration. If not, connect another antenna to the matching RX1 – RX4 port.
Plug one end of the transformer into an available power outlet, and the other into the +24 VDC port on the XR reader.


Clearing SDRAM ... Complete
}}}BootStrap of XR400 V 4.01.0000
Copyright 1999-2005, Symbol Technologies
Copying Monitor image to RAM ...
|
Run Monitor_0 ....}}}Flash Info: wMfgId=0x89, wDevId=0x891C
Flash Info: flashDeviceSize=0x2000000, blockSize=0x20000, bootBlockSize=0x8000
Done: P30 Flash Unlocked
Check BootData to Update system ......
Do nothing for recovery.
Copying CE image to RAM ...
|
Booting Windows CE ...

Unlike other models of readers the management console will NOT automatically appear! In order to display the management console, type AdvancedReaderConsole, or ARC for short, then hit enter.

ARC
        ****** Symbol XR450 RFID Reader Serial Console ******
Please enter user name:

The default username and password are admin and change. Entering these brings up the serial option console. If you get the username and password wrong, you need to type ARC again to bring up the login screen.


Current Configuration:
        Serial Number: C80507AF82805945   MAC Address: 00:A0:F8:C2:02:D5
         1 -- DHCP               : ON
         * -- IP Address         : 172.27.166.75
         3 -- BSP Port           : 3000
         * -- Network Mask       : 255.255.255.0
         * -- Gateway            : 172.27.166.1
         * -- DNS Host           : 157.54.14.146
         7 -- Web Server Mode    : HTTP
         8 -- HTTP Port             : 80
         9 -- Shell Type         : Telnet
        10 -- File Transfer Mode : FTP
        11 -- Watchdog           : Enabled
        12 -- Trusted Hosts Only : OFF
        13 -- Commit Change
        14 -- Discard Change
        15 -- Exit
        16 -- Reboot
        17 -- Show system log
        18 -- Trace system log   : OFF
        19 -- TCP Timeout (mins) : 0
        20 -- BSP Mode           : Unsecured
        21 -- HTTPS Port                    : 443
        22 -- BSP User Auth      : OFF
* These are current system values and cannot be changed while DHCP is ON
Select the menu number to change the item value:

From this console you can change the network configuration, interface options, view the system log and reboot the reader. You cannot read tags, change the password, etc. The purpose of this interface is to get the reader network-accessible, and then perform additional diagnostics using the web console.

Once logged into the device, you may use the following commands:

Configuring the device to use DHCP	1 <Enter> Toggles DHCP on and off
Configuring the device to use a static IP address	Turn off DHCP 2<Enter> [new IP address] 4<Enter> [new netmask] 5<Enter> [new gateway]
Rebooting the reader	16<Enter>

Scanning Tags

Ensuring that the reader has active/enabled antennae.
Ensuring that the reader is in native-API (i.e. not LLRP) mode. In LLRP mode the reader will only scan tags with a connected LLRP client (such as BizTalk RFID).
Enabling polling (such that the reader is autonomously scanning for tags)
Querying the internal tag list.

Ensuring that the reader has active/enabled antennae.

To ensure that the reader has active/enabled antennae:

Open an Internet Explorer window and browse to the IP address of the reader.
Log in with the username and password (defaults are username admin and password change).
From the Reader Administration Console, click on Status. We want to make sure that the reader has active/enabled antennae. In the status summary of the reader, ensure that at least one read point (aka antenna or antenna pair) is enabled (i.e. Read Points / Enabled >= 1).

Ensuring that the reader is in native-API (i.e. not LLRP) mode

Open an Internet Explorer window and browse to the IP address of the reader.

From the Reader Administration Console, click on Maintenance, then on Communication. If LLRP is Running is displayed, then we need to deactivate it by clicking on the Deactivate LLRP button.

Since none of the changes will take effect until committed (i.e. saved), we need to commit changes by clicking on the Commit/Revert menu option, then click the Commit button.

Enabling Polling

Open an Internet Explorer window and browse to the IP address of the reader.

From the Reader Administration Console, click on Scan Control.

If Reader is not polling is displayed, click on Enable Polling.

Since none of the changes will take effect until committed (i.e. saved), we need to commit changes by clicking on the Commit/Revert menu option, then click the Commit button.

Querying the internal tag list

Open an Internet Explorer window and browse to the IP address of the reader.

From the Reader Administration Console, click on Query.

An alternate method of querying the visible tags is by browsing to the URL http://[ip address of device]/cgi-bin/dataProxy?oper=queryTags:

Updating the Device Firmware

Updating the device firmware on the XR series readers can be a little tricky the first time, due to the need to set up a FTP server to host the firmware update files. However, once that server is in place and functional, performing the updates becomes a fairly trivial process.

Installing a FTP Server (Windows Server 2003)

The FTP server functionality included in IIS is the easiest method for enabling native firmware updates. To install IIS with the FTP server extensions:

Click on Start, Control Panel, Add/Remove Programs to bring up the Add or Remove Programs dialog.
Click on Add/Remove Windows Components.
From the Windows Components Wizard, click on Application Server, then click the Details button (IIS will already have been installed as part of the BizTalk RFID installation).
From the Application Server dialog, click Internet Information Services (IIS), then click the Details button.
From the Internet Information Services (IIS) dialog, ensure that the File Transfer Protocol (FTP) Service is checked, then click OK until you return to the Windows Components Wizard dialog.
Click Next to update the computer’s configuration, then Finish to close the wizard.

Configuring the FTP Server (Windows Server 2003)

Once the FTP Server has been installed, we need to create an FTP site with the appropriate security settings and firmware files. For the purposes of this article, we’ll use the default FTP site that’s created when the FTP service is installed.

From the IIS Manager, right-click Default FTP Site (under FTP Sites), then click on Properties.
From the Default FTP Site Properties dialog, click on the Security Accounts tab. Ensure that Allow anonymous connections is checked. Note: to configure the service with user accounts for extra security, refer to http://msdn.microsoft.com/en-us/library/6ws081sa.aspx.
Click on the Home Directory tab. This should display the FTP site directory as being C:\inetpub\ftproot. We’ll add the appropriate Motorola firmware update files under this directory.
Create the directory C:\inetpub\ftproot\Moto.
Download one of the XR Software releases from the Motorola web site for the XR450, such as version 3.3.10. Download and unzip this package into the directory c:\inetpub\ftproot\Moto\3.3.10\. This directory should resemble the image below.

To create a firewall exclusion for the FTP service, execute the following firewall rule (opens port 21)

netsh firewall add portopening TCP 21 "FTP Server"

Testing the FTP Server

From a different machine on the network (NOT the FTP Server itself!), connect to the FTP server to ensure that the Motorola firmware update files can be accessed. The easiest way to do this is via Internet Explorer, using the ftp URL syntax. From the Internet Explorer address bar enter the URI ftp://[IP address of server]/Moto/3.3.10/. If you have configured everything properly, you should see a directory listing similar to:

Performing the Update

From the reader’s web management console, click on Maintenance, then Version to bring up the Version Control panel.
In the FTP server text box type in the full FTP URL to the firmware files (i.e. ftp://[ip address]/Moto/3.3.10/
For the username enter Anonymous.
For the password enter ftp@.
Click on Start Update to start the firmware update.

The reader will then start the process of retrieving and installing the firmware update, which you may observe from the web console. This process usually takes about 5 minutes, so go grab a coffee or either suitably caffeinated beverage.

(Part 2) – Impinj Speedway and BizTalk RFID: Hands On

masimms — Wed, 24 Jun 2009 01:24:46 GMT

Building on the steps in the previous post, we’ll use BizTalk RFID to connect to the Impinj Speedway. This post assumes that you've gone through the steps in part 1.

Connectivity and configuration with Biztalk RFID

Now the part we've all been waiting for - firing up Biztalk RFID, and using it in conjunction with the Impinj reader to do cool stuff. As the Speedway supports LLRP (low-level reader protocol, a standard for communication between RFID readers and middleware such as BizTalk RFID), no additional provider is required – BizTalk RFID 2009 ships an LLRP provider out of the box (note; if you’re using BizTalk RFID 2006 R2, you’ll need to download and install the Standards Pack).

Adding the Reader

From the RFID Manager, right click the Devices node, and click on New Device.
From the Add Device Wizard (Introduction) dialog, ensure that the Add single device radio button is selected, and click Next.
From the Add Device Wizard (Provider) dialog, click on LLRP in the list of available providers and click Next.
From the Add Device Wizard (Connection) dialog, type the IP address of the device into the Name or IP address textbox, and type in 5084as the value for the Port. Note that the standard port for LLRP is 5084. Click Next.
From the Add Device Wizard (Add Device to a Group) dialog, select any device group (or the root device group) and click Next.
From the Add Device Wizard (Authentication) dialog, type in root for the username, and impinj for the password (the default factory values). Click Next to start connecting to the device. This will take several seconds, so don't get too impatient.

Checking for Tag Reads

Place a tag in the read field of the antenna (in this case, somewhere close any of the connected antennae).
From the RFID Manager, click the Devices node.
Right click on the new device you have just added, and click View Tags.

Almost there! Now that we are successfully communicating with the Speedway reader and receiving tag notifications, we need to bind the device into an RFID process to persist tag events into a database, and then build a report.

Building a BizTalk RFID process and capturing tag reads

Now for the fun part - capturing the stream of information from the Speedway reader, and making it consumable by a user. In this section, I'll create a basic RFID process using the SqlSink event handler.

Creating a Biztalk RFID Process

The first step in capturing the information from the RFID reader will be to define an RFID process, bind in that reader, and use an event handler to route information to a SQL database.

From the RFID Manager, right click the Processes node, and click on New Process.
From the New Process Dialog
- Type in SampleProcess as the Process name.
- Select Reliable as the Tag processing mode.
- Leave the description blank.
- Ensure the Start Bind Wizard box is checked.
- Click OK.

From the Bind Wizard (Welcome to the Bind Wizard) dialog, click Next.
From the Bind Wizard (Bind Process to Logical Devices) dialog, we'll create a logical device. Logical devices are used to create associations between event sources (like devices and antenna) and logical or physical constructs (like portals or doorways). In this case, our system will pretend that the Speedway is located at a loading dock, door A.
Click New.
From the Logical Device Name dialog, type in Dock Door A and click OK.
Back in the Bind Wizard (Bind Process to Logical Devices) dialog, click on the checkbox for Dock Door A. If you don't click on the checkbox, the option to bind physical devices to the logical device will not be available.
In the Bind Wizard (Configure logical device - Dock Door A) dialog, expand the Speedway entry to expose the list of sources (4, for the four antenna supported by the Speedway).
Click on the checkbox next to the Speedway reader to bind all events from the device to this logical device. Note that this also creates "soft links" to all antenna of the reader.
Click Next.

From the Bind Wizard (Configure Components) dialog, click New Component.
Click on the SqlServerSink component, then click Add.

Type in SqlSink as the Instance name and click OK.

Click Close to finish adding components.
Click Next.
Ensure that the Start the process when I click Finish box is checked, then click Finish.
From the RFID Manager, you should be able to see the process running.
Right click on the process name and click View Tags. By default the page is on a Manual refresh, so click the Refresh button. If you don't see any tags in the window, it's time to troubleshoot! Happily, troubleshooting is covered in the next installment of this series.

Now that we've confirmed tags can be read in the process, the last step before building out a reporting interface will to confirm that the event handler (the SqlSink) is processing the tags correctly. Start up the SQL Server Management Studio, and connect to the RFIDSINK database.
From the list of tables in the RFIDSINK database, dump the contents of the dbo.TagEvents table. The tag reads should now be visible in the database.

Summary

In this posting, we walked through using BizTalk RFID to communicate with the Impinj Speedway and flow tag information into a database.

(Part 1) – Impinj Speedway and BizTalk RFID: Hands On

masimms — Wed, 24 Jun 2009 01:22:35 GMT

As the next (much delayed) post in a hands-on series, I’m going to walk through the process of creating an end to end solution with BizTalk RFID and the Impinj Speedway reader. The primary steps covered are:

Setting up the reader (from the shipping box to the network)

Performing native firmware updates

Connectivity and configuration with Biztalk RFID

Building a basic business logic and reporting interface

Setting up the reader (from the shipping box to the network)

From the Impinj web site:

All Purpose, High Performance Tag Reading

The Speedway reader provides superior system performance in all RFID environments, especially when paired with Impinj reader antennas and Monza tag chips.

Some of the key features include:

Monostatic antenna arrangement (1 antenna per read point)
Directional sensing capability—using standard UHF Gen 2 tags
An LLRP standard network interface (using the Octane 3.0 version of reader firmware)

Obtaining Documentation

The key document for working with the Speedway Reader is the Octane 3.2 User Guide (IPJ-R1000).

Connecting the Serial Connection

The serial communication settings for the Impinj Speedway are 115200 8N1 (or, 115200 baud rate, 8 bit data, none parity, 1 bit stop, none flow control).

Powering the Reader

If we can’t successfully power the reader, this is going to be a very short blog post. The Speedway readers use a 24 VDC @ 2.5 A transformer “brick” with an industrial connector that securely fastens to the Speedway reader. As of the time this article was written, the adapter is a CUI Inc Switching Adapter.

Connect an Ethernet cable between an available network hub, and the 10/100 Base-T port on the Speedway reader.
Connect a serial cable between the SERIAL port (not the GPIO port) on the Speedway Reader and your computer’s serial port.
Connect an antenna to one of the available antenna ports (ANT1 – ANT4).
Plug one end of the transformer into an available power outlet, and the other into the +24 VDC port on the Speedway reader.

After powering the reader, the bootup information similar to the following should stream over the serial port:

kPOST
/
Complete+
Detected: 48F4400P0VT0 (0-B,1-T) Flash
OTP Version: 2
Serial Number: 370 08 08 0176
Hardware Revision: 030-02.0001
Impinj Powered RFID Reader Rev: E

…

DHCPDISCOVER on ixp0 to 255.255.255.255 port 67 interval 4
DHCPOFFER from 157.56.24.1
DHCPREQUEST on ixp0 to 255.255.255.255 port 67
DHCPACK from 157.56.24.1
bound to 157.56.26.220 -- renewal in 6736 seconds.
done.
mDNSResponder (Engineering Build) (Feb 25 2008 15:57:02) [498]: starting
Starting Apple Darwin Multicast DNS / DNS Service Discovery daemon: mdnsd.
Starting system log daemon: syslogd.
ntpdate -u -b -s
Starting NTP server: ntpd.
Cleaning: /tmp /var/lock /var/run.
Upgrade Agent Version: $Id: upgrade_agent v3.0.1 Built on: Mon Feb 25 15:56:55 2
008 $
Starting OpenBSD Secure Shell server: sshd.

Speedway-One login:
Version: $Id: modem_ctrl v3.0.1 Built on: Mon Feb 25 15:55:50 2008 $

If the reader is configured to use DHCP to obtain an IP address, a DHCP status message like the one highlighted in red above should be visible. If not, you’ll need to log into the machine to either obtain the static IP address or configure the reader to use DHCP.

Note: Impinj readers support a very useful and handy discovery feature, that is also supported by Biztalk RFID. The intent of this article is to demonstrate an “always works” technique for cases wherein discovery doesn’t work.

Using the Serial Interface

The Speedway readers all support a rich serial/telnet interface that allows configuration of virtually all aspects of the device. While all of these features are accessible through Biztalk RFID, it's vital in troubleshooting scenarios to be able to isolate portions of the system (from the power supply on up), which is why I'm talking about them in this article. All of the Speedway commands are documented in their Octane 3.2 User Guide (IPJ-R1000), but a couple of useful commands are shown below. Note: Octane refers to the Speedway’s firmware.

To log into the device via the serial console (or a telnet session), hit <Enter> to bring up the login prompt, and enter the default username (root) and password (impinj).

Version: $Id: modem_ctrl v3.0.1 Built on: Mon Feb 25 15:55:50 2008 $

Speedway-One login: root
Password:
>

Once logged into the device, you may use the following commands:

Command	Process
Displaying the current network configuration (results are for a reader with DHCP enabled)	> show network summary Status=0,'Success' ipAddressMode=dynamic ipAddress=10.10.26.220 ipMask=255.255.255.0 gatewayAddress=10.10.26.1 broadcastAddress=10.10.26.255 hostname=Speedway-One llaStatus=enabled
Configuring the device to use DHCP	> config network ip dynamic Status=0,'Success'
Configuring the device to use a static IP address (in this case IP = 10.10.10.100, gateway address is 10.10.10.1).	> config network static 10.10.10.100 10.10.10.1
Rebooting the reader	> reboot Status=0,'Success'
Set the reader back to factory defaults.	> config image factory > reboot

Scanning Tags

Open an Internet Explorer window and browse to the IP address of the reader.
Log in with the username and password (defaults are username root and password impinj).
In the navigation bar at the top of the screen, click on the RFIDemo tab (note: you will need Java installed on your machine).
Click on Operation, then Start. Wave some tags in front of any connected antennae.

Performing Native Firmware Updates

Occasionally it may be necessary to perform firmware updates using the vendor native interface. A specific example of this is a reader which has a version of firmware which is not supported by the vendor's Biztalk RFID provider (usually in the case of older firmware versions). If Biztalk RFID can't connect to the reader, it's not in a good position to perform firmware updates :). Firmware updates are available from the Impinj web site, but you first need to register as a customer here. There's a manual approval process involved, so it's good to register as a partner as soon as you order your Impinj equipment (though approval usually only takes a day or two).

From the support portal, browse to Content, then search in Reader & Reader Antenna. In the list of available content should be files such as Speedway_Octane_3_2_1_Fw, containing the Speedway firmware. Download this file to your computer, and extract it contents into an available directory. The firmware file should have a .upg extension.

Open an Internet Explorer window and browse to the IP address of the reader.
Log in with the username and password (defaults are username root and password impinj).
Browse to the Configuration screen, then Firmware.
In the Image File section, click on the Browse button to select the .upg file, then Apply to upgrade the device’s firmware.

As the firmware update proceeds, the Upgrade Status box will refresh.

After the firmware image is updated, you will need to manually reboot the reader in order for the update to take effect. Click the reboot button at the bottom of the screen (under the Firmware Upgrade box).

PowerShell and BizTalk RFID (1) - Providers and Server Configuration

masimms — Wed, 18 Mar 2009 00:48:44 GMT

Been on the road pretty much non-stop since January, so I haven't had the opportunity to post as much as I'd like. However, it looks like the next couple of months will be a little more reasonable in terms of the travel schedule, so I should be able to clear out a bit of the backlog of strange and interesting posts about RFID, BizTalk Server, and other bits of Microsoft technology.

I've always been a scripting guy, going back almost 15 years to being a pretty hard core UNIX sysadmin. Cut my teeth on perl4, and every manner of shell scripting under the sun (as well as some that should never have seen the light of day). Although I no longer have much (any) claim to vi wizardry (I'll keep my Visual Studio thank you very much) one of the aspects of the *NIX environment that I'd always missed was a rich scripting and automation interface. With the release of PowerShell, the Windows platform has an amazing scripting environment that combines much of the magic of other scripting hosts, as well as some truly unique features leveraging the .NET platform.

If you've never been exposed to PowerShell before, I highly recommend checking out the following:

When deploying and managing (troubleshooting!) BizTalk RFID installations, there is often the need to automate certain tasks. BizTalk RFID ships with a command line utility (rfidclientconsole.exe), but this isn't well suited to adhoc tasks and quick scripting, as it relies heavily on the use of parameter passing via complicated XML files. Happily, PowerShell is very well suited to wrapping up .NET API's and making them consumable with rich parameters and aggregation.

The intent is to publish a series of blog posts on using PowerShell and RFID, and gradually build up a library of cmdlets that can be used to administer BizTalk RFID installations.

Source Code Package here.

Providers and Server Configuration Cmdlets

In this first post we'll pick off some low-hanging fruit - the ability to get information about providers and server configuration, then create some code to perform a basic sysadmin task - changing the log level of a provider or process component programatically. Following the usual PowerShell naming conventions, we will create the following cmdlets (mimicking functionality of the rfidclientconsole application, only with a rich parameter experience):

Cmdlet Name	Rfid Client Console equivalent	Description
Get-RfidProviderStatus	GetAllProviderStatus GetProviderStatus	Retrieve the list of registered providers and their current status.
Get-RfidProviderProperties	GetProviderMetadata GetProviderProperties	Retrieve the list of properties for a given set of providers. Note that unlike the rfidclientconsole version, this will return all properties (by default the GetProviderProperties() API call only returns non-default values).
Get-RfidProviderMetadata	GetProviderMetadata	Retrieve the set of provider metadata for a given set of providers (metadata describes the available properties of the provider).
Get-RfidServerConfig	GetServerConfiguration	Retrieve the current server configuration. This includes both the bootstrap (i.e. startup / initialization) and runtime parameters. Note that the logging level for a component is an aspect of the server configuration - not of the component.
Set-RfidLoggingLevel	NONE	Set the logging level for a given component(s).

Creating PowerShell Cmdlets

To get started on creating PowerShell cmdlets, read the following excellent blog posts:

David Aiken's Creating a Windows PowerShell CmdLet using the Visual Studio Windows PowerShell Templates
Mike Stall's Debugging PowerShell cmdlets in the VS IDE

The samples in the rest of this post will use the PowerShell templates and debugging techniques from these posts. To get started:

Install David's project wizard from http://channel9.msdn.com/Photos/ZippedFiles/256835_PSTemplates.zip.
Create a new Windows PowerShell project called BizTalkRFID.PowerShell. Make sure that the project is set to use .NET 3.5.
Configure the project for auto-registering and debugging the cmdlet as per Mike Stall's post.

NOTE: If you are running on a 64-bit system, you need to GAC the output assembly with both the 32-bit and 64-bit versions of installutil.exe. Do that with a post-build event command lineof:

c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\installutil.exe $(TargetDir)$(TargetFileName) 
c:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\installutil.exe $(TargetDir)$(TargetFileName)

Get-RfidProviderStatus

We'll start with a fairly simple cmdlet - retrieving the status of a set of providers, leveraging the GetProviderStatus() API call. The cmdlet should be able to take in the name (or names of a set) of a provider as well as a target server. The signature of the cmdlet will be:

Get-RfidProviderStatus [Provider Names] [-Server servername]

1. Start off by adding a new Cmdlet to the project, under Add, New Item, Windows PowerShell, Windows PowerShell Cmdlet. Name it GetRfidProviderStatusCmdlet.cs.

2. Add the following references to the project, from the C:\Program Files\Microsoft Biztalk RFID\bin\ directory.

Microsoft.Rfid.Client.dll
Microsoft.Rfid.Design.dll
Microsoft.Rfid.ManagementWebServices.dll
Microsoft.Rfid.SpiSdk.dll

3. Add the following using statements to the top of the class file:

using Microsoft.SensorServices.Rfid.Runtime;
using Microsoft.SensorServices.Rfid.Management;

4. Change the class Cmdlet attribute to reflect the desired name of the cmdlet. Note that since this cmdlet does not have any impact on the system (i.e. doesn't change anything), we can set the SupportsShouldProcess value to false.

[Cmdlet(VerbsCommon.Get, "RfidProviderStatus", SupportsShouldProcess = false)]
    public class GetRfidProviderCmdlet : Cmdlet

4. Define the parameters, as per the following code. This will define two parameters, ProviderName (an array of strings to represent the provider name), and Server (a single string to represent the target BizTalk RFID server).

   1:  [Parameter(Position = 0,

   2:      Mandatory = false,

   3:      ValueFromPipelineByPropertyName = true,

   4:      HelpMessage = "The name (or names) of the target providers")]

   5:  [ValidateNotNullOrEmpty]

   6:  [Alias("name")]

   7:  public string[] ProviderName

   8:  {

   9:      get;

  10:      set;

  11:  }

12:

  13:  [Parameter(Position = 1,

  14:      Mandatory = false,

  15:      ValueFromPipelineByPropertyName = true,

  16:      HelpMessage = "The name (or names) of the target BizTalk RFID server")]

  17:  [ValidateNotNullOrEmpty]

  18:  public string Server

  19:  {

  20:      get;

  21:      set;

  22:  }

5. Override the BeginProcessing method to create initialization code which will create the ProviderManagerProxy object pointing to the appropriate server.

   1:  private ProviderManagerProxy provProxy;

2:

   3:  protected override void BeginProcessing()

   4:  {

   5:      if (String.IsNullOrEmpty(this.Server))

   6:          provProxy = new ProviderManagerProxy();

   7:      else

   8:          provProxy = new ProviderManagerProxy(this.Server);

   9:  }

6. Now the meat of the whole cmdlet development exercise - actually reaching out to the BizTalk RFID server and retrieving the provider status information. Create an override for the ProcessRecord method, as per:

   1:  protected override void ProcessRecord()

   2:  {

   3:      try

   4:      {

   5:          if (ProviderName == null || ProviderName.Length == 0)

   6:              WriteVerbose("Retrieving status for all providers");

   7:          else

   8:              WriteVerbose("Retrieving status for providers " + String.Join(",", ProviderName));

9:

  10:          ProviderStatus[] provStatus = provProxy.GetProviderStatus(ProviderName);

  11:          WriteObject(provStatus, true);

  12:      }

  13:      catch (RfidClientException ex0)

  14:      {

  15:          ApplicationException ex_app = new ApplicationException(ex0.RemoteErrorMessage, ex0);

  16:          WriteError(new ErrorRecord(ex_app, ex0.RemoteErrorCode, ErrorCategory.InvalidOperation, ProviderName));

  17:      }

  18:      catch (Exception ex1)

  19:      {

  20:          ThrowTerminatingError(new ErrorRecord(ex1, "", ErrorCategory.InvalidResult, ProviderName));

  21:      }

  22:  }

This entire method boils down to two lines (10 and 11) - the rest is diagnostics and error handling. Note that we have to catch the RfidClientException and wrap the RemoteErrorMessage, otherwise the only feedback to the user is "Remote method failed" - an instance of absolutely correct and singularly useless feedback.

7. Now that the cmdlet has been created (sans documentation - we'll get to that in a minute), it's time to see the fruits of our labours. This cmdlet is executed against a base install of BizTalk RFID 2009 with the LLRP provider registered. Press F5 to start a debuggable instance of PowerShell, and dump out the basic provider information:

PS C:\files\BizTalkRFID.PowerShell\bin\Debug> Get-RfidProviderStatus


Name           : LLRP
ProviderFaults : {}
LastFaultType  : None
LastFaultTime  : 1/1/0001 12:00:00 AM
ProviderState  : Registered

Exciting stuff, eh? :). The real "wow" factor here isn't being able to dump out this basic list - could do that with rfidclientconsole. The exciting part is now this information can leverage all of the power and utility of PowerShell scripting to do things, build reports, drive automation, etc. Expanding the idea a bit:

PS C:\Files> Get-RfidProviderStatus | format-table Name,ProviderState -autosize

Name ProviderState
---- -------------
LLRP    Registered

Creating a simple table of available and registered providers.

   1:  PS C:\Files> Get-RfidProviderStatus | where-object { $_.ProviderState -eq 'Regis

   2:  tered' }

3:

4:

   5:  Name           : LLRP

   6:  ProviderFaults : {}

   7:  LastFaultType  : None

   8:  LastFaultTime  : 1/1/0001 12:00:00 AM

   9:  ProviderState  : Registered

Now we're starting to do fun things - with this command we filtered out registered provider names. Further on in this series when we create cmdlets such as Start-RfidProvider, we could write simple scripts that automatically started all Registered providers with something as simple as

Get-RfidProviderStatus | ? {$_.ProviderState -eq 'Registered' } | Select-Object Name | Start-RfidProvider

Get-RfidProviderMetadata

The next cmdlet will be retrieving the metadata from a provider, or set of providers. This cmdlet is nearly identical to the previous, the only difference being the cmdlet name, Cmdlet() attribute definition, and implementation of ProcessRecord.

   1:    [Cmdlet(VerbsCommon.Get, "RfidProviderMetadata", SupportsShouldProcess = false)]

   2:      public class MyCmdlet1 : Cmdlet

   3:      {

   4:  ...

5:

   6:  protected override void ProcessRecord()

   7:  {

   8:      foreach (string name in ProviderName)

   9:      {

  10:          try

  11:          {

  12:              WriteVerbose("Retrieving provider metadata..");

  13:              ProviderMetadata meta = provProxy.GetProviderMetadata(name);

  14:              WriteObject(meta);

  15:          }

  16:          catch (RfidClientException ex0)

  17:          {

  18:              ApplicationException ex_app = new ApplicationException(ex0.RemoteErrorMessage, ex0);

  19:              WriteError(new ErrorRecord(ex_app, ex0.RemoteErrorCode, ErrorCategory.InvalidOperation, name));

  20:          }

  21:          catch (Exception ex1)

  22:          {

  23:              ThrowTerminatingError(new ErrorRecord(ex1, "", ErrorCategory.InvalidResult, name));

  24:          }

  25:      }

  26:  }

Compile and run the updated project. From the PowerShell window you should now be able to execute the Get-RfidProviderMetadata cmdlet, as per:

ug> Get-RfidProviderMetadata LLRP -verbose
VERBOSE: Retrieving provider metadata..


ProviderInformation            : <providerInformation><id>Microsoft BizTalk RFI
                                 D LLRP Provider</id><description>Provider for
                                 LLRP devices</description><version>3.7.0.0</ve
                                 rsion></providerInformation>
ProviderCapabilities           : {The provider supports TCP/IP transport., The
                                 provider supports raising a defunct event., Th
                                 e provider supports device discovery., The pro
                                 vider supports triggering of device discovery.
                                 }
ProviderPropertyMetadata       : {[Connection:Port], [General:LLRP Version], [M
                                 anagement:LLRP Message timeout], [Management:T
                                 CP KeepAlive Time]...}
VendorExtensionsEntityMetadata : {[HoppingEvent:DSPI management event], [Reader
                                 ExceptionEvent:DSPI management event], [RFSurv
                                 eyEvent:DSPI management event], [ConnectionAtt
                                 emptEvent:DSPI management event]...}
DevicePropertyMetadata         : {[LLRP General Capabilities:Antenna Sensitivit
                                 y Maximum Index], [LLRP General Capabilities:A
                                 ntenna Sensitivity Minimum Index], [LLRP Gener
                                 al Capabilities:Can Set Antenna Properties], [
                                 LLRP General Capabilities:Has UTC Clock Capabi
                                 lity]...}

Not very exciting, either. Or is it? Remember that PowerShell uses the default formater defined by the underlying .NET type - in this case output as XML. Those aren't text strings, but fully fledged objects that can be manipulated. Like this:

PS C:\Files> $meta = Get-RfidProviderMetadata LLRP
PS C:\Files> $meta.ProviderCapabilities


Value              : 4
Description        : The provider supports TCP/IP transport.
IsDiscoveryRelated : False
IsEventRelated     : False
IsTransportRelated : True

Value              : 3
Description        : The provider supports raising a defunct event.
IsDiscoveryRelated : False
IsEventRelated     : True
IsTransportRelated : False

Value              : 1
Description        : The provider supports device discovery.
IsDiscoveryRelated : True
IsEventRelated     : False
IsTransportRelated : False

Value              : 2
Description        : The provider supports triggering of device discovery.
IsDiscoveryRelated : True
IsEventRelated     : False
IsTransportRelated : False

Displaying the list of capabilities for the LLRP provider.

PS C:\Files> $meta.DevicePropertyMetadata.Keys | sort GroupName

GroupName                               PropertyName
---------                               ------------
General                                 Regulatory region
General                                 Name
General                                 Firmware version
General                                 Vendor...

Listing out the provider properties (full list truncated for space reasons).

PS C:\Files> $meta.DevicePropertyMetadata.Keys | sort GroupName | format-table -autosize | select-object -first 10

GroupName                               PropertyName
---------                               ------------
General                                 Regulatory region
General                                 Name
General                                 Firmware version
General                                 Vendor
LLRP Access Report Spec                 Trigger
LLRP Antenna Configuration              Receiver Sensitivity Index
LLRP Antenna Configuration              Transmit Power Index
LLRP Antenna Configuration              Hop Table Id

Listing the first 10 provider properties, sorted by GroupName, with automatic sizing in the table formatting.

Get-RfidProviderProperties

Now to dig a little deeper into provider properties. The GetProviderProperties() method of the ProviderManagerProxy() returns the non-default (i.e. changed) values from the provider. The GetProviderMetadata() returns the metadata for said properties, including the defaults. Useful information, but in two separate buckets. Let's write a cmdlet that returns a unified view of the properties using a custom PSObject (i.e. leveraging PowerShell's awesome adaptive type system).

1. This cmdlet is nearly identical to the previous, the only difference being the cmdlet name, Cmdlet() attribute definition, and implementation of ProcessRecord. The definition of the class and Cmdlet attribute is:

   1:   [Cmdlet(VerbsCommon.Get, "RfidProviderProperty", SupportsShouldProcess = true)]

   2:      public class GetRfidProviderPropertiesCmdlet : Cmdlet

   3:      {

2. The implementation of ProcessRecord is a little trickier, and requires some explanation.

   1:  protected override void ProcessRecord()

   2:  {

   3:      foreach (string name in ProviderName)

   4:      {

   5:          try

   6:          {

   7:              WriteVerbose("Retrieving provider metadata..");

   8:              ProviderMetadata meta = provProxy.GetProviderMetadata(name);

9:

  10:              WriteVerbose("Retrieving provider properties..");

  11:              PropertyProfile prof = provProxy.GetProperties(name);

12:

  13:              foreach (PropertyKey k in meta.ProviderPropertyMetadata.Keys)

  14:              {

  15:                  PSObject obj = new PSObject(meta.ProviderPropertyMetadata[k]);

  16:                  obj.Properties.Add(new PSNoteProperty("Group", k.GroupName));

  17:                  obj.Properties.Add(new PSNoteProperty("Name", k.PropertyName));

  18:                  // Modified value

  19:                  if (prof.Keys.Contains(k))

  20:                  {

  21:                      PSNoteProperty n = new PSNoteProperty("Value", prof[k]);

  22:                      obj.Properties.Add(n);

23:

  24:                      PSNoteProperty o = new PSNoteProperty("Default", false);

  25:                      obj.Properties.Add(o);

  26:                  }

  27:                  // Default value

  28:                  else

  29:                  {

  30:                      PSNoteProperty n = new PSNoteProperty("Value",

  31:                          meta.ProviderPropertyMetadata[k].DefaultValue);

  32:                      obj.Properties.Add(n);

33:

  34:                      PSNoteProperty o = new PSNoteProperty("Default", true);

  35:                      obj.Properties.Add(o);

  36:                  }

  37:                  WriteObject(obj);

  38:              }

  39:          }

  40:          catch (RfidClientException ex0)

  41:          {

  42:              ApplicationException ex_app = new ApplicationException(ex0.RemoteErrorMessage, ex0);

  43:              WriteError(new ErrorRecord(ex_app, ex0.RemoteErrorCode, ErrorCategory.InvalidOperation, name));

  44:          }

  45:          catch (Exception ex1)

  46:          {

  47:              ThrowTerminatingError(new ErrorRecord(ex1, "", ErrorCategory.InvalidResult, name));

  48:          }

  49:      }

  50:  }

Line 3 - Since we can receive multiple provider names, we'll iterate over each.

Line 7-11: In order to aggregate the property information, we need to retrieve both the metadata and property profile.

Line 13: As the metadata has the "master" list of all properties, we use this as the baseline for enumeration.

Line 15-17: Here is the PowerShell magic. We're going to create a PowerShell object (PSObject) that wraps the native metadata object, and decorate it with some note properties. In this case the GroupName and the property name.

Line 19-25: If the property profile contains the value, then it's a non-default value. We add two note properties, one with the modified value, the other with a flag indicating its non-default status.

Line 30-35: If the property profile does not contain the value, then it's a default value, which we grab from the metadata. We add two note properties, one with the modified value, the other with a flag indicating its default status.

Line 40-47: The usual error handling.

With this simple bit of code we can now do some interesting automation (well, for now we can play with data - once the Set-RfidProviderProperty cmdlets are written in future posts we can have more fun).

ug> Get-RfidProviderProperty LLRP | format-table

Group   Name      Value Default IsInitO Type    Descrip LowerRa HigherR ValueEx
                                    nly         tion        nge    ange pressio
                                                                        n
-----   ----      ----- ------- ------- ----    ------- ------- ------- -------
Conn... Port       5084    True    True Syst... Prov...       1   65535
General LLRP...   1.0.1    True   False Syst... Indi... ...+308 ...+308
Mana... LLRP...   45000    True   False Syst... Time...   10000 ...3647
Mana... TCP ...   60000    True   False Syst... Time...   30000 ...3647
Conn... Devi...      60    True    True Syst... Inte...       1 ...3647
Disc... Matc...      10    True   False Syst... Indi...       1 ...3647

Retrieving all of the provider properties and their current values.

ug> Get-RfidProviderProperty Contoso | format-table Name,Value,Default -autosize

Name             Value                                  Default
----             -----                                  -------
Init_NonEditable Rfid                                      True
Name             Contoso                                   True
Description      Sample Microsoft BizTalk RFID Provider    True
DevelopedBy      Microsoft BizTalk RFID Team               True
Year Developed   2006                                      True
Integer_Editable 100                                       True
bool_Editable    True                                      True
DiscoveryPort    9876                                      True
HostDS           False                                     True
XML              False                                     True

Having a look at the Contoso provider's properties.

PS C:\files\projects\Microsoft.Rfid.PowerShell\Microsoft.Rfid.PowerShell\bin\Debug> Get-RfidProviderProperty Contoso | ? {$_.Type.FullName -eq 'System.String' } | format-table Name,Value -autosize

Name             Value
----             -----
Init_NonEditable Rfid
Name             Contoso
Description      Sample Microsoft BizTalk RFID Provider
DevelopedBy      Microsoft BizTalk RFID Team

Get a list of all of the string type properties.

Set-RfidLoggingLevel

Most of this article was written while trying to create this one cmdlet, for automating log level configuration. This can be a somewhat non-intuitive exercise (or at least it was for me :), so a quick walkthrough of the steps involved may be useful. The log level appears on the Initialization Parameters of the Properties page of a provider in the RFID Manager. This may lead one to assume that the logging level is a property of the provider. One would be flat out wrong :)

The logging level is an aspect of the RFID Server Configuration. Let's use the rfidclientconsole to dump the server configuration and have a look:

   1:  C:\>rfidclientconsole GetServerConfiguration test.xml

   2:  C:\>type test.xml

3:

   4:  <?xml version="1.0" encoding="utf-16"?>

   5:  <RfidServerConfiguration xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/Microsoft.SensorServices.Rfid.Management">

   6:      <clusterNetworkName i:nil="true" />

   7:      <rfidServerBootstrapConfiguration>

   8:          <eventLoggingPolicyForExceptions>

   9:              <logNonRfidServerExceptions>true</logNonRfidServerExceptions>

  10:              <minimumExceptionSeverityForLogging>Fatal</minimumExceptionSeverityForLogging>

  11:          </eventLoggingPolicyForExceptions>

  12:          <log>

  13:              <component>

  14:                  <ComponentLogLevelType>

  15:                      <level>Info</level>

  16:                      <name>MSBizTalkRFID</name>

  17:                  </ComponentLogLevelType>

  18:                  <ComponentLogLevelType>

  19:                      <level>Info</level>

  20:                      <name>ProcessManager</name>

  21:                  </ComponentLogLevelType>

  22:                  <ComponentLogLevelType>

  23:                      <level>Info</level>

  24:                      <name>DeviceManager</name>

  25:                  </ComponentLogLevelType>

  26:                  <ComponentLogLevelType>

  27:                      <level>Info</level>

  28:                      <name>Device</name>

  29:                  </ComponentLogLevelType>

  30:                  <ComponentLogLevelType>

  31:                      <level>Info</level>

  32:                      <name>FixedTimerQ</name>

  33:                  </ComponentLogLevelType>

  34:                  <ComponentLogLevelType>

  35:                      <level>Info</level>

  36:                      <name>Common</name>

  37:                  </ComponentLogLevelType>

  38:                  <ComponentLogLevelType>

  39:                      <level>Info</level>

  40:                      <name>SecurityManager</name>

  41:                  </ComponentLogLevelType>

  42:                  <ComponentLogLevelType>

  43:                      <level>Info</level>

  44:                      <name>ProviderManager</name>

  45:                  </ComponentLogLevelType>

  46:                  <ComponentLogLevelType>

  47:                      <level>Info</level>

  48:                      <name>ComponentManager</name>

  49:                  </ComponentLogLevelType>

  50:                  <ComponentLogLevelType>

  51:                      <level>Info</level>

  52:                      <name>ConnectorServices</name>

  53:                  </ComponentLogLevelType>

  54:                  <ComponentLogLevelType>

  55:                      <level>Info</level>

  56:                      <name>RfidWebService</name>

  57:                  </ComponentLogLevelType>

  58:                  <ComponentLogLevelType>

  59:                      <level>Error</level>

  60:                      <name>Tracking</name>

  61:                  </ComponentLogLevelType>

  62:              </component>

  63:              <dateTimeFormat i:nil="true" />

  64:              <defaultLogLevel>Info</defaultLogLevel>

  65:              <logFile>logs\RfidServices.log</logFile>

  66:          </log>

  67:          <rfidStore>

  68:              <connectionString>Persist Security Info=False;database=RFIDSTORE;Integrated Security=SSPI; server=MASIMMS-DESKTOP</connectionString>

  69:          </rfidStore>

  70:          <wsConfiguration>

  71:              <wSPort>0</wSPort>

  72:              <wSPortSpecified>false</wSPortSpecified>

  73:          </wsConfiguration>

  74:      </rfidServerBootstrapConfiguration>

  75:      <rfidServerRuntimeConfiguration>

  76:          <deviceManagerConfiguration>

  77:              <autoApplyNonPersistentProperties>true</autoApplyNonPersistentProperties>

  78:              <deviceCommandResponseTimeoutMilliseconds>180000</deviceCommandResponseTimeoutMilliseconds>

  79:              <deviceConnectionCheckTimeMilliseconds>60000</deviceConnectionCheckTimeMilliseconds>

  80:              <deviceConnectionFailedThreshold>10</deviceConnectionFailedThreshold>

  81:              <deviceConnectionRetryTimeMilliseconds>60000</deviceConnectionRetryTimeMilliseconds>

  82:              <maxTagPrintedEvent>50</maxTagPrintedEvent>

  83:              <stampNotificationEventWithID>false</stampNotificationEventWithID>

  84:          </deviceManagerConfiguration>

  85:          <exposeStackTrace>false</exposeStackTrace>

  86:          <hostingConfiguration>

  87:              <iisHost>localhost</iisHost>

  88:              <iisPort>80</iisPort>

  89:              <iisTimeOutSeconds>60</iisTimeOutSeconds>

  90:              <iisWebsiteId>1</iisWebsiteId>

  91:          </hostingConfiguration>

  92:          <logConfiguration>

  93:              <currentBackupIndex>0</currentBackupIndex>

  94:              <fileCheckFrequency>25</fileCheckFrequency>

  95:              <fileCount>2</fileCount>

  96:              <fileSize>10</fileSize>

  97:              <maxAllowedDuplicates>3</maxAllowedDuplicates>

  98:              <spamControlTimePeriodInMinutes>10</spamControlTimePeriodInMinutes>

  99:          </logConfiguration>

 100:          <processManagerConfiguration />

 101:          <providerManagerConfiguration>

 102:              <delegateThreadTimeoutMilliseconds>60000</delegateThreadTimeoutMilliseconds>

 103:              <providerSideBySideLoadAllowed>false</providerSideBySideLoadAllowed>

 104:          </providerManagerConfiguration>

 105:          <wSConfiguration>

 106:              <shouldAuditSuccess>false</shouldAuditSuccess>

 107:          </wSConfiguration>

 108:      </rfidServerRuntimeConfiguration>

 109:  </RfidServerConfiguration>

Wow. That's a lot of stuff. The interesting items are the logging components. These define the individual logging level for each component in the system, both internal system components and the "user" components such as providers and processes.

Note that the LLRP provider does NOT appear in this list. This is due to the INHERIT LOG LEVEL checkbox being set in the RFID Manager. If a user component is set to inherit a logging setting, it will not have an entry in the RFID Server Configuration data set. This comes into play in our implementation of the Set-RfidLoggingLevel command.

The ServerManagerProxy exposes a very chunky interface, meaning that we have to retrieve the RFID server configuration, make changes to that configuration, then dump the configuration back in order to effect any changes.

   1:   [Cmdlet(VerbsCommon.Set, "RfidLogLevel", SupportsShouldProcess = true)]

   2:      public class SetRfidLogLevelCmdlet : Cmdlet

   3:      {

2. The parameter set is a little different, consisting of the Log Level, followed by the component names with an optional Server parameter.

   1:  [Parameter(Position = 0,

   2:      Mandatory = true,

   3:      ValueFromPipelineByPropertyName = true,

   4:      HelpMessage = "Logging Level")]

   5:  [ValidateNotNullOrEmpty]

   6:  public ConfigLogLevel Level

   7:  {

   8:      get;

   9:      set;

  10:  }

11:

  12:  [Parameter(Position = 1,

  13:  Mandatory = true,

  14:  ValueFromPipelineByPropertyName = true,

  15:  HelpMessage = "The name (or names) of the target components (providers and processes")]

  16:  [ValidateNotNullOrEmpty]

  17:  [Alias("name")]

  18:  public string[] ComponentName

  19:  {

  20:      get;

  21:      set;

  22:  }

23:

  24:  [Parameter(Position = 2,

  25:      Mandatory = false,

  26:      ValueFromPipelineByPropertyName = true,

  27:      HelpMessage = "The name of the target BizTalk RFID server")]

  28:  [ValidateNotNullOrEmpty]

  29:  public string Server

  30:  {

  31:      get;

  32:      set;

  33:  }

3. The initialization code is also a little different. In order to perform parameter validation we need to have the list of user components (providers and processes), and will thus need the proxy objects to access these in addition to the ServerManagerProxy.

   1:  private ServerManagerProxy srvProxy;

   2:  private ProviderManagerProxy provProxy;

   3:  private ProcessManagerProxy procProxy;

4:

   5:  protected override void BeginProcessing()

   6:  {

   7:      if (String.IsNullOrEmpty(this.Server))

   8:      {

   9:          srvProxy = new ServerManagerProxy();

  10:          provProxy = new ProviderManagerProxy();

  11:          procProxy = new ProcessManagerProxy();

  12:      }

  13:      else

  14:      {

  15:          srvProxy = new ServerManagerProxy(this.Server);

  16:          provProxy = new ProviderManagerProxy(this.Server);

  17:          procProxy = new ProcessManagerProxy(this.Server);

  18:      }

  19:  }

4. Now the good stuff. Actually implementing the changes.

   1:  protected override void ProcessRecord()

   2:  {

   3:      try

   4:      {

   5:          // Get the server configuration, which contains the logging level information in the

   6:          // bootstrap (i.e. startup) settings

   7:          WriteVerbose("Retrieving server configuration");

   8:          RfidServerConfiguration config = srvProxy.GetServerConfiguration();

9:

  10:          // Get the list of provider and process names - these are the only valid components

  11:          WriteVerbose("Retrieving provider list");

  12:          ProviderStatus[] provStatus = provProxy.GetProviderStatus(null);

  13:          List<string> providerNames = new List<string>();

  14:          foreach (ProviderStatus s in provStatus)

  15:              providerNames.Add(s.Name);

16:

  17:          WriteVerbose("Retrieving process list");

  18:          List<string> procNames = new List<string>(procProxy.GetAllProcesses());

19:

  20:          // Perform parameter validation on the list of input components

  21:          List<string> validComponents = new List<string>();

  22:          foreach (string name in this.ComponentName)

  23:          {

  24:              if (procNames.Contains(name) || providerNames.Contains(name))

  25:              {

  26:                  WriteVerbose("Component " + name + " is a valid logging component");

  27:                  validComponents.Add(name);

  28:              }

  29:              else

  30:              {

  31:                  WriteWarning("Component " + name + " is not a process or provider name");

  32:              }

  33:          }

34:

  35:          foreach (ComponentLogLevelType n in config.RfidServerBootstrapConfiguration.log.component)

  36:          {

  37:              if (validComponents.Contains(n.name))

  38:              {

  39:                  WriteVerbose("Changing log level of component " + n.name + " to " + Level.ToString());

  40:                  n.level = this.Level;

  41:                  validComponents.Remove(n.name);

  42:              }

  43:          }

44:

  45:          // Check for "default" logging levels

  46:          List<ComponentLogLevelType> vals = new List<ComponentLogLevelType>(

  47:                  config.RfidServerBootstrapConfiguration.log.component);

48:

  49:          foreach (string name in validComponents)

  50:          {

  51:              WriteVerbose("Setting log level of component " + name + " to non-default value " + Level.ToString());

  52:              ComponentLogLevelType t = new ComponentLogLevelType();

  53:              t.name = name;

  54:              t.level = Level;

  55:              vals.Add(t);

  56:          }

  57:          config.RfidServerBootstrapConfiguration.log.component = vals.ToArray();

58:

  59:          WriteVerbose("Updating Server..");

  60:          srvProxy.SetServerConfiguration(config);

61:

  62:      }

  63:      catch (RfidClientException ex0)

  64:      {

  65:          ApplicationException ex_app = new ApplicationException(ex0.RemoteErrorMessage, ex0);

  66:          ThrowTerminatingError(new ErrorRecord(ex_app, ex0.RemoteErrorCode, ErrorCategory.InvalidOperation, this.Server));

  67:      }

  68:  }

  69:  }

adfasdfasdf

Lines	Description
7-8	Retrieving the RFID Server Configuration, which contains the logging components. See the XML dump above for the typical contents.
11-18	Retrieving the list of process and provider names, and making them available in List<> objects.
21-33	Filtering out any non-valid component names.
35-43	Non-inheriting log levels will be present in the server configuration. Find the log level object for the component, and modify the log level.
46-57	Since inherited logging level don't have a record in the component list, we need to add any new values to a list, and then replace the list stored in the server configuration.
59-60	Updating the server with the new configuration.

All of this code (well, it's not a huge amount), but we get a very straightforward logging configuration experience:

ug> Set-RfidLogLevel Verbose LLRP -verbose
VERBOSE: Retrieving server configuration
VERBOSE: Retrieving provider list
VERBOSE: Retrieving process list
VERBOSE: Component LLRP is a valid logging component
VERBOSE: Changing log level of component LLRP to Verbose
VERBOSE: Updating Server..

Once we have the opportunity to implement more of the Get-Rfid* cmdlets, this method can be used to do some interesting things. However, since we already have a way to retrieve a list of the provider names:

ug> Get-RfidProviderStatus | select-object Name | Set-RfidLogLevel Verbose -verbose
VERBOSE: Retrieving server configuration
VERBOSE: Retrieving provider list
VERBOSE: Retrieving process list
VERBOSE: Component LLRP is a valid logging component
VERBOSE: Changing log level of component LLRP to Verbose
VERBOSE: Updating Server..
VERBOSE: Retrieving server configuration
VERBOSE: Retrieving provider list
VERBOSE: Retrieving process list
VERBOSE: Component Contoso is a valid logging component
VERBOSE: Changing log level of component Contoso to Verbose
VERBOSE: Updating Server..

PowerShell script to set all of the Provider log levels to Verbose.

Note: because of the use of ProcessRecord the log levels are being changed sequentially. A more efficient way of doing it would be to aggregate the component names in ProcessRecord and actually update the server in EndProcessing.

Pro RFID with BizTalk Server 2009 - Hot Off the Presses

masimms — Wed, 18 Mar 2009 00:42:54 GMT

After a marathon writing binge over the past few months, the first book on BizTalk RFID has been published by Apress. Written by myself, Ram Venkatesh (former Lead Architect on BizTalk RFID, now CEO of S3 Edge), and Mark Beckner (prominent writer and consultant on BizTalk Server and EDI) it's packed full of BizTalk RFID goodness. Available now for order!

Read Chapter 1, or have a look through the table of contents:

Foreword
About the Authors
About the Technical Reviewer
Acknowledgments
Introduction
CHAPTER 1 RFID Background Primer
Tracking Stuff: Eyeballs and Lasers
Introducing Radio Frequency Identification

Navigating the Technology Matrix
What’s in a Tag?
Active vs. Passive
Passive Readers in Action
Active RFID Technology
Tag Memory: Reading and Writing
Printers and Applicators

Cutting Through the Hype

The Science of the Feasible vs. the Art of the Possible
The Myth of the RFID Solution

Electronic Product Code Class 1 Generation 2

Closed-Loop vs. Open-Loop Systems

Applying RFID
Conclusion
CHAPTER 2 BizTalk RFID Architecture and Installation
The BizTalk RFID Process Architecture

The Physical Layer
The Device Layer
The Device Provider Layer
Application-Level Services
LOB and Back-End Connectivity

The BizTalk RFID Device Model

Identity
Endpoint
Connection Initiation
Authentication
Discovery
Knobs
Management
Sources

The BizTalk RFID Device Model for Applications

The Device Model Assumed by DeviceConnection
The Device Security Model
The Concurrency Model for the DeviceConnection Class
The RFID Business Process Device Model

Installing BizTalk RFID
Conclusion
CHAPTER 3 The RFID “Hello World” Application
Overview
Using the Device Simulator

Configuring Settings
Configuring Notifications

Creating a Device in BizTalk RFID

Creating a Process

Conclusion
CHAPTER 4 Using RFID Manager
Overview of RFID Manager

Permissions
Connecting to Servers
Managing Server Properties
RFID Manager Server Dashboard

Managing Providers
Managing Device Groups
Managing Devices

Importing and Exporting Devices
Device Configuration
Managing Device States

Managing Processes

Understanding Logical and Physical Devices
Managing Components

Conclusion
CHAPTER 5 Asynchronous Event Processing in BizTalk RFID
What Is a BizTalk RFID Process?
Hands-On Exercises
Event Processing Application Model

Initialization
Design-Time Support
The Actual Event Handler Methods
Tear-Down and Cleanup
Deployment and Undeployment
Strong Typing
Error Handling
Binding and Deployment

Executing RFID Processes

RFID Process Runtime Architecture
Activation and Hosting
BizTalk RFID Hosting Model for Windows Server
Transactionality

Conclusion
CHAPTER 6 Command Processing
Connecting BizTalk RFID to Your Application

Processes
Devices

Device Management

Implementing Synchronous Calls from .NET Applications
Implementing Device Callbacks
Managing Device Connections
Standard Commands

Vendor Commands
Common Tasks

Simulating Tag Reads

Conclusion
CHAPTER 7 BizTalk RFID Mobile
BizTalk RFID Mobile Architecture
Installing BizTalk RFID Mobile
Creating a BizTalk RFID Mobile Application
Asynchronous Event Notification

Using Triggers to Control Asynchronous Notifications
Scanning RFID Barcodes from your BizTalk RFID Mobile Application

Integration with BizTalk RFID Server

Remote Management Support
Storing Events Locally in a SQL Server CE Database

Tag Data Encoding and Translation
Conclusion
CHAPTER 8 Integrating with BizTalk Server
Publishing Events to BizTalk Server

Publishing to BizTalk Server Using MSMQ
Publishing to BizTalk Server Using SqlServerSink
Extending the Flexibility of Event Retrieval

Calling the BizTalk BRE

Logging Using the BRE

Calling a BizTalk RFID Web Service Proxy from an Orchestration
Conclusion
CHAPTER 9 Direct Communication with Enterprise Applications
Integrating with SQL Server Reporting Services

Querying the BizTalk RFID Databases
Writing the SQL Server Reporting Services Reports

Connecting to BizTalk RFID via Remote Machines
Integrating with SharePoint 2007

Developing the SharePoint Web Part Foundation
Extending the Web Part to Use the RFID Web Service Proxies
Extending the Web Part to Use a Custom Web Service

Conclusion
CHAPTER 10 Diagnostics and Troubleshooting
Setting the Stage: Tools and Techniques

Introducing PowerShell
Tailing a Log File

Peeking Inside a BizTalk RFID Application

BizTalk RFID Server Log Files
Provider Log Files
Process Log Files (Event Handlers)
WMI for RFID

Troubleshooting BizTalk RFID

RFID Devices
Tags and Objects
Communication
Service and Providers
Logical Devices and Process Binding
Event Handlers
Sinks and External Applications

Conclusion
CHAPTER 11 Enterprise Planning and Deployment
From Development to Production

Staging RFID Device Definitions and Device Properties

Planning for Disaster Recovery

BizTalk RFID Footprint
Enabling Cold Standby
Running BizTalk RFID Under Microsoft Cluster Service

Enterprise Deployment

Servicing RFID Device Providers
Servicing RFID Processes
Changing Device Bindings for a Process
Distributing and Upgrading Business Rules

Enterprise Monitoring

RFID Management Pack for BizTalk RFID
Device Versioning
BizTalk RFID Service Discovery Through Active Directory

Conclusion
CHAPTER 12 BizTalk RFID Recipes
12.1. Transport Protocols Within Event Handlers
12.2. RFID Data, XML, and SQL Server
12.3. Debugging Tips
12.4. Integration with BizTalk EDI Functionality
12.5. Creating an XSD Based on BizTalk RFID XML

(Part 2) - Hands on with Biztalk RFID and the Alien 9650

masimms — Mon, 15 Dec 2008 08:15:44 GMT

Building on the previous post, the next thing we'll do is use Biztalk RFID to connect to the Alien 9650. This post assumes that you've gone through the steps in part 1.

Connectivity and configuration with Biztalk RFID

Now the part we've all been waiting for - firing up Biztalk RFID, and using it in conjunction with the Alien reader to do cool stuff. This process (at least the first time) involves obtaining and installing the provider, configuring the appropriate firewall access on the host machine, and then adding the reader itself.

Obtaining and Installing the Provider

The provider is available from the partner site (another reason I recommend getting a partner login as soon as possible :). In the partner site, under Technical Information -> Software, look for the Microsoft BizTalk RFID Provider for ALR-9900, 9800, 8800, 9650 link. This leads to a zip package containing an installer. Download the package and execute the installer. This will install the provider DLL under Program Files at \Alien RFID\Alien RFID Provider.

Note: the installer does not register the provider, so we'll need to take care of that in the next step.

To register the provider (remember that multiple versions of the same provider can be simultaneously registered - great feature :):

Start the RFID Manager, and click on the Device Providers node. We'll go ahead and add the Alien which I downloaded from the partner site in the last step.

Right click on Device Providers, and click on New Provider.
From the Add Provider dialog window type in Alien as the name.
Click on Browse, and navigate to the Alien RFID Provider directory (under \Program Files\Alien RFID) and select the AlienRfidProvider.dll file.
Click Register to load the provider into Biztalk RFID.

As of the time I wrote this article, the Alien provider has a minor bug when running on Windows Vista with IPv6 enabled related to the Local Host property. This property is used by the provider to auto-configure the device's notification host. The notification host is the destination to which the reader sends asynchronous events, such as "I saw tags", or "my input port changed". If the provider does not have the correct value for this asynchronous events will never be received - i.e. RFID Processes in Biztalk RFID will never receive tags.

To fix the problem get rid of the IPv6 "fluff" around the local address. In the example the default host string is fe80::200:5efe:10.0.0.1%12. Change that to 10.0.0.1 (the IPv4 address buried in the middle). A quick review of the other configuration properties (which don't need to be changed for default scenarios, but good to be familiar with none the less) is listed in the next section.

Ensure the Start the provider box is checked, then click OK to start the provider.

Snapshot of Vendor Properties

Property Name	Vendor Description	Default Value	Comment
Discovery Port	Decimal network port number used for discovery. Same port must be set as the HeartbeatPort vendor property at device evel	3988	This port needs to be open on the local machine firewall for discovery to work.
Local Host	For network notifications: String of local host IP Address. If not specified, the provider will use the first available local host IP Address. Same IPAddress must be set as the Notification Host property at device level.	Varies	As noted above, may need to remove the IPv6 formatting from the local host address.
Notification Port	Decimal network port number used for notifications. Should be different from the IO Events Port. Same port must be set as the Notification Port property at device level	7797	This port needs to be open on the local machine firewall for asynchronous notifications to be received.
IO Events Port	Decimal network port number used for IO events. Should be different from the Notification Port. Same port must be set as the IO Stream Port property at device level.	7799	This port needs to be open on the local machine firewall for I/O events to be received.
Tag Stream Port	Decimal network port number used for Tag Streaming. Should be different from the Notification and IO Events Ports. Same port must be set as the TagStreamPort property at device level.	7798	This port needs to be open on the local machine for tag streaming mode to work.
Discovery Update Time	Time interval in seconds used for updating readers discovered over network.	10	No need to modify this value for most scenarios.
Log Reader Communications	If TRUE provider will log excessive reader communications to the 'Program Files\Alien RFID\AlienAPI*.log\' files for diagnostic purposes when investigating and fixing issues. They should be deleted manually to free disk space.	False	Only set this value to true when performing diagnostics.
Use Tag Streaming	If TRUE provider will set the Alien Custom property TagStreamMode = ON on all connected readers for UNCONDITIONALLY reporting every single tag found. As a result the provider will send not only 'TagListEvents' caused by Event Mode but also separate 'TagReadEvents' for every single tag read (sometimes far too many.) Set this property to FALSE if you're going to use 'TagListEvents' only and/or reader's notifications with specifically configured Alien CUSTOM properties.	True	Depends on the type and shape of data that your application or scenario requires. Understand how the Alien reader's internal tag list and configuration properties work before changing this to FALSE.
Default Event Mode	If TRUE, provider will automatically set the Event Mode = true whenever establishing connection to device; otherwise client application will be responsible for configuring the Event Mode as a separate operation after device connection has been already established.	True	Unless you're writing a manual / synchronous application that sets this property manually, leave this value as TRUE.
Auto-Save individual properties	If TRUE provider will automatically save to reader's flash memory all individual properties. Otherwise, call to the Save command is required to make ALL properties persistent after setting them with the SetProperty command.	False	If using the Biztalk RFID interface to perform "permanent" configuration changes, set this value to TRUE. Otherwise changes will be discarded when the reader restarts.

Configuring Firewall Ports

As noted in the previous section certain inbound ports need to be opened in the firewall to enable asynchronous notification and discovery functionality. The default ports 3988, 7797, 7798, and 7799 may be opened by executing the commands below.

For Windows XP / Server 2003:

netsh firewall add portopening TCP 3988 “Alien Discovery”

netsh firewall add portopening TCP 7797 “Alien Notification”

netsh firewall add portopening TCP 7798 “Alien IO”

netsh firewall add portopening TCP 7799 “Alien Streaming”

For Windows Vista / Server 2008:

netsh advfirewall firewall add rule name=”AlienDiscovery” dir=in action=allow protocol=TCP localport=3988

netsh advfirewall firewall add rule name=”AlienNotification” dir=in action=allow protocol=TCP localport=7797

netsh advfirewall firewall add rule name=”AlienIO” dir=in action=allow protocol=TCP localport=7798

netsh advfirewall firewall add rule name=”AlienStreaming” dir=in action=allow protocol=TCP localport=7799

Adding the Reader

Seems like a lot of work just to connect to a reader and a get a few tags, doesn't it? I went into a lot more detail for the prerequisites than was perhaps strictly necessary - however, knowing why certain things are done is crucial when you have to perform troubleshooting. Not to mention the number of times that diagnostics have ended with staring at the end of an unplugged cable has taught me to start with the basics (power, connectivity, firmware, tags) before building up. To add the reader:

From the RFID Manager, right click the Devices node, and click on New Device.
From the Add Device Wizard (Introduction) dialog, ensure that the Add single device radio button is selected, and click Next.
From the Add Device Wizard (Provider) dialog, click on Alien in the list of available providers and click Next.

From the Add Device Wizard (Connection) dialog, type the IP address of the device into the Name or IP address textbox, and type in 23 as the value for the Port. Note that the Alien provider uses port 23 for connecting, not the web interface on port 80. Click Next.
From the Add Device Wizard (Add Device to a Group) dialog, select any device group (or the root device group) and click Next.
From the Add Device Wizard (Authentication) dialog, type in alien for the username, and password for the password (the default factory values). Click Next to start connecting to the device. This will take several seconds, so don't get too impatient.

If you cannot connect to the device, and upon clicking View Error you receive the Error 24 Invalid Format error your notification host value is set incorrectly at a provider level. Go back to the provider properties and fix that value.

From the Add Device Wizard (Properties) dialog, click Next to advance the final step without modifying any of the base device description properties, unless of course you really want to.
From the Add Device Wizard (Completion) dialog, click Finish to finish the process of adding the device.

Checking for Tag Reads

Place a tag in the read field of the antenna (in this case, somewhere close to the built-in antenna).
From the RFID Manager, click the Devices node.
Right click on the new device you have just added, and click View Tags.

Almost there! Now that we are successfully communicating with the Alien reader and receiving tag notifications, we need to bind the device into an RFID process to persist tag events into a database, and then build a report.

Building a BizTalk RFID process and capturing tag reads

Now for the fun part - capturing the stream of information from the Alien reader, and making it consumable by a user. In this section, I'll create a basic RFID process using the SqlSink event handler, extend the table schema to associate tags with assets and generate a basic ASP.NET report from that database table.

Creating a Biztalk RFID Process

The first step in capturing the information from the RFID reader will be to define an RFID process, bind in that reader, and use an event handler to route information to a SQL database.

From the RFID Manager, right click the Processes node, and click on New Process.
From the New Process Dialog
- Type in SampleProcess as the Process name.
- Select Reliable as the Tag processing mode.
- Leave the description blank.
- Ensure the Start Bind Wizard box is checked.
- Click OK.

From the Bind Wizard (Welcome to the Bind Wizard) dialog, click Next.
From the Bind Wizard (Bind Process to Logical Devices) dialog, we'll create a logical device. Logical devices are used to create associations between event sources (like devices and antenna) and logical or physical constructs (like portals or doorways). In this case, our system will pretend that the ALR-9650 is located at a loading dock, door A.
Click New.
From the Logical Device Name dialog, type in Dock Door A and click OK.
Back in the Bind Wizard (Bind Process to Logical Devices) dialog, click on the checkbox for Dock Door A. If you don't click on the checkbox, the option to bind physical devices to the logical device will not be available.

In the Bind Wizard (Configure logical device - Dock Door A) dialog, expand the Alien RFID Reader entry to expose the list of sources (2, for the two antenna supported by the ALR-9650). Click on the checkbox next to the Alien RFID Reader to bind all events from the device to this logical device. Note that this also creates "soft links" to both antenna of the reader.
Click Next.

From the Bind Wizard (Configure Components) dialog, click New Component.
Click on the SqlServerSink component, then click Add.

Type in SqlSink as the Instance name and click OK.

Click Close to finish adding components.
Click Next.
Ensure that the Start the process when I click Finish box is checked, then click Finish.
From the RFID Manager, you should be able to see the process running.
Right click on the process name and click View Tags. By default the page is on a Manual refresh, so click the Refresh button. If you don't see any tags in the window, it's time to troubleshoot! Happily, troubleshooting is covered in the next installment of this series.

Now that we've confirmed tags can be read in the process, the last step before building out a reporting interface will to confirm that the event handler (the SqlSink) is processing the tags correctly. Start up the SQL Server Management Studio, and connect to the RFIDSINK database.
From the list of tables in the RFIDSINK database, dump the contents of the dbo.TagEvents table. The tag reads should now be visible in the database.

Summary

In this posting, we walked through using BizTalk RFID to communicate with the ALR-9650 and flow tag information into a database. In the next posting we'll cover troubleshooting the most common problems and build out a basic reporting interface using ASP.NET.

(Part 1) - Hands on: Building an End to End Solution with Biztalk RFID and the Alien 9650

masimms — Fri, 05 Dec 2008 02:00:00 GMT

As the first post in a hands-on focused series on building out solutions with Biztalk RFID, I'm going to walk through the process of creating an end to end solution with Biztalk RFID and the Alien 9650 RFID reader. Future posts in this series will cover the Motorola XR450, Impinj Speedway, and others. The primary steps covered are:

Installing the necessary software bits
Setting up the reader (from the shipping box to the network)
Performing native firmware updates
Connectivity and configuration with Biztalk RFID
Building a basic business logic and reporting interface

Installing the necessary software bits

The first step will be to ensure that you have all of the necessary (and few optional :) software bits installed on your workstation. The baseline components are:

SQL Server 2005 (any edition, including express), including Service Pack 2 - trial
Visual Studio (preferably 2008) - trial
Biztalk RFID - trial

Trial editions for each of the base software are available from the links above. Note that the next release of Biztalk Server (Biztalk Server 2009) will officially support SQL Server 2008 and Visual Studio 2008, but since Visual Studio 2008 can target the base 2.0 .NET Framework it works with Biztalk Server 2006 R2 (caveat; use at your own risk - it will not be officially supported until the next release, so if something goes wrong, you're on your own :).

The installation instructions for each are included with the trials, but a Quick Start Guide for Biztalk RFID is available. Remember to install / enable MSMQ, and install WSE 3.0 (required for the complete installation option of Biztalk RFID).

Note: Vista User Access Control (UAC) does some strange things in conjunction with Biztalk RFID. For development purposes only, it may streamline things to disable UAC. As this has security implications, do this at your own risk.

Setting up the reader (from the shipping box to the network)

From the Alien web site:

ALR-9650 Complete, Easy, Single-Antenna RFID Solution
The ALR-9650 is the ideal solution for single and two-antenna applications. The reader electronics and a high-quality, circularly polarized antenna reside in a single package, eliminating external antenna cables, resulting in the simplest and least expensive installation. A second antenna port enables 2-antenna applications.

Some of the key, unique features of this device are:

The device supports Power-Over-Ethernet to reduce cabling requirements. One of the practical aspects of this is the provided power adapter, which can be a little tricky to plug in the first time (more about that below).
Built-in antenna - excellent for applications with constrained space requirements.

The box includes:

The ALR-9650 (pictured above)
CD-ROM (documentation and software)
Crossover Ethernet cable (for connecting PC directly to the RFID reader)
Standard Ethernet cable, PoE rated (for connecting the reader to a hub or the enclosed power supply)
PoE converter brick (provides a PoE connection without a full-up PoE infrastructure)
RS232 serial cable

Ensure that you have all of the pieces that you're supposed to have - including the serial cable! You will also need an additional Ethernet cable to connect the reader to a hub.

Installing the Software and Documentation

Before going crazy plugging things in, take the time to install the software and documentation from the provided CD-ROM. The key documents will be located under

Alien RFID -> DocZone -> ALR_9650

in the form of the Hardware Setup Guide and the Quick Installation Guide. I know nobody reads documentation, but if you take one single piece of advice in this whole article - READ THE HARDWARE SETUP GUIDE!!! Rant over :).

Connecting the Serial Connection

The serial communication settings for the Alien ALR-9650 are 115200 8N1 (or, 115200 baud rate, 8 bit data, none parity, 1 bit stop, none flow control).

Powering the Reader

The fundamental aspect of using any electronic device - that wonderful stuff we call power. While the ALR-9650 supports the standard Alien power adapter (the ALX-616-2 AC/DC brick), the power supply enclosed with the reader is a PoE Power Sourcing Equipment (PSE) module that "jumpstarts" power onto a standard Ethernet line. As per page 18, figure 10, we'll use the enclosed PoE power supply in conjunction with the reader.

Plug one end of the enclosed Ethernet cable into the LAN port on the ALR-9650.
Plug the other end of the enclosed Ethernet cable into the J1 DATA & PWR port on the PSE module.
Plug one end of another Ethernet cable into the J2 DATA port on the PSE module.
Plug the other end of the Ethernet cable into a network hub.
If we were using an additional antenna with this reader, we would plug it into the auxiliary antenna port at this time. Since we're not for this purposes of this walk-through, moving on..
Take the enclosed AC power cord and plug one end into the wall socket, the other end into the PSE module. At this point, the green POWER LED on the reader should illuminate.
1. Note: if you're not sure which end is which on the AC power cord, please step away from the computer.

Note: the ALR-9650 is a mono-static reader. This means that a single antenna is used for both transmit and receive. As such, the reader needs only a single antenna to operate.

When the reader is starting up, it will print a stream of information to the serial port (which was the whole point of doing that first :). The key information we'll be looking for during boot-up is the network settings, which will look like:

Network Settings:
   MAC Address : 00:1B:5F:00:0E:E1
   Hostname    : alien-000EE1
   IP Address  : 10.10.10.125
   Netmask     : 255.255.254.0
   Gateway     : 10.10.10.1
   DHCP        : 1
   DHCP Time46
   TimeServer  : 132.163.4.103
   TimeZone    : -8
   CommandPort : 23

The key information is the IP address - this will tell you if the device has successfully captured a DHCP lease from the network.

Note: Alien readers support a very useful and handy discovery feature, that is also supported by Biztalk RFID. The intent of this article is to demonstrate techniques that can be used to connect to readers in edge cases (such as the reader being on a separate broadcast domain from the host PC or server).

Using the Serial Interface

The Alien readers all support a rich serial/telnet interface that allows configuration of virtually all aspects of the device. While all of these features are accessible through Biztalk RFID, it's vital in troubleshooting scenarios to be able to isolate portions of the system (from the power supply on up), which is why I'm talking about them in this article. All of the Alien commands are documented in their Reader Interface Guide, but a couple of useful commands are shown below.

Alien>ipaddress?
IPAddress = 157.56.25.21

Alien>dhcp?
DHCP = ON

Alien>

In this case we use the ipaddress? and dhcp? commands to query the specific IP address and dhcp configuration for the reader.

Scanning Tags

I always recommend checking for tag scans with the lowest number of moving parts (i.e. if tag reads aren't showing up in a report there are many potential sources of failure - tag, antenna, reader, network, middleware, database and the report itself). Since the ALR-9650 has a built in antenna, and only requires a single antenna to implement a read point, this is relatively simple out of the box. Wave a valid EPC Class 1 Gen 2 tag over the reader, then execute the t? command on the reader.

Alien>t
30 14 35 D8 C0 10 D4 80 00 00 00 03, 0, 2008/12/04 12:59:20.691, 2, 3000

If a valid tag(s) is in the antenna read field, it should show up on the display. Provided this is directly out of the box, there shouldn't be any misconfigured configuration properties to handle the basic case. However, in the case where the reader has been in service, it's usually a good idea to revert to the "stock" settings. The easiest way to perform this operation from the console is factorysettings.

Alien>factorysettings
All settings reset to factory defaults.

Peforming Native Firmware Updates

Occasionally it may be necessary to perform firmware updates using the vendor native interface. A specific example of this is a reader which has a version of firmware which is not supported by the vendor's Biztalk RFID provider (usually in the case of older firmware versions). If Biztalk RFID can't connect to the reader, it's not in a good position to perform firmware updates :). Firmware updates are available from the Alien web site, but you first need to register as a partner here. There's a manual approval process involved, so it's good to register as a partner as soon as you order your Alien equipment (though approval usually only takes a day or two).

Once you've accessed the partner site, browse to Technical Information -> Firmware. There's usually one primary "active" firmware version available that works across all of the Alien readers, in the form of a .zip package. After downloading the current firmware package, unzip it to a local directory. In this section we'll use the native web server interface to perform a firmware upgrade (rather than an external application such as Biztalk RFID or the Alien Gateway software).

Log into the device's web management interface by navigating to the device's IP address. The task selection list should look similar to the one in the picture below.

Click on Upload Firmware. As this is the first operation that requires authentication to the device, you'll need to log in. The default username and password for all Alien devices is username alien and password password. Click on the Browse button and select the appropriate fw aef file. Click Upload File to update the firmware image.

The progress of the upload process can be viewed from the serial console (yet another reason to know how to use the serial console :).

Primus Posting

masimms — Tue, 05 Aug 2008 13:41:46 GMT

Coming into my fourth week here at Microsoft as a Field Program Manager in the Customer Experience group within CSD has been quite the experience. My role centers around working with customers, partners and the Microsoft field teams to enable the adoption of Biztalk RFID.

My goal is to use this as a medium to spread the word on all of the exciting things happening both within the partner community and around Microsoft related to RFID, and to share tips and tricks for delivering Biztalk RFID based solutions.

Rfid Factotum

(Part 1) – Motorola XR450 and BizTalk RFID: Hands On

Setting up the reader (from the shipping box to the network)

Documents and Software:

Connecting the Serial Connection

Powering the Reader

Scanning Tags

Ensuring that the reader has active/enabled antennae.

Ensuring that the reader is in native-API (i.e. not LLRP) mode

Enabling Polling

Querying the internal tag list

Updating the Device Firmware

Installing a FTP Server (Windows Server 2003)

Configuring the FTP Server (Windows Server 2003)

Testing the FTP Server

Performing the Update

(Part 2) – Impinj Speedway and BizTalk RFID: Hands On

Connectivity and configuration with Biztalk RFID

Adding the Reader

Checking for Tag Reads

Building a BizTalk RFID process and capturing tag reads

Creating a Biztalk RFID Process

Summary

(Part 1) – Impinj Speedway and BizTalk RFID: Hands On

Setting up the reader (from the shipping box to the network)

All Purpose, High Performance Tag Reading

Obtaining Documentation

Connecting the Serial Connection

Powering the Reader

Using the Serial Interface

Scanning Tags

Performing Native Firmware Updates

PowerShell and BizTalk RFID (1) - Providers and Server Configuration

Providers and Server Configuration Cmdlets

Creating PowerShell Cmdlets

Get-RfidProviderStatus

Get-RfidProviderMetadata

Get-RfidProviderProperties

Set-RfidLoggingLevel

Pro RFID with BizTalk Server 2009 - Hot Off the Presses

(Part 2) - Hands on with Biztalk RFID and the Alien 9650

Connectivity and configuration with Biztalk RFID

Obtaining and Installing the Provider

Snapshot of Vendor Properties

Configuring Firewall Ports

Adding the Reader

Checking for Tag Reads

Building a BizTalk RFID process and capturing tag reads

Creating a Biztalk RFID Process

Summary

(Part 1) - Hands on: Building an End to End Solution with Biztalk RFID and the Alien 9650

Installing the necessary software bits

Setting up the reader (from the shipping box to the network)

Installing the Software and Documentation

Connecting the Serial Connection

Powering the Reader

Using the Serial Interface

Scanning Tags

Peforming Native Firmware Updates

Primus Posting