Allen-Bradley Woes
Today was a lousy day with regards to progress on my current project for work. I'm working on getting a small telemetry system up and running for a drinking water association in the rural part of the state. The equipment we use is Allen-Bradley MicroLogix 1000 and SLC 5/05 PLCs and Dataradio Integra-TR radio modems.
So the day starts with Ethernet communication problems between my laptop and the SLC 5/05. As it turns out (even though the controller was configured off-line to be Auto-Negotiating at 10/100 MBps Full/Half Duplex) that the on-line settings had changed to 10 MBps Half Duplex Fixed. The help files said to look for the firmware revision on the Ethernet daughterboard on the controller, but there was no label on the board to tell.
I then called our local Allen-Bradley distributor North Coast Electric Company to ask their tech support guy(s) where to find the firmware revision number. As it turns out everyone with any knowledge of the product was either teaching a class, or out of the office, so I was refered to their Seattle office. I called and heard that the guy I need to talk to is also out of the office, but I can talk to someone that might know the answer.
I had just started to describe the problem to him when my cellphone battery dies with something of a three-second Low Battery warning (the P.O.S.!). A couple minutes later I had found a land-line telephone and called him back. This time I was connected to the receptionist who paged him for me. He didn't respond to her repeated pages so I called the cellphone of the guy who was out of the office, only to be connected to his voice-mail.
Finally, with frustration building, I called factory tech support. The guy there tells me where I can find it in the system status data file and that it is the same as the controller operating system revision number. So I thank him and walk back to the test bench to check. Well, he was wrong. It is not the same revision as the operating system but it is to be found in the spot he told me to look.
With the Ethernet problem solved I planned to go full-steam ahead on the radio communications part. I configured the radios without a glitch and setup the controller for a master-slave half duplex network (per factory recommendations).
On a side note: Yesterday I found a little glitch with setting up the communications port on the MicroLogix controller. The offline configuration allows you to only set up the Baud rate and the station number. Then, after downloading the configuration to the controller I lost communications between my laptop and the controller. As it turns out, the controller configuration defaults to the CRC error checking protocol whereas the laptop communications driver defaults to BCC error checking. The problem is that you can only change the controller settings on-line!!! Off-line you are not given the opportunity to change the error checking scheme. Somewhat of a Catch-22.
Back to the issues of today. My Ethernet is working and the radio modems look to be in good shape. But the messages are not coming across. So I call factory tech support again. The first-tier guy I talk to runs me through a couple simple checks, all of which fail, so he brings in a second-tier guy. I spend over an hour on the phone with him and he decides to duplicate my control network on his test bench and call me back.
About an hour later he calls me back and says that his network has no problems. But he concedes that his laptop cannot talk to his controller (just like mine) even though it should, but luckily we still have the Ethernet connection up and running so we are able to make changes on-line. He then calls in a third-tier guy to help solve the problem.
While this guy is reading up on some material I find a polling list setting in one of the configuration screens that have the factory default values in them. Two settings called Priority High and Priority Low are set for 0 and 255 respectively. I ask the third-tier guy if these numbers should be reversed (High set to 255 and Low set to 0). He dismisses this as the cause of the problem and continues to read the documentation.
While I wait for him to finish reading I decide to play with these two numbers. Lo and behold! After setting High to 255 and Low to 0 the system works like a charm and my communications network is finally passing data across.
By then it was after noon and I hadn't really progressed much since I started in the morning. Over two hours in phone calls to tech support plus waiting time for them to duplicate my system.
Granted, I'm an idiot for not finding these settings ad playing with them sooner, but come on!?! Why would the factory defaults be set to prevent communications? And why would a third-tier guy dismiss this as the cause of the problems?
Anyways, I got this off my chest.
Doei!
So the day starts with Ethernet communication problems between my laptop and the SLC 5/05. As it turns out (even though the controller was configured off-line to be Auto-Negotiating at 10/100 MBps Full/Half Duplex) that the on-line settings had changed to 10 MBps Half Duplex Fixed. The help files said to look for the firmware revision on the Ethernet daughterboard on the controller, but there was no label on the board to tell.
I then called our local Allen-Bradley distributor North Coast Electric Company to ask their tech support guy(s) where to find the firmware revision number. As it turns out everyone with any knowledge of the product was either teaching a class, or out of the office, so I was refered to their Seattle office. I called and heard that the guy I need to talk to is also out of the office, but I can talk to someone that might know the answer.
I had just started to describe the problem to him when my cellphone battery dies with something of a three-second Low Battery warning (the P.O.S.!). A couple minutes later I had found a land-line telephone and called him back. This time I was connected to the receptionist who paged him for me. He didn't respond to her repeated pages so I called the cellphone of the guy who was out of the office, only to be connected to his voice-mail.
Finally, with frustration building, I called factory tech support. The guy there tells me where I can find it in the system status data file and that it is the same as the controller operating system revision number. So I thank him and walk back to the test bench to check. Well, he was wrong. It is not the same revision as the operating system but it is to be found in the spot he told me to look.
With the Ethernet problem solved I planned to go full-steam ahead on the radio communications part. I configured the radios without a glitch and setup the controller for a master-slave half duplex network (per factory recommendations).
On a side note: Yesterday I found a little glitch with setting up the communications port on the MicroLogix controller. The offline configuration allows you to only set up the Baud rate and the station number. Then, after downloading the configuration to the controller I lost communications between my laptop and the controller. As it turns out, the controller configuration defaults to the CRC error checking protocol whereas the laptop communications driver defaults to BCC error checking. The problem is that you can only change the controller settings on-line!!! Off-line you are not given the opportunity to change the error checking scheme. Somewhat of a Catch-22.
Back to the issues of today. My Ethernet is working and the radio modems look to be in good shape. But the messages are not coming across. So I call factory tech support again. The first-tier guy I talk to runs me through a couple simple checks, all of which fail, so he brings in a second-tier guy. I spend over an hour on the phone with him and he decides to duplicate my control network on his test bench and call me back.
About an hour later he calls me back and says that his network has no problems. But he concedes that his laptop cannot talk to his controller (just like mine) even though it should, but luckily we still have the Ethernet connection up and running so we are able to make changes on-line. He then calls in a third-tier guy to help solve the problem.
While this guy is reading up on some material I find a polling list setting in one of the configuration screens that have the factory default values in them. Two settings called Priority High and Priority Low are set for 0 and 255 respectively. I ask the third-tier guy if these numbers should be reversed (High set to 255 and Low set to 0). He dismisses this as the cause of the problem and continues to read the documentation.
While I wait for him to finish reading I decide to play with these two numbers. Lo and behold! After setting High to 255 and Low to 0 the system works like a charm and my communications network is finally passing data across.
By then it was after noon and I hadn't really progressed much since I started in the morning. Over two hours in phone calls to tech support plus waiting time for them to duplicate my system.
Granted, I'm an idiot for not finding these settings ad playing with them sooner, but come on!?! Why would the factory defaults be set to prevent communications? And why would a third-tier guy dismiss this as the cause of the problems?
Anyways, I got this off my chest.
Doei!
0 Comments:
Post a Comment
<< Home