“It’s a DOS product! From 1990! What other ‘90 products do you have that support Windows (insert latest version) ?”
Ok, not the best way to make friends but sometimes you just have to say it the way it is…
Below is the story I compiled over the years from several sources on why the 1747-PIC always had such a difficult time being supported in Microsoft Windows:
The 1747-PIC was designed in the late 80’s and released with the SLC-500 family in 1990. Now if you’re as old as I am you may recall that in the 80’s memory was expensive, and (as the story goes) to keep the price of the 1747-PIC down it was given a small communications buffer.
For everything to work, the small communication buffer had to be compensated for by having smaller packets transmitted at a high frequency. And to keep everything synchronized, a heart-beat of 9-10ms was used. Since the Operating System the PIC was designed for was Microsoft DOS, a high speed connection to the Computer’s communications (comm) port was available and well suited for this design.
However, when Windows 3.x began to grow in popularity, users of the 1747-PIC found it wouldn’t work in this OS. Windows it turns out was designed to service the communications port at a considerably slower rate, much to slow for what the PIC required.
In an attempt to work around this Windows limit, ICOM (makers of the Windows 3.x Allen-Bradley communications software package, “WinLinx”) took it upon themselves to rewrite Window’s communications port driver, “comm.drv.” They produced a new ICOM Windows comm driver named “icomcomm.drv.” When this was used in place of the Windows default, WinLinx was able to use the 1747-PIC in Windows 3.x.
When Windows 3.x was replaced by Windows 95, to get the PIC to work again the Win95 comm. port driver had to be re-written. ICOM, since merged into Rockwell Software, rewrote the Windows 95 comm.drv, however it took many months and was not available until many complaints had flowed in.
The with the release of Windows NT, a new issue developed around it's “HAL.” Previous Windows and DOS programs that controlled hardware directly didn't work in NT. They had to be rewritten to interface with Windows NT's Hardware Abstraction Layer (HAL) instead. And since the “HAL” loaded on boot, even when Rockwell finally re-wrote the NT comm port driver, the only time the RSLinx PIC driver could be switched in (or back out) was when the machine booted. Then Windows 2000 was released with an updated HAL that again required the comm driver be rewritten for the PIC.
Finally when XP rolled around we caught a break. As it was extensible just an update from Windows 2000, many were able to get the existing RSLinx and it’s PIC driver to work out of the box. However, it wasn't without issues as to stop the 1747-PIC from locking on to your comm. port you needed to open up Device Manager to delete it when you needed your comm. port for something else (until the updated XP version of RSLinx was released.)
In the end, the 1747-PIC was a device designed for DOS. While Rockwell did eventually support all later Microsoft Operating systems, the time it took to re-write Microsoft’s comm.drv each new Windows release left most Rockwell customers frustrated and disappointed. Fortunately in 2003 those who still needed to connect to DH-485 devices and were interested in getting off the “comm.drv-merry-go-round” finally had their opportunity with Rockwell’s new 1747-UIC. This “USB to DH-485” was warmly welcomed by all customers who exclusively used 19.2K baud. Because of this “baud rate” restriction I now recommend the below third party device (black 1747-UIC pictured on right) which many of my clients have told me works well and
supports all DH-485 baud rates.
Update: While third party 1747-UIC's represent a great price savings versus the Rockwell version, and in my own tests they work extremely well, further investigation has not been able to confirm support of multiple baud rates. In the mean time, Rockwell has released a firmware utility for it's 1747-UIC which allows switching between 9,600 and 19.2, but does require running the utility every time you wish to change the baud rate.
I hope the above “tale of the PIC” was interesting. If you have anything thoughts or comments to add please feel free to leave them by filling out the “leave a reply” form at the bottom of this page.
If you enjoy reading my articles please consider helping me take The Automation Blog "Ad Free" with a small monthly pledge at Patreon.com/Automation