BLDC controller target velocity update rate

[daclmc]

I am trying to use the BLDC motor controller, in speed control mode, as a position control with the position loop closed in software (the reason is I need higher resolution position data than can be derived from the hall effect sensors, so I have an encoder connected and reading on the computer).

The software is showing an acceptable update rate reading the encoder and calculating the output (about 2k samples/second), But I find when I go to write the new target velocity to the BLDC controller, it is taking about 20 ms-- calculated by the time from when I call PhidgetBLDCMotor_setTargetVelocity_async to when the completion function is called. So I can only get an effective update rate of around 50 samples/second. It is sort of working, but I feel it needs around at least 200-300 samples/second for smooth position control in my application.

50 samples/second seems slower than what the USB/VINT interface should be capable of, so I'm wondering where the speed limitation is and is there anyway to improve it? I am aware there is a function to set the update rate of data going the other direction, TO the host, but the documentation seems to imply it wouldn't affect the rate at which I can send data to the Phidget (I haven't tried changing it). I am using the 6 port VINT hub connected to the computer over USB.

[Patrick]

DCC1100 is a low-speed isolated VINT Phidget - so that means comms at 10k bits/second. It's polling rate is 8ms - so it is asking for commands from the Hub every 8ms. With the comms overhead, and the polling interval, as well as the overhead from USB, and the processing of commands on the Hub itself, 20ms average is not very surprising - I believe if you measured it, you would see some 16ms and some 24ms latencies, corresponding to the 8ms polling interval.

Have you tried the MotorPositionController API? This is designed to handle the control loop on-board, as the latency is too high to really manage it from the PC.

-Patrick

[daclmc]

Thanks for the explanation Patrick.

Regarding the position controller API, Yes, I have used this and it works well, but the problem is I need higher resolution than just using the Hall effect motor position sensors. So I have a quadrature encoder signal I am using for position-- I don't see anyway to feed this into the Motor Position Controller API of the BLDC controler. Is there possibly some work around to do this?

[nm17]

The MinDataInterval on dcc1100 is 100ms so I always assumed that polling data after than every 100ms is just reading stale data.

I have the opposite issue where my hall effect sensor gives good precision readout but I can't control motor quick enough as the data rate is 100ms and my move completes in 200ms. So by the time I could read out the position it's too late and I am either over or under shooting.

Are there any plans/timelines to make dcc1100 1Mbs phidget?