JimRowell

An innocent answer to a post (you can view it here:message) allowed me to find the following site: http://www.lighthouseplcs.com/plcs/shihlin.html The question in the original message thread was about Hitachi plc's. I've always wondered why there are Hitachi processors in the Mitsubishi pls's when Mitsubishi is a world leader in microprocessor development. At one time, not so long ago, Mitsubishi sold more per year than anyone else. I think they are still the leader in 8-bit sales and are somewhere around the top in 16-bit. Hitachi processors have always been known for their speed (but lack of high level features) and Miti's have always been rather slow (but feature rich). I figured it came down to them needing the speed for the plcs which are heavily burdened by the operating system (speed sells). Now I know better. It kind of looks like Mitsubishi doesn't make plcs. It appears they have been rebranding 'Lighthouse' plcs who have some kind of connection with Hitachi. Reliance, Furnace and a few others also use Lighthouse. Anyone here know anything about Lighthouse? Pricing, service, etc? Let's see... if Beijer did all of the original software, cables and some HMI's... and if Lighthouse makes most (all?) of the other hardware... Interesting. Jim Rowell Note (added 03/12/02): I should not have said "Lighthouse". It appears they are just a distributor. The manufacturer is a Taiwan company called Shihlin Electric.

I'm thinking of getting GX Simulator. Considering my low opinion of GX Developer, I'm probably not going to be happy with my purchase. Since I can't seem to get a trial or even find anyone in Toronto with a copy to try out, I figure I should at least ask for your opinion. Anyone have it and like to offer their opinion about its usability, limitations, features? Does it have any import ability (Medoc) or is it strictly for use with GX? Good, bad, ugly?

Can't help with any links but perhaps a passive infra-red sensor. These are not really used much (to my knowledge) in industrial but are the standard in the security industry as motion sensors. If someone makes a similar sensor but targeted to general sensing it might fit the bill.

You affect the balance as soon as you tap any non-3-phase loads off a 3-phase supply. In other words, you can take 0% without having any affect. To balance it back, you need to take the same additional amount from the other phases. So, if you have 3 of these loads & they are all the same size, put 1 on each of the 3 phases. Don't put them all on 1 phase. If they are different size loads, then distribute them appropriately. It's not automatically a bad thing to not be balanced. For instance a transformer doesn't care if it's balanced or not. You can draw the maximum phase current from each phase without concern for what the other phases are doing. On the other hand, if you want to use the entire capacity of a 3-phase transformer or run it at it's coolest temperature for longer life, you'll have to use each phase equally. The thing to remember is that the more you draw on a phase, the lower that phase's voltage will be. If you have uneven currents on your phases, you will have uneven voltages. How much current you can draw for a particular voltage drop depends on your system. Depending on your loads, the amount of drop you encounter may or may not matter. Heaters will still work but the heat output drops fast (according to the square of the drop, ie if you divide the voltage by 2 then you just divided the heat by 4). More of an issue are 3-phase motors which are easily affected by unbalanced voltages. It becomes an issue if you have heavy single-phase loads that unbalance things on the same system as 3-phase motors. Motors run hotter than normal on unbalanced lines. A motor can handle a small imbalance and most systems are far from perfect. You calculate it as follows: Measure the voltage on all 3 phases (either phase-to-phase or phase-to-ground). Find the average value (ie take the sum of the 3 values & then divide by 3). Now determine which of the original 3 values is furthest away from the average and divide that one by the average then multilply by 100. This will give you what is known as the "percent imbalance". Ideally, it should be less than 1%. Above 1%, you should derate the motor or fix up the imbalance. At much over 3%, you should shut the motor down before you destroy it.

In the end, I used the latest version of both GX & Simulator. Simulator is sold as a plug-in for GX but nowhere that I saw did it mention that it was version sensitive. My Mitsubishi rep was not aware of that and neither was the fellow on the Mitsubishi N.American help desk in Chicago. There is a quick blurb in the manual about 1 particular feature needing version 8 of GX but that was all we found. Real impressive. I was trying to use it with a older version of GX (7. something). In the end, once I got hold of the latest versions of each, there were no more excuses & it fired up ok. I tried the latest. Gave it a quick run through. I can also say that for me it was the last. If you guys like it then great. I still stand by all of my previous rants. Mitsubishi has proven time & again that they are simply not capable of writing software that is up to my usability standards. The hardware is fantastic. The old software written by Beijer was very good. The software that has come from Mitsubishi that was not written by Beijer is beyond bad. It lacks required features & is very old in it's implementation. The message boxes are ridiculous. Maybe it's just me but I think an English version should be in ENGLISH. Basically, the programs are some of the most amateurish stuff I've ever seen. I'd be gentler if it was free or maybe $20.00 a pop. Well, maybe I wouldn't. After all, this is supposed to support an extensive line of hardware products in an industry where speed of implementation, clarity and accuracy are paramount. I wouldn't allow it on *my* factory floor. I'm quite sure that the differences in opinion are at least partly because I write in List. For those of you who use Ladder, etc, perhaps it fits the bill somewhat better. It's just too much of a shock for me to go from my Delphi IDE or even Medoc to GX. I'm going to have to get some additional info about Beijer's 32-bit Medoc & see whether it's up to date enough to warrant using it to replace my Dos Medoc. Or get my own compiler/IDE finished (doubtful unless I thought I could find a market for it). Eventually I may just have to say good-bye to Mitsubishi. Too bad really considering how much I like the hardware. Oh well. I'm in beautiful Scotland on vacation at the moment so I've got lots of time to vent, rant & rave. :-p

Thanks for the info. I did finally get a copy to try out and after much trouble, finally got it to install. Apparantly it only works with GX version 8. Found that little morsel out by accident despite doing the install with the help of 2 people while on the premises of my Mitsi rep and 2 calls to the Chicago help desk & trying to install on 3 different machines. Of course, there would'nt be any point in having an error message stating that the wrong version of GX was found would there? And of course, no point in the sales brochure mentioning it. I wasn't too happy about version 8 being required. I've got an older version which I despise. Did they really think I'd pay good money for a new version that doesn't appear to be any better? So we installed the version 8 free trial which finally let me install Simulator. And of course, it's pretty much just a half-wit extension of GX. By that I mean it's the same disorganized half-Japanese, half-English, piece of.... software. Not sure why I thought it was even worth looking at. After about 2 screens, I just closed it down. Can't be bothered. I'm very, very glad I didn't pay money for it. I almost did because of time pressures. Mitsubishi just astounds me. Literally astounds me. Unbelievable. Windows 3.1 comes to XP. It sort of works. Even does 1 or 2 things you'd expect. Heck, I've heard that some folks have found sections that make sense. Only a couple of thousand dollars for the whole package. Good deal. What I AM impressed with is the patience that you guys have for this stuff! If you've ever used GX, Simulator, etc extensively, you're either briliant or have the patience of an ocean. After 3 minutes, I figure they owe me for my time. Anyway, I promise to stay away from this stuff at least until I cheer up.

It's been a while since I opened up LabView but I can tell you that some people like it and some don't. I'd say it's one of those things that demos really well. Looks like a piece of cake to learn and use until you get far enough into it to hang yourself. For very simple applications it can be great. It simplifies many tasks. For complex work, it multiplies the complexity. That may not be a fair summary for everyone as it depends a great deal on you personally. Regardless, there is a vast depth to plumb in LabView and it's not as simple as National Instruments would have you believe. I'd hazard a guess that people who have never programmed much and who are very visually oriented, will think it's the greatest thing since sliced bread while those with a more traditional programming background will cringe in horror from it. I guess I'm in the latter category. I'd recommend you try it a bit and see what you think and if you call National Instruments (they have great support) they will invite you to one of the intro seminars they have constantly in every major city in N. America (including Toronto). One downside is you will get drawn slowly into using more & more National Instruments hardware once you get hooked onto the software (it's one of their goals). They have ok stuff but it's very pricey. To answer your question (sorry I took so long), yes, you can make an HMI with it. If time is tight and you have no experience with it, you may regret the attempt though. I'd give a much higher recommendation to using TestPoint if you decide you like the LabView sort of thing (www.cec488.com). I'm certified as a TestPoint CTAS specialist if you need help. Or get yourself a copy of Citect which is made for doing HMI work. It's free until you actually are ready to commision the output. That means you can take as long as you wish to get the hang of it. Since you say that time is tight, you are probably best to get something from Omron that's a little bit more "ready-to-go". I'm sure that would be the least painful and most productive in the near term. One of the Omron experts here can steer you in the right direction.

Nope. Not bundled. And there is no trial and no real explanation of features (!!!??) I forget the exact cost for me but it was well over 400.00 CAN. Can one do serial comms with it? I mean will the simulator connect to the real ports on the pc or can I at least pre-load fake simulator ports with data to check the response of the program, etc?

Also these. http://www.amplicon.co.uk/data/ventrix65.html

I Beg to differ, Peter. I mean, yes, software takes an enormous effort that a lot of people do not appreciate. We all face that problem with our own customers. But keep a handle on the scale we are referencing here. Mitsubishi and others like them sell more than 1 piece of hardware each day. I know only too well what's involved in writing PC software. It's a large part of my business. I also know what's involved in writing a Mitsubishi editor/compiler (or to be more accurate, assembler which is really what Medoc and GX Dev are). I've written one to about 75% complete for List. Fully functional, far exceeds the abilities of either Medoc or GX Dev although only for the FX series and as I said, so far it's only concerned with List. It will upload and download code to the plc same as theirs. Point is, I do know what's involved. I'm just one person who's busy with other things. No one else in my office has worked on it. I don't sell millions of dollars worth of hardware each year as my core business. And by the way, the firmware on the FX series is now old. Hasn't been touched in some time. They don't work on the firmware, they don't work much on the manuals and they certainly don't work on the editor. If they even have any full time software writers they are not working on FX related projects very often. There are many well-known software houses that support packages so complex, they make GX Dev look like a utility program. Often the team of programmers doing all of the work on these projects will be anywhere from 2 to 20 people. Most of the work on Delphi is done by about 1/2 a dozen people or so (the exact number is secret but they've admitted in separate statements to more than 4 and much less than 10). Delphi is hundreds of times more complex (I mean that literally) than GX and sells for only about twice the price. The producers of it sell no hardware at all. They rely on their software for all of their income. They also have no distribution network except through their own costs and efforts. In my opinion, the cost of software development to a large established hardware producer of the scale of Mitsubishi is close enough to zero to not even count. They could set up 2 people starting over from scratch and roll out a new whiz-bang editor in 6 to 12 months on a budget of somewhere between 100 to 200 thousand dollars (esp if they contract it to someone cheap like me <grin>). Peanuts. Marketing, etc is much more costly but that is required whether they do the development or not. Let's assume a profit of 100.00 per plc (I'm being kind here), that's a full return after selling only 2000 of them if they were to give the software away for free. How long does that take? <g> To be fair, they'd have to keep the development cycle going hard for at least 1 more year to smooth it out and they should keep it going permanently so it would have to pay for itself year after year. So a small fee such as 200.00 is fine. But regardless, I still believe it's their right to do as they will.

The Medoc that came free would have been Medoc Dos v2.3 or lower. Medoc 2.4 refers to the 32-bit Windows version of Medoc which is only sold in Scandinavia. It's available by email direct from Beijers but it's not cheap. I *think* that GX Developer from Mitsubishi is cheaper but I'd recommend buying either Medoc dos from Mitsubishi or going for the 32-bit version from Beijers.

Couldn't have said it better. Mitsubishi and to a lessor extent AB are both examples of companies that put comparitively small effort into their software (for the volume of hardware sales). Mitsi is one of the best examples in the industry. GX Dev was old when it was introduced. It uses ancient windows features in a poorly implemented fashion. They've never rewritten it as they should have. It's had only very minor upgrades during its entire life cycle. This from a company who sells millions in hardware every year and has a ready-to-go distribution network. The software should support the core business rather than be a sideline business that thwarts new users from hopping onto the bandwagon. The suggestion of $200.00 max is a good one. Free makes a lot more sense. 1 or 2 full time developers is all that GX requires to be many times better than it is. 4 or 5 would make sense. Four full-time guys would show up on the overhead sheet in Tokyo several lines below "pencils". Regardless, it is their right to do as they wish. Pirating & giving away software without thought or care is theft. The vast bulk of PLC users are professionals who make a living using the software so, by definition, we shouldn't mind paying for it. It would be nice though if it was high quality, feature rich and moderately priced though. There is not one major player in the plc industry who has good software in my opinion. A couple of the small guys (really small) have great stuff. Explain that! Longer term trials wouldn't hurt, say 6 months. Perhaps what they should do is implement a policy of allowing diskless installs by the distributors. Some distributors will actually do this as a sales technique (with nervous glances over their shoulder) in order to get you to buy the hardware. They know that you will probably be willing to pay for upgrades after the first freebie and the alternative is you walking away forever. Generally you have to appear to be a significant buyer. Unfortunately, my Mitsi distributor is not one of these. Maybe the original poster should explain why he needs free software?

I agree with the Medoc crowd. It's outdated sure. It's also well written and capable. I can't recommend GX Developer to anyone for anything (what were they thinking!). Medoc will run on any machine, is not too bad to learn on and works very well under pressure with both small and large programs. It can be run straight from dos and it can be run under windows (in a console window, it's dos after all) in 95, 98, 98se, W2K, XP. You just need to learn a few of it's tricks such as once you get into an edit mode, hit Alt-H and you'll get a nice high-res screen. Use lots of comments and when you press Alt-C, you'll get a navigation screen that is hard to beat.

Since your signature indicates your with AD, let me ask you this... Does the EZ-Touch use a full-blown, spec 422 interface chip or is it an in-house make-up? Perhaps you are both leaning towards opposite ends of the spectrum and now a change on Mitsi's end has the two of you too far apart (spec wise). An untwisted cable would exagerate that although I'm surprised that at less than ten feet it would be an issue. Try putting an isolator between the two (check out www.bb-electronics.com) and see if that fixes things up. That would suggest a voltage compatibility problem if it does. I've got an fx2n beside me with a 485BD board on it and the driver voltage is within spec but just barely with a light load on it. If your hmi interface is a really heavy receiver load, or puts out an even worse driver voltage than Mitsi does than problems could arise. Somehow I suspect that it's not related to any of the above since I can't say I heard anyone having problems along these lines before. Perhaps these customers havn't told you that they just finished installing a really, really noisy something-or-other right beside every display. If you had that piece of info, it might not be surprising that you now need a twisted-pair cable. If you are only talking about 2 customers, then as far-fetched as that seems, it's a possibility (I've had worse you-won't-believe-it scenarios happen to me). It would be interesting to see what effect an isolator has. Also, you should already have gotten yourself a brand-new plc to check this out further. See if it works on your desk. Maybe there are addtional environmental issues working against you. The cable should be ok. I've done 422 comms to the FX2N using wet string. No problems.

It does sound like you mean an old F2 not an FX2N. I've never used one nor do I have any info but Medoc offers a default for this plc as 19200, 8, E, 1. I would imagine that's correct. If you are trying to connect via your own cable setup, there are a few pitfalls that could be hitting you. For instance, the latest RS485-BD boards from Mitsubishi seem to have the A (-) & B (+) terminals mixed up. Put a meter across an A-B pair when everything is at idle. With your meter's red lead on A and the black lead on B, you should get a negative reading. You won't. ;) Maybe the F2 has similar problems. Don't know. Another problem could be the convertor you are using. Is it expecting power to be supplied from the PC or the PLC or both or its own separate supply? You should be able to get the original manuals from Mitsubishi. You are far better off getting the proper Mitsubishi cable and moving on from there. Jim Rowell

Well, then it must be pretty good since higher level languages such as ST, when not internally optimized, can be seriously inefficient (and I doubt that GX optimizes very much if at all). Was that a Mistubishi plc you managed sub 500us scans on? I'm asking because it sounds like you are not using the END instruction or normal scans since the END instruction by itself is listed as taking 450us on an FX1N and 508 on an FX2N. The A series gets much, much worse. I'm not knocking you. I'm seriously interested in how you managed to do this. I work below 1 ms at times and avoid END for short periods (back-looping) occasionally when I really have to but I wouldn't say that I keep my scan time well below 0.5ms. I have an FX2N running beside me right now with a program that consists of nothing but a single line with END on it. It shows a minimum scan of 500us, a current scan of between 500 and 600 us and a maximum scan of 900us.

Hi Kemmons, I can't really comment too well about GX IEC since I've never used it (I use the old dos Medoc) but it should be more or less servicable since it is supposed to be IEC (more or less?). I'm tempted to tell you not to be completely put off from your look at GX Dev... the multi language support in GX IEC "should" be enough to zoom it light years beyond GX Dev. IMO Developer itself is absolutely 100% unusable. I can't even call it software (although others here disagree with me on that point). What I would suggest is if you are close to a serious supplier, they will have a copy installed. I'm sure they would allow you to sit down for an hour in their office and try it out. Can't beat a test drive (a *long* test drive).

I'd like to know more about this problem you're having. Is it always the same bit(s) that sticks? What device number? Do you sometimes have to click more than once in E-View to get it to set? Do you have several that work properly (never stick) even though you are using them from E-View? There has to be 2 commands sent from E-View to produce a momentary action since there is no true momentary action available in the plc. First a set command is sent then after a short pause, a reset command is sent. There is reasonable (albeit not great) error checking done by the plc and a good/bad reply is returned to the sender (E-View) after each command. If noise is a problem I'd be surprised if only the reset command is being botched. I suppose it's possible that E-View does not properly check for the reply. You are there clicking until the bit gets set but then it's up to E-View to reset it on its own. If it's not checking the reply, then it's not resending the command until it gets through and that could explain it. However, I'd be surprised if E-View's programmers were that lax. As a workaround, you only need to add a single RST command into your existing code in the plc for each affected value. eg. change your code from: LD M0 [perform action] to: LD M0 RST M0 [perform action] Nonetheless, I'd really like to find out what's causing this problem you're having. If you post some or all of your code, we could perhaps offer some more help. If this is a problem with the plc or E-view, I'd like to understand it. If it's a problem with your code, I'm sure you'd like to understand it. Either way, you're a winner. While you're at it, why not register on MrPLc?

Yes, it can mean a PC. Basically, the 232-BD boards are identical in use to the normal 422 programming port. In other words, you can use them for any of the types of comms mentioned in the programming manual including the actual programming of the plc. You can transfer programs, go on-line, etc using the 232-BD board. You can also do serial comms between plc's, etc as you would expect. There is nothing different for you to do either. Pretend you are connected to the 422 port. The plc treats it the same. The first thing I usually do when I buy an FX system is install a 232-BD. Then I do all programming with an ordinary serial cable between it and my pc. I find it's easier than fiddling with and wearing out my sc09 cable. I don't scream quite as loudly when someone steps on my $5.00 serial cable as I did when it was the sc09. I can also plug an hmi into the now empty 422 port and still program the plc without having to configure for pass-through mode, etc. When the project is complete, I can easily recover the 232-BD if it's no longer needed.

Most relay/contactor manufacturers sell ac suppressors for use across the coils of their products. Just ask your supplier. Or, if you wish, you can go in to your local electronics supplier and pick up some zeners or varistors. If your are not sure what you are doing then I'd recommend the varistors. You need to choose a voltage rating which will be the point at which the varistors will conduct and create a short circuit across your solenoid. The exact rating is not too important. It must be higher than will be experienced during normal operation. For 120 vac, you should choose something like maybe 300 volt varistors. They come with 2 leads. Wire 1 lead to each solenoid terminal. I'm assuming you are not exceeding the specs of the relays with the current these solenoids are drawing. If you are then you should place intermediate relays in there.

Well, I don't want to presume to answer for Rebuke but I do know that it's a common thing for people to have a general idea that a powerful feature which is laying just outside of their grasp can offer many unique improvements. They'll often have a general set of plans on how this thing will be truly valuable. Then when it's thrown in their lap much quicker than expected, they realize there are many details to be ironed out. Panic sets in because someone else is looking for fast results. Doesn't mean the initial vision was wrong. Just means there is some work and research and learning to be done. I've met and spoken with Rebuke and found him to be thoughtful and intelligent. The small investment for this equipment is chicken feed to his company and will have zero impact on their profit even if it just sits on the shelf collecting dust. If it can be eventually utilized to the extent he's hoping then a very large payoff could be realized. Small research projects, trials and experiments are important for keeping things moving forward. Nothing wrong with that in my mind. I'd agree, Sergei, if this was coming from the pockets of a small customer with a limited budget. That's not the case here.

I agree with Kink. It's not acceptable if the motor will restart when the E-stop is released. I realize that a switch would also allow this but an e-stop, by definition, indicates to people that they can release it without startup occuring. If your invertor requires a manual restart action then I suppose you could argue that the setup is ok (I still don't like it). The other thing you need to concern yourself with is the HP rating of the e-stop contacts. Most e-stop contacts will have a very low rating. It may not even have a HP rating (just a current rating which is meaningless) in which case you shouldn't use it. No fun if the contacts weld on the button. You are also encouraging constant use of the button since it sounds like the only easy way of turning off the motor. And everytime you operate it, the e-stop is handling the full current of the motor. Worse, if the motor burns out and blows the fuses, someone will change the fuses and then operate the e-stop to see if it's fixed. They'll blow the fuses again before changing out the motor. Meanwhile, because of that last test, they've really done a number on that poor little e-stop, possibly even welded its contacts closed. So now, when the new motor is put in, you no longer have a stop button. Or worse, you have one which will fail a little bit down the road. I'd suggest you install a convenient on/off setup using a properly sized contactor with an e-stop breaking the contactor. Contactors are made for this sort of thing.

I assume you mean digital comms between two systems. In other words, the analogue and digital inputs will be into a local system which then has to communicate the data to another system 200 meters away? Use good old RS-422. You can do 200 meters standing on your head.

I like Jay Anthony's earlier suggestion of a place to record hardware failures. Could be a good resource for info on products that have problems, methods that cause problems, etc. Also gives us an idea of the reliability of items that are often marketed as being perfect (ie. no one brand may be worse than others but at least we get an idea of the failure rate of the group as a whole).

I'm guessing it's made by Shihlin and labelled for Delta. Shihlin make Mitsubishi plc's and a few others. http://www.seec.com.tw/