Colin Carpenter

I certainly am. It's a small World isn't it? Don't recall anyone looking like a redfootballfish though!

I'm always nice to the maintenance men, in fact I'm so nice to them that they occasionally let me buy them beers at Christmas!! Seriously though, I take your point about ease of fault finding. I always reckon that if someone else has to take a laptop to one of my PLCs, then I haven't done the job properly. If there truly is a bug in the code, then tell me and I'll fix it. Guaranteed. I always use the Beijers range of HMIs as default, and spend ages programming screens to tell the maintenance man what's wrong. The Mitsubishi PLCs are "bomb-proof", and in 20 years or so, I have NEVER known one fail or get its programme corrupted. I've known a few relay contacts burning out due to over use or over current, but that's about it. Mind you, they don't like water ..... just keep them dry. I use 0-20 mA analogue inputs to sense 4-20 mA sensors, so I can tell when they fail. I set up screens so that outputs can be switched on for testing, I write routines to check that motors are available, haven't tripped and don't have failed contactors. I give valves time to move between sensors, then alarm if they don't. I have huge alarm lists telling the operator if anything is untoward. Honestly, maintenance wise, I've been there and bought the T shirt. I've cursed programmers who write with no structure and even fewer comments in the documentation, panel builders who don't ground the 0VDC of the power supply, and companies who build machines in NPN mode not the more easily understood PNP mode (though that's a personal opinion, not necessarily a scientific one). On the other hand, if I bought a nice M series BMW, I don't somehow think they'd supply me with the source code for the engine management system if I asked nicely.......?

Thanks for the reasoned comments, lads. In 20 years of programming, I've never ever considered password protection, and I've always encouraged the maintenance men to be as familiar with the software as possible (within reason). The main reason is that I'm not over keen on getting panic phone calls in the middle of the night asking me to travel hundreds of miles to a site that has a PLC problem. Trust me, I'm with you all the way on that one. Having said that, all of those jobs were "one offs" ..... specifically designed for that piece of plant and very specific to that site. No problem with me leaving the fully commented code at all. This latest project we have developed is a "skid mounted", "plug and play" system that "does what is says on the tin". The FX2N uses FP maths to continuously solve simultaneous equations and executes triple PID loops to control to very fine tolerances. Sure, someone else could programme it better, maybe a good copy would be better than the original, maybe the maintenance guys could make a much better job........ etc., etc. but at this point in time, no one has. The PLC and HMI software is all part of the overall package. The overall package is a combination of "off the shelf" bits. Anyone could buy the "off the shelf" bits and knock up one of these machines, but, without the software, it wouldn't do what it was supposed to. That was what prompted my original question. If we sold one of these units to a multi national company with many sites, what's to stop them buying the bits, sucking out the HMI and PLC code for free and making one for each of their sites? Who owns the code in this case? Me or them?

Thanks for the reasoned reply. Yes, it would be marketed directly at the target industry, and I think the risk is fairly minimal given the password protection available. I believe that if I've produced a system that requires maintenance guys to have to access the source code, then I've not done the job properly. I tend to agree that the password protection is probably adequate in most cases, I just wondered if there was a more secure means. Maybe an encrypted EEPROM or harware interlock or something along those lines. What is the general feeling regarding ownership of PLC programmes? For example, if you are paid to produce code for a "one off" machine, does the company that paid you have the right to build more machines and just use the source code over and over again with no further payment to you? It certainly doesn't happen that way in the most of the commercial desktop PC world (maybe Linux is an exception).... what is the generally accepted view in the Automation world?

OK, let's assume that you've spent a lot of your own time, your own money and your own brain cells, and at the end of it, you've produced a system that does what a lot of people thought couldn't be done, through a combination of smart software and clever mechanical / electrical design. The mechanical / electrical design is easy to copy, and so is the software by anyone with a bit of Mitsubishi knowledge. Patents probably aren't applicable, or, even if they are, would probably take too much time, money and legal expenses. So you want to market it, sell a few and make back a bit of the investment that you've made in the project? How do you protect the software? Or do you give it away to all and sundry? My name is not Bill Gates. I have a mortgage, wife and kids. They like to eat and keep warm. It concentrates the mind.

The attached text file is a MEDOC listing that reads the pulses from a shaft encoder into X0 and X1 (Phase A and B) and uses high speed counter C246 for Phase A. You need to know the relationships between the high speed counter inputs and the high speed counters for your particular PLC. This particular application was a pneumatic ram carrying a printer head which had to fire date codes onto 2 pot lids on a rotary filling machine. ENCODER.txt

There's a question that needs answering: Has this system ever worked properly? If it has, and the software hasn't changed, then you stand a chance of finding the answer, even though the code has no comments or name file. If it hasn't, then you've got a big problem. I've had another run through the code and there is another place where data is written to FX2N-1PG, look for the value D262 in the attached text file. Best of luck. SERVO2.txt

Thanks, Neil I've tried for another few hours and can't get it to work (the freeware one from HW-Group). As soon as I uninstall it and load the trial one from Tactical Software it works flawlessly. Looks like I might have to shell out for it

I think I've pretty much sorted this out now. It seems that the freeware driver only opens the virtual port at a speed of 9600 baud, while the Q2AS needs 19200 to communicate. I downloaded a trial version of one of the commercial serial / IP drivers and it all works fine on that one. The freeware one would probably be OK on the FX family which I think use 9600 baud for comms, but unless I can work out how to change the Baud Rate I think I'm stuck on this one.

On another topic, I re-read an old thread where you had managed to get transparent comms between an E300 HMI and a PLC using a freeware Ethernet / Serial driver. I've got it all set up on the bench but can't get comms to the PLC. Any chance of telling me the settings you used in the freeware driver, please? Thanks

Not sure .... never used one. One thing I would look at though, is the operation of address M208. By definition, M208 is the "Single Speed Positioning Start" bit which your programme writes to the FX2n-1PG. It is shown as M8 in their example on Page 10-6, and is operated by the their timer T0 on page 10-7. Seems like that bit could be a reset bit, as it's the only Command Bit that your programme seems to write. Try turning it on from Medoc and seeing if the value in D260 resets. If it does, then it could be the code that operates that bit which is faulty .... or something attached to it. It's only shown as a PLS element, meaning that it is only there for one cycle scan. I'm only guessing here ......

It seems like your FX2N has one special function module (an FX2N-1PG) which is situated at position 0. The Code in the software shows the following, relating to that module: LD M8000 (Always ON) DTO K0 K19 K4000 K1 Writes a value of 40000 to Buffer Memory 19 of the FX2N-1PG TO K0 K25 K4 M200 K1 Writes a 16 bit binary word stored in the Memory addresses M200 - M215 inc into Buffer Memory 25 of the FX2N-1PG FROM K0 K28 K3 M220 K1 Reads 12 binary bits from the FX2N-1PG and stores them at addresses M220 - M231 inclusive DFROM K0 K26 D260 K1 *****Reads a double word (32 bit word) from the FX2N-1PG Buffer Memory 26 and writes it onto the 32 bit data register occupying D260 and D261. ****** D260 (and D261) is showing you the value in the FX2N-1PG. If things are stopping when this exceeds 999,999 then you need to check the FX2N-1PG manual to find out what Buffer Memory 26 actually means, then work out what to do about it. Bear in mind that this is being reported to the PLC FROM the special function module. Have never used one before, I'm afraid. Cheers

I'm the same ..... used STL instructions extensively in FX PLCs for processes that stepped through in sequence, to the extent that when I had to write a similar process using an A Series, I looked really hard for an alternative, and there is a good simple one. Check out the Commands MC (Master Control) and MCR (Master Control Reset) An MC command when enabled, "energises" the rungs between it and the next MCR command in the programme, which, if you think about it, is much the same as an STL command. So, energise the MC command at the start of your "virtual Stepladder" and energise the MCR at the end of it when it's done, having energised the next MC command to create the next Stepladder etc. etc. Works fine ..... believe you can also nest these things as well, but haven't tried that.

What's an "AutoRefresh" box? Haven't noticed that one.

Thanks ..... I'll have a play with those options. Have to admit that I always wondered what the DEBUG menu was for. Will keep you posted on what I find out.

It seems to me that the constants used by different manufactures mean different things, and that very few people truly understand the meanings, me included. The FX2N manual defines the P and I constants as shown below: Certainly, in my case, getting the "I" value right was the best piece of advice I could get. Note that in the FX2nN, the units of the I value are seconds, and it seems that this value should always be around "60-80% of the system response time" (the time it takes for the valve to move 100%). Once this value was entered, I only needed to experiment with the P value to get the system exactly how I wanted it The guru didn't really mention the D term .... seems that PI is the preferred method as Derivative values can introduce massive mood swings!! P - proportional change When a proportional factor is applied, it calculates the difference between the Current Error Value, EVn, and the Previous Error Value, EVn-1. The Proportional Change is based upon how fast the Process Value is moving closer to (or further away from) the Set Point Value NOT upon the actual difference between the PVnf and SV. Note: Other PID systems might operate using an equation that calculates the Proportional change based upon the size of the Current Error Value only. I - integral change Once a proportional change has been applied to an error situation, ‘fine tuning’ the correction can be performed with the I or integral element. Initially only a small change is applied but as time increases and the error is not corrected the integral effect is increased. It is important to note how TI actually effects how fast the total integral correction is applied. The smaller TI is, the bigger effect the integral will have. Note: The TI value is set in data register S3+4. Setting zero for this variable disables the Integral effect.

Looking at that Web Site doesn't work if you're outside of the USA.

It's also used with the older An series and the QnA and the FX2N series of PLCs. As I understand it, (might be wrong), File Registers are a bit different from other registers in that they are the stored in a seperate area of memory from other variables. To enable File Registers, you need to lose some programme area memory. For example, in the FX2N, you lose 1000 steps of memory to enable 1000 File registers. They are battery backed and reckoned to be vary safe from data loss...... though I can't really explain why.

Also an instruction code listing that I know works .... because nobody's phoning me. FX_4AD.txt

Here you go. fx_4ad.pdf

The manual says it shouldn't work ....... scary!!

As I see it, your display is an E700 connected via its RS422/485 port to the programming port of the CPU. All you have to do is knock up a simple 9 pin to 9 pin serial cable (2-2, 3-3 and 5-5 from memory), plug this into your laptop serial port and the 9 pin port on the E700, and there you have it ....... transparent comms to the CPU through the E700 from GX Developer, IEC developer, whatever. You may have to configure the comms in E-Designer, but it's pretty easy. The internal Web Server does work reasonably well, only trouble is that you control the screen just like a local operator when you use it. Scares the hell out of local operators when the screen starts moving on it's own when he's not pressing the buttons!!! The transparent comms does slow the screen operation slightly when it's transferring a lot of data, but it's still workable.

I had a similar problem recently with sending E-Mails from a SCADA system through an Intranet. The main server was running Microsoft ???? with all the local PCs running XP Pro. I realise that the ???? isn't much help, but I'm not too familiar with Microsofts Server Software. However, the point is that the SCADA software demanded SMTP and POP protocols / accounts, and the MS Server software has moved on to something else. We found that we had to configure the MS Server Software to be "backwards compatible" with POP and SMTP. The site network genius worked all this out as I had no access to their server. Got a feeling that the problem might not be with the E-600, but possibly with your servers ability to accept POP and SMTP accounts. That's extremely vague I know ..... but it might be a hint in the right direction?

I have a similar set up, but using a Q2AS CPU. It is as follows: MAC E900 connected to Q2AS programming Port (RS422/485) MAC E900 ethernet connected to ethernet switch. MAC E700 ethernet connected to ethernet switch. Programming Laptop connectes to serial port on E900 and talks transparently to Q2AS SCADA PC talks to Q2AS using RS485 card on Q2AS rack (and converter at PC to change serial RS232 to RS485) Either MAC screen can be programmed from LAPTOP ethernet port using TCP/IP option in E-Designer Both Mac screens have access to data in the Q2AS. Setup using E-Designer software only. Assuming that a SCADA PC can talk to the RS485 BD (which I've never tried), then I think you have a similar setup. Have never used Profibus, so can't help there, sorry.

Yes, I think I probably will upgrade now. They tell me that V6.21 is the latest version .... apparently some of the recent releases re-incorporated bugs that had been fixed in earlier versions!! Even the pros have problems with version control.