Custom Dashboards and the Driver Station Software

This is mostly for the NI guys, but anyone else who knows the answer can feel free to jump in as well.

Whenever I replace the default dashboard on the Classmate (in C:\Program Files\FRC Dashboard\Dashboard.exe), it starts up twice when either logging into the Driver account or when running the Driver Station program in the Developer account. Also, when I replace the default dashboard with a command line program (a TCP forwarder I wrote that just uses printf() for some diagnostic information) command prompt never shows up.

Summarized, my questions about the Driver Station software are:

  • Why would it start custom dashboards twice?
  • Does it redirect stdin or stdout from the custom dashboard? Why wouldn’t a command line program not display?

We’ve also experienced the “two instances” problem.

Is there detailed documentation or source code (ideally something that could be read without doing a LV install) available for the classmate-side DS/dashboard software? Plugging into the remote and/or custom dashboard mechanism has been a continuing series of little surprises like this. Some more concrete information would be most helpful.

I have also had the two instances problem. I solved it by checking if another instance was running. my only guess is that they want to make sure it runs

EDIT: It appears LV builds a one instance application, so it could also be to focus the dashboard, or make sure it runs

Maybe I misunderstood the original question. Is the issue that two DBs run when the Driver starts, or is the issue that fast-user-switching results in a DB running in both Driver and Developer?

If it is the second, then you can solve this similar to how the DS does. You identify a resource owned by the DB – it can be a file or a network connection. When the second app fails to acquire the resource, it sends a message to the first instance to commit hara-kiri. The second then sleeps and tries again until the first releases the resource. As a fallback, the second can give up and decide it lost the battle and exit with a message or something.

Greg McKaskle

Only logged in once, as driver.

It happens when we replace the dashboard with a non-LabVIEW program that allows multiple versions of itself.

For instance, point the DS ini file to start wordpad instead of a traditional LabVIEW Dashboard exe and you’ll see what they’re talking about.

Until we get an “official” solution, I threw together a launchpad of sorts that fixes this. It’s just a C# program that you set as Dashboard.exe

When the DS runs it, it creates a file on the C drive. Additional instances check if this file exists, and if it does, exit right away. The program then launches the your dashboard (renamed to DashboardActual.exe), waits for it to close, and deletes the file. Simple.

I’m heading off to the North Star regional today. I’ll try to put this up if I can get internet access at the hotel. If anyone wants to check this out, find me (Matt Kline) in the Team 537 pit and I’ll be happy to set you up with it and any of my other software such as the CARDS Video Dashboard or video forwarder.

I’m still confused. Does one launch of the DS launch two instances of the dashboard, or simply launch one more? In my test, I see one more.

Greg McKaskle

If the DS is launching “one more,” that means some other mechanism launched the first, right? It’s unclear to me why there are two different ways to start the same program, with both enabled in the system. If the DS is explicitly launching the second, how and why was the first started? Can one of these launch mechanisms be disabled without breaking the other?

If it’s indeed by design, that makes it a specific requirement for a custom dashboard that it contain logic to handle redundant instances. Certainly doable, but again, if the intent is to support custom components here, it’s good to be clear about such things.

I’m pretty sure that the DS itself starts two instances, because not only does the “two instance” problem arise when you log in as Driver, but also when you start the DS in the Administrator account.

Also, where is the .ini file everyone keeps talking about for the Driver Station software?

C:\Documents and Settings\All Users\Documents\FRC DS Data Storage.ini
Most people just keep the Dashboard.exe name and replace it with their own program, like you’re probably doing.
For instance, create a shortcut for wordpad, rename it “Dashboard.exe”, and put it in C:\Program Files\FRC Dashboard.

Greg,
The launch of the DS attempts to start two instances of the dashboard, but the LabVIEW default dashboard only allows one to appear.
Replace the LabVIEW default dashboard with a non-LabVIEW custom Dashboard (or some other program) and you’ll get two copies when you launch the DS.

I happen to use wordpad on occasion when I want to copy/paste and save the Diagnostic Tab error messages.

when you login to Driver, it starts the DS, which then starts two instances of the DB. this also works in Developer and on a different computer

launching DS
launching DB
launching DB
launched DS

Mark, I don’t see this file

Here’s where the file is on our Classmate





I’ll look again, and because LV catches and prevents multiple instances automatically, it would mask such a bug pretty well. This morning I tested with wordpad in the ini file and I received only one copy. I guess I’ll look at the source on the server.

Greg McKaskle

Edit: Found it.

Grrr, left in some debugging code. Still doesn’t explain why wordpad test didn’t show the issue. It should be fixed for next year, possibly the next rev if one occurs this season. I can’t think of an easier workaround than to make your DB a singleton using a wrapper or using a build setting to catch launch events.

Greg McKaskle

Great to hear we found out what the problem was. In the meantime, a simple launchpad that prevents multiple instances can be downloaded from the CARDS FIRST Forge site at

http://firstforge.wpi.edu/sf/frs/do/listReleases/projects.cards/frs.cards_dashboard_launcher

this sounds strangely similar to an article I read about a disabled watchdog for testing…

ZomB v0.5 will have a DashboardDataHubForm that prevents multiple instances via a system mutex. Not sure how CARDS does it
(From: http://firstforge.wpi.edu/integration/viewcvs/viewcvs.cgi/trunk/ZomBdlls/System451.Communication.Dashboard/DashboardDataHub.cs?root=zomb&system=exsy1002&view=markup )


[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool SetForegroundWindow(IntPtr hWnd);

...
            //Check Singleton
            bool createdNew = true;
//Create System Mutex. createNew is false if this already exists
            mutex = new Mutex(true, "ZomBSingletonMutex", out createdNew);

            if ((!createdNew) && (!DesignMode))
            {
                Process current = Process.GetCurrentProcess();
                //Don't kill designer
                if (/*Don't kill designer test here*/)
                {
                    foreach (Process process in Process.GetProcessesByName(current.ProcessName))
                    {
                        if (process.Id != current.Id)
                        {
                            //focus other
                            SetForegroundWindow(process.MainWindowHandle);
                            break;
                        }
                    }
                    current.Kill();//suicide
                }
            }

Its already in the r19 Nightly: http://firstforge.wpi.edu/sf/frs/do/viewRelease/projects.zombdashboard/frs.nightly_unstable.v0_4_1_19

The initial version I released last night used a file for a lock, but after some trial by fire this morning at the North Star regional, it now uses a named mutex. Great minds seem to think alike. :smiley: