Adam Kemp

It's actually CAR# 526291.

Right, but my previous post explained how you can create a LabVIEW application on Linux that does not have a dependency on X11 at all. That method is officially supported, and it was designed for exactly this use case. It is what we (NI) recommend doing.

For what purpose?

Does it work for other commands, or do they all fail the same way? As I'm sure you're aware LabVIEW normally doesn't want to create new instances of itself so you would have to give it an argument (that I can never remember) to create a new instance. I'm honestly not sure why that would cause this VI to fail (as opposed to just appearing to do nothing), but I thought it was worth pointing out. I also noticed there are quotes in the command line. Is that expected? It's been a while since I've used this VI so I can't remember whether those are necessary or forbidden.

You can build a Shared Library in LabVIEW for Linux with the "Embedded" runtime (in the Advanced page of the build spec properties check the box that says "Use embedded version of run-time engine"). When you do this your shared library will link against a LabVIEW runtime engine without GUI support, which means it does not require X windows. We don't support building executables this way, but you can build a shared library and then load it into a simple shell executable written in another language. This may be a useful way to write your server. As for system requirements in general, our website documents that information: http://sine.ni.com/nips/cds/view/p/lang/en/nid/2541 (see the "overview" tab).

The communication for -launch goes through the X server and uses string names so if there is another LabVIEW process running on the same X server the message will go to it regardless of which machine it was run from. That's just a result of how we communicate with our already running process. If you just want to send messages to an already running application then you can use some other method of inter-process communication like named pipes or TCP. This is probably what LabVIEW should have done as well, but alas that's not how we implemented it.

Howdy! I'm glad to see you're trying out the app. When you browse for variables in Data Dashboard it will only show variables which are supported. The list of supported types is here: http://digital.ni.com/public.nsf/allkb/D9B247551BE7F46A8625795000552CDE?OpenDocument There's also a troubleshooting page with useful links here: https://decibel.ni.com/content/docs/DOC-19388 Lastly, keep in mind that the application does not support authentication. If you need to secure your variables then we suggest using VPN. If you go through the documents above and still can't figure out what's wrong then please visit our official support forum for this product here: http://forums.ni.com/t5/LabVIEW-Web-UI-Builder-and-Data/bd-p/480

I'm excited to finally be able to tell you all about the project I've been working on since NIWeek. Thanks to the success of the iPad in the last two years tablets have become very common. They're more convenient in many cases than laptops, and an increasing number of people are carrying iPads or other tablets around instead of a full blown computer. You can do a lot of things with a tablet, but there are still some gaps, and access to your LabVIEW applications has been one of those gaps until now. Data Dashboard for LabVIEW is a FREE tablet application which gives you a simple, intuitive interface to quickly connect to and display data from a network published shared variable and/or LabVIEW web service. If your application publishes useful data through either of those mechanisms then you can show it on a tablet from anywhere. Data Dashboard supports scalar integer and floating point numeric, boolean, and string data types and four controls: text, chart, gauge, and LED. You can connect to up to 6 variables/web services at a time on a single page, and you can have multiple pages to connect to different sets of data. Data Dashboard is available in the iOS app store (for iPad only) and the Android Market (for Android 2.3+ tablets, not phones). Also coming soon to the Amazon App Store. You can read more about the application here: https://decibel.ni.c.../docs/DOC-19387 Please give it a try and let me know what you think.

I don't know what you mean by this. Can you show me the C code which is giving an error (I assume you probably mean crashing?). If you have an array of clusters of two strings then your data will look something like this in C (I assume you are including extcode.h, which comes with LabVIEW in the cintools directory): typedef struct { LStrHandle str1; LStrHandle str2;} ClusterWithTwoStrings;typedef struct { int32 cnt; ClusterWithTwoStrings elt[1];} ArrayOfClustersWithTwoStrings; Then your C function would look like this (assuming you set it up to be "adapt to type" and "handles by value"): void MyFunction(ArrayOfClustersWithTwoStrings** arrayHandle){ if(arrayHandle) { for(int32 i=0; i != (*arrayHandle)->cnt; ++i) { if((*arrayHandle)->elt[i].str1) ; // do something with this string if((*arrayHandle)->elt[i].str2) ; // do something with this string } }} Note the checks to make sure the array handle and the string handles are not NULL. In LabVIEW an empty array is a NULL handle, and an empty string is a NULL handle as well. You may be crashing because you are not checking for empty. So let's assume now that you want to actually create this array in your C code. That's a little more complicated. What you have to do now is pass in a pointer to the handle (just in case it's empty you need to allocate it and give it back to LabVIEW), so you set your call library up to be "adapt to type" and "pointers to handles". Now your C function looks something like this: void MyFunction(ArrayOfClustersWithTwoStrings*** arrayHandlePtr){ if(arrayHandlePtr) { if(*arrayHandlePtr) { // free any existing elements for(int32 i=0; i != (**arrayHandlePtr)->cnt; ++i) { DSDisposeHandle((**arrayHandlePtr)->elt[i].str1); // This function can handle NULL without an error DSDisposeHandle((**arrayHandlePtr)->elt[i].str2); (**arrayHandlePtr)->elt[i].str1 = NULL; (**arrayHandlePtr)->elt[i].str1 = NULL; } // Resize the array and clear any new elements DSSetHSzClr(*arrayHandlePtr, Offset(ArrayOfClustersWithTwoStrings, elt) + sizeof(ClusterWithTwoStrings)*numberOfElementsToAllocate); } else { // Allocate a new handle *arrayHandlePtr = (ArrayOfClustersWithTwoStrings**)DSNewHandle(Offset(ArrayOfClustersWithTwoStrings, elt) + sizeof(ClusterWithTwoStrings)*numberOfElementsToAllocate); } if(*arrayHandlePtr) { (**arrayHandlePtr)->cnt = numberOfElementsToAllocate; // Initialize new elements } else ; // error } else ; // error} (sorry about the tabbing; I can't figure out what this editor wants...) The important things to note here are: Arrays and strings must be allocated (or resized) using the LabVIEW memory manager functions (DSNewHandle, DSDisposeHandle, DSSetHandleSize, DSSetHSzClr, etc.) from extcode.h. Link against labviewv.lib to get access to those functions. Empty arrays or strings are NULL. After disposing a handle set it to NULL After allocating or resizing a handle for an array or string set the cnt field to the number of elements you allocated. When allocating space for an array or string you have to calculate the total number of bytes for that array or string. You do this by using Offset(structName, eltField) (to get the number of bytes for the cnt field plus any padding) plus the size of your element (ClusterWithTwoStrings for your cluster or uChar for a string) times the number of elements you want. Also note that you can convert an LStrHandle (a LabVIEW string) to a null-terminated C string using LToCStrN, and you can also convert from a C string to an LStrHandle using LStrPrintf. You can find documentation for these functions in the LabVIEW help. Also check out the "Calling Code Written in Text-Based Languages" section of the help. There's a lot of information in there.

The web services feature is not supported on Linux. You can only deploy the web service from a Windows machine and only deploy to a Windows or RT machine. If for some reason you need to do the configuration part from Linux then you may try the Moonlight plugin instead (http://www.mono-project.com/Moonlight). It is meant to be a replacement of Silverlight for Mac and Linux. I have no idea whether the configuration utility works in Moonlight, but it's worth a shot. I'm not sure if that's really useful to you, though, if you can't deploy from or to Linux anyway.

CAR #281328.

That least part is a contradiction, though. A "restore" is a resize. You can't say it's not resizable if you are able to "restore" it. That changes the window's size, therefore it is resizable. The fact that you can get into that state is a result of the fact that we treat non-running VIs differently. When you maximized the window it was resizable. It's a bug that when you run the VI and resizing is disabled we don't immediately unmaximize it. That's just a bug, though. What you described after you unmaximize is the correct behavior. You should not be able to do anything to a non-resizable window to change its size, including maximize or unmaximize, and as I said before, you can't have a "maximized" window which can't be unmaximized. Therefore maximized and non-resizable windows are a contradiction. This can't be done. As I said, that's a contradiction. You can't have a "maximized" window that is not resizable. It's just not allowed. The only way to disable minimizing unmaximizing is to disable resizing, and disabling resizing means you can't maximize to begin with. I have to ask, what value is the title bar if you can't minimize, unmaximize, etc.? Why do you want the title bar visible? If you hide that you can't move it. Problem solved. I think you're making it harder just to show a useless title bar. This is not a bug. It is the expected behavior. Not in teh way you have described. The presence of a title bar implies that you can move it. The ability to "maximize" (which in OS X means make larger, not necessarily fill the screen, and it doesn't ever disable resizing of any kind) implies that you can resize the window to begin with. This is the platform where that contradiction is most apparent because "maximize" is truly just a resize. It's equivalent to manually moving and stretching the window to fill the screen, thus is can't be done if you disable resizing. The only way to get a full-screen, non-resizable, non-movable window is to disable resizing, hide the title bar, and set the window size to be the full size of the screen.

That's true, but my point is that "resizable" applies to more than just whether or not there are resize handles. On OS X there is no such thing as "maximized" in the sense of not having borders. That concept just doesn't exist. Also, in Windows 7 you can grab a title bar from a maximized window and drag it somewhere else to unmaximize and then move it. There's no such thing as "maximized and not umaximizable", and If the size can change then it is resizable. Maximizing and unmaximizing changes the size, therefore if a window is maximizable it must be resizable. Like I said, this is just how it works. You can't be "maximized" if you're not resizable. The best you can do is try the steps I listed above.

Sure you can. Just unmaximize it. That's a resize. You can only be in a maximized state if your window is resizable because you can't get into a maximized state without maximizing, and maximizing is itself an act of resizing. That's just the way Windows and Linux (and presumably OS X) work, and at the very least that's the way LabVIEW works.

Maximized implies resizable. That's just how the window managers work. It sounds like what you want is something to be full screen. To do that you need a combination of multiple settings: disable resizing, hide the title bar (which appears to also hide the border), hide the toolbar (or not, maybe you want that), then set the panel bounds to be the size of the screen. Make sure to reset all of that when your VI is stopping or it could get quite annoying to work with. When I experimented with this it looked like maybe LabVIEW wasn't accounting for the invisible border when I set the panel bounds, so you may need to account for that. You also may want to hide the scrollbars while running (that can be set directly from the front panel).

I tested this just now with LabVIEW 2010 on Ubuntu 10.04, and it worked fine. Are you sure you don't have "Allow user to minimize window" unchecked in the VI's Properties? Note that this is the default for the "Dialog" appearance. You can check the current state by clicking the "Customize" button in the Window Appearance part of the VI Properties dialog.

We can't comment on what will or will not be in future versions of LabVIEW. If a feature or improvement is important to you then I suggest you use the LabVIEW Idea Exchange to raise awareness. We use that quite a bit these days to measure support for features.

The version is 9.0. The name of the version is 2009. We have to store a version number in there somewhere, and our representation of version numbers can't handle 4 digits for the major version.

It looks like someone had a similar problem before and was able to get it to working. See if this link helps you figure it out. I think in the end they did an uninstall of all the drivers and reinstalled them because some old NI drivers were causing some kind of conflict. Maybe you should try that. By the way, that site (the NI Linux community website) is the best place to post these issues because a lot of people post there with NI driver issues and help each other figure it out, even on unsupported Linux distributions.

Could you post the exact error message printed when LabVIEW crashes?

If I remember right this usually means that the PAL drivers are not loaded. Try running updateNIDrivers (or restart your machine).

Ton got the most important things to watch out for (DLLs and path formatting), but here are a few more: locations (i.e., there is no Documents and Settings, Program Files, etc.), permissions (you can't modify most files outside the user's home directory or /tmp), missing features (there are some features not supported in Linux, like Timed Loops and RT or variable hosting). Those are probably the more common porting issues.

Even if we ignore all conversions and all byte swapping we still have to copy the data because the code that UnFlatten uses cannot take ownership of the data it's reading. On the diagram it might make sense to say "I'm done with this string, so this output array can own it", but the same code handles unflattening from a file stream (that's how we read default data and constants from a VI file, for instance). Copying the data is an O(n) operation so we can't do any better than that. It may be possible to optimize specific cases, but that comes at the expense of complicating code that currently doesn't care what it's reading from. Since unflattening from a string isn't normally considered a high-performance operation that's not a tradeoff we've been willing to make.

Unflatten has to go through a lot more checks because it doesn't know what format the input is in. It can't possibly just reinterpret_cast the pointer and let you work with the data because if the string was malformed then you would crash (we don't like that). With the typecast primitive we can avoid some of those checks because we know the source type and from that we know both that the layout of the input data and that it is well formed. The reason it's still linear is that there is still a conversion taking place. We still can't do a real reinterpret_cast in most cases because that would be unsafe.

Linux and Solaris are not the same, and binaries from one are not compatible with binaries from the other. If they refuse to accept a Windows application then maybe you could just convince them to accept a Linux application. I see no reason to use Solaris, unless they specifically require that you use Solaris. I don't know why anyone would do that, though. EDIT: Another option that's better than VNC (though still somewhat silly) is to run the app on Linux remotely using X Windows. Solaris's GUI is X Windows, and that natively supports running remote apps and having them display locally. It's a much better experience than VNC because the windows look native to your current desktop (they float around and can be moved and resized normally, rather than all being forced into a single box). This is as simple as something like this: solarisbox:~$ ssh -X username@linuxboxPassword: (enter password)linuxbox:~: /path/to/labview Once you've logged in with SSH and told it to forward X stuff (using -X or -Y) then you can just run LabVIEW or any LabVIEW app (or any other X app, for that matter) on the remote machine and have it appear on the local machine's display. It's wonderful.