Glitchy motor behavior, requires double code upload to fix
 

https://www.reddit.com/r/FRC/comment...s_double_code/
X-post: http://www.chiefdelphi.com/forums/sh...30#post1454330

Like clockwork, when the robot first powers up and code is uploaded to it(play button in labview,NOT deployed) the CAN talon srx refuse to work. However reuploading the code fixes the issue. It's not just the SRX sometimes it's the drive motors(victor 888) too. So some uploads the talon would work but the robot won't move, re-uploading code also fixes that.

that's not even the end of it, sometimes pwm port 8 sends a value to a servo which I never send it! I send an inverse position to ports 8 and 9 and while 9 always works fine, sometimes 8 goes to a position I never set the value for and it's always the same position. I never send it this value and when it does that port 9 which should be the mirror position works fine.

EVERYTHING is updated with the latest firmware as of this post's date. In fact, doing a labview update with "NI update service" actually breaks code deployment completely(see other post about this issue).

ideas?

Re: Glitchy motor behavior, requires double code upload to fix
 

Try waiting for code to start, then clicking the restart robot code button on the driver station. Does this cause the problem to go away?

We're experiencing the same thing in Java, and we currently believe that it has to do with the date/time.

Re: Glitchy motor behavior, requires double code upload to fix
 

Jared, I don't think we should assume your issue (which seems to be temporarily alleviated by re-imaging) is the same as the OP. And by the way is it still happening?

sanelss, so you are saying that when your robot powers up and you teleop-enable....
1 - Your CAN Talons don't move at all? Are they blinking orange or solid orange? What does the web-based config self-test says? Check the mode and throttle as well.
2- Your PWM Victor 888s dont' move at all? Are they blinking orange or is the led solid orange?
3-Your PWM channels 8 and 9 are nonzero when they should be zero? What are the Victor LEDs doing?

more questions...
[4] What does your driver station messages list say?
[5] I assume you are creating motor controllers in Begin.vi. Are you wiring safety-config? If so I would set it to 'disable' to rule out watchdog events.
[6] Anything in the DS log when this problem occurs?

Might be easier to just post your project somewhere. I can try deploying on my bot and see what happens.

[7] What's with all the posting? What does 'X-post' mean? Your just confusing the forum members.

Re: Glitchy motor behavior, requires double code upload to fix
 

they are blinking red and green. Well one blinks red, one blinks green. I was not aware the web interface provides this information so I'll take a look

this only happens on occasion but is still a problem, forgot the LED status when it happens

i don't know if they should or shouldn't be "zero". i just know 9 always works without issue and as expected but 8 which is programmed in the exact same way and just gets a mirror value sent to it sometimes goes to position i never send it and gets stuck there. it certainly is some kind of default position but it's not "zero" as far as i'm aware. I believe I have found a solution to this particular issue although I don't like it since i'm constantly getting the servo ref and writing the same value to it in code which to me is unnecessary.

on initialization a lot, too much to keep up. Most of them seem like non issues. for example I get some i2c errors but don't have any errors with the i2c device so not sure where they come from, among other messages i'm not sure the meaning of.

yes i set it up in begin.vi. no safety config on anything.

as mentioned in another question there is a lot of stuff on the DS, and only when it initially powers up and first code upload.


i may be able to skim out the relevant section, you REALLY don't want to have to deal with the spaghetti that labview tends to make

it stands for cross-post, and i posted all over since i didn't know where i would get the best(or for that matter just any) answer. pretty standard forum jargon

I believe i have determine what the problem is and why other teams don't experience them. Still need to verify. I have seemed to have fixed the issue with the servos I was having though. The way my code works is that in teleop it sets function modes in global variable, then in periodic task i check for a change of function modes and only send the motors a value once on each change. I mean why keep sending a motor the same value over and over? I also tried only getting the motor ref prior to loop and using a shift register&/or tunnel to set value which i think part of the problem lies with. If i get the motor ref every loop execution and keep sending it values the issues seem to be mitigated.

From what I can find online there does seem to be some kind of issue with initializing motors(perhaps some kind of race condition?) so you need to send it a value after a certain point for it to work. Still needs investigating though.

Although not tested for long, our competition bot didn't seem to suffer from these issues, the roborio on our practice bot seems to be having a lot more issues for whatever reason. we simply can't have these kinds of glitches happen at competition and considering how sporadic and seemingly random it happens i don't see how it could be a code issue. But i'm aware it very well may be so will need more testing/investigating.

Re: Glitchy motor behavior, requires double code upload to fix
 

I have found a solution to the issue. If you get the motor ref and set a value every loop iteration it will work. Previously I was getting the motor ref before the while loop(in periodic task) and tried using tunnels/shift registers. Doing it this way though caused said glitches. By getting the motor ref and setting a value every loop iteration things seem to work

Re: Glitchy motor behavior, requires double code upload to fix
 

Could you post your specific code or where you are calling the motor ref? I am not sure I follow why this would be an issue, and our team does something similar without issue.

Re: Glitchy motor behavior, requires double code upload to fix
 

It almost sounds like Periodic Tasks is starting before Begin is finished. Does your Robot Main still have the error wire connecting the two VIs?

Re: Glitchy motor behavior, requires double code upload to fix
 

This question was about the DS log...,
http://wpilib.screenstepslive.com/s/...og-file-viewer
... not the DS messages...see "Messages Tab" at
http://wpilib.screenstepslive.com/s/...tware#Messages

That means the Talon's are driving. Most likely just not enough throttle to move.

Those Victors don't really know anything about "position". Do you mean they are going to a nonzero output-value (as in not neutral). That really sounds like a code-issue, so... I guess it could be that you weren't updating them as often as you thought? Or at all?

I wouldn't worry about that. It just updates a register which is then periodically sent at a fixed rate over PWM/CAN. There is no harm whatsoever.

I'm a little worried that by adding logic to detect changes and reacting to them, your over-complicating what is normally a simple task, updating throttles. And as a result its muddying the waters as far as: why are the motor controllers not doing what I expect? The fact that your having trouble with CAN and PWM MCs also kinda suggests that.

It sounds like you got something working, but you might want post your latest anyway. Might help better explain what you mean by where the motor-refs are retrieved.

Re: Glitchy motor behavior, requires double code upload to fix
 

Just closing out this thread...sounds like OP found a working solution.
https://www.reddit.com/r/FRC/comment...s_double_code/