FRA7NP Encoder rotation count? Or pulse monitor reset?

[speakerman 4]

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 Edited 1 Mar 2008 by speakerman

[panic mode 246]

you are correct, it is not very clear, in fact that document has word "feedback" only once but it does mention that this option requires FR-A7AP (manual IB_NA_0600238ENG-A.PDF which is also very minimalistic). as you know, FR-A7AP is used to add encoder feedback. according to page 74 of the IB_NA_0600167ENG-B.pdf, H23 is just a pulse (feedback pulse) and shows no increment value (like revolution). based on this, H23 should only have two values ("on" and "off", probably only one bit changing). since you have the unit, can't you just monitor it and see what it does? i could imagine few things for example: - direction - one pulse per revolution (not sure what would pulse length be, maybe 180deg?) - one pulse per specified travel (see page 33, parameter 430 of IB_NA_0600167ENG-B.pdf) - since H23 seam to be 16-bit value, i would expect posibility to show number of revolutions etc. good luck

[speakerman 4]

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.

[speakerman 4]

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.

[cadomanis 0]

speakerman, You have taken on a challenge that by I an a senior Mitus Apps enigineer I frequently work with have been stuck on for awhile. If you don;t mind sharing the code, I would love to see what you have done. I am about to start doing some research into the sam idea, trying to only use the drive's encoder card to get data into my PLC and it sounds like you have figured most of it out. I am supposed to be getting some Mitsu assistance with this, and will certainly post any results I can share. Thanks for all the leg work. C

[speakerman 4]

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.

[speakerman 4]

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