IMPORTANT: A700 FRA7NC Information

[speakerman 4]

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

[panic mode 246]

hi speakerman, I appreciate your effort, I welcome and encourage sharing of your findings but i would also like to offer some guidance. personally i find description in previous post very confusing, specially when one considers that this was supposed to clarify or supplement manual. ihmo this has potential to help some but also cause even more grief and confusion to other users. content should be "to the point", for example: - 4-digit hex display on your HMI that has rolloever at 9999 has nothing to do with discussed VFD, at best it means that you are using BCD indication and display was not formated to show needed positions - the number of pulses per second is just speed feedback and this would be all that needs to be said - this post should not have been yet another new tread so people who read this, don't have to waste time digging through forum and finding bit's and pieces and connecting information like from "that previous thread". one discussuion (like reading status of the VFD) and all followup shoud start and finish in one and only one thread. i would like to ask everyone to refrain from starting new treads - unless it's something different of course. previous topics on the same issue are: http://forums.mrplc.com/index.php?showtopic=13412 http://forums.mrplc.com/index.php?showtopic=13196 - when testing some "black box" system, always establish what are static readings before moving to dynamics (specially short bursts). in this case it was VFD drive that was moved in short bursts and struggle to draw conclusions from readings that are not stable. short bumps are what is used to determine one-bit information (like motor direction). for analogue values (!) you need more points (may not be linear and - even if it is, it's hard to make sure that captured values are collected by hand and in right moment if the value is changing and there are delays in updating etc.). as far as I know you are trying to get position feedback from your drive. if the value is not provided "as-is" (raw or scaled) you will not be able to calculate it with sufficient accuracy, specially from speed info that is updated once per second. i would look into passing encoder signals to PLC (the good old KISS principle) or using separate encoder. regards

[speakerman 4]

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.

[panic mode 246]

no problem, i was learning along... good job and contratulation. there are way too many pieces of equipment out there where the hardware is not used to it's potential.