Does VEX make any optical disks for the IME’s that are higher resolution than the standard one that ships with the unit?
Sorry, but no. Why did you feel higher resolution was necessary?
I do not believe there are any other discs for the IME. However, depending on the motor gearing you use (soeed, torque, or turbo), there will be a different number of ticks corresponding to one rotation of the output axle.
It’s for the launcher wheel speed control. Resolution isn’t great right now, but workable. Nervous about changing the gear ratios since the kids are having good scoring results with no battery or fuse issues.
Did you see this thread?
Flywheel velocity control
I though resolution for the IME (in a motor with the speed gear set) was going to be fine. What resolution are you looking for at the flywheel? In my mind the limiting factor is motor control resolution (the useful range of motor control values will be perhaps 70 through 100) not the ability to measure the flywheel speed.
We are ending up with a control point of 20 at 50Hz.
Ok, do you mean that the IME changes by 20 every 20mS? So in one second the IME changes by 1000 counts? If so then the motor must be running near its limit (a typical 393 will do about 1100 counts/sec free speed).
50Hz for monitoring flywheel speed is probably too fast. I would calculate the speed at perhaps 10Hz-25Hz. Motors ports 2 through 9 are not that responsive due to delays in getting the motor control value through to the MC29 (port 1 and 10 are much better), the delay is anywhere from (approx) 20mS to 40mS so no need to send a new values any faster than that. There will be jitter in the motor speed measurements but the momentum of the flywheel is going to tend to smooth all this out anyway.
Hi spearman,
Yes, they are at 1000 to 1100 pps setpoint from the 393 torque gear config.
The output launcher speed is good and so is current, so they don’t want to change to speed gearing, which would decrease the effective IME resolution anyway. I looked at your quad encoder post, not thrilled about the A/B lead/lag, symmetry is very iffy at speed. But, maybe workable in their operating range depending where on the gear train it would sit. But, they have seen a lot of friction from the encoder wheel if it isn’t lined up dead nuts when trying this.
Very good info on the motor posts, got rid of a dynamo in my garage that would have been great for measuring these, kicking myself. Would have been a great teaching tool.
On the port issue, is the period 18 or 20ms on ports 2 thru 9? Also, 1 and 10, how fast does RobotC update these? i.e. if we update from 50 to 127 on the motor port, does it load the PWM generator immediately so they come out the next cycle? 800us?
Thanks so much
See this old post.
Best motor update speed
There are two delays involved for motor ports 2 through 9.
User processor (running our code) sends a command to the master processor, this happens approximately every 15mS (actually 16mS in ConVEX). Master processor sends an RC pwm pulse to MC29, this happens about every 20mS. So worst case delay could be >30mS before the MC29 sees a new speed command. There may be further delays in the MC29, not sure I ever measured that.
Ports 1 and 10 will update the pwm output at at least 500Hz, it all depends if a direction change is needed. Some more old tests here.
Not all motor ports are created equal post #5
Thanks so much,
So one clarification, when you say the host processor runs motor control, then does it drive the h-bridge for ports 1 and 10 directly not the user processor? So we could still have a delay of up to 15ms for output update on ports 1 and 10 due to the need for SPI transfer from the user to host?
There are two processors in the cortex (somewhere I posted a diagram before but cannot find it right now). The master processor runs VEXnet etc. and creates the motor control for ports 2 through 9. The user processor, where our ROBOTC code is running, directly controls the H-Bridges for ports 1 and 10 (although the master processor has the ability to also disable them). Motor control values for ports 1 and 10 never go to the master processor, only ports 2 through 9.
Edit: The block diagram in this post shows the cortex architecture, the H-bridge motor is not shown but connects to the user processor.
https://vexforum.com/showpost.php?p=329197&postcount=3
Is it viable to use a Y-cable to split 1 and 10 so 2 pairs of 2 motors can be used?
Will that overload the H-bridges do you think?
For competition that is not legal.
If the motors stall, yes it will overload the h-bridge, they are rated somewhere around 8A (forget the exact number).
Thanks, I was going to check with Karthik on the legality since there were no mods to the wires.
It’s pretty clear that it is not legal. Even if it were, I wouldn’t do it anyway, there’s a serious risk of damaging the cortex.