testInit() Does not appear to issue commands in Simulator

Technical
1

I’m doing videos for noob programmers using the Simulator. I tried to initialize a DO in testInit() but it doesn’t change. I did a test:

testLed.set(!testLed.get()):

It stayed true. setup a similar command for auto, teleop & disable these all worked. I know test is setup for testing hardware but I thought it worked the same as the rest of the Init & Periodic. Missing something?

Thanks,

2

Please link to a GitHub repo (or similar) of your code, so people here can help effectively.
If you are scheduling commands, where are you calling CommandScheduler.getInstance().run()? Without that being called every robot loop, commands won’t run properly.
Did you make sure you are running test mode, and code inside is being executed?

3

No, used TimedRobot to keep it simple.

Thanks

4

I see the same result when using a DO. However, if I put a print statement in testInit, it does print, so testInit is getting called. I also put DO calls in testPeriodic and those worked. I wonder if it’s a startup issue with LiveWIndow.

5

As Joe hypothesized, it is indeed an interaction with LiveWindow. Test mode is different than the other modes in that it enables LiveWindow. What LiveWindow does is map the DigitalOutput to NetworkTables and installs a listener during TestInit() for NetworkTable value changes that sets the output to whatever is in NetworkTables. The thing is, what it sets is what is currently in NetworkTables. So when TestInit() is called, you set it to false, but LiveWindow has already cached the true value in disabled mode, so the output is set back to true when the listener is called a bit later. This only really affects the TestInit() function; if you set a value continuously in TestPeriodic() it will update the NT value and “stick”. I need to think more about whether this behavior is a bug or what we want to have happen.

6

I suspected as much. As I created various vids for noobies I was using the 3 modes to run different simple interlock examples without having to abandon or comment out the previous example. I assUme the three modes were the same then ran into this issue. As I worked through additional training in to SmartDashboard & Shuffleboard use, I noted that LiveWindow was uniquely linked to test mode.

The fix was easy enough, moved the initialization to robotInit(). I was just concerned it was something I had missed. But it is good to know there is something else. Just need to make a note.

Thanks for the feedback.

7

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.