Colin Carpenter

Have recently purchased a large stainless panel which includes a "no longer required" Control Logix PLC. This system was installed around the year 2000 (I believe) and was the control system behind a large, very complicated filling machine in the food processing industry. The machine never really worked, and was "scrapped" a couple of years ago. The PLC has sat in the control panel in a warm, dry electrical switch room until now. The 10 servo channels were "mated" to 10 SEW Eurodrive Servo Motor control units, which are also in very good condition (same panel) and are also available, though I must admit to knowing very little about servo drives. Anybody interested? The PLC contains the following components: 1 off 1756 - A10/A 10 Slot Rack 1 off 1756 - PA72/B Power Supply 1 off 1756 - L1/A (Logix 5550 Processor Unit) Cat Rev H01. Part No. 96350471 A01 . F/W Rev 3.29. Series A 1 off 1756-M2/A (1MB Memory Expansion) Cat Rev. A01. Part No. 96160872 A01 5 off 1756-M02AE/A (2 Axis Servo Modules) Part No. 90801702 B01 Series A F/W Rev 1.6 1 off 1756 - DHRIO/B (DH+/RIO Comms Interface) Part Number 96308273 A01 Series B F/W Rev 2.17 2 off 1794-ASB (Flex IO Modules) Part No. 96333271 Rev A01 F/W Rev A 5 off 1794 - OB16 Flex Output Modules 5 off 1794 - IB16 - 24VDC Sink Input Flex Modules

You need to set them up in the software. Tell the analogue units whether they will be current or voltage, then read and write the information to the analogue units. It's pretty standard stuff, if you know the part numbers of the analogue blocks.

Yes, I pretty much agree with all the observations. If I was buying second user parts, I wouldn't want to pay much more than 20% of list value (unless the item was brand new, current and still in the packaging). Guess that kinda sums it up really .....

Geez ..... just looked up the price of all this lot in the catalogue and nearly fell over backwards!! How do they get away with charging this much???? By my reckoning, the new price of all this, based on a price list I had from a couple of years ago equates to a grand total of £9,374, or based on 1.7US dollars to the pound, $15,936. It's the servo modules that bump the price up, selling for a staggering £985 each. Question is, what % of the new price is second hand stuff worth? E-Mail me if you like, I won't be offended ......

If anyone's interested, the details are now in the "For Sale" Forum. Thanks

Can anyone tell me if there's much of a market for second user Control Logix PLCs? Reason for asking is that we have just purchased a large control panel complete with a "no longer required" Control Logix Rack, PLC and various cards. Firmware version is V7 I believe. Is E-Bay the best option to move these things?

Sounds like your 16 A series PLCs are pretty old. If that is the case, then I'd be tempted to dig out a copy of DOS Medoc as this will almost certainly talk to those old PLCs and do the initial code and name list work in DOS Medoc, for the following reason. IEC developer works in a different way to DOS Medoc, in that it is "Name" based programming as opposed to "Address" based programming. To cut a long story short, upload programmes from PLCs using DOS MEDOC. Edit the Name Lists as far as you can in DOS MEDOC, then export to IEC (easily done) then convert to graphics. Trust me, you'll save a lot of headaches doing it this way, because at the end of the day, you'll end up with IEC graphical code using Names not Addresses. Also, there is a magic utility for comparing text files showing differences between them , then re-synchronising, which is much easier to work with using MEDOC print files. Another tip .... ask the original guy how much he wants to let you have all the software versions that he probably still has somewhere

Thanks Lads, will work out all the part numbers and let you know. Didn't realise there was a "For Sale" section ..... you learn something every day

From Win98, make yourself a Boot Disc (floppy) and boot the PC to the floppy. This should ensure that you have a very basic DOS loaded. Then change to the C Drive and the Medoc directory, then try again. This will ensure that you are accessing the COM port directly from DOS and that there are no other Windows drivers pinching the port without you knowing. If that doesn't work, then you have to assume that there is a physical problem with the COM port(s). I have known a COM port on a laptop that "used to work", but now doesn't, even though Windows shows that it's all fine and configured OK. Pretty sure that Windows talks to the UART chip on the COM port only. It just maybe that modern PCs come with only some of the pins wired for the COM ports ..... I've certainly seen it with parallel ports that way .... but must admit that that's clutching at straws a bit

In numerous years of programming Mitsubishis I have never come across any which had lost comms from their CPU ports. I've known a couple of very old ones in harsh environments that needed a squirt of WD40 on the comms pins to get things going, but have never known any actually lose their comms, so, based on that principle, it's probably related to the PC end. Have just set up a project in MEDOC for an FX0/FX0S and the comms settings should be 9600,7,EVEN,1 STATION 0, which are the default settings for that particular PLC. Does your MEDOC show the same settings under transfer? What software are you running on the PCs. XP doesn't have a true DOS environment, whereas Win98 (and anything before) does. Try and find a PC which you can boot to "pure" DOS and try that. Check on the PCs that the serial port (s) are enabled in the Bios. Look for the settings of the interrupt and memory address on the COM ports. See if the com ports are working by, for example, plugging in a serial mouse and seeing if anything is recognised. See if you can find a laplink serial cable and connect the serial ports together on two PCs and see if they can talk to each other. When faced with a problem like this, eliminate what you can, and what's left must be the problem. Never assume ........

You've got a problem if you don't have the original files that the previous incumbent used to programme the PLCs with. Make very effort to try and track them down and save yourself a vast amount of work. Key thing is that regardless of the programming software, the PLC works in instruction mode and it has no idea what is connected to it's inputs or outputs. The only thing it needs to know is the instruction code and that's the only thing you will normally get out of it when uploading the programme. There is the ability to also store comments on certain PLCs, but in general, it tends not to be used as the comments take up memory space in the PLC and reduce the amount of memory left for instructions. There is a free utility which can be used to convert instruction code in IEC into graphical (ladder) format. It comes on the IEC Developer CD, or, can be downloaded from the Mitsubishi (German) website. It works pretty well, but still needs a lot of tidying and re-arranging afterwards. It also has the ability to change DOS MEDOC and GX Developer programmes into IEC graphical projects. However, without the comments, name lists etc of the original projects, the only thing you are going to get is a non commented, ADDRESS ONLY programme ..... because that's the only thing that the PLC knows and needs to know to be able to work. Be aware that even when working in graphical (ladder) mode in IEC, when you "build" the project, you are effectively creating an Instruction List programme which will be downloaded to the PLC. Nothing more, nothing less ...... Good luck ..... you're gonna need it.

I can never seem to work out if it's OK or not to do this, for example: LD X0 PLS M0 LD M0 INCP D0 I seem to get strange (unpredictable) results if I use a pulsed memory address to operate another instruction with "P" appended to it. Obviously it's easy to get round ..... LD X0 PLS M0 LD M0 INC D0 works fine, as does LD X0 INCP D0 Anyone know what the "official" line on using one pulse to drive another is? No real reason why I would want to do it, but can't really think of a reason why it shouldn't be done. Just curious .....

>>Like you can 'pulse' a coil but by mistake put the bit of that coil on a line before that coil and sometimes it works - sometimes not.<< Interesting .... could you write a bit of instruction code to show me exactly what you mean? Maybe this is the clue to the inconsistencies that I seem to get.

Thanks, I guess it must just be me. It's always been one of those things that lurk in my far distant memory from when I was starting to programme PLCs and didn't REALLY understand all the bits and bobs. "Never pulse a pulse" - just seems like one of those "old wive's tales" that are based on something factual but aren't neccessarily true all the time. It's still one of the things I'll look for and change if I'm trying to find a bug in the programme, even though, I have to agree with you and say that there is no logical reason why it shouldn't work Old habits die hard .... just like old superstitions.

Pierre's right .... had a quick look and it seems that you can view at least 128 data registers in that one window. All those years and I never discovered it ................ you learn something every day

What software is your friend going to use to programme the FX with? How many data registers do you want to collect each time? Reason for asking is that the programming software might just be the best way to interrogate the FX .... just go on line, and read the values in the data registers and write them down with pen and paper. Long winded, but cheap. IEC developer has a DEVICE EDIT function that allows ranges of data registers to be read from the PLC and exported to spreadsheet .... much quicker for large numbers. DOS MEDOC will just display them. Not sure what GX developer does, but would imagine it has a similar function to IEC Developer. Failing that most of the Beijers "E-Terminal" HMIs have the ability to not only interrogate D registers, but, by setting up trends on the screens, will actually save "time and date stamped values" into CSV files which can be read from the HMI using the freely available HMI tools software. Comms from PC to FX are normally RS232 at the PC and RS422/485 at the FX .... and a bit specialised / odd so that a Mitsubishi converter lead is normally needed, or failing that, a Beijers HMI does exactly the same comms conversion for you.

Normally go for relays unless there's a lot of high speed switching of low currents to be done. For example, I often use a small, cheap member of the FX family as a "pulse width magnifier" or pulse catcher for larger A or QnA PLCs .... easier than buying dedicated hi speed counter cards or messing with interrupts, so would tend to use transistor outputs here. Although most relay outputs are rated at 2 amps, if it's much more than 0.5 amps and is switching quite often, would tend to use interfacing relays, or at least fit flyback diodes if switching DC voltages. Anything above 1 amp, and I would definitely use an interfacing relay. Sparks eat contacts over time.

In E-Designer, under SETUP/ PERIPHERALS do you get something like this? The RS232 setup port is shown by selecting, then clicking EDIT The KEY point is that TRANSPARENT MODE is "hung" onto the RS232 port

You set up transparent mode in the software that you programme the E-Terminal with, not the PLC programming software. Assuming that you are using a version of E-Designer, it's a case of making sure that the "transparent" option is hung onto the RS232 port in SETUP / PERIPHERALS .... or failing that, you can do it by going into SETUP mode on the HMI (two key presses together) and using the scroll keys to go to the right section. Much easier in the software.....

You can happily force outputs ON as long as the PLC is not in the RUN position. I often do this to test the wiring prior to running the programme. Failing that, as others have said, you can include, if you want to, an extra M coil in parallel with the normal code that drives the output. This M coil will not be referenced by the programme, only by the programming software (or HMI if you want a "manual" facility).

>>This interface offers a web server capability which we intend to use to remotely monitor machine status and for debugging.<< I've used the Web Server facility built into the excellent Beijers range of E Terminals and it works well. It is also easy to fit an ethernet adapter to the E series or use one of the newer range (yet to try one) which comes with ethernet built in. As long as there is a driver for Ethernet CompactLogix comms, it would work well. As Mitsubishi distribute the Beijers range in the UK, it's not well know that they can talk to most other manufacturer's PLCs. Top kit, top software. Just a thought .....

One of the big differences between Mitsubishi and Allen Bradley programming is in the handling of data tables when transferring programmes to or from the CPU. In the Mitsubishi world, if I transfer a new programme to the CPU, then whatever values are currently residing in the data registers, stay there. In other words, the programme only transfers the programme and nothing else. Using RS Logix 500, if I transfer a programme to or from an SLC5/05, then the values in the data tables are transferred along with the programme. This is fine when transferring FROM the CPU, but can cause a problem when transferring TO the CPU in the event of replacing the programme with an older back up version. Question is: Can I elect not to transfer data table values? I have a feeling this is a pretty simple question ...... but I don't currently know the answer.

Hmmm .... there is a tag upload / download tool on the AB site which claims to work on all Allen Bradley PLCs .... SLC, Control Logix etc., etc. Link is: www.software.rockwell.com/support/download/detail.cfm?ID=2788 Not sure whether it needs a specific version of RS Linx though as I don't have an easily accesible SLC to play with at the moment. Interesting ......

Mitsubishi sell a conversion adaptor that enables an FX-4AD (or any old FX expansion blocks) to connect to an FX2N PLC, but I've never really been able to work out if the converter works the other way round - in other words, is it possible to to connect an FX2N-4AD to a FX PLC. Anybody know?

As far as I can see, you will open the damper with a signal that is proportional to the difference between your Set Point and your Process Value? This will "kind of" work, but what you will probably find is that the system achieves a "Balance Point" and just stays there. In other words, there will be an "equilibrium" state where the position of the damper is just sufficient to achieve NO change in the the PV. At this point, the system will "hold" - as no change in (SP-PV) results in no change in damper position (which means no change in (SP-PV) and so on. Thus, you will always have an offset from your setpoint, the offset being a function of the mechanical design of the plant and the way you scale the damper analogue output. A true PID block (often only using P and I, not D) will actually remove the offset and "land" on the set point. PID blocks are very easy to use in FX2N and FX3U PLCs, but needs a bit of head scratching in A and QnA PLCs. Not sure if "supllied" PID function blocks have made it to the Q range just yet.