JimRowell

MrPLC Member
  • Content count

    154
  • Joined

  • Last visited

Posts posted by JimRowell


  1. I've run into the same type of situation several times and an extra plc does the job well. I've got a very expensive 16-input DAQ device but why would I leave that on a jobsite along with the needed computer when a small plc will usually do just as well? Just set the input filter time down to zero or whatever you need (I'm assuming you can do that with a AB plc; can't recall) and program it to record the input #, time, etc whenever any input changes state. I had one tough problem where the plc was able to prove it wasn't electrical but rather a mechanical problem. Because there was just too much data to record for any great length of time, I gave the plc the ablilty to search for data patterns as triggers before writing data to memory. As we narrowed the pattern down we could quickly input our new ideas of what the pattern should be into the plc via an HMI screen we had connected to it. We gradually reduced the amount of recorded data that had to be ploughed through with better and better patterns until we understood what the problem was. Worked really great. I Used a bottom of the line micro plc from Mitsubishi. I would not repeat that experience today; I'd use high end DAQ equipment, record everything in one shot and analyze it offsite but it worked well with our limited resources at the time. Most cases are much easier to diagnose and a quicky program into a spare plc is as good as anything. A side benefit of buying a plc for the job is that you can use the plc in your next project. If you buy special test equipment, you get to admire it on the shelf! Even renting is money down the drain by comparison. Jim Rowell

  2. Mitsubishi uses the term "Memory bit" to describe a memory location that is 1 bit wide, is directly addressable and is not I/O. In other words, an internal relay. A "diagnostic" bit is a memory bit that indicates or controls the state of the system. In other words, they have pre-defined functions. Example, there are bits for indicating whether the plc is running or stopped, whether an error has occurred, operation flags for zero, borrow, carry, etc. Some of the diagnostic bits are referred to by Mitsubishi as "Status" bits. I wouldn't be surprised if a lot of people use the terms interchangably. Anyway, its not important what you call them. A status or diagnostic bit has a pre-defined function. Other memory bits do not and are available for whatever use you wish. Jim

  3. Dariusch, I wrote a quicky utility for you to try (its attached to this reply). All it does is send a simple enquiry to the plc. If it doesn't work, it doesn't prove anything. If it does work, then you should be able to communicate with the appropriate software. It should work fine in XP. Just make sure the Port and other settings are right and click on Send. Its under a meg. Not too long a download and does NOT require any sort of installation. Just double click on the file to run. Simply delete it at any time it if you wish. Jim Hello.zip

  4. For starters, you need the programming manual. It has a troubleshooting section in it that may help. You can get it here: http://www.meau.com/Files/IB_NA_66057-C.PDF Also the user's manual: http://www.meau.com/Files/IB_NA_66058-D.PDF I don't know too much about this series but I do know that it can have battery backed program memory. If the power was off to the machine and the battery was dead and the progam was stored in ram... there is no longer a program in the plc. Regardless, you should be able to connect to it. Check the manuals for the appropriate cable and procedure for comm. You need the manuals anyway even if someone else can help you more directly. Don't open up GX or any other software while you are trying to communicate with the plc via Medoc. Its not unusual for programs to lock up a port while they are running (Medoc itself does). Make sure the comm settings are correct in Medoc. If you need help on that, let me know. Jim

  5. I think the only way you are going to get a quick education on them is to go to www.meau.com. There is not much info outside of Mitsubishi's own sites. Check out the Documents section on their site. The brochures will give you a good overview of the various models and peripherals. Then check out the manuals. There are tons of manuals but just look for the ones that have "programming" in the title. They are aimed at new users. If you are interested in the FX series (the micros) then be aware that there are two versions of the manual. One for all except the FX1 and then one that covers both the FX2 and the FX1 only. The first manual is older and is missing some added features of the FX2. The A series, etc gets more complicated for manuals. If you have some model numbers of what you will be working on, then you can find the appropriate manuals. Mitsi, over all, has pretty good documentation and only suffers midly from the usual JEnglish problems. Check out the UK site, too. Jim

  6. You can get a very old copy of dos Medoc at the following address: http://www.plcman.co.uk/page6.html I thought there was a place to dl a trial version of GX but I can't find the link. Perhaps someone else can help you there. Jim

  7. If you plan on buying the plc specifically for this project then use an FX series. They have high-speed inputs built in as well as a SPD function. Another possibility is to use the CHZ line from the encoder. Most encoders have at least 3 outputs. CHA, CHB and CHZ. CHZ (channel zero) is the zero pulse. It occurs once per revolution. You could make good use of that in your application. Connect it to a counter and then use a timer to check the total in the counter at regular intervals. Clear the counter after each read. A little math and you have an rpm value. Jim

  8. Actually, I appreciate the picture you gave of the Taylor Series. Its gives a little more of the detail that a non-math person such as myself needs than any others I've seen on the net. Thanks again. Jim

  9. Thanks PlC Cables, I think I found a pretty good solution. Here's a copy of a reply to my request in a math forum. Its from a gentleman named Ricardo Gibert: <quote> let pi = 3.14159... let a = arc length let c = chord length let r = radius let y = c/2 let x = sqrt(r*r - y*y) let u = min(y, x) let v = max(y, x) Now we have u, v and r being the sides of a right triangle sth u <= v <= r. Now compute smallest angle U in degrees: U = 172*u/(v + 2*r) with roughly 4 digits of accuracy! This approximation was given by Ozanam in 1699. If u = y then A = 2*U else A = 2*(90 - U) A is now the angle needed to compute a. a = pi*r*A/180 </quote> Is that sweet or what? Jim

  10. Well first, to what Sergei said... I wouldn't compare List vs Ladder as the same as Dos or Assembler vs Windows. Actually I would say with absolute conviction that both List and Ladder are different ways of representing the plc version of Assembler. List is a mnemonic view and Ladder is a graphical view. The point is, they are different views of the same thing. One may have a preference for one view over the other for various reasons but neither takes the "native" language of the plc and elevates it in complexity like C, VB, Delphi, etc do on PCs. Now for what the Guest (whoever you are ) said: I guess you are referring to the abundance of orb, anb, mps, mpp that you see when write in ladder and then switch to List view to see what it looks like. Its possible to eliminate much of that simply by understanding how the plc reads the code. Changing the order of your instructions is the answer. A quick example: ;example 1 LD pushbutton LD sensor1 OR sensor2 ANB ;example 2 LD sensor1 OR sensor2 AND pushbutton These both say the same thing. Example 2 is more readable when in List, plus it executes faster and takes less memory. Most people, including me, prefer the way example 1 looks in a ladder diagram and that's ends up being the way they draw it. Jim

  11. Quite a few and I'd have to interpolate if I didn't have a very large table. The arc lengths and therefore the angles will cover a wide spread and accuracy is important. There is an approximation of inverse functions in the form of a trig series that is well known (I just heard about it a few minutes ago) but I'm considering the look-up table approach too. Its kind of frustrating that with the amount of difficult work involved in this project, I have to consider such a basic thing. Thanks Jim

  12. I've always been able to avoid this issue by just using pythagoras but I think its finally caught up with me. I need to find the length of an arc when given the radius of the circle and the length of the chord (the straight-line distance between the two ends of the arc). I'm told there is no way to do it without having access to inverse trig functions. The FX2n can do sin, cos and tan but it won't do arcsin, arccos, etc. For the life of me, I don't know what Mitsi was thinking. Chances are if you want the standard trig functions, you also have a need for the inverses. Has anyone ever had to overcome this limitation? Any ideas? Jim

  13. I think its a great idea, Macgyver. I'd like to see 2 additional forums added. One for general, non-manufacturer-specific topics and a non-technical forum where people could discuss the surrounding issues like business, marketing, trends, etc. As for the rumour of Panasonic starting the Mitsi line... never heard that one. If I recall correctly, the microprocessor in the Mitsubishi Alpha series is a Hitachi (which is odd considering that Mitsubishi is mega-huge in the processor business). I forget what they use in the FX line but it may be Hitachi too. Hitachi makes very fast, simple, inexpensive processors whereas Mitsi's are fairly complex and pricey. I suspect there are many arrangements between them and several other companies. Jim

  14. Yeah, that's a very powerful feature, DesertDog... one of my favourites. I spoke with my rep yesterday and she swears up and down that there is no version of Medoc beyond v2.3. As an aside, she also says that Medoc was not written by Beijer. She's not sure who did write it... she just knows it wasn't them. I'm not sure why but I'd always thought that they had written it. Does anyone know who did write it? Jim

  15. Interesting point, Chakorules. Its also one that justifies a difference in approach for sure. Actually, the idea of who should modify and maintain a machine's control system is a discussion all in itself. And probably one that would create even more dissenting views. My opinion is that you shouldn't touch the program or modify the wiring on a machine if you don't have both: 1) An extensive background in designing control systems incl safety issues. 2) An intimite knowledge of the machine itself including the prints and program. Very few plant maintenance people can make those claims. They can do a great job of monitoring the machines, changing external parts such as motors and fuses and providing assistance to the person who will work on the program. I'm not playing favourites here or talking down to other trades either. Few engineers have any business doing control work. You need experience. Needless to say, since I don't write my code for novices to modify, I have a different view on this. I worry more about how hard it will be for ME to maintain it and provide updates. I comment the heck out of things and often include redundent code (just to make sure that contactor OPENS) and I usually will write for simplicity rather than efficiency (but you can't always do that). I section the program out into small parts, etc. Nonetheless, if I can read it but the packaging machine mechanic can't.... fine by me. That's not an attempt at preventing others from taking my market share. I feel its both my reputation for quality and the safety of the operators that's at stake. Kind of like, I won't perform brain-surgery, re-plumb your building or handle your stock trades... don't you touch the plc. My customers seem to agree. Perhaps I'm just very lucky in this regard while others are under pressure to conform to the customer's standards. I can understand how that would make a huge difference. As far as turorials go, I don't have a lot of time but I'll see what I can do if you're not in too much of a hurry. Jim

  16. I'm still getting over my initial shock at hearing people here talk about List this way. Those PC's you mention are themselves almost always programmed with a text-based language. There are very few programmers in the world outside of the plc crowd that would even consider using a diagramatic form such as SFC or Ladder for anything other than planning and general layout. There is a bit of a movement towards using similar stuff for repetitive, cut and paste style things but that's about it. Do you suppose that several million people are just plain wrong? And trust me, plc programming is no different than any other form. Non-plc programmers are writing code that is both lower level as well as higher level than plcs and 99% of the time its done in text. Everything from microprocessors to desktop operating systems, for your fridge or the military. Even the web page you are reading from, the browser you're using to read it and the computer you're sitting at. The chips inside it..... etc. I did relay design for years using ladder diagrams and was quite comfortable with it but when I started programming plcs, I learned List. Perhaps it was easier for me because I had a solid computer background previously but its not really that hard to learn. Anyone can learn it. Its many thousands of times EASIER to read and follow a large program that is properly written in text rather than Ladder. Ladder is like Cuneform or runes on the wall. Its just too limited. That's why alphabetical languages took over for written words a long time ago. I can't help but think it comes down to general acceptance by plc programmers that its not worth learning or that its the old way or something. Sorry, I'm simply astounded that anyone would think that ladder has any strengths at all beyond being a useful companion tool. It is useful, no question, but I wouldn't write a program in it. Or maybe I'm wrong (I'm wrong a lot). I've seen a lot of machinery that works well and I know it was written in ladder. But I can't see myself slogging away that way. Maybe some tutorials in List would help paint a different picture. If anyone's interested. Jim

  17. A bit that has been set using the SET instruction is no more likely to survive a power interuption than any other. On power up, the operating system resets all non-retentive bits. So, what you describe may have been the result of a power blip that affected other pieces of equipment (so you knew it had occured) but was too short to affect the plc. Or some other unknown explanation such as a bug in the program. Regardless, I wouldn't hesitate to use SET/RST in your programs. I use them HEAVILY in my work which often involves high hazard programs and I've never had unpredicable behavior or an internal failure in a Mitsi plc. Its the one piece of hardware I don't worry about. The times I've had wacko things occur always ended up being the fault of my coding mistakes. ;) Regardless, use what works for you. I'm glad we solved the problem. Happy coding, Jim ;)

  18. Actually, to address you request more directly, you might want to consider a different idea. Using the shift method is a bit too blind and prone to errors (eg. what if you accidently code an extra shift?). A more positive, safer method would be to set the proper bit yourself each time. At each step in the process do: RST K4M0 ;clear your entire 16 bit buffer. SET M2 ;set whatever specific bit belongs to the step you are in. Now when troubleshooting, you know where in your code each bit gets set. cheers, Jim

  19. That instruction will be processed continuously every scan unless you use the pulse version or some sort of interlock. The pulse version (SFTRP) won't work on FXon/os models. I imagine, you are shifting your bits completely through the area faster than you can see them. Something like this should work: LD X7 SFTRP X0 M0 K15 K1 A single shift will occur each time X7 closes. or... LDP X7 SFTR X0 M0 K15 K1 or in Medoc... LD X7 PLS X7'PLS LD X7'PLS SFTR X0 M0 K15 K1 Cheers, Jim