BLDC and fanuc redcap parameter problems?

andypugh wrote:

gmouer wrote:

Ok, here is the hal file I used for tests. I have a mesa 7i77 and 5i25 along with the parport breakout board. The encoder is connected through the 7i77 encoder0 inputs.

I wonder about this

#  Encoder A/B phases routed to parallel port for TTL level compatibility to AMC drive velocity feedback

net a-phase  hm2_5i25.0.encoder.00.input-a     parport.0.pin-05-out
net b-phase  hm2_5i25.0.encoder.00.input-b     parport.0.pin-06-out

Those outputs from the parport can only update at servo-thread rate. Above 10rpm the output will be rubbish.

I never gave that a thought and should have known better. Strangely though, the AMC drive must be getting decent signals to its encoder input, used for velocity feedback or I would have a run away condition in velocity mode that I am running. (been there in the past). The speed adjusts smoothly, motor is rough but no runaway thats for sure. Considering the low bandwidth as you point out, now I wonder why I don't have a run away. I have the servo thread at 2khz but thats still slow for a 3000 count encoder. Strange indeed. I will investigate further.

How about the rest of the HAL file? Do I appear to have BLDC configured correctly for the task at hand? Any suggestion for a range to try for encoder offset?

andypugh wrote:

gmouer wrote:

Strangely though, the AMC drive must be getting decent signals to its encoder input, used for velocity feedback or I would have a run away condition in velocity mode that I am running.

I wouldn't assume that. Perhaps the drive is getting very confused about the mis-match between Hall-sensor and encoder.

Is it possible to run the drive in pure current mode without the encoder input? It would be instructive to see if that is smoother.

According to the datasheet www.a-m-c.com/download/datasheet/be25a20ac.pdf yes, current mode is a option. I have never played with current mode at all with any drive so I'm pretty lost at the moment. Also if interest, I wondered what mode John Sheerin was running his drive in, I am awaiting that info.

Later, I was planning on looking over the encoder feedback to the drive and see if I can come up with a better solution. The fanuc encoder outputs about 3V which is fine for the mesa but the drive inputs expects ttl levels and may not switch at 3V, I will research tonight.

If the drive expects TTL levels, anything above 2.4V for a high level or 0.8V for a low level should be OK
(TTL thresholds are typically between 1.4 and 1.8V)

andypugh wrote:

Well, it looks like you just need to set some DIP switches and turn a potentiometer all the way left to set up current mode. It must be worth a try.

Also, have you tried twiddling the potentiometers to tune the velocity mode? It is entirely possible that the roughness is a badly-tuned velocity loop. Be aware that it would need to be tuned again when the motor is on a machine and loaded.

Yes, I attempted tuning the drive. I have used these drives with brushless motors, in velocity mode on my RF45 mill I retrofitted so I am pretty familiar with the drive. (at least in velocity mode)

PCW wrote:

If the drive expects TTL levels, anything above 2.4V for a high level or 0.8V for a low level should be OK
(TTL thresholds are typically between 1.4 and 1.8V)

Will have to give it a try.

I used the same drive, kelling brushless motors, along with AMT103 encoders on my RF45 mill. I made the mistake of getting line driver cables for those encoders, the output from the chip in the cable was only 2.4 volts and gave me a run away condition with the drive. The encoder feedback inputs on the drive were not switching. I removed the line driver chip and got 4.8V directly out of the encoder which the encoder feedback recognized nicely. This is why I had concerns of the 3V level not working with the drive although I did not try it. I was just going from past experience with the drive.

The 2.4V in my prior retrofit might have been right on the threshold, hopefully the 3V out of the fanuc encoder will work on the drive input. Also, I am not sure the drive is indeed ttl levels, it only says 5V, so I was guessing TTL.

I am going to try the encoder A/B direct to the drive tonight. (in parallel w the 7i77 encoder0 input that is now connected) I am in complete agreement that running the encoder feedback through the parallel port could be causing unknown funny's due to bandwidth, going to eliminate that possibility.

Ok, here is a update.

Last night I connected a DVM to the AMC drive velocity monitor output. That output comes directly off the frequency to voltage converter used for encoder feedback in the drive according to their schematic. I have used this output before to troubleshoot encoder feedback to the drive.

In the original configuration, no output was seen on the velocity monitor. That means the drive was not "seeing" the encoder input.

Next, I moved the encoder A/B outputs directly to the encoder feedback inputs on the drive. STILL no output seen on the velocity monitor output. The drive did not "see" the 3V fanuc encoder output.

Next, did a little research. Apparently I was wrong, the drive encoder input is NOT TTL, TTL would switch with the 3V input. Looking at the CMOS spec, that says 3.5V for a logic one, so I am now saying the drive input is CMOS. Past experience with these drives has always been with a 5V input to the encoder terminals which worked nicely.

After some thought, I decided to run to the local radio shack today and pick up a TTL nand gate which I will use to convert the 3V output of the encoder to a level that will trigger the drives CMOS input. (radio shack has a 5 pack of TTL chips including nand, schmidt trigger, etc) That SHOULD do the trick.

Note: I did not attempt torque mode on the drive just yet. First I want to get the proper velocity feedback into the drive and see how that effects the behavior. I am extremely curious if proper velocity feedback will smooth out the motor running. After all, the drive is not operating in its intended mode with that input missing. It will be interesting to see ! Of course, encoder driven BLDC is still the end goal but one step at a time.