We are using the REV swerve drive module with NEO motors and Spark Max’s and we are having problems with our encoder where the encoder values within periodic tasks aren’t being read from a subVI that’s also within periodic tasks.
If anyone knows of a LabVIEW code that uses the REV swerve module and NEO motor controllers then please link it. We also would like if anyone would be able to help us personally and look at the code through a Zoom call. Our first competition is next weekend (Mar. 7-9th) and we are not sure if we can compete unless we get this done so we will take any help we can.
Can you post your own code? We haven’t used LabVIEW for a few years and never used NEOs for swerve specifically, but I’m familiar with both LabVIEW swerve and using the LabVIEW SPARK Max API.
What does not being read mean? Is the encoder value not updating? Does it just return zero? Does it throw an error?
Edit: I missed that this was 6 days old, but if you still need help of any sort, I should be able to provide it.
It not updating, it just returns with a value of 0. I’ll post the code in around 2 hours. If you can Monday, Tuesday, or Wednesday be able to Zoom call us please DM me.
It would also be helpful to understand the hardware you are using. Looking at your code, if looks like you have an encoder plugged into the spark max data port, is that correct.
Why type of encoder is it? Rev Thru Bore?
You commenting and naming convention should be a bit cleaner. You name your steering motors “drive” and your drive motor “motor”. It can be confusing. Are you sure you have the encoder plugged into the correct Spark Max as a result.
Debugging process I always start by making sure the hardware is good:
Plug into the REV Spark Max using the client and go to the Absolute Encoder screen and make sure you can read the encoder. This makes sure that the encoder works, it is plugged into the correct spark max and with the correct CAN ID.
In Period, move your get ref num out of the while loops. It is a time consuming activity and you don’t need to get it more than once since it never changes once initialized in begin:
Also in your periodic tasks there’s no time delay in the upper loop. That’ll hog CPU time. Here as well all the RefNumRegistryGet blocks should be outside the loop to improve performance.
(And you could clean it up a little to fit on one screen, something I about clean LabView code)
@sthump’s already outlined a few issues, but there’s more; you need to select the correct encoder type for one. It’s hard to know what that is since you haven’t said. What type of modules are these? REV MAXSwerve? Something else?
There’s some general code logic problems. Your post processing vi is being called from a while loop that never exits, and is also inside a while loop. That’s not good, as the outer loop will never actually loop because the inner loop will never finish (and outputs will never be sent to your motors). You should remove the while loop in the post processing vi while keeping the code inside (you can do this by right clicking the while loop).
I suspect you’ll need to increase the output of the steering motor, but one thing at a time.
Finish.vi never actually executes under normal operation, so this isn’t really all that useful.
I also noticed in the Begin that they were using the older, depracated versions of the Open and SetRef pointing to not having installed the newest REV.
I have always thought that if you didn’t finish, launch code in debug mode, i.e. hit the run button, and then kept doing that without power cycling the robot you eventually run out of memory or some sort of resource.
It is true, in competition, power cycling solves all of that but in development, without closing devices, something bad eventually happen.
I have never tested it fully but I have always taught my kids it’s just better to close it. If REV gives you a close, I am assuming they found a reason to do so.
I’m not entirely sure what the behavior is when you hit stop vs. the button to call Finish, but I was either a student or mentor for a LabVIEW team from 2013-2022 and almost always hit stop. We never had a memory issue.
I believe the application’s memory usage is cleared when you hit stop, but like I said, I don’t know for certain. The fact that you can set a refNum of the same name again though implies stuff gets cleared, as that normally throws an error.
Properly setting up Finish and calling it can’t hurt of course, but when a team is struggling to get their drivetrain working and has an event in three days it’s the last thing I’m worried about.
about clean LabView code)