MSDTC and NT AUTHORITY\NETWORK SERVICE vs NT AUTHORITY\NetworkService

We encountered a very strange issue with MSDTC recently. We were getting an error when trying to execute a remote stored procedure, which appeared to be security related. We were using NT AUTHORITY\NETWORK SERVICE, which didn't work, but then found that NT AUTHORITY\NetworkService did. I was not even aware that the NetworkService account existed, as I had always used NETWORK SERVICE. I can't seem to find anything that explains the difference and why you must use NetworkService for MSDTC. I would love to hear from someone that can explain that to me.

Reporting Services Delivery Extensions

I attempted to implement the Reporting Services Printer Delivery Extension sample last week, which I thought would be a fairly straight-forward task. As usual, I was wrong. The documentation was quite sketchy and I spent the better part of a day just trying to get SSRS to detect the extension. I suspected that I wasn't putting the CodeGroup element in the right spot of the rsxxxpolicy.config files, but couldn't find any documentation telling me WHERE to put it. I finally came across an entry in K. Scott Allen's blog that explained exactly where it needed to go, and I then thought I was sitting in high cotton (yeah, I know).

However, I soon found that SSRS wouldn't recognize my printer entry. After an hour or so of trying to attach a debugger, I finally found that the sample code compares the printer with the list of installed printers, but does a case-sensitive comparision. I modified the code to make it case-insensitive and next found that network printers do not show up in the list of InstalledPrinters. So I created a local printer using a TCP/IP port and SSRS (finally) detected it.

You would think I had to be getting close now, so I scheduled a report, watched it execute and voila!, I had a report on the printer! WOOO HOOO, this printer crap is a piece o cake. Right......

It printed, but it was scaled up when compared with the same report printed from ReportManager, and wouldn't display on one page. I started digging and found the Image Device Information Settings and began playing with the settings. It appeared my only options were the DpiX, DpiY, PageHeight and PageWidth settings. I began with the DpiX and DpiY, but no matter what I set these parameters to, I got no change in the scaling. The PageHeight and PageWidth didn't change the scaling, but it did change how many pages actually printed with certain settings.

After messing with these parameters for a couple of hours and running out of time, I decided to take another approach, since I had already spent almost two days and was really no closer to delivering a production quality report. I created a Windows service to monitor a file share for new PDF files, spawned an instance of FoxitReader in the background to print it, then renamed the file and moved it to an archive folder. Not exactly a perfect solution, but it works. And I still have my hair.

ControlLogix DateTime Add-ons

A cool new feature of ControlLogix v17 is add-on instructions. I had originally hoped that these would be great replacements for indirectly addressed subroutines since zooming into an instruction shows you the logic but only displays the data of the current instance of the instruction. However, Rockwell strongly discourages using add-ons for large, complex subroutines, and the inability to edit them online really made them undesirable for that use.

They are good for encapsulating reusable pieces of code though, and Rockwell has provided some samples that perform manipulation of DateTime values, which I have already put to good use. The instructions included are:

• T_Add - Adds a time span to a DateTime and returns a new DateTime
• T_Clock - Sets or returns the controller clock time
• T_Diff - Returns the difference between two DateTime values
• T_Dow - Returns the day of the week for the passed in DateTime value
• T_Equ - Compares two DateTime values for equality
• T_Geq - Compares if one DateTime value is greater than or equal to another
• T_Grt - Compares if one DateTime value is greater than another
• T_Leq - Compares if one DateTime value is less than or equal to another
• T_Les - Compares if one DateTime value is greater than another
• T_Lim - Compares if the DateTime value is within a low and high limit range
• T_Neq - Compares two DateTime values for inequality
• T_Now - Returns the current controller clock value
• T_Scan - Returns the previous scan time
• T_Sel - Uses an input bit to select one of two DateTime values
• T_Sub - Subtracts a time span from a DateTime value and returns a new DateTime value
• T_Sun - Returns the local sunrise and sunset times
• T_TtoS - Converts a DateTime value into a human-readable string
• T_Valid - Checks if the given DateTime value is valid

I used the T_Now and T_Sub instructions to calculate the local date/time using a local offset. We use UTC time in the PLC to avoid time change issues and calculate local time using the current local time offset.

You can find these by opening the Start Page in RSLogix5000, selecting Open Sample Project, and then choosing Add_On_Instruction_Samples.acd, or going to [Drive]:\RSLogix 5000\Projects\Samples\ENU\v17\Rockwell Automation\.

Serial to PLC Gateway Nightmare

We've been using some really handy serial-to-PLC gateway products from Realtime Automation recently that are especially easy to set up and allow us to transfer data bi-directionally between the PLC and barcode readers, printers, etc. You connect them to your serial device and to Ethernet, then configure the device through the embedded web server. You set the IP address of the PLC that will send or receive the data, configure the register that will be monitored or written to, configure the serial port parameters and voila, you have communications! No PLC programming required other than reading or writing the data.

These have worked well, especially for bringing barcode data into the PLC, and have also worked well for simple printing, but we ran into problems when trying to print a large barcode label. The label format was too large to transfer all at once, so we had to chunk the data. Most of the time, the labels would come out perfectly, but occasionally they would leave out entire sections of the label, or even worse, modify single characters in a certain field! Have you ever arrived at a plant early in the morning, only to find the plant manager, and 2 engineers waiting at the door for you?

We didn't know where the cause of the problem lied, so we began trying to isolate it. I first ruled out the printers by writing a small .NET application to do the printing. We ran this for a few days and had no problems, so we could assume the printers were okay. Next, we had to know if there was a problem with the PLC code or the gateway. This was harder to prove. We tried using an RS-232 monitor cable with HyperTerminal to see if maybe the PLC was sending the data improperly, but the data was coming in garbled, so that didn't shed much light. We tried different cables, different RTA gateways, etc., all to no avail. After weeks of trying to pinpoint the problem, I decided to try a different vendor's gateway product. I ordered a Comtrol device, which turned out to be a little more complicated to implement, and required that we write message instructions in the PLC to write the data, but once we installed it, all of our issues magically went away!

Now, I am not saying that RTA's product is bad for printing, as I still don't know exactly what the problem was. We have had great success using the RTA devices with barcodes, RFID readers, and simple printing applications, but on the next printing application, I'm going to avoid the early morning meetings with management and use the Comtrol.