John Lokanis

There are several sessions where I have a conflict. So, here are a few (in no particular order) to try and tape that I will likely miss: TS3017 - LabVIEW Champions Live: From Specification to Design TS4863 - Don't Think You Need an FPGA? Think Again! TS3399 - How to Eat the Elephant: Turning Ideas Into Architecture TS3457 - Extending LabVIEW to the Web Using the LabSocket System TS3364 - Standard and Nonstandard Inter-Thread Communication TS3204 - How to Create Truly Reliable LabVIEW Real-Time Applications TS3398 - Using LabVIEW Code Inside .NET Applications TS3237 - Everything You Ever Wanted to Know About Network Streams TS4257 - Web Technology for Test and Automation Applications Frankly, I am that so many good sessions are at the same time while other days/times have little to offer for me.

Yes, you are correct. The folder name cannot be changed. So I guess I am stuck. Maybe I can buy some of the NI guys a few beers at NI Week and try to persuade them to open this up.

Ok, resurrecting this one because I am in the middle of an massive bug fix re-architecture that requires me to change the name of a class data element in many classes. After doing a few, I am back to wishing there was a tool to do this for me. So, does anyone know if it exists? If not, is it even possible via scripting? Here are the steps: Select the class private data element to change. Rename it to the new name (I'm not even trying to change its type). Save Find any accessors for the element. Rename their VIs to match the new name. If said accessors are in a property folder, rename the folder to match the new name. Rename the inputs and output on the accessors to match then new name. Save everything. I can handle the VI FP edits and the file name changes. Not sure how to edit the class control or how to update the property folder name. I also don't want to end up doing this: http://xkcd.com/1319/ -John

Thanks for the reply. Unfortunately, I cannot give up on them because I have a lot of data-only classes that I need to access the elements from methods in many classes (although that could be worked around with a lot of sub-vis) but I also have several DVR wrapped classes that I use property nodes to access the data. So, I hope these gets fixed soon.

I have seen a strange bug crop up when editing a large LVOOP project that uses property nodes in several classes. When I am wiring into a class property node, the compiler does not complain about mismatched types all the time. It sometimes just lets me wire anything together but later will report the VI as corrupt. I first noticed this when accidentally wiring a scalar into an array (of the same scaler type) input on a class property node. But just today, I had an instance where it let me wire a string to a numeric input. (see image). Is this a known bug? Has anyone else seen this before? Anything I can do to mitigate it? I am using version 13.0.1f2 thanks, -John

WooHoo! The two PRAGMA settings seem to fix it. No Disk I/O errors and no speed issues (so far). I'll have to test a bit more of course. Thanks everyone! LAVA FTW again!

Jack: I am using the .net interface for SQLite. How do I set these flags? I have poked around but not found a way to do it yet.

I'll give those a try!

Multiple Clients might be using the Server at the same time. I want each of them to have their own data file for their work. If I go with a database server solution then all their data gets intermingled. And I don't want to spinup a database server for each user on the fly. Oh, and I don't have a network resource to run the DB server, unless I go to battle with IT. I wish there was a better way. My understanding is the issue has to do with making the SQLite file transaction safe in case of power loss. I wish there was a way to just turn that off.

In my case, I am never accessing it at the same time from the Client and the Server. The Client does it's work and then closes the connection. The Server then connections later and does it's writes. I could replace this with a flat file of some type (.csv, etc) but I like the ability to query the data since I can reuse some of my SQL code I use with the regular DB server. This is just sort of an off-line mode I am implementing for experimenting with new ideas where we dont want to pollute the central database but still want to collect data for analysis. Sucks that SQLite can't do this since it is such a good solution otherwise. I hate to have to switch to MSAccess but it is the only other file based DB solution I know of. thanks for the feedback. -John

I am using file based SQLite in my LabVIEW application as a temporary data storage file when not using the main database server. My application is a client-server system so I need the ability to access the SQLite DB File from two machines at a minimum. The Client app will create the DB if it does not exist and read existing data from the SQLite DB. When it hands off to the Server application, the Server will write to the DB as it collects information. Later, I want the user to be able to access the data with their preferred analysis tool. My original plan was to place the SQLite file on a network drive that both the Client machine and the Server machine could access. But, when I started testing this, I ran into a number of issues: 1. SQLite does not like UNC paths. I got around this by detecting the UNC path and adding an extra to the start of the path. 2. When accessing a SQLite file using a UNC path, I get lots of random Disk I/O errors and my DB file is missing data. 3. I tried mapping a drive letter to the network path and this seemed to eliminate the Disk I/O errors but the speed was so slow that operations took several minutes or never completed at all. So, after much googling, I found some comments that said SQLite does not work well when the file in on a network drive. This sucks as it makes my application nearly impossible to do. I don't want to have a server for the database since these were supposed to be one-off temporary data files for storing data when not using a real DB server. I require an atomic file based solution. So, has anyone found a way around this? Is there any clever hacks or settings or other ways to make this work reliably? thanks for any ideas, -John (using LV2013.0.1.f2 and SQLite Interop DLL version 1.0.90.0 based on SQLite3)

Looking for a LabVIEW Dev with minimum 5 years experience and CLD certification in the Seattle area for a 6 month contract. This position would be working on a team doing code development, unit test generation and documentation. Experience with LVOOP, .NET, Actor orientated programming and SQL a plus. CLA certification also a plus. If you are interested, send me your info via PM and we can go from there. thanks, -John

I am not sure I understand your solution. But, I have already created the classes that store the data and do not want to modify them. They are used throughout the application already and changes would be far reaching. I could add a method to their parent that extracts the name-value pairs of the class or gets the value of the element by name.

I have a need to access the private data values and control names at runtime. I have come up with a quick solution but was wondering if anyone had a better way to solve this problem. Background: I want to execute some SQL statements that insert data into a DB. These statements are in a config file. Each section of the config file has a name and a series of statements to execute. These statements have tags for the data values that I want to replace with real data. These tags correspond to the names of elements in a class's private data. There are several classes that contain data I want to write. There are several different sets of SQL statements, each with different set of tags within them. I want to be able to modify the SQL statements outside of the application without changing the code. This needs to work as long as the object containing the data has elements that correspond to all the tags in the SQL statements. So, what I am looking for is a generic solution. I feed in an object containing the data, a name of the set of SQL statements in the config file to use and the code takes the data out of the object, using the element names in the private data to match to the tag names in the SQL statements and then replaces the tags with the values of the data in the object. I can then execute the statements and my data is in the database. I have attached the VI I came up with to take the tag name and return the object data. This has some limits I am willing to live with. First, the elements in the object must have unique names. If they are not unique, the tag is going to get replaced with the first match only. Second, this mainly works for simple objects that do not use composition or arrays of other objects, since we would always match to the first element in the array. Why not just create a VI that unbundles the data in the object and wires it into a VI to do the replacement and execution of the SQL? Well, given the number of elements that need to be replaced, these VIs would be porcupines at best. And I would have to update them every time I added elements to the class. Why not simply bundle the class data into a cluster and pass that in, then use VI Server calls to get the cluster element names and do the tag replacement? Again, I would have to maintain two versions of the class data structure and update both when changes were made. And finally, why not build an array of name-value pairs from the object data and use that for tag replacement? Same issue of maintenance. I would have to add a new name constant each time I updated the class. And with all of these solutions, I would have to build the custom version of the tag data extraction for every SQL command set case. I know some of you have come up with some interesting ways of accessing class private data. I am looking for a stable approach that is likely to continue to work in the future and is simple and fast. Please share any solutions you have. Here is my first attempt: Get Class Private Data Value by Name.vi -John

If you have VI Server on both sides, you can avoid polling, at least in your code. I do not know if you consider VI Server waiting for incoming connections as polling. I will look into web sockets. For some reason, the links in you message just take me back to this LAVA post. Weird.

In my current design, VI Server is my listener, always waiting for a connection. The caller simply runs a VI in the receiver and injects a message onto the receiver's message bus. So, both sides are callers and receivers. It is basically a peer to peer messages system. If I were to give up on VI Server, I would need to find a way to send my messages (LVOOP objects) over the alternative transport (TCP?). I could flatten them to XML but not JSON as the built-in flatten to JSON functions don't work with objects. But as you point out, the client would have to open a connection to the server, send it what ever commands it wants to send, then sit and listen for responses in a loop. Since both applications are based on an Actor design (not AF) they need to not be blocked while waiting for messages. This will mean coming up with some way to keep the listener in a separate thread that can hear messages, while at the same time still being able to send message to the server on the same channel. And be able to abort the listener when the app shuts down. Oh, and the server must allow N clients to connect to it at the same time. And it must be able to reply to any of them or all of them at any time. With little if any latency. It just kills me that I get all this with VI Sever and now I can't use it...

Bummer. That is what I thought. Thanks for the feedback...

Unfortunately, that won't fix it. The problem is not having app1 (the server) discover app2 (the client). The problem is our network security blocks all connections from a server to a client. So, it is fine for a client to initiate a connection to a server, but the server can never connect back. Apparently this would lead to an insecure network so it is not allowed. (personally, I think this is more due to insecure IT people, but either way it is out of my control). So, I am trying to think of a way for the client to open a connection, leave it open without polling on it and allow the server to use that connection to send a message to the client at any time. I would love to still use VI Server because it eliminates the need to worry about flattening data, but if that won't work, what is the next best thing?

I think I am going to be out of luck solving this one, but can anyone think of a way for a LabVIEW EXE (call it app1) to call a VI on remote machine running a different LabVIEW EXE (call it app2) without app1 knowing the IP or name of the machine running app2? What I need to do is allow VI Server to call a VI where the application with the VI being called has opened the connection to the caller. So, the client needs to open a VI Server connection to itself and then allow the server to call VIs in the client using that connection. I know it sounds impossible, but I was hoping there was some hack or some unique way of achieving this through some other means. I do not want the client to poll. The server needs to push the data to the client when the server is ready. The client needs to be able to accept the data at any time. And the data needs to be a LVOOP object. -John

Yes, I thought of using plain TCP but I did not want to invent my own wheel if possible. And I could not think of a way to avoid polling. The connection must be robust so it can deal with dropped connections and not lock up. I also need to serialize my message objects in order to send them. I am concerned with the overhead this might entail. I have the VI Server solution working well right now with decent responsiveness. Is there a good LabVIEW messaging library out there that uses TCP and would support sending objects?

I need to find a transport for message objects that allows two way communication without polling but is limited to server side connections only. So, the client can connect to the server but the server cannot connect to the client. First some context: My application communicates over the network using VI Server. My client app (the UI) opens a ref to a VI in my server app (the engine) and sends a message object containing the client app’s machine name and VI server port. The server app then opens a ref to a VI in my client and sends a message object with the reply data. I now have a two way communication channel via VI server and can pass any message object back and forth without polling. I learned today that our IT department plans to block all incoming connections to all non-server machines in the future. So, my client would still be able to connect to the server app within the network, but the server would not be able to connect to the client app because of this rule. This will completely break my networked messaging system. I do not know a way for LabVIEW to setup VI Server so only one end can connect to the other but allow two way communication without polling. Does anyone use a message system that would work in my situation? I would prefer to continue to use VI Server but I am willing to look at other solutions, as long as they were very robust and had low latency. thanks in advance for you help. -John

'All VIs in Memory' is blocked for all remote connections. "Returns a list of VIs in memory for the specified application instance. This property returns an error if you wire a remote application reference to the reference input." I did finally get this working. The problem was a mistake in the port number due to a default value in a VI I forgot to override. So, it turns out I was doing something stupid... thanks for the replies...

I am running into a problem running a remote VI using VI Server. I am sure I am just doing something stupid but I can't seem to put my finger on it. The system is intended to work both in Development (running in the IDE) and compiled mode (running under the RTE). When I want to control the remote application from the local one, I open an application reference to the machine/port, then open a VI reference to the target VI. The difference is, if the app.kind is Development System then I get the project list, search the project names for the one with my VI in it, then get that project's app reference. I then open the VI ref using this app ref. I use the VI name, not path to open the VI since is should already be in memory in the target application instance. I am using the fully qualified name (.lvlib and .lvclass included in the name). This works fine if both the 'local' and 'remote' projects are open on the same machine. But if I put the remote project on a difference machine, then I get error 1004, the VI is not in memory. I get this error even if the target VI has it's front panel open on the remote machine. I have also tried using the main VI Server app ref instead of getting the app reference of the project from the main app reference but that gave the same result. I can confirm that I have the correct application ref since it returns the correct lvproj name. And if I open the VI using it's full path, that works fine. It just appears that I cannot open a ref to the VI that should clearly be in memory. So, is there some subtle difference in what is allowed with an application ref if it is on the local machine vs a remote machine? Can I simply not get a ref to a VI in memory if the machine is remote? I thought anything you could do between two application instances would work in all cases, regardless of if they were on the same machine or different ones. thanks for any thoughts... -John

Ok, I managed to fix this one. I edited the class icon on the source machine, applied the change to all members of the class, then saved changes. I then copied the code to the new machine, cleared the object cache again (just to be sure). Restarted LabVIEW and opened the class. It now looks correct. Still no idea why. But, when I try to close the class or the project, I get a save request for 100's of VIs. The change description seems to be one of these two reasons: "The master copy of a Type Definition (or Strict Type Definition) used by this VI was modified." "The VI's name was changed outside of LabVIEW, or one of its subVIs was found in a different directory." Since the disk layout has not changed, what else could be causing this? Is this a known bug?

Nope. Tried that. And this is the first time opening the code on the new machine so I started with an empty cache. But thanks for the suggestion. Something is amiss. I wish there was some tool to reset a class and clear away the mutation history so it does not have all that baggage. I suspect many bugs lurk in there. I have been over the steps I took to move the code to the new machine and I cannot figure out why it should be different. Same OS Same version of LabVIEW Same versions of VI Packages Same file layout on disk It seems to me that LabVIEW code is becoming non-transportable as they add more features. Especially LVOOP features. I have done this type of move in the past with non-LVOOP code and had no issues. Any other ideas to try?