I'm not sure you're understanding what I'm saying as your post isn't telling me anything I don't already know. I've tried all these methods of making the mini-flipper work already:
Method 1> Direct control by internal mech using the getmech(0) (i.e. position) data. This method works the most lke the real thing, but it slows to a crawl at times for no apparent reason (you can see this if you just run the DMD in full debug mode and put a simple timer in place to activate switch 30. It will not run consistently each time you start the table. The flipper should move at a slow to medium speed when the game starts and sometimes it will, but other times is CRAWLS (watch how slow the numbers move) and then the game wonders internally why the home switch hasn't been activated (because it's going too slow to get to that position which tells me it SHOULD NOT be going that slow PERIOD or the game wouldn't go into "search" mode where it starts reversing the motor and altering speeds. The problem is when it switches back to the same direction it's usually moving the same CRAWLING speed (we're talking maybe 20 seconds to make 1 revolution SLOW type speed here) and so it then switches back yet again. The really funny thing is that if I land the ball in the saucer while it's acting all crazy slow, the game will suddenly kick the flipper into high gear and move much faster and then it starts acting normal again... for awhile until you land another saucer shot and then it might start acting up again.
I can ONLY conclude there's something fracked up in the internal mech handler as the flipper should NEVER move that slow and yet ONLY VPM is controlling that position code using this method. The ONLY thing I do is set the switch 30 to activate across a small range around position 0 (the same range Gaston recommended).
Method 2> VBS mech handler. This uses the onedirsol method with both solenoids. This has two odd behaviors and one major limitation. The major limitation is there is no speed control. The two odd behaviors are that the flipper motion is slightly jerky (not smooth despite having 72 frames so it SHOULD be smooth) and I think that's due to the odd timing behaviors associated with the VBS mech handler under some circumstances and the other issue is that you have to order the frames backwards because the VBS handler has no way to tell it the direction to go with the 2nd relay solenoid. It defaults to the wrong direction (i.e. it's going counter clockwise whereas I numbered the frames clockwise so I have to reverse them since I can't reverse the default direction in the VBS mech handler as there is no switch for that.
3> Custom Mech Handler. This method uses a simple timer control for the animation and switch data and uses solenoid 27 with a flag to determine which direction to count. I can easily set the correct direction just by changing the flag value. Solenoid 25 controls whether the timer is running or not. This results in ultra smooth visual operation and correct directional behavior as long as the timer is set within a valid range (8ms-52ms or so per frame with 72 frames works OK; if you go much slower, the flipper will start acting up in that "search" mode again (which tells me that the game was never designed to have that flipper move slower than a certain rate or it thinks its broken). The only problem with this method is that there is no speed control. The flipper will always move at the rate the timer is set to. That is functional, but not accurate to the real behavior, whic has the ability to move at different speeds.
4> Custom mech code but using getmech(1) (i.e. speed/direction) data to alter the timer interval so that method 3 might work yet have speed control. I've tried just using 3-4 set possible speeds and using a 2nd timer to "smooth" (acclerate and deaccelerate) while "switching gears" so-to-speak so it doesn't just suddenly start moving much faster/slower. Neither method works right. The speed data is too limited coming off that getmech call with only 4 possible values for each direction (1-4 either positive or negative to indicate direction). You might think well that means there's only 4 distinct possible speeds for that flipper and it would be OK. Nope. It fluctuates between those numbers very quickly, resulting in odd/choppy/jerky looking motion (not totally dissimilar to the jerky movements in method #2, but a lot worse since it's speed related to the internal mech handler data being shoved out, not just a timer issue. I thought maybe using a smoothing timer would help, but it just seemed to make things worse overall. Worse yet, the speed data seemed to get the position all out of sync somehow (probably because the speed data coming off that get mech is wrong or too limited) and that then causes more weird "search" behavior soone or later and VERY choppy behavior at that since the speed data seems to go wild in that mode.
Basically, I know of no other possible methods to do a mech handler for that mini-flipper. Method #3 is the only "reliable" method in the sense that the flipper motion is constant at least and doesn't do weird things like slow to a crawl or move jerky or get out of sync. But it can't speed the flipper up. Method #1 behaves exactly right at times, but it seems to suffer from kicking into majorly SLOW speeds that the game just doesn't expect to see (I'm guessing there's an error in the handling code as it should never move that slow and the motor solenoid just comes on; it doesn't pulse so it's the internal speed calculations that causes that internal position and speed data to go to a crawl, etc., not the solenoid callback signals.
I mean the fact is if you try these methods yourself on a little mock setup (you don't exactly need to make the whole table to test the flipper out since it's just 2 solenoids and a switch and a few dozen flippers flipped through using the ".visible" attribute, you'll quickly see that what I'm saying is true.
They best fix would be to correct VPM's mech handler so those "too slow" speeds never occur as those are what screw things up. Again, I'm not sure offhand what exactly is causing it to go that slow at times internally. It has nothing to do with the switch position, but the internal speed calculations where apparently something is a bit off.
Otherwise, the only other option is to just use a single speed handler as described in method #2.