closed loop stepper and gearing issue

[Martin.D]

Hi all,

We have 2 steppers and we are using Flexmotion & LabVIEW. We use electronic gearing and the master is (and must be) configured in closed loop mode. A gear ratio of 1:1 is used, the master spins in velocity mode (and the slave follows) and point-to-point moves are then superimposed on the slave. Our application requires us to control the relative angle of the two motor shafts while they are spinning. All works as expected when the master is in open loop mode. But when the master is in closed loop mode: after stopping and starting the master the superimposed moves go in the correct direction but not as far as they are commanded it seems. I'm thinking this may be something to do with pull-in moves and gearing but I'm not sure. I'm going to try and find a way to read the number of pull-move applied and see if they match the error, but I'm not yet sure this is possible. Does anyone have any other ideas for us to try?

-Martin

[Jochen]

Martin,

everything should work fine if you don't use a master axis but a master encoder (= encoder of the maste axis). In this configuration it doesn't matter if the maste raxis does some pull in moves or not and the slave axis will always follow the real position of the master axis.

Best regards,

Jochen Klier
National Instruments Germany

[Martin.D]

Hi,

We have tried that, unfortunatley it still does not work. Last night we decided to try a virtual master (an axis with nothing connected) and have both our motors set as slaves. Unfortunatley that does not work, with both motors set as slaves with a 1:1 gear ratio over night the motor shafts drifted by almost 15 degrees while spinning at 100rpm (driven by the virtual master). All axis were set to open loop. We are currently using NI-motion 7.4, PCI-7358, LabVIEW 8.01. Since we now have the motors both as slaves this opens up some more things for us to try: virtual master in closed loop, slave the second slave off the first slave (encoder & axis), we may even have to resort to that unsatisfactory work around mentioned in my other post (closed loop stepper and gearing issue). Please help urgently the customer delivery is already late, this could turn out to be one of those projects with a non-satisfactory conclusion if we don't resolve this issue soon.

-Martin

[Jochen]

This discussion is also related to this thread.

Martin,

in general I can think of two scenarios that could cause this issue:

1. The slave axis looses steps and as it's running in open loop mode this can't be compensated.
2. The PCI-7358 doesn't generate the correct number of steps. I haven't been able to find any evidence that this could be the case but it's still an option.

In case 1.) there is not much we could do about that. The only thing you could do is to check if you can increase the current of your drive and decrease accleration and deceleration values.

I don't have exactly the same setup here as you do, but I will do my very best to reproduce the issue. What I can try is running a virtual axis in velocity mode as master and a real axis as slave. The slave axis will run in open loop mode but there is an encoder connected to it so I will be able to compare the commanded position and the real position.

Could you please tell me the steps/rev value of your axis? This will help me to run the axes at the same velocity as you do.

I'll post my results soon.

Jochen

[Jochen]

Martin,

I have been running a test for almost 1 hour now and the master and the slave axis have stayed perfectly in synch. The slave axis' commanded position and the encoder value are exactly the same (I have a motor with 2000 microsteps/rev and an encoder with 2000 counts/rev).

I don't know if this is relevant, but I'm using NI-Motion 7.5. I haven't found an explicit hint that 7.4 contains bugs in the step generation that are fixed in 7.5 but you may give it a try.

Here is another idea: What type of drive are you using and how is it connected to the 7358? I have seen several cases where the output high voltage of the step signal from a 73xx was pulled down to a value below 2.5 V which could also result in a step loss when the threshold of the drive is close to this value. This happens if the input impedance is quite low compared to the 3.3 kOhm resistor that is used as a pull-up resistor to +5V at the step output.
The output can sink up to 64 mA so you can safely connect a 200 Ohm resistor from the step output to +5V (e. g. available on an UMI-7764) to increase the output voltage of the step output (the same is true for the direction output).

I hope this helps,

Jochen

[Martin.D]

Hi Jochen,

Thanks for helping us with this because it’s causing our company major issues. We have 4000 steps/rev and an encoder with 4000 counts/rev. I do know that the issue is velocity and electronic gearing related, the commanded position and the encoder position stays perfectly in sync for most velocities but 100rpm and 1:1 gearing ratio is what we use to make the system go wrong. Remember that running the axis independently (no gearing) at 100 rpm is fine - the two motors stay in sync. So I don’t think it’s a wiring issue. I’m quite sure that out of the two options you put forward we have issue 2 (The PCI-7358 doesn't generate the correct number of steps) – unfortunately. I hope you can recreate the problem at your end, Are you running the master at 100rpm if so try 80rpm and maybe double / half these speeds because of the your motor & encoder has half the resolution. Also our slave is in absolute operation mode. Also try comparing the master axis' commanded position and the slave encoder value. I am explicitly enabling the encoders in LabVIEW and polling them in a 100ms loop, I know this is not deterministic but we have established that if we plot encoder 1 – encoder 2 that if the noisy line has a gradient (over about 5mins) the motor shafts are drifting, we can confirm this due to the resulting product. We are using a laser to spin optical lenses that cut different size holes depending upon the relative angle. And sure enough when the gradient of the line changes the hole size changes as well – this is our problem.

I will try and match your setup this end to confirm that you should see the issue.

I will also try version 7.5.

I have also started to think of an alternative implementation. Do you know could we achieve the desired control by using a vector space? The relative angle changes are pre-defined and form a profile that is superimposed onto the base velocity.

I will not be here for about 15hrs now, so I’ll pick up any of your results in the morning – Thanks again.

-Martin

[Jochen]

Martin,

I have configured my virtual axis and my real axis both with 4000 steps/rev and I ran my master/slave application for 15 minutes at 100 RPM.

Good news first: I have been able to reproduce the issue. After this period of time I have seen a deviation of 150 counts between the encoder and the commanded position.

The bad news is that this is probably a verification that there is an issue in the firmware and we probably can't provide a fix immediately. I will forward the error description to R&D and let you know what they can do.

Now let's think about a workaround. I think the best solution is using a 2D vector space with contouring. Are you familiar with contouring mode? In this mode you can provide a position buffer containing position data for up to three axes in a vector space. Please refer to the existing examples for more information.

Jochen

[Martin.D]

Hi,

I'm pleased you have managed to recreate the bug at your end. And yes I am familiar with contouring, I can see no reason why this will not work for our application except I may have varify the user definable profiles due to the memory restrictions on the card, but I think there is enough memory, on the other hand I think a rolling buffer is also possible - best I get busy now!

Thanks for your help.

-Martin

[Martin.D]

Hi,

Just thought I would let you know that we are now using contouring and not gearing for our application. The system has been running for some time now and has proven to be very accurate and reliable. Thanks.

-Martin

[Jochen]

Martin,

thank you for this information. I'm glad to hear that this solution is working for you. Our Motion Control R&D group is currently tracking down this issue. I feel very confident that they will be able to provide a fix in one of the next releases of NI-Motion.

Jochen