nighthawk

I've looked at the serial configuration - tried it default, slower bauds, parity=none, odd. Only thing I haven't tried was even parity. How is your Serial Port Setup configured?

Hi Steve, RSLinx is not on this computer, but am aware of the issue you mentioned. LM 90 is version 9.04. I am able to comm with TI/Siemens using this laptop with no problems. Thanks for your reply. I can't think of any reason why it should not be working! Jimmy

Greetings All, I am also having problems Communicating with LM90 using XP. Tried the Win95 mode with no change. Am using default comms port settings and should be able to connect using the cable - AS693232SNP, which has built-in RS-232 converter and both LEDs blink. The laptop's comm port is known good. I am assuming the two PLCs I am trying have good ports, but that could be the problem. Any suggestions will be greatly appreciated. ~Jimmy

Thanks for the reply. I looked at the link -- it applies to non-enhanced PVs. The 1400e will not work with Panelbuilder 32 and I'm pretty sure the only way to update the firmware is the utility on the Panelbuilder 1400 disk. Yes, I'm sure a 32 MB card would hold the firmware, but that seems like overkill. If AB does not specify size of card for firmware storage, seems like any and all should work 256 to . After all, it is only the firmware, not a big application, right? AHHH!!! I just found my answer: I was looking in the User Manual for reference to card sizes and found under the specs that the PCMCIA card is used for PV1200 series F and above, "1.75 MB for firmware; application storage up to 2.25 MB for enhance F and above terminals." That's some BIG FIRMWARE!

I tried loading the firmware for a PV1400e from the Panelview Firmware Utility to a PCMCIA card (2711-NM12 - 1MB Memory Card) and it failed saying "Error 11: The memory is not large enough to hold the new firmware. Use a PCMCIA card with larger memory." It seems that 1meg should be big enough for firmware, but I guess not. Does anyone know what size of card I need for the firmware?

Hi Ken, Many thanks for the reply. The firmware did install via serial to the terminal. Oddly it failed to download from a PC, but using my laptop it worked. Same PC works fine with RSLinx serial and other serial. The error occurred when it was clearing memory of the terminal and same for the card. I will try the suggestion for clearing the card's memory. That sounds like a good idea. New LCD screens on the 1400e would look good!

Problem solved! I had a scrap unit with good keypad membrane, which was the culprit. Of course, the "Operator Quit Acknowledged" should have said "Set the DIP switches, Dip!".

Hi, The DTAM does not respond to any keypad entries. I tried reloading firmware but the unit will not communicate - comes back saying "Operator Quit Acknowledged". I'm guessing it's little brains are fried. Anybody out there ever seen this? Jimmy

Sounds to me like one of the Comms driver ICs has failed. I would say you need a repair. That's my job. Jimmy

Two issues regarding a problem with a 1747-L20C. It had been pulled from scrap with no firmware IC. I had an L20D and so decided to try and see if that firmware would work. When trying to copy a program configured for the L20C, RSLogix 500 says "Downloading Program - (TEST) for 1747-L20C/F ... to (DEFAULT) 1747-L20A... This would indicate that the firmware made the processor think it was a 1747-L20A, yet it works in the L20D. Regarding programming, I'm in a catch-22 situation. Attempting to program the 1747-L20C using a 1747-PIC and RSLogix 500, RSLinx sees the processor as a SLC500 with no problems. Memory was reset to default on the L20C, so when trying Who Active Go Online, I get a window saying "Corrupted Processor". If I try downloading to the L20C, I get the message about it being an L20A, asking if I want to procede with the download. I answer YES, and then get "Download Failed! - Communication Errors!" So, as you can see, it won't go online while only having the default program and won't accept a download while being corrupt, therefore there is no way to go online and clear faults or anything. The RSLogix 500 program definitely supports the 1747 processors as they are all listed in the selection under Controller Properties - so I don't think it is an issue requiring upgrade of software. I did ask the AB distrib if they can supply a new firmware IC for my L20C, but have not heard back from them yet. So, I am confused, my software is confused and my processor is confused. Please, if anyone out there is NOT confused, maybe I can get this to work - or maybe not. Any help is greatly appreciated James C. Williams

Thanks Ken. I found that my communication problem was largely due to a conflict of a change in motherboard/RAM and my 1747-PIC. I switched to using the PCMK driver for DH485 and had no problem logging onto the L20D and programmed it fine. Maybe my PIC was pic-ky about only using 80MB of RAM running W2K. Jury is still out on the firmware. If you look at the cases of both L20D and L20C they both say FRN 6. I will be spending some more time on this and will come back with what I find for future reference. ~JCW

________________________________________________________________ Wow! So far you've gotten several replies with lots of heavy tecnobabble! By now you have either gone through several bottles of ibuprofen (or stronger!), or you may have done the smart thing and made the job someone elses headache. Just to verify, the above information is correct - you do need a SLC5/05 processor; however, Panelbuilder 32 works with the PV600 - don't know about Plus. That's about all the help I have to offer, other than meditation and medication. NEVER GO TO RADIO SHACK!!! Order whatever you might buy from them online, from anyone else (rant suppressed). I'm currently undergoing my own grueling self-education on ethernet, attempting to test a PV600. Anyone else have any advice for a simple test?

Seems like since the 600 and the 1000 have same comms ports (232 and RIO) the setup should be the same.

Am FRUSTRATED, trying to download an application from PanelBuilder 32 (ver 3.71) to a PanelView 1000 (Cat# 2711-T10G8, Ser D), using RS-232 (from real port). PB32 uses PFTSERV.DLL and PVDF1F32.DLL as it's communication panel. The printer terminal is disabled on the PV. Cable, serial port and software verified good by up/downloading to/from PV600 with no problems. When downloading to the PV, PB32 shows that it is starting the download, as does the terminal. Both show the process get to 3% (512 bytes of 14522 transferred) and stop. Terminal displays "File not supported"; software displays "Application file is incompatible type", then gives error 4091. Also will not upload the original program residing in the terminal. I'm trying to download an application modified from a PV900 to work on the 1000. It worked fine with the 900. I actually have two PV1000s and both do the same, so am doubtful of it being a firmware issue (one has earlier firmware, the other more recent). Am I just not holding my tongue right? Are the planets aligned in such a way to screw up communication? Do I need to throw it in the pond? Any suggestions? Thanks, Jimmy

Thanks, will look into the flashcard -- I think I have one around here somewhere. Most of what I do is small test programs, since I am only repairing this stuff. I am wondering about the firmware, but can't find a place to download. AB seems to not suppport PV1000 firmware except to buy a CD from them.

Hi Steve, am guessing you solved your prblm. Am slogging through a similar problem with a PV1000, RSLinx and PB32, all old versions. RSLinx autoconfigs DF1 fine on the com1 port, and shows the PV1000. When I try to download to the PV, I get an Error 4091 on PB32 and the PV displays a File not compatible message. I also tried the trick of configing RSLinx with the PIC/AIC driver, but it didn't see the PV. Only RS232 DF1 works. Am suspecting I need updated software.

So, what version of panelbuilder 32 is that? I have older version that has no screen like that.

So, you bought a piece of software and have to have it to support a bunch of equipment, spending a lot of money along the way. It works great! You have lots of programs written for your equipment and they all run fantastic. Then one day, the computer that this software is on has a problem. You buy a new computer and go to put the software on it so you can continue to use this equipment and the programs you wrote for it, but guess what -- the software has problems running on the new computer. You contact the manufacturer and they will be happy to solve your problems by selling you a SERVICE CONTRACT, enabling you to download an update for the original software, without which you cannot use your software. You now see my current dilemma with Rockwell Automation and you may understand my being more than a little upset with them. This software was not cheap. It was legally purchased directly from them and is legally registered, but that amounts to zilch. They want us to have to keep paying for the software, now that we have made the commitment to their equipment and are depending on them for support. Let's see, there is a saying about how crack pipes are cheap... I am hoping that some great legislator comes along and passes a bill making it unlawful to require software developers to force people to have to continue paying for something years after they paid good money for it. No wonder so much software bootlegging happens on a huge scale when this is the norm. I am also hoping that industries start turning away from Rockwell Automation and going to some of their competition that is more customer oriented. Maybe when this starts happening and Rockwell starts laying off their tech support to keep afloat, there will be some change in the way these lumbering giants provide technical support for a price. Crash and burn, Rockwell!!! Jimmy Williams, Greensboro, NC PS - if you work for Rockwell, you should look for another job! Good luck!!! PPS - I will be installing my software on a PC running Win98.

So, how many of you guys work for Rockwell? Now I know how Micheal Moore felt at the Republican Convention! That's fine, I can put up or shut up. Something that I see in common with many of you in favor of paying for support contracts is that you are working for larger companies. I agree with the above point and cannot dispute the value of that support when your production is stopped and operating losses soar - in that case, support is priceless. If you consider my position, though, you might better understand my reason for feeling the way I do. I work for a very small repair shop with less than 10 employees. We don't do programming, only repairs. As I stated previously, competition for repairs is astoundingly complex and the profit margins aren't nearly as lucrative as you might think. The first PLC shop I worked for had bootlegged nearly all of their software. My current employer has purchased liscensed software. This expense is very large for such a small business, but not such a concern to larger corperations that employ hundreds. My time is valuable and I wish I could pick up the phone and ask someone how to program some of this stuff, but I also know that it would be a bigger waste of time for me to ask my employer to consider a support contract. It would never happen. Those of you who have always had that sort of support should consider yourselves very fortunate. I had a lot more hair before I started working on PLCs! I appreciate having learned other peoples opinions about this issue, and have learned a few things about some of the folks I am repairing this stuff for. You folks in maintenance have tough jobs and need the support Rockwell offers, no doubt! Maybe knowing a little more about my environment gives you folks a different perspective on my position. Jimmy PS - now would be a good time for some other techs working for Mom & Pops to give their 2 cents!

Okay, so I stirred up the hornet's nest! It disturbs me that so many of you are going along with the idea that the cost of Rockwell's "support" is worth it. Just ponder this: if your company had not paid so much for technical support, software, etc. you might have gotten more of a raise. Or, that the cost might not have been passed onto the consumer. Everything is connected, so one wrong begets another (just look at the White House). I am not new to AB, Reliance, TI/Siemens, GE/Fanuc or the rest, as I have been repairing their equipment over the past 7 years. That's right, I am not an end user, I'm one of those good guys out there giving the equipment a new lease on life so that your company doesn't have to spend $100K to retool the plant. The business of industrial repair is insanely competitive because companies can't afford to spend that fortune, being that most of them are about to go out of business due to rising costs and overseas competition. We do everything possible to keep our costs down so we can keep a reasonable profit margin while giving the highest quality of repair possible - and free tech support to our customers. That's a very tiny tightrope to walk in this economy! So, when I complain about the cost of getting an update to a piece of software, I'm not doing so because I have a chip on my shoulder. BTW, I think all auto manufacturers have had to do numerous free upgrades to their systems - they are called recalls. And most recalls probably had to do with equipment manufacturing flaws that resulted from a problem on the production line when an AB PLC failed. Keep it coming, this is good! Jimmy

Re: Mikey's cool pics from RSLogix 500. I'm currently working my way through testing a NT8 module in for repair. The info I have found is that that last configuration screen Mikey provided is from a more recent version of RSLogix 500. My version is 5.20. Our registration with AB was done by someone who no longer works here, so we have no way of downloading the update aside from paying for the program again, which ain't gonna happen. AB makes nothing easy. If someone could provide configuration words to test the channels for J-type inputs, a tremendous amount of good karma would be your reward. Jimmy