I am in full support of utilizing Windows XP Mode within a Windows 7 64-bit host Operating System to run PanelBuilder32 v3.83 and RSLinx Classic v2.59. This setup effectively prevents potential compatibility issues that may occur when using 32-bit software on a 64-bit OS or with other software versions. This solution ensures seamless operation of Rockwell Automation Software within this environment. For more information on supporting Rockwell Automation Software in Windows XP Mode on Windows 7, please refer to document 341918.
Best regards, George.
I am experiencing the same issue with compatibility between PanelBuilder32 and Windows operating systems. Previously, I had successfully run PanelBuilder32 on Win 7 64-bit, but now with Win 10, it is not working. I was using RSLinx v3.9 on Win 7, but now I have upgraded to v4.00. Tech Support mentioned that PanelBuilder32 is not supported beyond XP, which explains the challenges.
I have attempted various solutions, such as running WinPFTv2.exe and PBWin32.exe in compatibility mode for Windows XP, but with no success. Even running RSLinx in compatibility mode did not yield results. There must be a specific combination of fixes that will work, and I am seeking assistance.
In the past, there were tools provided by Rockwell to manipulate RSLinx's version number for compatibility with PanelBuilder32. However, with the complexities of Windows XP mode, I am considering using a VMWare virtual machine instead of re-imaging my current system. I plan to revert RSLinx to v3.9 post-reimaging to troubleshoot the issue effectively.
Interestingly, I encountered a similar issue last week while working onsite. I came across a technical document that mentioned PanelBuilder 32 not being compatible with Windows 7, despite my successful installation. If I encounter the same issue in the future, I plan to test PanelBuilder 32 in XP mode. For more information, visit the Rockwell Automation website at the following link: https://rockwellautomation.custhelp.com/app/answers/detail/a_id/150966.
Looking for a solution to a software compatibility issue? Recently, I made a major upgrade from CCW 10.01 to CCW 11.00, which required me to install RSLinx 4.00. After troubleshooting with Process Explorer, I identified the problematic file as DTL32.dll. By replacing the newer version with an older one from a similar setup, I successfully resolved errors in PanelBuilder 32 and WinPFT. Ensuring the correct version of DTL32.dll is crucial when using RSLinx, RSLogix5, or RSlogix 500. I have provided the old DTL32.dll for download, along with instructions in a ReadMe file. It is important to note that upgrading RSLinx to 4.01 did not address the PanelBuilder issue. PanelBuilder 32 can be easily installed on Windows 7, following a specific installation sequence to avoid conflicts with other programs. No compatibility settings or XP Mode are required to run PanelBuilder 32 smoothly on Windows 7 Professional Edition x64. Remember to have administrator rights when making changes in the SysWOW64 folder.
I would like to express my gratitude to lstavropoulos for providing a solution that saved me on a Sunday when I had no technical support available. If you are experiencing a similar issue, you can find a helpful knowledgebase article on the topic at https://rockwellautomation.custhelp.com/app/answers/detail/a_id/1076131.
I strongly recommend sticking to the technote's suggestion and using an older version of RSLinx Classic with PanelBuilder32. It's best to install them in XP Mode or a similar virtual platform to avoid compatibility issues. Trying to maintain the relationship between older RSLinx Classic and PanelBuilder32 in a Windows 7 x64 Operating System can be challenging, especially with other constantly upgraded software like CCW. It's easy to overlook older software when installing newer upgrades, which can cause problems when you try to use legacy products like PanelBuilder32. To prevent these issues, I advise using RSLinx Classic v2.59 with PanelBuilder32 v3.83.01. By following these recommendations, you can avoid running into frustrating compatibility issues down the line. Regards, George
I am thrilled that the files I uploaded are working successfully, chiefy! I initially had doubts about whether others would be able to access and utilize them effectively.
I want to express my gratitude to lstavropoulos for helping me avoid a lot of frustration. I was able to resolve my issue by using the DTL32.dll file from one of my older computers. Additionally, I conducted further tests and created batch files to easily switch between different versions. I have tested the PanelBuilder version with ControlLogix processors ranging from series 60 to 80, as well as firmware versions 19, 30, and 31, and a SLC 500 without encountering any problems. For now, I am sticking with the old version as it has been working well. I am currently using Windows 10 Pro 64-bit. If I encounter any issues, I will provide an update.
I appreciate your suggestion of utilizing batch files, Hicbanzet! I plan to incorporate that into my workflow. Can you confirm if the file I shared is compatible with different computer systems? Additionally, I'm curious if you have Connected Components Workbench 10.1 installed, which led me to install RSLinx 4.0. I'll experiment with an older version of DTL32 to test for any issues with the software. Thank you for your input!
Absolutely! I successfully downloaded and extracted the files you provided. I refrained from using a downloaded dll unless absolutely necessary, as I do not have CCW installed. In the attachment, you will find my complete setup including batch files and dlls. The file labeled "DTL32.DLL_W540" originated from a Windows 7 64-bit machine running RSLinx v3.9. On the other hand, the file named "DTL32.DLL_Win10" came from a Windows 10 64-bit machine with RSLinx v4.0 installed, likely after the installation of Studio 5000 v30. Following the running of DTL32PB.bat, I have not made any changes. Please ensure all these files are placed in the SysWOW64 folder. Due to size restrictions, I had to split the files into two separate zip folders for attachment purposes. Thank you once again for your assistance. - lstavropoulos
Recently tested and confirmed to be functional on Windows 10, specifically on the x64 version 1803. Appreciate your support!
Prochot - Were you testing the Istavropoulos DLL or my entire system configuration?
Thank you! I want to express my gratitude for this solution, as it resolved my issue successfully.
I want to report that I have not encountered any situations where I needed to utilize the dtl32.dll provided with RSLinx 4.0+. I replaced it with the dtl32.dll from an older version of RSLinx and have had no issues since. This has been my experience with using RSLinx and its dll files.
I can confirm that this solution is effective. Despite being unable to revert back to an older version due to being on a new VM with updated software, this tip saved the day. Grateful for the assistance!
Thank you for providing a solution to this issue! After upgrading from CCW 10.01 to CCW 11.00, I encountered a problem with RSLinx 4.00. Through Process Explorer, I identified DTL32.dll as the file causing the issue. By replacing it with an older version from a different computer, I was able to resolve the issue and successfully use PanelBuilder 32. It's important to note that this file is also accessed by RSLinx, RSLogix5, and RSLogix 500, so it's recommended to switch back to the newer version for other tasks besides PanelView communication to avoid any bugs.
I have shared the old DTL32.dll file and a ReadMe for reference. It's crucial to keep a copy of this file handy before installing RSLinx 4.00 to perform this workaround. Additionally, I found that upgrading to RSLinx 4.01 did not impact the PanelBuilder issue. Editing PBA/PVA files is not affected, but the new version of DTL32.dll causes problems during PanelView transfers. PanelBuilder 32 can be easily installed on Windows 7 following a strict installation order to avoid conflicts with other programs like UltraWare and DriveExecutive.
In my experience, PanelBuilder32 runs smoothly on Windows 7 Professional Edition x64 without requiring XP Mode or compatibility settings. However, it's essential to have administrator rights to modify files in the SysWOW64 folder. It's important to follow a meticulous installation process to ensure the stability of PanelBuilder and related programs on newer versions of Windows.
Hello everyone, I am encountering a similar issue with PB32 and RSlinx V4.0. I am unable to access the RSLinx configuration under the transfer type when attempting to upload from any PV device that requires a PIC or UIC. This problem arises despite the fact that it works smoothly for direct serial communication without the need for RSLinx by selecting "DF1 - Point to point - internal Com1". However, if RSLinx is necessary, I face difficulties. I have attempted the workaround suggested by lstavropoulos, but it seems that as I am using Windows 7 32-bit, the solution may differ as I cannot locate the specified folder. Additionally, I have utilized sysinternals and have not observed the DLL file being used by RSLinx or PB32. lstavropoulos, can you provide insight into how you pinpointed that DLL? I am also curious to know if there is another DLL file that I could substitute as a 32-bit workaround. Thank you for any assistance.
- 20-01-2025
- JarJarBiscuits
I had success using the file provided by lstavropoulos on my Windows 10 Pro 64-bit system. I also experienced no adverse effects when using RS500 or RS5000 without reverting back to the original file. Thanks to lstavropoulos for saving me from having to go back to an older version of RSlinx and losing access to CCW. - kdog
I am thrilled that it was successful! I was unsure if anyone else would use the files I uploaded.
After conducting additional tests, I successfully installed PB32 on my Windows 10 x64 Rockwell laptop. However, I encountered difficulties getting it to work on a W7 32-bit system. Despite trying to replace the .dll file in various locations suggested through a search, I had no luck. It seems that this solution is only effective for x64 systems. Has anyone found success with an X86 machine? Ideally, I would like a fix for X86, but at least I can now support the hardware on site with my laptop.
- 20-01-2025
- JarJarBiscuits
Hello JarJarBiscuits, I apologize for the delay in responding. You are correct in noting that on a 32-bit Windows 7 system, DTL32.dll is stored in the Windows\System32 folder instead of the SysWOW64 folder. Therefore, you should navigate to the System32 folder to locate the file. The process for swapping the file remains unchanged.
Following cbanzet's advice, I have been using the old DTL32.dll for almost a year now and everything is running smoothly. I am delighted to hear that many of you have found success in getting the software to function properly using this method.
In response to your question, JarJarBiscuits, I utilized Process Explorer from Windows Sysinternals to thoroughly examine all files and registry entries accessed and modified by RSLinx and WinPFT. It took some time to sift through the data by customizing the results, but eventually, I discovered the newer version of DTL32.dll. Taking a chance on swapping the file proved to be a fortunate decision.
After upgrading from CCW 10.01 to CCW 11.00, I encountered a crucial breakthrough. The installation of RSLinx 4.00 was mandatory, leaving no room for installing RSLinx versions 3.90 or lower. CCW stands for Connected Components Workbench, for those unfamiliar with the term. Through thorough examination using Process Explorer from Windows Sysinternals, I identified a problematic file - DTL32.dll. To resolve the issue, I replaced the existing file with an older version obtained from a similar computer with an outdated RSLinx version. By renaming the current dll file to DTL32.dll_NEW and substituting it with the older file, I successfully resolved the error in PanelBuilder 32 (or WinPFT), enabling seamless communication with RSLinx for uploading/downloading to a Panel View.
Further analysis revealed that RSLinx, RSLogix5, RSLogix 500, and other AB programs also rely on this file. Hence, it is advisable to restore the newer version of the file for tasks beyond panel programming to avoid any potential bugs. In case the provided old DTL32.dll file does not work, obtaining a suitable version before installing RSLinx 4.00 is recommended.
It's worth noting that despite upgrading RSLinx to version 4.01, the PanelBuilder issue persisted. When editing PBA/PVA files, no complications arose in any scenario. The concern with the new DTL32.dll version only surfaces during upload/download operations with a PanelView. Notably, PanelBuilder 32 functions smoothly on Windows 7 (both 32-bit and 64-bit) if installed following a specific sequence, ensuring compatibility with programs like UltraWare and DriveExecutive.
Given my experience using the provided DLL file on new Windows 10 machines running various AB software versions, including RSLogix 5000 and Studio 5000, I have encountered no issues. As all my machines operate on Windows 10 Enterprise, the transition to the new DLL file has been seamless without any setbacks. However, I remain open to updating if any challenges arise in the future. At the factory where I work, a mix of modern and older Allen Bradley equipment is in use. Despite attempts to revert to an older DLL file pre-RSLinx 3.90, adopting the provided file was the only viable solution for optimal system performance.
I am thrilled to report that the solution worked! While I understand this discussion is older, I must express my immense gratitude for the invaluable assistance provided here. I, too, encountered a frustrating obstacle not long ago when attempting to connect to my Panelview 300 using Panelbuilder 32. After two days of relentless searching for a resolution, I fortuitously stumbled upon this thread. Despite not initially finding what I needed, I discovered the solution within its pages. By swapping out the DLL file, I successfully established a connection and resumed uploading and downloading without any issues. Thank you to everyone for your contributions!
Hey there, Buddy! It's incredible how relevant this information still is. I can vividly remember experiencing this issue and feeling completely frustrated by it. Like you, I came across this discussion while frantically searching online for a solution. This particular topic was actually what prompted me to sign up for this website! I'm thrilled to see that you and others have found assistance here, as something as routine as updating software can unexpectedly disrupt such a crucial tool.
I wanted to provide a quick update on my previous comments: instead of using Process Explorer, I actually utilized Process Monitor (both available on the systernals website) to monitor PanelBuilder's activities. It was quite time-consuming to sift through the abundance of data generated by the program, but the insights gained were invaluable.
I want to express my gratitude for your help - you truly are the best! Please forgive me for commenting on an older post, I just had to.
This thread is absolutely hilarious! One thing I have been curious about is whether putting the "old" version of DTL32.exe in the same directory as PBWin32.exe could work if only PBWin32.exe requires it. Alternatively, if other .EXE files also need the old version, would placing them in the same directory help? It's interesting how RA appears to leave individuals stranded, as many in the industry may still be using outdated products due to the adage of "if it ain't broke, don't fix it." However, access to the KB article is restricted to those with a TechConnect contract – quite unfair, considering they no longer provide support for it. This seems like a push towards upgrades, withholding support and making it a pay-to-play system. It is the epitome of poor decision-making, trying to coerce users into upgrading. While we often joke about "necro-thread alerts," some of these discussions are timeless and should be archived for easy reference based on error numbers and applications.
This is the exact reason why, when managing a significant industrial site, I made the decision to remove all Rockwell (RW) equipment and switch to Siemens and Mitsubishi. Prior to being disappointed by RW, I proactively swapped out their drives and HMI's due to their persistent failures. Additionally, the lack of support for a Scada System that cost over $40k was a major concern.
I am grateful that my solution was helpful to you, Richie_S! Despite its age, this issue continues to cause problems in the present day. I had actually forgotten about it until I recently updated to CCW 12.0 and encountered issues while working on a PanelView Standard (using PB32). The frustration was real. Luckily, I had saved the DTL32.DLL_OLD file in my SysWOW64 folder, which allowed me to replace the problematic file from Rockwell. I highly recommend keeping a backup file for situations like mine, as I may have mentioned in my initial post.
I completely agree with drbitboy. One notable example is the stark contrast in quality between manuals from the PLC5 series and those released in recent years. The older manuals provided comprehensive information and even delved into topics beyond just the PLC itself. The current manuals, particularly for CCW and the Micro800 series of PLCs, are overly simplified and sometimes lacking in substance. Additionally, Rockwell's pricing strategy for "legacy support" is frustrating, requiring customers to pay extra just to get assistance with older PLCs, drives, HMIs, and other equipment.
Regarding the DTL32.dll file, it is utilized by WinPFTv2.exe, the file transfer utility for PB32. This file is typically located in the Windows system folder (SysWOW64 for 64-bit systems and system32 for 32-bit systems), so having a duplicate in the Panel Builder folder may not be effective. However, it might be worth experimenting with placing a copy in the Panel Builder folder to see if it helps alleviate compatibility issues when upgrading software. It's worth a try, at least.
I encountered an issue and considered transferring the dll file to the PanelBuilder32 Folder as a solution to avoid overwriting a newer dll. After restarting the program, the error dialog no longer appeared. I have attached a redacted image of the issue. Since I am not currently at the customer's location, all devices are showing a red x mark. I will conduct further testing during my next visit.
It was fascinating to see Process Monitor's extensive tracking of folder access and read actions while troubleshooting. It seems likely that the software is searching for the .dll file primarily in PanelBuilder's installation directory. I will experiment with this hypothesis to confirm your observations, as it could lead to a more streamlined solution. This way, other Rockwell software can freely perform operations in the System folder. Thank you for sharing this valuable information!
According to JCFC's research, the solution to the issue involving DTL32.dll in PanelBuilder32 lies in replacing the older version of the file in the application folder. I confirmed this during a recent test, and it worked perfectly! For Windows 7 x64 users, simply copy the file to "C:\Program Files (x86)\Allen-Bradley\PanelBuilder32". If you are using a different version of Windows (e.g., Windows 7 x86), you will need to find the appropriate folder location. To locate it, right-click on the PanelBuilder32 desktop or start menu icon and check the properties for the file location. By following this workaround, you can prevent future headaches with Rockwell software updates. RSLinx updates may overwrite the DTL32.dll file in the Windows system folder, but they will not affect the file in the PanelBuilder32 application folder (assuming it has been added, as the file is not typically found there by default). This discovery will undoubtedly streamline the update process.
In order to download applications to a PanelView terminal, it is essential to configure the appropriate communication driver on your system. This can be done by using either the RSLinx Lite Software (compatible with Windows 95 or Windows NT 4.0) or the INTERCHANGE Software (compatible with Windows 95 or Windows 3.x). INTERCHANGE consists of real mode DOS TSR communication drivers that are widely used by various Windows programs. It is possible that INTERCHANGE is already installed on your computer. The APS and 6200 Programming Software utilize INTERCHANGE in either DOS or Windows environments.
To verify the version of INTERCHANGE running on your computer, simply type DTLVER at the DOS prompt.
RSLinx Lite offers communication drivers that can be utilized by Windows programs. To check the version of RSLinx on your computer, navigate to the Help menu and select About RSLinx.
Prior to installing PanelBuilder on a Windows 95 computer, it is advisable to search the C:\Windows\System folder for the files VDF1.386 and V485.386. If these files are found, they should be deleted.
A heartfelt appreciation to tolstavropoulos for coming through in a big way and saving the day! Thank you so much for your help.
You're welcome! I'm happy to assist. Check out JCFC's post (post #35) for more information. By transferring the functional DTL32.dll to the PanelBuilder program folder, you can prevent any upcoming updates to RSLinx from impacting the dll file in the program directory, saving you from dealing with this issue in the future. The location of the program directory may differ depending on your system, so I provided some helpful tips on locating it in post #37.
Another big thank you to Istavropoulos!
Hello there! I'm happy to be of assistance. I recommend checking out JCFC's post (post #35) for guidance on replacing the old DTL32.dll with the new one in the PanelBuilder directory. Exciting news for everyone - the latest Rockwell software updates seem to have fixed the initial problem. I conducted a test using the updated DTL32.dll file from my SysWOW64 folder, removed the file from my PanelBuilder program directory, and found that the RSLinx Network option is now working smoothly. This updated dll file, dated August 2020, is slightly larger (2KB) than the older one from 2016 when I believe I had installed CCW 12.0. This development is promising, but it's a good idea to keep the old DTL32.dll file handy, just in case.
I want to express my gratitude to lstavropoulos, as a new engineer tasked with communicating with more experienced colleagues, I found it daunting. However, thanks to your invaluable solution, I was able to successfully navigate this challenge.
Incredible Discovery That Saved the Day!
I would like to express my gratitude to Stavropoulos and JCFC for their perseverance in this matter. It will be much more convenient to not have to constantly search for an old DLL file every time I install new Rockwell software. For those who are frustrated with Rockwell for moving away from older technologies, I learned the hard way that classic PanelViews are unable to communicate with newer ControlLogix firmware revisions past 31 or 32. It's ironic that only certain newer firmware revisions support older motion control modules. Rockwell's approach seems to be phasing out older technology.
Despite these challenges, Classic PanelViews remain my preferred HMI due to the simplicity of having a single program file that can be easily accessed and edited on a central server. In contrast, Rockwell's newer HMIs require a dedicated PC for programming or entail time-consuming backup and restoration processes that risk not having the most up-to-date version. If anyone is aware of a competitive HMI that also utilizes a single program file, I would appreciate any recommendations.
lstavropoulos, thank you so much! Your solution worked perfectly! It's strange that I encountered this issue after not using PB32 for a year. I had recently updated to RSL 4.11 and kept getting the 1091 error, only being able to transfer to a memory card, which I don't have.
Thank you, [Twitter handle] for sharing! The solution you provided for Windows 10 worked perfectly for me.
We are incredibly grateful for the exceptional job you have done!
Hello everyone, I apologize for my lack of activity on the site recently, but I am pleased to see that we are continuing to provide support for older equipment that still has years of service left. I highly recommend checking out post #35 (along with subsequent posts) for important information on the DTL32.dll file and its impact on the PanelBuilder program.
Many users, including myself, have encountered challenges with Rockwell updates to RSLinx affecting PanelBuilder's ability to utilize the RSLinx network connection option via the DTL32.dll file. By placing the file in PanelBuilder's directory, it has remained stable despite inconsistent updates that may initially work but later break the connection. This method eliminates headaches when updating Rockwell software like CCW or Studio5000.
Be sure to use a known-working version of the dll file, which can be found in earlier posts or in your own saved files. Best of luck to everyone facing these challenges!
The solution worked flawlessly! A huge thank you for that.
I successfully implemented your file on my Windows 7 32-bit Enterprise operating system, and it functioned perfectly! Just wanted to share this positive outcome with others who may be in a similar situation.
I am thrilled to add another victory to this blog post. I couldn't resist incorporating this as well. Many thanks!
A big thank you to @lstavropoulos for another impressive victory. We greatly appreciate your efforts in documenting your discoveries from years past.
I am happy to report that we have successfully installed and configured DTL32.DLL on our AssetCentre server, which is operating on Windows Server 2019. This file is located in the "C:\Program Files (x86)\Allen-Bradley\PanelBuilder32\" directory. It's truly remarkable how well it's running.
It appears that I needed to update to version 4.2, although it was quite some time ago. James.