Colin Carpenter

Strictly speaking, you're in the wrong forum, as that code is almost certainly for the AB SLC5 range, I would have thought. However, the same rules apply in Mitsubishi code, for example: LD X0 PLS M0 LD M0 SET Y0 Would do a similar thing, where PLS is the Mitsubishi equivalent of the AB ONS command. Consider the following code: LD X0 SET Y0 LD X1 RST Y0 If both X0 and X1 are ON, (maybe they are external switches), then the programme is having to SET and RESET Y0 as both commands are true. So will Y0 be ON or OFF in practice? It all depends on which was the last command that the PLC executed, in other words, the order in which the code was written. As I've written it above, Output Y0 would be OFF if both X0 and X1 are ON. However, if the code was reversed, ie LD X1 RST Y0 LD X0 SET Y0 then Y0 would be ON if both X0 and X1 were ON. Confusing ain't it? So let's re-write it using the Mitsubishi PLS command (AB ONS) LD X0 PLS M0 LD M0 SET Y0 LD X1 PLS M1 LD M1 RST Y0 So now, what is the status of Y0 if both X0 and X1 are ON? Answer, you don't know just be looking at the code, it all depends on whether X0 or X1 came ON first, in other words it's time dependant. The PLS elements M0 and M1 will only be on for one cycle scan, and they will occur at the instant X0 and X1 respectively go ON. So, if X0 came on first, followed by X1, then Y0 will now be OFF. The opposite will also be true. Personally, I NEVER use SET or RST (OTL, OTU) with a PLS element (ONS) . Edit Note: I actually meant to say I ALWAYS use a PLS element when using SET or RST

You're welcome, Paul. I've been stuck in my own "DO" Loop more times than I care to remember

Have you tried moving the value of C252 to a register then adding 360 to it?

>>Lol, I laughed in empathy. If you have done much programming on different PLC's then sooner or later you are gonna scare yourself.<< Tell me about it This whole business is a scary business. You negotiate a 10 minute shut down of a busy plant, you do the mods and you just pray that the HMI or SCADA system or PLC is going to re-boot properly, because, if it doesn't, then the WHOLE WORLD will be looking at you .... the toe tappers will be tapping their toes, the MD will be on his way, the lawyers will be sharpening their pens, people with first class honours degrees in "Stating the bl**dy obvious" will be stating the bl**dy obvious and everybody and his dog will be be asking "When do you think it will be going again?", and when you say ""I don't know, I don't know what's wrong with it", they'll reply with "Well , when do you think it might be going again?" It can get to you if you let it .... met a programmer once who was "away with the fairies", because he was absolutely convinced that it was his presence in the room that was causing the PLC error light to come on. Honestly ........ and if I told you what his programme was controlling you wouldn't sleep easily at nights. But we still do it ...... probably for the adrenaline rush that's so addictive. Bungee jumping ..... that's child's play

Version control of software is, and always has been a major headache with MItsubishi PLCs. For me, the problems arise when I have a fully documented programme on my laptop, but the local site electrician has added some lines of code then disappeared without documenting the changes. So I walk up to the PLC, verify the programme in the PLC and find that it's different, so if I download any changes that I have been asked to make, then the programme won't include the changes that the electrician made .... bless his little cotton socks. In the days of DOS MEDOC, I used to upload the programme from the PLC into a new project in MEDOC, then print it to a text file, then print my documented code to a text file, strip out all the documentation and names using the brilliant "TextPad " (the only text editor I ever found that allows you to delete columns of text, not just rows), then compare the two text files with the also brilliant "Visual Difference" (no longer available), which was the only text file comparing software I ever found that was smart enough to notice where the text re-synchronised, so would show you line insertions and deletions, without highlighting every other line as being different. When I'd found the changes, I 'd then incorporate them in the documented code, download and feel fairly secure. Long winded, but accurate and would let you know what the electrician was trying to achieve. Now that I exclusively use IEC Developer, I don't know what you can do other than make sure that the electrician just can't get this hands on things without letting you know first.Because IEC compiles system variables with every re-build, (gives them new addresses) a programme can be identical in the graphical editor, but won't verify because the system addresses will be different. Scary the first time it happens. IEC will show you the differences after a verify, but there's gonna be an awful lot of address changes if it's been re-built. Rule of thumb says that if the number of lines are the same, and the only changes seem to be addesses in the system variable range, then it's probably the same ....... but only probably. Have to admit that the Allen Bradley "merge option" when you go online is a far better way of doing things. If someone has played with the programme since you last did, then the changes will merge into your documented programme as you go online ..... which can also be a bit scary!!

Just to say that I left the S/S terminal unconnected once and saw the wierdest things happen!! Inputs were coming on as and when they felt like it, including those that weren't even wired up. You have to make a choice and wire it ..... leaving it unwired is NOT an option.

It gets a little more like it when you use IEC Developer. In IEC Developer, there are 3 terms assigned to a normal timer, so, for Timer T0 there will be: TC0 ..... This is the "coil" of the timer, and when energised will commence timing. (Timer enable) TS0...... This is the "switch" of the timer (closes when the timer has timed out) (Timer done) TN0 ...... This is the current value of the timer timing to it's setpoint (Timer Timing) In GX Developer, the similarities are not so obvious. Presumably, you could use MOV T0 D0 (Move the current timer value to D0) to show the timer value in D0, but I've never tried it?

COM 0 is the common connection that feeds the voltage to the normally open relay contacts that Y0 operates. In other words, connect 24VDC+ to COM 0, then connect Y0 to one terminal of your light and the other terminal to 0VDC. Then operate the output and you should find it an illuminating experience ... assuming, of course, that your bulb is rated for 24 VDC.

I have an A1S68DAV, which gives me 8 channels of 0-10 volt ouputs. Anyone know of a cheap and simple way to convert a couple of those voltage outputs into 4-20 mAmp outputs? Just wondering......

In the IEC Developer manual it says that you can import GX Developer ASCII files, but you need to export from GX Developer using something called GX Converter. Warning ... it will only come in as a text file. You can import into graphics in GX IEC, but it's a bit convoluted. Check Mitsubishi (Germany) site for the tool to do it with.

If you're fluent in Corel Draw, then you will love Xara Xtreme. Transparencies, graduated fills .... the list is endless.

If you are using one of the Beijers range of HMIs, then it is very easy to store and retrieve data. Just setting up a trend in the HMI will automatically store data on the HMI in *.CSV format. You access the data through the serial port using the freely available HMI tools from Beijers. It's smart as well, the system only logs values when the values change, so it's good at reducing file sizes. Obviously the amount you can store is a function of the number of values and the frequency of storing and the memory size of the HMI ...... as always

Thanks, All. An A1S68DAI is about £650 list price, and I would need to convert all of them. Based on around £85 per channel, then there's not a lot of price difference, so the A1S68DAI is the obvious solution. I just wondered if anyone knew of an 8 channel version for around a couple of hundred pounds or so, but it seems like they don't exist. Thanks again.

I don't know .... hence the question

Beijers brought out E-View (as opposed to their HMI software E-Designer), which pretty much gave you and HMI screen running on a PC. Worked fine, though a little different to the HMI. Not sure if it's still available, but at the time it cose £1250 for a "dongled" runtime and development package ..... about the same price as an E700.

I'm currently working on a project that uses a Q2AS-S1 which has come with a Mitsubishi 1 MB memory card pre-installed. Never having used one before, what would be the normal use for such a thing? Data storage, programme backup?

Personally, I always found it harder to remember addresses when moving from Mitsubishi to Allen Bradley. I always found it easier to remember M100 than N57:5/0, especially regarding the syntax and the fact that there is more than one way of addressing the Allen Bradley bit. Makes my head spin on occasion. Interestingly, with IEC Developer and Control Logix, both software packages have now moved away from being address based and are now name based, where the names are assigned to addresses in a Global Variables part of the software, and meaningful names can now be applied to individual bits and data registers. Makes life a lot easier

That's a seriously old PLC, and you want to be really careful!! The old F and F2 series went out of production in the late 80's and were replaced by the FX range which had much more power and memory. Changing the battery is easy enough, and a capacitor normally holds the programme in place for a while, but I really wouldn't risk it without having a backup of the programme. To programme the PLC requires a special interface that Mitsubishi no longer make. It may be, however, that the F2 has an EEprom fitted that will hold the programme ad infinitum, in which case, don't worry about the battery. However, it's not possible to programme those EEproms from a laptop, instead, the RAM memory is programmed, then you use one of the old, obsolete, Mitsubishi graphic programmers to suck the programme out of RAM and blow it onto the EEprom. Makes me shudder to think about it ......

The way you do it is by using some software called a "Com port redirector". Install this on your laptop and it will set up virtual com ports so that they appear to be serial ports, but in fact are using the ethernet card to transfer data. The "market leader" is a company called Tactical Software, and their software does work well, though it's a little pricy at $100 per com port per laptop. I recently found a company that does one for free at http://www.wut.de/e-58135-11-inus-000.php3 though I have yet to be able to try the software. Should be able to do so in a few weeks time. It would be good to know if this software works OK. You also need to set up the E410 so that the transparent option is "hung" onto the ethernet card, not the serial port. You can download a 30 day trial version of the Tactical Software programme and try it, but I'd be really pleased to know if the free version works OK.

I think your best option would be the FX2N-232BD board. These are very cheap (about 60GBP) and set up a direct RS232 port into the the FX2N.Also, the board is very small and fits just to the left hand side of the programming port on the FX2N, so if space is an issue, you can still fit one.

Hmmm .... having realised a bit more the situation with File Registers and the overlap with the D registers, it does seem that you are stuck with the problem that you have exceeded the memory storage capacity of the FX2N. Afraid I've never used a GOT terminal, but I do know that Recipe storage is available in the Beijers range of E-Terminals, though whether the storage capablity extends to the large amount that you need to use, I just wouldn't know. The terminals have a certain amount of onboard memory and the larger ones can have memory expansion cards added. Either an FX3U or an external SCADA type system that can upload data into the FX2N registers might seem to be the only solutions available to you?

What happens when you lose power? As far as I know, the only battery backed registers in an FX2N are those from D200 to D511, so when the power goes off, don't you lose all the data in the other registers? How big is your programme? You can add an extra memory module to an FX2N to take it up to 16k steps, then you can elect to have those very secure file registers that take up some of the programme memory. I think that 1k steps equals 1000 file registers, but I've never had to use them, so am not too sure. Might be an option?

Interesting points you raise ..... I upgraded to IEC Developer V7 and the lastest E-Designer a couple of months ago, and here in the UK, there is absolutely no sign of any license protection. The CDs arrive in cases, you phone for a serial number and that's it. As far as I know, that serial number is always valid in the event of a re-install. I don't even think the new E_Designer even has a serial number, though I stand to be corrected on that. It's one of the reasons I've always preferred Mitsubishi to Allen Bradley ...... their approach to software upgrades was always so much more sensible and relaxed. It always seemed like their approach was to sell hardware rather make lots of money selling software, which, at the end of the day, could only be used to programme their hardware. Hope things aren't due to change dramatically over here .....

It's down to the time delays involved in the comms between the SCADA software and the PLC. Sometimes when it looks, it's on, sometimes it's not. It's surprising that even Developer is showing a regular pulse. As stated, use a counter or incremented data register to count the pulses and then read the register. Much better option. The Rule .... when using a PLC to count pulses (not hi speed counters), as long as the pulse duration is greater than the PLC cycle scan time, then you will catch all the pulses. If the pulse duration is less than the PLC cycle scan time, then you are gonna miss some of them ..... how many you miss depends on the difference between the pulse duration and the scan time.

In Mitsubishi speak, H stands for Hex, as does "16#" ...... just two different ways of saying the same thing. You need to know how to work out the Hex address of the card that you are interested in, and it all depends on where it is in the rack in relation to the other cards in the PLC. In general, all other cards take up either 16 or 32 (decimal) addresses, but in the programme code, it's always referred to as a Hex address. If the card is a 16 way input or output card, then it takes 16 addresses, 32 way input or output cards take 32 addresses and special cards (analogue in and out, comms, network etc.) almost always take 32 addresses. Example, say you had a PLC configured as shown below, the Hex addresses would be as shown alongside: Starting at the first slot (call it Slot 0) Slot 0 16 Outputs 16 addresses Starts @ H00 Ends @ H0F Slot 1 Special 32 addresses Starts @ H10 Ends @H2F Slot 2 32 inputs 32 addresses Starts @H30 Ends @H4F Slot 3 16 outputs 16 addresses Starts @ H50 Ends @H5F Slot 4 A1S68AD 32 addresses Starts @ H60 Ends @H7F The "start address" is known as the "head address". And so on, and so forth. As you add more racks, you just keep counting in Hex. Mitsubishi A and QnA CPUs can generally handle 256, 512 or 1024 (decimal) addresses 256 (H100) addresses is equivalent to 8 slots of "32 address cards" ( 1 complete rack) 512 (H200) addresses is equivalent to 16 slots of "32 address cards" (2 complete racks) 1024 (H400) addresses is equivalent to 32 slots of "32 address cards" (4 complete racks) Just to add a bit more complication, FX PLCs use Octal notation or inputs and outputs. They may be odd ...... but they're bomb proof.