speakerman

Hey Matt; You've got a great plan structure. I would like to put forth a couple of thoughts regarding interface, if you haven't considered them already. I approach something at the scale you describe considering the nature of each 'zone' of control, looking at the level of automatic action desired, and the amount of operator interaction with the normal process flow. You mention this concept within the listing 'interaction boundaries', and the implications are something I consider vital. The more automated an area, the more self-reliant the code structure must be, and the clearer its fault detection and appropriate automatic response. You may find the code design and structure might change from zone to zone, to avoid overcomplicating the simple areas, while properly enabling the complex ones. An example of this is a system that has a visual line of sight to the control station as opposed to one that is sensor based - whereby most of the decisions made are assumptions based on gathered data. With visual systems you can put a lot of power into the hands of the operator to override possibly failed sensors, as they can confirm everything is correct before proceeding. In this case I generally allow all but the most contradictory actions to occur in the manual interface, trusting the operator to see what needs to be done. When designing from the ground up I orient operational controls within the sight line of their machines, and break down the panel locations and size based on that reality. I never want a local control activating something that the operator cannot see. HMI structure can be quite different, as it tends to be more central and less directly informed. If a remote HMI is part of a system, my local control automatic/manual selector switches are always the master control with the highest authority, so that when a local panel is turned to manual, no other control method will activate that part of the system. This protects the people interacting directly with the equipment from a mistaken remote start. Sounds simple, but I often see it otherwise. Dual-zone control interface and the inherent complexity for operator safety is one of my pet peeves. The second aspect I consider that weights the code structure and how it faults is the level of personal interaction people will have with the equipment/product. This adds weight to the above point, or takes it away, depending on the physical reality. If all parts are internal, like inside a washer drum or tank system, then protecting the equipment from plugging and damage is likely the concern. If it is a conveyance system with people and machinery working around and handling large product, then the interface needs to be solid and have redundant backchecks. A perfect example I run into frequently is the wiring of end limit switches on lines that carries 3500 pound stacks of pulp bales. Failures when wiring them N/O have let the stacks run right off the end, or successively butt up against the stop blocks until they toppled over, broke the chain, or kicked out the motor. Most line switches are wired N/O to prevent switch failures from initiating a machine cycle, but the conveyor end limits all need to be N/C so that they fail full. Everywhere that people interact with the line, either to work on it or walk by it, the sensors need to be N/C so that if they fail they will not let the next stack run onto the conveyor in auto until the sensor is repaired. I hope that gives you a couple of helpful ideas, Matt. Good luck with the project! Take care, Speakerman.

Hey all! Reading the threads and seeing the general spectrum there is a real mix of topics raised from very simple to very complex. Is it possible for us to build a short list of helpers that a newbie like me could see pinned at the top of the posts, containing some of the common little things that some of us struggle with a little bit at first, and then don't remember later? I've got a bunch sizzling in my short term memory, and would be happy to share. Loved that "PLC Law" pinned thread, it's one of the first things I read here, and what actually convinced me to join. This applies to all PLC types, really. Love to see how it goes with Mitsubishi, if that's allowed Unless this has been done already, and I've missed the link. Cheers, speakerman

Hey Paul; Thinking about this I see your point. It's been a while since I posted this and have been way too busy to follow up myself. The impetus kinda faded when I got embroiled another project. Forgive my hypocrisy... One interesting hint for newbies like me: to find this post again, I did a search for the word "newbie" as the thread was not on the main page. The results of that search revealed a wealth of questions posted by first time users, and loads of awesome answers! If you are a newbie, search that word, and see all the tricks, hints and methods that others like yourself have stumbled upon, and then overcome. Cheers, speakerman

Hey JMK; I am currently working in a mill where in the excitement to cross train everyone they gave a bunch of people training on how to edit PLC logic, and then access to the code. I have about a years worth of work ahead of me taking out the cross-purposed "improvements" that are messing up production. Like was said so well above, there are benefits and drawbacks to the multi-skilled employee, and the excitement of the accountant looking to cut that extra man can be implemented very badly. I like to deal with people who have multiple disciplines, but so far they are rare here in northern Canada. Have a good one, B.

Hi Everyone; Thought I better post a correction about something I had guessed at earlier, and wasn't correct about, so no-one is led down the wrong path. In my old thread on asking for information about the position and feedback pulses from this encoder card, I had properly described the position pulse, and it has been a reliable piece of data. I was trying to learn about the feedback pulse and did some preliminary testing which resulted in a wrong conclusion. Speaking with a Mitsubishi rep, I did communicate my initial guess, and he did not contradict it, so he doesn't appear to know either. I originally thought the feedback pulse was this: a running count of all the pulses since the motor started to move. This is what I thought I observed, and realize now it appeared that way only because I was ramping it up and slowing it down for short bursts, so the numbers were climbing and falling continuously. Based on that misconception I wrote a test program to use the feedback pulse as a rotational counter, and did some more intensive study. This is what it is actually doing: It is a count of the total pulses per second, updated every second overwriting the last value, held constant between each update when the speed is stable. If I had waited for my drive to stabilize at a very slow speed the first time I tried it instead of following the ramp up for a few seconds I would have seen this before. It also uses the actual sensor pulses - not quadrature - so there are 1024 pulses per rev instead of 4096. If you display it correctly, it will ramp up to 30720 at 1800 rpm. My 16 bit hex display was wrapping at 9999, on its way up to 40,106 pulses per second at the feed drive max rpm of 2350. I'm still trying to think of a solid way to use this information as a rotational counter. There are some issues with the scan time and fact that the number can be stable for many scans in a row. I did try adding it to a register each time it updated, and that gets pretty close, but you'd need a bullet proof way to tell that it has updated so it won't get out of sync and miss a number. If there was a bit that turned on for the scan during which it updated the register I'd be laughing. That bit could drive an DADD command to a holding register, and the rotational counter would be done. Man, it would be nice if the manuals explained this. Happy programming, speakerman.

Hey Panic mode, I've been on the road for a few weeks, and finally got caught back up to see your reply. I didn't know the feedback pulse was a running tally updated every second until I had the time and opportunity to fully test it, but the positional code is already working and accurate to within a couple thou of an inch using the position pulse. I was looking for a rotational counter of some kind to increase the maximum rpm that the PLC could accurately track. I'm not interested in complicating the process by adding another encoder counting method direct to the PLC, as right now the wiring and system in general is nice and simple. In the end, the machine works great, the feed speeds are fast enough, the foreman and operators are happy, and the project is complete. We're all pleased with the results, and I've learned a few things. Good all 'round. Thanks for the help along the way, man! B.

If you go to that trouble, markn, I'll do my best to help you. Nothing sounds too difficult, and I can see that you want this to be a safe as possible - which is something I believe strongly in. In another thread I was able to save my GX-Developer file as a new project, delete the extra stuff, then zip that folder and post it. If that's the programming software you're using it should be no problem. I'm here until Thursday, then traveling until next week, so I'll keep an eye out for your code. Cheers, speakerman.

Hey markn; I am not certain what an anti-tie down feature is, but I'll take a shot at the description... It appears you would like to have the clamping of the piece not initiate the cut cycle, but rather the hands activating the photoeyes would start it - for safety, I assume. So that action, combined with the piece being clamped, will initiate the cut cycle and the piece will proceed into the saw. The cut cycle will complete, and the existing logic will run the piece out to the starting limit switch again, and you'd like the clamp to release automatically at that point. Then the operator will take that one out and put another in, hit the foot switch, put hands in the photoeye area... and so on. Is that close? I have a few questions so I can be of more help: Are you using the photoeyes to confirm the operator is not reaching into the saw area during a cut cycle? Is there an auto/manual mode for this, or is it a single, manually initiated cycle? Is the foot switch able to interrupt the logic and stop or mess up a cut if it's hit mid-process? Do you want it be able to stop the process for safety reasons? What stops a cycle now, if something goes wrong? This is a simple sounding move, and I would guess the priority is safety for the person feeding the saw, and a smooth, sensible work flow. Once I have a better understanding of the desired workflow, and the switches in the area and their functions, I can give you a code example to spark some ideas. Have a good one, speakerman.

Hey Mark; Here's a thought: I would suggest that you use more than just the limit switch toggling to decide to release a clamp, because when the switch starts to age and wobbles, it would release the clamp during whatever cycle the table had moved the part being clamped into. I must assume that if you're clamping it, it will either fly around, or at the very least be spoiled. You can use the table output direction in conjunction with the switch changing state to decide whether to clamp, or to release. You control the table output already, so that has some backchecks in it, and this would work in manual or auto. If you have a 'cycle complete' bit for whatever is happening to the piece, that would be useful as well - just bypass that bit to unclamp when in manual, and the operator will appreciate it. The worst that would likely happen with this code is that the clamp could release while the piece was being moved back to the start position, and not while it's being worked on by whatever you've clamped it for. Then you also wouldn't need a discreet command, but rather the direction of the table determines the toggle. Hope you find this useful, speakerman.

Hey Pawel; One of the different things about the Mitsu PLC is the way it handles its registers. It takes some getting used to, and then it gets easier. They don't look right unless they are contantly computed, especially the doubles. First, I would recommend that you make sure your registers are spaced at least four apart wherever you are doing DDIV, or DMUL, or any double register function. Next, I would recommend re-writing the rungs with math functions to be driven by M8000, or whatever internal PLC bit for your CPU is the 'run' monitor, and always on. Then move the bit that you want to drive the timer with down onto the branch the timer is on. This would keep the register constantly updating, so you could see it, and still only drive the timer when you want based on the code example. See the attached pic for a simple representation of that. Hope this helps, speakerman.

You're right panic mode, it isn't a problem, more of a minor preference. When I first noticed that scan time register in the monitor window, it seemed to me to be a maximum, as it wouldn't update in the downward direction. It wasn't hard to find the special register designations for the three different scan time values, and lay small numerical displays on the HMI. Really clear, actually, and I'm glad it has the maximum built in. I have had to trap that value in other processors with code. I guess I'm saying that considering they went to the trouble to build those registers, they could show them off a bit For us it's just another part of a learning curve that you are, thankfully, far past the bottom of because I notice how much you help people here. As a new user still rounding the first turn, I have to say that most of the difficulties with this system have been "simple" items. There's noone around me who knows a thing about Mitsubishi, so there wasn't anyone to ask. You should have seen me trying to figure out how to type in a timer coil for the first time. It was comical! They look a certain way in the manuals... I spent about an hour looking through the menus for a "timer" selectable bit, typing various things into the F7 coil, pouring over the manuals for something other than a picture of how it looked when it was done. Great descriptions of what they do, how they work, etc. Really good! Nowhere does it say that you type it "T1 K20" that I could find. I would never mention something like that as a criticism, because it was so basic, and my own fault for doing this without at least a little support. Throughout all the things I've learned there are powers and features that I have really grown to appreciate. A lot of it is really quite intuitive. Some of the things mentioned are merely preferences, and that's me trying to contribute to the system becoming enriched and strengthened for future users. Some of them are not criticisms, but suggestions based on programming needs that have cropped up. I did read that pinned thread on possible improvements and I can see some real venting has occured, which may make people a bit touchy. Considering the intent of this forum and the spectrum of humanity, it's going to happen. Respectful contrary always seems welcome, and that's why I keep coming back. When performing machine upgrades I can always tell more about how friendly a system is to use from the newbies than the lead hands. The lead hands can tell you anything about how it works, and they are the people I trust to properly describe the operation, and the problems that occur. They've often accepted certain difficulties as normal, however, and no longer regard them as something worth the effort to correct - even if that effort is very low. We all want to go after the big fish, but if you add up enough small fish you've got a full stomach. It's up to me as the control strategy designer to weed out the normal learning curve items from the real opportunitites for improvement. You might say I criticize for a living. Dang, must be why I have no friends... The accuracy of the encoder itself is not related to scan time, but the amount of machine movement measured by comparing the position pulse value differential each scan determines overall accuracy. At a certain threshold of scan time, it will also become impossible to count rotations reliably. This is why I was asking if anyone knew of a rotational counter, or a cumulative pulse counter, so my scan time would stop being a factor determining maximum rpm. Guess I needed to be clearer on that one. To properly program my positioning logic I need to monitor both current and maximum scan times, one for ultimate resolution, the other to determine the rpm at which the logic fails and the heads sail around unchecked. Another example is the job I just finished this last week. It was on a Modicon, and they were having very intermittent problems that were serious in nature, real mechanical crashes. It turned out to be scan time, whereby the normal cycle was 20 ms, and the maximum was 65 for a short time about every seven minutes. It turns out that code for part of the process was not robustly written, so it pulled the whole processor down when it was active. Many critical items are positoned with encoders - which all became three times less accurate - and some sensors were only activated for as short as 50 ms. So during that time, if a critical event was happening, "random" parts of the rest of the process could fail completely, or intiitate something weird when it relied on two sensors activating together. We re-ordered the press discharge cycle code to stop being such a hog, and set up critical sensors to trigger longer, and that problem was solved. Happy days! Thanks for the posts on the encoder pulse monitoring thread Got some good stuff going on there, hoping I can finally be of help to someone else. Have a great weekend, speakerman.

Odd isn't it that only the maximum is shown, and not the current. I've had to work around this to check the scan time during mode activations to maximize encoder tracking accuracy, and it was weird to have to hunt for it. If there's a Mitsu rep reading this, take note! Such an easy thing to have up on that monitor window, both the maximum and current... speakerman

Hey cadomanis; Here's the part of the code that does the tracking. If you have any questions, feel free to ask. Have a great weekend! speakerman Encoder_Rotational_Tracking_Example.zip

Oops, I meant the FRA7AP, typo there, sorry. Can't change the title now, it seems. Hi Everyone. I'll keep this brief, there are more details of my questions in this other post. http://forums.mrplc.com/index.php?showtopic=13196 I have two questions that the manuals I have simply do not explain. What is a "Feedback Pulse" referred to on page 74 of the manual IB_NA_0600167ENG-B.pdf listed in the previous thread? It's in the directory of possible communication data with the VFD, they just don't seem to want to explain what it is "feedback" of. Is it a rotational counter? That would be so nice. Also, is there any communication device, bit or instruction to reset the position pulse counter to zero when I stop the drive? Is it device RYB, the terminal reset function, listed on page 54 of that same manual? Or would that screw up all the other settings that we've got in there. I can't find anything, no reference, no instruction to just reset that pulse count. It was enough work for us having to figure out how the positional pulse monitor command worked by playing with it. I can't believe that the system does not have a reset bit or word for that register. When I first power up the VFDs, the pulse monitors are all zero, so it must be a relative device, not an absolute. Can anyone please let me know some details on these two functions that have such poor - or no - explanation of what they are and how they work. I have the feeling that there's a way easier method than what I've developed through trial and error. I would appreciate advice from anyone with answers to these topics, and I'd be happy to share what I've learned thus far with anyone who wants to know how to do things the hard way! Cheers, Speakerman

Hey cadomanis; I'd be happy to share what I've got so far. Right now I'm out of town on another job, but I'll be back after the weekend. Now that I've got the drives tracking where the machine is, we are designing auto-cut cycles to turn this old Russian girl into a modern, if a bit rough, version of a C&C. Figuring how to get at that encoder data reliably and match it with some careful logic for the different possibilities was a long process, and it could be so much easier if a couple of things were changed in the communication data possibilities. Resetting the encoder position pulse value at my discretion would allow me to always start my travel point from zero, which simplifies the math a lot. Access to the next register of feedback pulses in another buffer memory register with its own instruction code would be awesome as well. That would give me a total revolution count I could measure many times beyond anything I'd need, and allow for over twice as much rpm with accurate tracking. I don't need that for this job, but someone might . Perhaps your senior Mitsu engineer can pass these things along, if they make sense to you? Once I'm back at this next week, I'll make a PDF of the encoder tracking code and post it. Keep in mind that the exact behaviour of the entire drive system, mechanics included, are all critical to the operation of this code. There are doubtlessly many ways that it could screw up. Good luck! B.

Hey panic mode... Did some testing, and it looks like the value of the feedback pulse is a cumulative count that increments with the position pulse. It could have been the display method chosen, but it started at zero, and went up to 9999, then back to zero, as the motor turned. I'm guessing that the value continued to increment as the motor ran, but the register passed back to the PLC is 16 bit, so it would only display or hold the lowest four integers. Perhaps if I changed the display parameter it could go to 32,000 odd, the maximum for a 16 bit register? This is only guesswork, it's a little frustrating that they don't explain it in a way that makes it more useful. It seems like an internal register that the VFD uses only in positioning mode, so it stores the total number of pulses since rotation began in a group of registers, to establish a total rotational goal. Again, just so no-one does a lot of work relying on these observations, it's all guesses based on reading the section of the 'position mode' and interpreting the observed data. I'd be interested to explore that for other applications than this one, because it appears that I'd lose some critical aspects of flexibility and operator control when position mode is implemented. Note the ever present "it appears...". I can't be "sure" about anything at this point. The impetus is to explore it is not high, as the code to move the motor based on the position pulse values is proving to be solid and reliable for all cases of machine variability. The range of data where the code would fail are factors of ten beyond what the machine does in reality, so there would be no significant advantage to changing everything now that the math and adjustments are complete for the 1 to 4096 count that the position pulse monitor returns. That option is monitor code H13 explained (minimally) on page 74 as well, and it also shows no increment value. You think they could just say 'integer that oscillates relative to encoder rotational position from 1 to 4096'... that would be helpful! So if anyone needs to work with these drives and perform specific rotational moves while maintaining the powers of speed control in the operator interface, I'd be happy to pass on what I've learned. The code is stable and accurate up to 500 rpm, with a 55 ms scan time in the FX2N, and when approaching the end of the cycle I have the motor slow down to 10 rpm, which provides a resolution of the position of the armature relative to the starting point within half a thousandth of an inch. Now that it's done, it seems so simple... Thanks for weighing in panic mode. Hope you had a great weekend. B.

Thanks Panic Mode. That's the train of thought I was having, just hoping someone out there knew what it did. Any thoughts on resetting that position pulse monitor without messing up the drive? I was planning on just activating the feedback pulse monitor and seeing what came back. That's how I started with the position pulse monitor, just turned it on, figured out how it worked, and developed the rotational counter and positional change code from there. It works, but it was 600 program steps to get the permutations dealt with so I can accomodate things like: 1. Doing all the math to convert the desired length in thousandths of an inch into a rotational counter, then converting the remainder of that division into a partial rotational amount - the pulse monitor cycles from 1 to 4096, so the code has to handle passing through zero in both directions. 2. Holding the furthest value reached as the stop/start point before the backlash of the motor armature on the coupling after stopping the drive, in forward or reverse. 3. Doing this and counting correctly when the backlash value and the stop position are on opposite sides of a count point, depending on whether the motor changes direction when it restarts or not. The three drives all behave slightly differently in this respect. If there was a way to reset that position pulse value each time the drive stops, it would simplify my code considerably. Is that something you've ever heard of? I do it with a Modicon that I've worked on, and it really helps to keep the travel positions consistent. There are a lot of details in how this all works, and it does work well so far. The math and the rotational counters literally are accurate to half a thou. The only variation we get in the machine travel is mechanical. If anyone would like to know how this works, I'll do my best to share and save them going through the same learning curve. Have a great weekend. I will post the result of this experimentation again. B.

Hey Keith; It just looks like you need to split up the wiring for A and C, and add one isolated N/O PB contact to activate C on the second push through an active B. The B and D circuit needs to stay linked, as the only path to D through C while the button is pushed is through an active B contact. Then the flow will be as follows: push the button, only A comes on release the button, A stays on, B comes on push the button again, B makes C come on (at this point, the button could be released and the flow would continue) B and C make D come on D makes A go off A off makes B go off B off makes C go off C off makes D go off The thing I like about this circuit is that once the button is pushed the second time, the relay chain will continue no matter how short or how long the button is held, as the seal in hand-offs ensure that last relay to go off will always be D. Cheers! Speakerman

Hey Keith; Went back and looked at the code again, and I think I outsmarted myself in the first place! The close race condition was added to my usual code design with the intention of stopping any backdriving of the circuits - but that arose due to a planning error on my part, which showed such a possibility. Reviewing it, I don't think the circuit had any backdriving issues, so the N/C contact from R3 to R2 has been removed, and the circuit returned to the normal configuration that I generally use it. This now looks exactly like the standard PLC toggle chain for simple actions. The race condition has been reduced, as now R1 has to open it's contact, then R2 will start to open it's contact... it's still there, but R3 has a really good head start on R2 opening up. It could still lose the race, but you would need to be upside down, using your toe to hit the button, et al, and your pants must be on fire. The electrical drawing is still jazzed up for the fancy light show, but has been edited to match the refined toggle. Please put the fire-proof robes of litigation back on, and let me know if you think this circuit does the trick? Or have I made the all too common buzzer again, like all those ashtrays I made in woodshop...? Cheers, Speakerman Hardwired_Relay_Fixed.pdf

Hey Keith; Thanks for pointing that out. Totally missed it! My blond PLC roots are showing... It would eventually crop up, and probably more often than the yoga - inspired operating method you describe! BTW, is that an OSHA approved procedure? Do you need fall arrest? Looking at it in more detail, I see now how your circuit neatly uses the fourth relay to make the off/on transition stable in both directions, and that is absolutely robust. Although my design would probably work for a long time, as the reset relay will always be activated and already moving before the contact for the set relay breaks, it does have a definite path to failure, pun intended, which I do consider an unacceptable flaw. Well said, and thanks. Speakerman

Whoops, forgot to remove that redundant contact created when I put the jumper on the feed to Lamp 1. Here's the drawing again, with the redundancy removed. It's the smaller of the two files - couldn't delete the old one. Perhaps that better anyway. Cheers, Speakerman. Hardwired_Relay_Toggle.pdf Hardwired_Relay_Toggle.pdf

Hey guys; I agree with Keith that the circuit will work as drawn in a PLC but may run into relay lag time errors when the relays get old and start to wear. I do work a fair bit with older relay systems, (are there any other kind? ), and the activation for each relay will need to be consistent and fast for one to close before the other opens during a handoff. Re-writing it with three contacts on the button with individual wired leads to each of the relays solves any relay errors by making each transition from on, to off, to on, a positive step. It still has thirteen total contacts, but two of them are moved to the button itself, as each of the button contacts in the three rungs are individually wired. A N/O contact would be mounted onto the toggled relay for the output that you want to switch. Alternatively, you could mount it on the set relay, if you want the output to come on only after the button is released. This is identical to the toggle rung circuit I use all the time in my code, except for the addition of the reset relay on the set relay rung, which is added to eliminate any backdriving or relay lag problems. Both methods will work, but I think this one will work without any issues when parts get old. What do you think? Speakerman Hardwire_Toggle.pdf

Hey Crossbow, thanks for jumping in. I have tried the communication code, and there may be some interesting facts here for people who haven't used these functions before in the Mitsu environment. Here's how it went: I tried this for my Table feed drive, which uses D108 to D111 as instruction words to the VFD, and D208 to D211 as words back. Moving H13 into D108 sent the request to return the position pulse in the first monitored data word, which should have given a value back in D208. This didn't happen at first, as I missed one thing: you have to turn on the bit that drives RYC, which is needed to tell the VFD to write the monitored data to the word address RWr0. In my case, the coils written to the buffer memory for the VFD inputs were from M2164 to M2179, and I had to set bit M2176 high to tell the VFD to give me back the position pulse data. This did work, and data started to appear in D208. Here is what it looked like: The position pulse data word is (up to) a four digit number representing the position of the motor armature around the rotational arc, broken down in this case to 4096 steps, as there are 4096 pulses per revolution with the encoder we are using. The number was an absolute reference from 0 to 4096, wrapping with each revolution, starting at 0, counting up to 4095, starting again at 0, etc. It did not change when stopped, unless the motor armature was moved by hand after stopping rotation. It did give some excellent feedback into the mechanical backlash of the unit, showing how much the armature would spring back when the run command was released. We got our feed rate data by writing some temporary code to generate a count whenever the encoder value was higher than 2048, which worked to give us a revolution counter and, combined with the positional pulse data, allowed for calculating the distance travelled per revolution to a fairly precise margin. We ran it for 1000 revolutions, and added the difference of the positional pulse data for an absolute rotational change, mechanical variations aside. The travel we calculated worked forwards and backwards to within 10 thou, each time. The fluctuation was probably mostly mechanical. The amount travelled worked out to 52 thousandths of an inch per armature revolution, which is nicely accurate for the large scale machining this unit will perform. I could use this same method to build a register for monitoring and setting the distance travelled during a cut, but the scan time of PLC becomes significant at about 300 rpm. This is a speed that will be used for some cutting jobs. If the rpm was too high or the scan time was too long, the PLC may miss the position pulse value when it is between 2048 and 4095, and not count that revolution. If the VFD can return the number of revolutions since its last communication, the scan time of the PLC will not be an issue at any speed. We will slow the feed rate down as we approach the desired cut length to increase final accuracy. We can get down to 15 rpm, and the resolution of feedback pulses at that point is equal to about one thousandth of an inch per PLC scan. I need to be sure we haven't missed any revolutions, however, or the cutter will over-travel and could spoil the piece. The problem that remains is as follows: I still cannot find the data I was originally searching for, which is a pulse train of absolute encoder pulse counts accumulated from the origination of a run cycle - but if I could identify and receive a count of the number of rotations, and combine that with the position pulse data I'm getting already, I'd be home free. Does anyone know how to get that piece of information from the VFD? I still can't find how to turn on monitoring of that piece of data, unless its called by another name and I'm missing it. Thanks for any help that can be given, and I'll be sure to post the results of this endeavor. Speakerman.

Hey everyone; Well, it's another "can't find it in the manual" question, although I know I've seen it somewhere. I just can't seem to find it again - and with over 5000 pages of manuals, some redundant like crazy, I have to say this is my least favorite aspect of this new experience with Mitsubishi programming. I would expect that something so common would be found with simple searches, and be in mutliple places, but for the life of me, I just can't find the actual instructions of how it's done. I am using an FX2N© processor, with three A700 VFDs on a CC-Link network. Everything works great, configuring the CC-Link, checking for errors, resetting, sending run commands and speed frequencies, reading rotation direction, et al. I need to find the area in the manual(s) where it describes how to program a data request code from the PLC - the two separate ones in the first buffer memory data word location - so the VFD will return its count of the number of encoder pulses since its last data transfer. I can then add that number to a register array built to hold those counts, and then use that value to establish positional limits for moving the cutter heads driven by each motor based on a cumulative encoder count. All the data and manual references I have talk about vector control and position mode, but not specifically how to set a speed, then write a code to the first or second portion of the data word that tells the VFD to return the encoder counts in the data word passed back to the PLC. Does anyone know where that particular instruction or list of communication protocols resides? I have the encoder cumulative register code written, I have error handling, a positional input interface for the operator... I just can't find how to get the VFD to give us those counts, and get this part of the program to function. Here are the manuals I have already: JY992D66301-N.pdf SH_NA_080522ENG-J.pdf JY997D09101B.pdf JY992D48301-J.pdf JY992D94801D.pdf [693]Melsec_FX_Series_Programming_Manual.pdf JY992D88101-D.PDF IB_NA_0600167ENG-B.pdf IB_NA_0600255ENG-C.PDF IB_NA_0600254ENG-E.PDF I eagerly await the answer, and thanks in advance to whomsoever provides it. On the positive side, I am enjoying many aspects of this program and interface, and haven't yet encountered a function we've needed that didn't have a ready solution. It's just hard to find, sometimes, so here we are... Speakerman.

Hi FNMdeJong; Thanks for the response. I do have the parts you list, FR-A7NC and the encoder feedback card FR-A7AP. That section of the manual is one of the ones I had looked at, as it certainly seemed to be related. Position pulses are what they use to refer to an encoder pulse, I take it? And there's no mention of whether or not the pulse train data word is given as the number that accumulated between PLC scans. Is that what happens, in your experience? I'll build a rung to send the data code and see what comes back in RWr0. Thanks for the help, Speakerman.