geniusintraining
Lifetime Supporting Member + Moderator
Disagree Gary, maybe its just your PC that you were using but I have found the W7 32 or 64 works flawless with them
1747 UIC to micrologix 1200 issues
- Thread starter solojayda3rd
- Start date
Disagree Gary, maybe its just your PC that you were using but I have found the W7 32 or 64 works flawless with them
TimWilborne
Lifetime Supporting Member
Can you even use the 1761-NET-ENI with a configured DH-485 PLC?
GaryS
Member
Yes the NET-ENI was designed to put the ML processors on Ethernet
the processor port is a 9 pin din the same as the programming port on the ML processor. the NET-ENI will even draw it power from the ML port
I use the AB 2711-CBL-HM05 cable.
as for the UIC I tried it on 4 different computers all acted the same
sometimes it would connect and later drop the connection other times it would not connect at all.
called tech support many times many hours of frustration trying to get it to work. if you are just in and out of the processor it probably will work OK but stay on line for hours as I sometimes have to then it will drop the connection
I think it works better when connected to a SLC processor.
the processor port is a 9 pin din the same as the programming port on the ML processor. the NET-ENI will even draw it power from the ML port
I use the AB 2711-CBL-HM05 cable.
as for the UIC I tried it on 4 different computers all acted the same
sometimes it would connect and later drop the connection other times it would not connect at all.
called tech support many times many hours of frustration trying to get it to work. if you are just in and out of the processor it probably will work OK but stay on line for hours as I sometimes have to then it will drop the connection
I think it works better when connected to a SLC processor.
Bering C Sparky
Lifetime Supporting Member
I too have been dropped offline while using the UIC on a DH485 network for a long period of time.
But I found that if you UNCHECK the Auto Browse in RSLinks that this solves that problem.
(OR at least it did in my case)
Now I just uncheck this box immediately after seeing all my nodes are active in Linx and I am able to stay online for long periods of time with no problem.
Other than that the UIC works just fine for me.
BCS
But I found that if you UNCHECK the Auto Browse in RSLinks that this solves that problem.
(OR at least it did in my case)
Now I just uncheck this box immediately after seeing all my nodes are active in Linx and I am able to stay online for long periods of time with no problem.
Other than that the UIC works just fine for me.
BCS
Mickey
Lifetime Supporting Member
I have seen the same results with DH+ networks.
geniusintraining
Lifetime Supporting Member + Moderator
Next time your in the mood... try one of mine
http://www.plccable.com/allen-bradley-1747-uic-usb-to-dh485-usb-version-1747-pic-slc-500/
I have sold a few thousand of them and everyone is very happy with the purchase, we offer a lifetime replacement (fails under normal use) and if you have any issues in the first 60 days we will pay the return shipping and refund you money so you are not out a dime
Ok, back for more...
GaryS,
There is something not quite right here or am I missing something?
The 1747-UIC, or the older 1747-PIC, are DF1 to DH-485 Protocol converters. They can only be used to communicate with devices configured for the DH-485 Protocol.
If you are/were attempting to communicate with controller ports configured for the DH-485 Protocol, using a 1747-UIC, and having issues - then I do not see how a 1761-NET-ENI can directly replace a 1747-UIC?
The 1761-NET-ENI and 1761-NET-ENIW provide EtherNet/IP connectivity for controllers and devices that are configured for DF1 Full-Duplex only. It cannot be used to communicate with controller ports configured for DH-485, or anything other than DF1 Full Duplex.
From the 1761-NET-ENI(W) Manual...
Unless the ports you like to use the ENI with are reconfigured to DF1 Full Duplex, and free to do so, I cannot see how the ENI "works every time" while they are configured for DH-485?
But either way...
The 1747-UIC is fully compatible under Windows 7 x86 or x64. FTDI provide 64-bit drivers specifically for their chip inside the UIC. I use it on a regular basis natively with Window 7 x64, as well as in VMware. That's two of us now, but many others could also contest to this fact.
I cannot speak for your experience, or the advice you received from Support. There are a number of things that can prevent a successful communications session while using the 1747-UIC, whether in Windows X, Y or Z. As we are not specifically dealing with such an issue here for yourself, I won't get into all that. The least I will advise users to do is to always use the same USB port for the UIC and assign it a COM port number higher than COM4. Windows tends to share resources for COM1 & 3, and COM2 & 4 respectively. I personally use COM 8 and have it on a sticker which also indicates that the USB port is for UIC use only.
Whatever the reason for your woes, and barring faulty hardware, the issue should have been addressable, but it can require some persistence.
As for discontinuation? You must surely be referring to the 1747-PIC?
The 1747-UIC is not going anywhere for a long time and Rockwell will most certainly contest to that fact. As long as support for DH-485 based devices is still required, and that is also a given for the foreseeable, then the 1747-UIC will be required until such a time as either DH-485 devices have all but vanished, or some hardware advancements have superseded the USB port and it starts to vanish, similar to the RS-232 serial port at present.
More on that to come...
GaryS said:
GaryS,
There is something not quite right here or am I missing something?
The 1747-UIC, or the older 1747-PIC, are DF1 to DH-485 Protocol converters. They can only be used to communicate with devices configured for the DH-485 Protocol.
If you are/were attempting to communicate with controller ports configured for the DH-485 Protocol, using a 1747-UIC, and having issues - then I do not see how a 1761-NET-ENI can directly replace a 1747-UIC?
The 1761-NET-ENI and 1761-NET-ENIW provide EtherNet/IP connectivity for controllers and devices that are configured for DF1 Full-Duplex only. It cannot be used to communicate with controller ports configured for DH-485, or anything other than DF1 Full Duplex.
From the 1761-NET-ENI(W) Manual...
Unless the ports you like to use the ENI with are reconfigured to DF1 Full Duplex, and free to do so, I cannot see how the ENI "works every time" while they are configured for DH-485?
But either way...
GaryS said:
The 1747-UIC is fully compatible under Windows 7 x86 or x64. FTDI provide 64-bit drivers specifically for their chip inside the UIC. I use it on a regular basis natively with Window 7 x64, as well as in VMware. That's two of us now, but many others could also contest to this fact.
I cannot speak for your experience, or the advice you received from Support. There are a number of things that can prevent a successful communications session while using the 1747-UIC, whether in Windows X, Y or Z. As we are not specifically dealing with such an issue here for yourself, I won't get into all that. The least I will advise users to do is to always use the same USB port for the UIC and assign it a COM port number higher than COM4. Windows tends to share resources for COM1 & 3, and COM2 & 4 respectively. I personally use COM 8 and have it on a sticker which also indicates that the USB port is for UIC use only.
Whatever the reason for your woes, and barring faulty hardware, the issue should have been addressable, but it can require some persistence.
As for discontinuation? You must surely be referring to the 1747-PIC?
The 1747-UIC is not going anywhere for a long time and Rockwell will most certainly contest to that fact. As long as support for DH-485 based devices is still required, and that is also a given for the foreseeable, then the 1747-UIC will be required until such a time as either DH-485 devices have all but vanished, or some hardware advancements have superseded the USB port and it starts to vanish, similar to the RS-232 serial port at present.
More on that to come...
The 1747-PIC - A well driven soul...
The 1747-UIC was released in 2003.
Why?
Well, for a couple of reasons...
Rockwell knew that an imminent trend in the computer manufacturing world at that time was to begin slowly phasing out the RS-232 9-pin serial port on most of their computer offerings. Both Desktop and Portable. USB was fast becoming the new serial port for all computer peripheral devices. This trend started in 2004 and the slow decline continued up to around the 2009 mark, where ever since, only a select few models, from a select few manufacturers, provide this hardware feature, natively.
Lenovo, whom we use for our leased business computers, currently offer no serial port models. There isn't a CD/DVD drive either on my current model, for that matter, but that's a whole other story of declination.
Toshiba stopped providing serial ports after 2010, with only a serial port replicator option available. I used one on my last business laptop - did not work so well.
Dell have also gone the way of replication for their once serially endowed Latitude Series. They now only offer built in serial ports on their Rugged Series. The 12" have one, the 14" have two, no less. But you pay a handsome price for such a luxury.
Fujitsu is another manufacturer that I know of that provides a serial port option. Mid 2014 they launched two models for their LIFEBOOK E Series. I remember because I looked into them before buying the second HP. For their E554/J model, a serial port is available as an optional extra.
HP, from whom I have two programming laptops, provide one on the ProBook 6560b (older model) and the EliteBook 8570p (newer model). There are others too, but the model numbers are not to hand.
I'm not sure about other manufacturers, but from what I know, HP seem to me to be the best well known brand which still provide native serial support on their not too expensive laptops?
Anyhow, I'm rambling...
So Rockwell released the UIC, in part, to counteract this impending hardware revolution. But also, they released it to finally do away with the myriad of driver issues they had long since lived with for the 1747-PIC.
The PIC interface was introduced way back in 1990 along with the SLC Family of Controllers. It was a DOS based interface device. It originally used WinLinx (RSLinx predecessor) to communicate. It had all the necessary resources available to its limited comms buffer. This worked well until Microsoft got clever and started overlaying DOS with a GUI. The newer Windows based OS (3.x) began "managing" resources and the new, but limited, "COMM.DRV" driver was introduced. Soon, the PIC was starved of its high speed connection resources. The DOS based device could not cope within this new "let's share" environment.
The COMM driver had to regularly switch over and back between real and protected mode, so this made it far too unreliable at high speed communications. Many companies had to rewrite the COMM driver as it was too slow for their serial devices' requirements.
ICOM, the original authors of WinLinx, rewrote the Windows serial port COMM driver to hand back the necessary resources to the PIC. I remember you had to edit the system.ini file "COMM.DRV=RHSICOM.DRV" to use the modified driver. So all was well again.
That was until Windows 95 arrived on the scene. Native DOS was all but dead now. It brought with it a whole new suite of communications improvements and enhancements. Remember all that email, fax, and online services that was starting to creep in. So again, ICOM (now Rockwell owned) had to set about rewriting the Windows 95 drivers. But this proved much more difficult with so many changes to the communications architecture and subsystem. It took many attempts before they finally released a relatively stable version. But the DOS based PIC still was not out of the oh so foreign woods just yet. Some of the communication enhancements that Windows 95 introduced also hindered the PIC. The VCOMM virtual comm port driver, that was supposed not to interfere with it's partner in the real world, did just that, on occasions. Also, newer power management options would tickle the com port periodically to see if it was awake, interrupting current transmissions through the PIC. Serial mouse drivers would now auto load on Windows startup for "convenience" should you require them, locking the serial port out from the PIC, and on and on.
But did they give up?
Where's the fun in that?...
Next there was the huge hurdle of the Hardware Abstraction Layer (HAL - "Just what do you think you're doing, Dave?") that was introduced with Windows NT. Applications and device drivers were now no longer allowed to deal with hardware directly and had to make calls to HAL routines to determine hardware specific information. This added back in unacceptable latency for the PIC's limited comms buffer. So once again, a lengthy journey was undertaken to rewrite NT's COMM driver. Even so, it had headaches. HAL must prime its routines during POST, so that meant the modified driver had to be loaded at BOOT. Making it unloadable until REBOOT. So once finished with the PIC, you had to REBOOT to free the COM port up for other applications.
Then came along Windows 2000 with a much improved HAL, yippee!...and yet again, the drawing board had to be wiped clean.
Eventually, Windows XP came on the scene and things became somewhat easier. There was little change with regard to the HAL and the PIC would work reasonably well. One advantage was that now you only had to delete the driver in Device Manager to free up the COM port, rather than have to REBOOT.
But the party was short lived. This hiatus lasted until Windows XP SP3 was released and the Serial Enumerator handler was updated, again making the PIC an outcast. "Serenum.sys" is an upper-level device filter driver that is used with a serial port function driver, namely "Serial.sys", to enumerate devices that are connected to a serial port. "Serial.sys" is the default provided function driver for serial devices, but any third party serial driver can be used in conjunction with Serenum.sys. The updates included changes in how the enumerator mapped COM ports to devices.
At last, a hurdle too high...
Between the protection issues instigated by Windows File Protection, which restores any modified protected system files, and the fact that the method used to mitigate said protection i.e. the replacing of Serenum.sys with the XP SP2 version, renders the serial port useless to all applications, but the PIC Driver - Rockwell threw in the towel and no longer pursued the, up until then, crazy, but somewhat commendable, path to keeping the 1747-PIC alive.
However, while the 1747-UIC might have appeared to be the direct successor to the 1747-PIC interface, this was not entirely the case. They both had there uses and relevance, at that time. Only computers running at or above Windows 95 circa 1998 supported USB v1.1 devices, which the UIC happens to be. Many 9-pin serial port only computers were still available to purchase and indeed in service running under older OS. So before, and indeed after Windows XP was released, the PIC was/is still required to support legacy computers that do not support USB. They could not, and did not "stop using (the PIC) about the same time XP came out". In fact, the 1747-PIC did not reach its Silver Series Date until 7/1/2008. Some seven years after Windows XP was first released.
God rest its well "driven" soul.
Regards,
George
GaryS said:
The 1747-UIC was released in 2003.
Why?
Well, for a couple of reasons...
Rockwell knew that an imminent trend in the computer manufacturing world at that time was to begin slowly phasing out the RS-232 9-pin serial port on most of their computer offerings. Both Desktop and Portable. USB was fast becoming the new serial port for all computer peripheral devices. This trend started in 2004 and the slow decline continued up to around the 2009 mark, where ever since, only a select few models, from a select few manufacturers, provide this hardware feature, natively.
Lenovo, whom we use for our leased business computers, currently offer no serial port models. There isn't a CD/DVD drive either on my current model, for that matter, but that's a whole other story of declination.
Toshiba stopped providing serial ports after 2010, with only a serial port replicator option available. I used one on my last business laptop - did not work so well.
Dell have also gone the way of replication for their once serially endowed Latitude Series. They now only offer built in serial ports on their Rugged Series. The 12" have one, the 14" have two, no less. But you pay a handsome price for such a luxury.
Fujitsu is another manufacturer that I know of that provides a serial port option. Mid 2014 they launched two models for their LIFEBOOK E Series. I remember because I looked into them before buying the second HP. For their E554/J model, a serial port is available as an optional extra.
HP, from whom I have two programming laptops, provide one on the ProBook 6560b (older model) and the EliteBook 8570p (newer model). There are others too, but the model numbers are not to hand.
I'm not sure about other manufacturers, but from what I know, HP seem to me to be the best well known brand which still provide native serial support on their not too expensive laptops?
Anyhow, I'm rambling...
So Rockwell released the UIC, in part, to counteract this impending hardware revolution. But also, they released it to finally do away with the myriad of driver issues they had long since lived with for the 1747-PIC.
The PIC interface was introduced way back in 1990 along with the SLC Family of Controllers. It was a DOS based interface device. It originally used WinLinx (RSLinx predecessor) to communicate. It had all the necessary resources available to its limited comms buffer. This worked well until Microsoft got clever and started overlaying DOS with a GUI. The newer Windows based OS (3.x) began "managing" resources and the new, but limited, "COMM.DRV" driver was introduced. Soon, the PIC was starved of its high speed connection resources. The DOS based device could not cope within this new "let's share" environment.
The COMM driver had to regularly switch over and back between real and protected mode, so this made it far too unreliable at high speed communications. Many companies had to rewrite the COMM driver as it was too slow for their serial devices' requirements.
ICOM, the original authors of WinLinx, rewrote the Windows serial port COMM driver to hand back the necessary resources to the PIC. I remember you had to edit the system.ini file "COMM.DRV=RHSICOM.DRV" to use the modified driver. So all was well again.
That was until Windows 95 arrived on the scene. Native DOS was all but dead now. It brought with it a whole new suite of communications improvements and enhancements. Remember all that email, fax, and online services that was starting to creep in. So again, ICOM (now Rockwell owned) had to set about rewriting the Windows 95 drivers. But this proved much more difficult with so many changes to the communications architecture and subsystem. It took many attempts before they finally released a relatively stable version. But the DOS based PIC still was not out of the oh so foreign woods just yet. Some of the communication enhancements that Windows 95 introduced also hindered the PIC. The VCOMM virtual comm port driver, that was supposed not to interfere with it's partner in the real world, did just that, on occasions. Also, newer power management options would tickle the com port periodically to see if it was awake, interrupting current transmissions through the PIC. Serial mouse drivers would now auto load on Windows startup for "convenience" should you require them, locking the serial port out from the PIC, and on and on.
But did they give up?
Where's the fun in that?...
Next there was the huge hurdle of the Hardware Abstraction Layer (HAL - "Just what do you think you're doing, Dave?") that was introduced with Windows NT. Applications and device drivers were now no longer allowed to deal with hardware directly and had to make calls to HAL routines to determine hardware specific information. This added back in unacceptable latency for the PIC's limited comms buffer. So once again, a lengthy journey was undertaken to rewrite NT's COMM driver. Even so, it had headaches. HAL must prime its routines during POST, so that meant the modified driver had to be loaded at BOOT. Making it unloadable until REBOOT. So once finished with the PIC, you had to REBOOT to free the COM port up for other applications.
Then came along Windows 2000 with a much improved HAL, yippee!...and yet again, the drawing board had to be wiped clean.
Eventually, Windows XP came on the scene and things became somewhat easier. There was little change with regard to the HAL and the PIC would work reasonably well. One advantage was that now you only had to delete the driver in Device Manager to free up the COM port, rather than have to REBOOT.
But the party was short lived. This hiatus lasted until Windows XP SP3 was released and the Serial Enumerator handler was updated, again making the PIC an outcast. "Serenum.sys" is an upper-level device filter driver that is used with a serial port function driver, namely "Serial.sys", to enumerate devices that are connected to a serial port. "Serial.sys" is the default provided function driver for serial devices, but any third party serial driver can be used in conjunction with Serenum.sys. The updates included changes in how the enumerator mapped COM ports to devices.
At last, a hurdle too high...
Between the protection issues instigated by Windows File Protection, which restores any modified protected system files, and the fact that the method used to mitigate said protection i.e. the replacing of Serenum.sys with the XP SP2 version, renders the serial port useless to all applications, but the PIC Driver - Rockwell threw in the towel and no longer pursued the, up until then, crazy, but somewhat commendable, path to keeping the 1747-PIC alive.
However, while the 1747-UIC might have appeared to be the direct successor to the 1747-PIC interface, this was not entirely the case. They both had there uses and relevance, at that time. Only computers running at or above Windows 95 circa 1998 supported USB v1.1 devices, which the UIC happens to be. Many 9-pin serial port only computers were still available to purchase and indeed in service running under older OS. So before, and indeed after Windows XP was released, the PIC was/is still required to support legacy computers that do not support USB. They could not, and did not "stop using (the PIC) about the same time XP came out". In fact, the 1747-PIC did not reach its Silver Series Date until 7/1/2008. Some seven years after Windows XP was first released.
God rest its well "driven" soul.
Regards,
George
GaryS
Member
Thank You Geospark
That was the best most complete explanation of the progression I have ever seen. Well put together.
In all my calls to tech support with both Rockwell and Microsoft neither would ever give me that detailed an explanation all they would say was it had to do with the com buffers and the delay in processing.
for the ML processors I started using the NET-ENI and works every time.
your explanation also explains why when I use a virtual PC. When I have to work on the PLC2's the communication is very slow compared to what it was under the old DOS or XP systems.
Thanks Again
That was the best most complete explanation of the progression I have ever seen. Well put together.
In all my calls to tech support with both Rockwell and Microsoft neither would ever give me that detailed an explanation all they would say was it had to do with the com buffers and the delay in processing.
for the ML processors I started using the NET-ENI and works every time.
your explanation also explains why when I use a virtual PC. When I have to work on the PLC2's the communication is very slow compared to what it was under the old DOS or XP systems.
Thanks Again
You are most welcome, but you did not really clarify the DF1/DH-485 situation with regard to the ENI?
This simply reiterates the original statement. Could you please just clarify that you intentionally started using DF1 Full Duplex with the ENI for MicroLogix controllers as an alternative to using the UIC with DH-485, and put to rest any notions I might have of some hocus pocus being at play here?
While I'm here...
The round RS-232 port on the 1761-NET-ENI is an 8 Pin Mini-Din, as is the default round serial port found on all of the MicroLogix controllers. The other available serial port found on the MicroLogix 1400 and MicroLogix 1500 LRP models is a 9 pin D-Shell, or standard DB9 serial port.
Note: You can only use the MicroLogix to power the ENI for non hazardous applications.
In Class I Division 2 applications, an External Class 2 power supply must be used.
This is another example of a slight mix up between RS Wiring Standards and Protocol Standards. Yes, you may see "RS232(DH485)" displayed in RSLinx. This simply denotes that RS-232 wiring is being used with devices configured for the DH-485 Protocol. You do not need to make the distinction that it is using the DH-485 Protocol, as this is the only Protocol mentioned here. The proper distinction, once again, is that RS-232 is a Wiring Standard and Data Highway 485 is a Protocol Standard.
Quiz Question...
We know what "DH" stands for in the DH-485 Protocol, but for the DF1 Protocol - what does the actual term "DF1" stand for?
Regards,
George
This simply reiterates the original statement. Could you please just clarify that you intentionally started using DF1 Full Duplex with the ENI for MicroLogix controllers as an alternative to using the UIC with DH-485, and put to rest any notions I might have of some hocus pocus being at play here?
While I'm here...
GaryS said:
The round RS-232 port on the 1761-NET-ENI is an 8 Pin Mini-Din, as is the default round serial port found on all of the MicroLogix controllers. The other available serial port found on the MicroLogix 1400 and MicroLogix 1500 LRP models is a 9 pin D-Shell, or standard DB9 serial port.
Note: You can only use the MicroLogix to power the ENI for non hazardous applications.
In Class I Division 2 applications, an External Class 2 power supply must be used.
This is another example of a slight mix up between RS Wiring Standards and Protocol Standards. Yes, you may see "RS232(DH485)" displayed in RSLinx. This simply denotes that RS-232 wiring is being used with devices configured for the DH-485 Protocol. You do not need to make the distinction that it is using the DH-485 Protocol, as this is the only Protocol mentioned here. The proper distinction, once again, is that RS-232 is a Wiring Standard and Data Highway 485 is a Protocol Standard.
Quiz Question...
We know what "DH" stands for in the DH-485 Protocol, but for the DF1 Protocol - what does the actual term "DF1" stand for?
Regards,
George
geniusintraining
Lifetime Supporting Member + Moderator
geniusintraining
Lifetime Supporting Member + Moderator
This is what I found... this manual is good if anyone is looking for information on DF1
DF1 protocol is an Allen-Bradley data-link layer protocol that
combines features of subcategories D1 (data transparency) and F1
(two-way simultaneous transmission with embedded responses)
http://literature.rockwellautomation.com/idc/groups/literature/documents/rm/1770-rm516_-en-p.pdf
geniusintraining
Lifetime Supporting Member + Moderator
git said:
Well you get 10/10 for effort and 10/10 for your answer, Mark. :nodi:
The Allen Bradley DF1 Protocol comprises the D1 and F1 command subset of ANSI/IEEE specification X 3.28. I am most certainly not in the mood to write an "essay" on that baby. The linked DF1 Protocol and Command Set Reference Manual, while somewhat dated now, is still the best resource for all things DF1.
Another issue I meant to address...
BCS said:
Mickey said:
RSLinx Classic, as we know, is primarily a communications application that allows you to configure the necessary drivers to communicate with devices. The GUI provides you access to configure the drivers and then test communications to your devices via RSWho. Once this initial testing is complete, RSLinx Classic is no longer required to be running as an application and can, as we know, even be set to run as a service in the background.
If you have successfully setup your driver and have established communications, then uncheck "Autobrowse" or close RSLinx Classic. You do not need to leave RSLinx Classic open with Autobrowse checked to establish the same communications through RSLogix 500/5000/Logix Designer. They will open another RSWho session themselves to do so. Leaving RSLinx Classic open and browsing the same driver you are then using through programming software will create more than one RSWho session to the device and will burden the ports traffic and Windows communications services. This can potentially cause timeouts issues.
G.
Last edited:
Similar Topics
se me desprendieron los cables del cable usb quiero soldarlos pero no se como van los cables si alquien me pudiera proporcionar una foto o como...
Hi again, so this new client has a SLC 5/02 with a DH485 port. I have the older white 1747-UIC adaptor, which I have only ever used for the RS232...
Hi Everybody!
Has anybody ever tried using the 1747-UIC (USB to DH-485) converter as a straight USB to RS-485 converter?
Since it present to the...
Hello
I will make it short and sweet. I need the cable that goes from the slc 501 to the 1747-UIC RJ-45 connection. From what I can find it...
Hey all, first time posting. I have gotten a lot of great info from all of you in the past. I have searched the forums and google as much as...