So from what I read on how to program Mecanum wheels so far:
Under Telop, switch Arcade Drive to to Holonomic Drive.
My questions are:
Do you configure the code under Begin.vi and Telop.vi etc, to 2 joysticks?
And what other additonal things do you need to do to have mecanum wheels?
There is a VI in Begin.vi that says something like “Open 2 Motor Drive” that needs to be changed to “Open 4 Motor Drive”. These VI’s are under “WPI Robotics Library > Drive” (I think). You then need to run 2 more PWM port constants into the VI (there needs to be a PWM constant for Front Left, Front Right, Rear Left, and Rear Right). You also need two more inversion boolean constants to run into the new VI which will tell it which motors to invert (not strictly necessary, should default to “false” and then you can just wire the motors accordingly, but it’s good to specify).
As far as joysticks go, it will be under “WPI Robotics Library > Driver Control?/Driver Station?”. You need an “Open Joystick” VI and the VI which sets the joystick refnum (picture of an arrow pointing to a file icon). You then create a string constant for the “Open Joystick” VI with the name of the joystick (like “Joystick 2” or “Rotation Joystick” or something). You also need to create a constant to tell which USB port to look at. You then wire the refnum cluster from the open VI to the refnum VI. You should also run the error wire through and open a new spot on the error array block (where all the dark green lines run together, drag down the bottom of that block one spot, and run the error wire from the refnum VI to that new spot.
To access this new joystick, you’ll have to use the other joystick refnum VI (next to the other one, arrow pointing away from a file icon), and wire it to a Get Joystick VI. This will have breakout pins for the axis and button clusters. You can open both with an “Open Cluster By Name” block (can’t quite remember what it’s called, but it’s something like that).
Note: I don’t have access to LabView right this moment, this is all from memory, so your milage may vary.
Thanks a lot, I will start programming this afternoon, and if I have any questions I will be sure to contact you. 
The holonomic drive vi wants three inputs: magnitude, direction, and rotation.
Magnitude is a value from 0 to 1 describing how fast you want to move.
Direction is an angle in degrees, with zero being straight ahead.
Rotation is -1 for full speed counterclockwise, +1 for full speed clockwise.
Rotation could be taken directly from a joystick axis, but magnitude and direction are a vector that you’ll have to derive based on how you want your joystick control to behave.
We made our own SubVI to replace the example’s Joystick Read. It uses the difference between the left and right joysticks’ y axes to determine rotation. The average of the y axes and the average of the x axes go into a rectangular-to-polar coordinate conversion (the Re/Im to r/theta vi), and the angle from that conversion is further scaled and rotated to match the “0 is forward” requirement of the holonomic drive vi.
http://www.facebook.com/CAG.Vignesh56?v=photos#/photo.php?pid=3343472&id=600658907
This is what I have done so far. What else do I need to do with the other VI’s? should I change Arcade to Holomonic in Telop. vi?
hey what is the phase when the vector is Zero? and which if any motors are inverted?
You should if you want to control a holonomic drive system in teleoperated mode.
The direction is unimportant when the magnitude is zero.
Which motors need to be flagged as inverted depends on which direction the motors want to move the robot when you apply “positive” power control. If you don’t want to trace the wiring and gear directions, you can just put the robot up on blocks, try running the robot forward, and see which motors are going the wrong way.
oh one other thing what is the scale that comes out of the magnitude?
how did you have to scale it?
Magnitude has to be between 0 and 1. The most general way to do it is to have the Y and X axes of one joystick just act as point-and-shoot and use Pythagorean theorem (Magnitude = sqrt(X^2 + Y^2)). However, this results in a scale of 0 to 1.141, which means that with the limiting blocks they have inside Holonomic.vi, when driving while using multiple joystick axes with high values, come of the motor values will get capped, so you won’t quite end up with the right vectors (because the over-1 magnitude will cause the motors to try to go faster than they can).
One way to get around this is to multiply the magnitude by .7, which will bring the max value back down to 1. However, this means that you can’t go as fast forward or sideways, and you’re only getting full speed diagonally. The way I prefer is to measure all of the motor values, and if any of them are out of range, scale all of the motors down to the most out-of-range motor (if the fastest motor is getting a value of 1.141, divide all of the motors by 1.141). This allows you to have full power in all directions, while maintaining correct vectors.
Just FYI, very similar changes were made to the WPILib code a while back and will be in the next update.
Is there a date as to when this is going to be released?
…Forest
Just to let you know with mechanum wheels it is very important that you have all WHEELS turning the same speed because as we all know motor speed is not very accurate some time i recommend putting encoders on your wheels using one joystick and a button to switch between tank drive and strafing back to the encoders 100% sure you will need to use PID but the benefits will show when you get it working
Looks like it will be next week.
the best way to scale the input into the holonomic drive vi is to set a case for overflow
if > 100 then = 100
that way
.70=.70
.80=.80
.90=.90
1.00=1.00
1.41=1.00
So, this has happened twice so far this season 
First, it’s the scaling I added in, and then this week, it was the single Jaguar CAN refnum VI I hacked together (and got working, thank you very much) that we just got the update for. I seem to be coding one step ahead of release…
Great minds …
And that is also why WPILib ships with source code in each of the languages. So you don’t necessarily have to wait for us.
Greg McKaskle