Encoder feedback from VFD's on CC-Link

[speakerman 4]

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.

[FNMdeJong 7]

See page 74 of the CC-Link option board (FR-A7NC). There is the code mentioned about the position pulses you request. (Manual : IB_NA__0600167ENG.pdf) A small detail, I suspose you allready mounted the encoder feedback option card (FR-A7AP)??? Succes

[speakerman 4]

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.

[Crossbow 295]

My guess would be a complete count, not scan by scan, as that's typical of the Mitsu PLCs with the pulse inputs. The A700 has basically an AOJ2H CPU inside.

[speakerman 4]

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.