We are a team that has never really done well in programming. We have went through and programmed some and wondering if we are doing it right. Would you please look at the programming and see if it will work!
Benson First Robotics
Begin VI
We are a team that has never really done well in programming. We have went through and programmed some and wondering if we are doing it right. Would you please look at the programming and see if it will work!
Benson First Robotics
Begin VI
I don’t immediately see anything wrong, are you having problems?
We haven’t been able to run our program yet. Hoping to try on the simulator tomorrow. We have set our goals high this year to have a working robot before we go down to the competition and it seems like it is going too easy. We are concerned because on the teleop vi we had orange dots show up on the t/f indicator.
The orange (red) dots mean you’re forcing a TypeCast. They serve as a warning of “Hey, I’ll convert this data for you, but it might not be right in the end.”
How did you create those Forward and Reverse Enums?
You should right click on the Solenoid Set and click Create -> Constant.
From there, copy and paste to the left of your T/F selector and then select the constant you want.
The dot mean that the program is converting from one data type to another. They are compatible but something is different. It was developed to make you aware because this conversion takes time for executing the code. If you have coercion dots it will take longer for your code to execute.
Here is what the help file from NI says:
Eliminating Coercion Dots to Maintain Accuracy and Optimize Memory Usage
Coercion dots can affect memory usage or overall performance of a VI in the following ways:
Type definition coercions—If you wire an instance of a type definition to an object that does not link to the same type definition, the VI may generate inaccurate results.
Scalar numeric coercions—If you manipulate different numeric types, LabVIEW coerces the data types to match. When this coercion occurs, the VI may generate inaccurate results.
Large array coercions—If you coerce the data type of a very large array, the VI may use a large amount of memory and take longer to execute.
If you have more questions we are here to help.
Right now you have an arcade drive programmed with a tank drive name on it. It will still work if you want arcade drive (at least I think so) but if you want tank drive you will need to open another joystick in the begin.vi as well as program the joystick in the teleop.vi, for tank drive you will only need the second axis from the dropdown (this is the y-axis value of the joystick whereas the first axis is the x-axis) here are some screenshots for how I did it for my team.
Also, your left side motors are inverted while your right ones are not, again not really sure if that is intentional or not but if you don’t want them to be inverted just toggle the t/f box on the inversion.
I have a feeling they’re using a game pad. Not too many joysticks have over 3 axes (X,Y, Throttle, Twist are the most common I know of). Good catch though, you might have caught something.
That’s very common if you wire your motor controllers with red motor lead going to M+ and black motor lead going to M-. All this does is invert the output. Probably not a mistake.
We are going to try and use an Xbox 360 controller to run the robot.
We were able to fix the coercion dots. Thank you all for the help! I know there is a way to test the code on the simulator. Is there a way to do this?
Thank you all again!
Maybe. The LabVIEW simulator is pretty limited in what you can add and remove to your robot without digging in to XMLs, CAD, etc…
Check out Tutorial 10 - Robot Simulation on the Tutorials tab of the LabVIEW Getting Started Window.