Labview data dashboard won't retrieve polling indicators

[George1020]

Hi,

I've attached my entire project including the error messages I'm receiving. I have my labview Vi's set up to have 3 different vis. My inputs, my inputs global and my "coast" outputs. I have created my web server and linked all of the controls and indicators that I have. However, when I try and run the data dashboard project, all of my indicators have error signals stating that it "could not connect to the server". I have no idea what I am doing wrong. Any ideas?

[AdamKemp · Accepted solution]

The reason this isn't working is that your web service code isn't structured quite right. When you call a LabVIEW web method what it does is run the VI linked to that method. In your case you have COAST.vi mapped to the URL http://host:8080/FINALCOAST/COAST, and then you have a web service poller bound to that URL. When you run your dashboard the poller accesses that URL which causes the LabVIEW web server to run COAST.vi. If you look at COAST.vi, though, you will notice that what it does is start a loop which runs until the stop button is pressed. That doesn't make sense for a web method. There is no one to press the stop button. In fact, there is no UI for anyone to interact with at all. That means that COAST.vi will run forever. Eventually Data Dashboard gives up and closes the connection because it shouldn't take that long for the web server to respond.

So what is the correct way? It depends on what you are trying to do. In your case it looks like you are just taking a bunch of inputs, doing some calculcations, and producing a bunch of outputs. You could do that in one VI with one web method that just has a bunch of inputs and a bunch of outputs. In that case you use just a web service caller (a button) connected to that one method. Since this method has both inputs and outputs you will get both input and output terminal adorners around the button which you can use to connect to your controls (inputs) and indicators (outputs). When you press the button it gathers the current values of the controls and sends those to the server to use as the inputs for calling your VI, then it gets the outputs back from the server and puts them in your indicators. In my attached example (see the modified dashboard file) I show you how to do that. Note that I also modified the VI code to create a subVI for the core calculation code, and it is that VI which is used for the web service. This VI has no loop in it, so it just executes once with the given values and returns the results.

If you instead want to have an ongoing process which is continuously taking real-time measurements from your system then you need some other way to access that data from a web service. It looks like that is what you were trying to do here, even though you weren't using live data. Let's pretend that you were, though. In that case you were kind of close, but we need to make a few modifications. First, the running process doesn't need to be part of your web service. It can be, but that's a bit more complicated. Instead, your running process (COAST.vi) can just be a regular VI running in LabVIEW. You just open it and press run like normal. However, you want to modify that VI to share its data with other processes. You tried to do this using globals. Globals let you share data between VIs running in the same process, but web services actually run in a totally separate process (in the web server), so you'll need something else. A drop-in substitute would be Network Shared Variables. You'll see that in the attached modified code I replaced your globals with shared variables. Then in your web service VIs you just use those same shared variables. Network Shared Variables allow you to share data across processes (even across machines over the network) so you can easily access the same data from both your running VI and your web service VIs. I modified your COAST.vi to do this (and it calls the same core calculation subVI).

In this case you could just make a single "inputs" method and a single "outputs" method, but it might be better to break up atleast outputs into separate methods that group strongly related values just to make things a bit cleaner. It can be tedious to deal with large numbers of terminals.

Alternatively, once you are using shared variables you could actually connect your controls and indicators in data dashboard directly to those shared variables. This has the downside of requiring more ports to be open through your firewall (and you can't use security like you can with web services), but for internal network usage it is easier to set up. To do that just run your VI as before, and then once it is running you can select each control or indicator in Data Dashboard, tap the little button under it, choose "Shared Variables", and browse for your variables on your machine. In this case each control is directly bound to the variable, and so there is no need for a button. The changes you make in data dashboard are immediately pushed to the server through the sared variable, and your VI (which is still running until you hit stop) will see the new value, update the outputs, and then push those new values back to data dashboard via the other shared variables.

I didn't create a dashboard for the latter two approaches, but if you can't figure out what I mean then I can create examples for those as well. The VIs and project should be set up to work either way, so the only difference is in how the dashboard is configured.