ZomB: a C# Drag and Drop Dashboard

[Azores]

Sorry for not checking back in so long

Anyway I didn't get any time to test anything out before packing up for Atlanta, and once we got there I really didn't have the time to be testing out the Dashboard . But, our robot is on its way back to us, so once it gets in I'll be testing ZomB out, and hopefully we'll get to use it for next year!

[Azores]

Good news, everyone! [/Farnsworth]

Finally got time to try and put ZomB back together. I now have the ZomB Dashboard reading data properly - graphs are giving me the values I want, switches are responding how they should - but it's very, very slow. Slow enough that the "Elapsed Time" counter in the Driver Station isn't counting consistently. I have the ZomB dashboard set to only update once every thousand CPU cycles right now - should it be a larger number?

Also, I remember reading this before but can't figure it out now, how do I have the Driver Station open the ZomB Dash by default? As it is the default NI/FRC dash opens when Driver Station is run (either by logging in to Driver or running it from Developer). I've replaced Dashboard.exe in C:\Program Files\FRC Dashboard with the ZomB Dashboard but the default one still opens instead. And I've replaced it and tried both leaving the ZomB dashboard named DefaultDash.exe and Dashboard.exe and either way the default opens instead. I thought I read something about changing a .ini or .txt file but I can't find which file that is now.

Update: Had to leave the shop at 6:00 today so I didn't get to do too much more testing, but besides being slow, the dashboard also rarely has camera feed (at all, it isn't just slow, it's just not there, or it will show a frozen frame). Still haven't figured out how to have ZomB open as the default dashboard. But I also noticed today that we're having the Watchdog Not Fed error again, which I had solved before our first regional. Not sure why it came back up between the robot leaving Atlanta and arriving here, so I'll have to take a look at the Classmate tomorrow and see what could be causing that (last time the solution was to change the power management settings and some stuff in the BIOS to do with power management and CPU speed). I think it's very possible that the camera not feeding, the slow performance and the Watchdog error might all have a common source.

But other than that, ZomB is working fine now. I have spk1, spk2, sw1 and sw2 showing solenoid statuses for testing purposes, and grph1 and grph2 showing joystick Y values, "right" showing whether our compressor is running, "go" showing which mode autonomous is set to... and everything is behaving relatively properly .

[Radical Pi]

To change the dashboard: There is a .ini file in one of the User folders (will say DS or Driver Station I think). In it there is a key that points to the normal Dashboard. Just change that and it should open your's. Also, make sure you have protections against multiple instances opening of your dashboard (for some reason the DS opens Dashboard twice)

[Azores]

Yea, I read about the anti-multi-instance-Dashboard solutions and I'll be sure to do that as well.

So in one of the User folders, as in under My Documents? I don't have the Classmate available to me right now so I can't go exploring for it

[byteit101]

The ZomB has automatic instance protection

Renaming the DefaultDash.exe to Dashboard.exe and putting it in the C:\Program files\FRC Dashboard\ folder did the trick for us, you might want to move the first dashboard out, and then put the ZomB in.

As for the slowness, was it slow with updating the graphs/controls? (ie. push a button, wait a second, shows up) or just with mouse/keyboard feedback (ie. move mouse over button, wait one second, ui cues show up)
I have noticed the mouse/keyboard feedback lag increases in driver mode for both the ZomB and the DS by about 1 second every 3 hours, which needs a full reboot to cure. (I don't think it took you 3 hours, but you still might have this problem)

for the delay (on the robot side) if you are just testing, use Thread.Sleep(20) to get maximum throughput

while(istelop())//?
{
//calculate
zomB.Add("spk1",0);
//etc...
zomB.Send();
Thread.sleep(20);
}

otherwise, use a timer (pseudo code)

Timer t
t.start()
while telop
{
...
if t.Get()>=0.02
{
t.reset()
zomB.add(...)
zomB.send()
}
...
}

As for the camera, click the "reset camera" button and wait 2-5 seconds. If it does not show up after 10 seconds, click it again (make sure the camera the camera is initialized, ~10 seconds after the camera ring turns green)
(also make sure you have a camera instance in your code)

You say it worked with the dash.commit() line?

EDIT: BTW, have you seen the awesomeness of the taco yet? (its a -1 to 1 float value) (full documentation on its awesomeness: http://firstforge.wpi.edu/sf/wiki/do...wiki/TacoMeter)

[Azores]

It was slow as in the Dashboard had a lag to it - for example the spk and sw indicators that I set to show solenoid statuses would be a few seconds delayed in showing the status changes. The UI cues though came up quickly enough.

I found the .ini file and edited the line pointing to the Dashboard and it now opens ZomB by default, so that problem is solved.

I'm just about to put in the timer to update ZomB now, I'll edit this post later after I get to test it.

EDIT: Oh, and yes I believe it was dash.commit(); that fixed it. I don't recall making any other changes before it started working. And I haven't tried using the Tacometer yet, but I'll find a use for it

[byteit101]

The only things that I can think of that would be causing the delay would be network traffic, or (kinda doubt it) slowness in sending the data. I know running at comps and wired and wireless at home I have seen little delay. Not sure what your issue is though

[Azores]

Yea it's weird, the lag only showed up after we got back from ATL, so I'm trying to figure out what's happening. It's more pronounced when running ZomB it seems but it's still present when running the default Dashboard. We ran a disk cleanup and defrag today though as well as removing some less necessary programs we had installed, so perhaps that will help it out. We also reformatted and reimaged the cRIO. If all that doesn't help then I won't know what to do next .

Oh, and I don't think it's network issues, because I'm doing these tests through tethered ethernet haha.

[Greg McKaskle]

You may want to open the Task manager and see what the CPU load is ... both when running the DS and DB, and when running nothing. I've sometimes seen the classmate successfully connect to the wireless network and the update programs phone home and try to determine which virus scanner, OS patch, etc are needed. The task manager should show what the computer is up to.

Greg McKaskle

[Azores]

CPU load seemed normal and I didn't note any unfamiliar running processes when I checked, but then again I wasn't constantly monitoring it... if the lag hasn't been resolved tomorrow morning I'll take a look at that too of course. Thanks.