Jon Kokott

Be careful measuring timings using the tick counter like that. Remember that unless you are using labview RT, the timer value will be somewhat of a suggestion. A better way to measure things like this is to use a piece of hardware to capture the waveform.

For the first question, post your code and someone will be able to help you do what you're trying to achieve. Question 2: you really cant use a table in an array because you need to get the reference to the array objects (MCLs in this case) and labview doesn't provide you with a way to do that. If you hack a little bit you'll notice that the reference you from the Arrayelement get will just populate all the tables in the array. I'm not gonna say its impossible, but you are not using the control the way the designers intended, and might get some strange behavior. you can achieve your table in a 2D array by doing the following: make a cluster of a 2D string array and put that cluster in another 2D array. It might not look as pretty as you want, but the behavior will be a little simpler. Watchout as this will be a pretty slow FP object to display and arrays of arrays are pretty hard on the memory manager as well.

The best way I've found is to click on the (open) FP Background, and Drag a selection box over/into the XControl. You don't have to select the whole thing, just some of it, it is kind of annoying though.

Networked shared variables are certainly easier to work with, and if they "work" then use them. That said, compared to straight up TCP (which is what they are built on anyway) crushes them. Its WAY more involved, and you're completely changing the architecture at that point. I take back that all shared variables are slow, its really just network shared (reading and writing a shared variable is pretty wicked fast). Publish-Subscribe shared variables is an approach that will definitely work. I really don't ever use them, but shared variables offer no mutexing (like a DVR or FG) if an atomic transaction is required, and need to be polled unlike a Queue. The publisher-subscriber approach with Shared Variables can be replaced by a Notifier. At the end of the day I prefer reference objects (like variables) to have their reference wired to them. Maybe its just personal preference. Aside from that, if you are dealing with same-application synchronization, which is my assumption based on the passing data to subpanels, Queues and DVRs are generally my bread and butter. If everything is in the same application space there is no reason to use a network shared variable (or any TCPing in general) as it will be unnecessary. Paul brings up a good point that Shared Variables are an effective way to do things and you yourself said you envision a solution using them. Sometimes its better to stick with what you know and get things done. If you are doing something simple like displaying a reading from a gauge, you'll be done in less time than it took to read this post! Without knowing the specifics of your application its difficult to know what the "best" solution is. I still like queues. Use the static VI reference, but "strictly" type it (right click on the static VI ref) then you can use an invoke node to insert that reference into a subpanel, then call by reference node to actually call the VI. This will allow you to wire the connector pane references that you may/may not need.

I prefer message queues. Shared variables are... slow. You'll have problems with race conditions using them as well. I don't suggest using user events unless it is actually a user event. They are very similar to queues in performance but don't give you the same level of control (they only size unlimited, message can queue up badly in rare cases.) Your other options are LV2 globals (ugh, I don't like these, but they can be fast to program atleast.) and DVRs. With DVRs/LV2 you'll be polling in all likelyhood if thats the only mechanism you have for synchronization. Queues/User events will be all event based processing. This is a real challenge, and if you are new to these concepts, I would almost plan on writing your VI, taking a step back in a week or two, and re-doing the whole thing. Ultimately you'll understand how you're solving the problem better, and end up with something that doesn't look overly complicated to you anymore.

Use a picture control to change images at run time.

OK this is a little more definitive. C:/Documents and Settings/All Users/Application Data/ = C:\ProgramData or C:Users\username\AppData\Roaming folder. I'm getting conflicting forum guidance on that detail. There is an NTFS Junction point linking those two folders. Win 7 supports symbolic links, so there must be a performance/usability advantage to using a junction instead (or maybe its just more proprietaryier <-lol.) at any rate, the username can create restrictions between users, use the "All Users" folder and it will be safer.

In Windows XP: We use "C:/Documents and Settings/All Users/Application Data/<Application Name>" Supposedly that is guaranteed to give access to everyone. I'm on my home computer right now and the Program Data folder folder looks promising, I always like a shorter path. Should probably check the official Microsoft recommended stance on this, I know it changed from XP to Vista/7.

Nice, that fixes the problem. So happy. Same question as asbo though.

Arg, Something is still not right about this. I'm updating an Xcontrol by directly wiring the terminal with a string extremely quickly. I don't actually need the control to update that fast, but its possible that it will get hammered like that every once in a while. The problem is that once execution stops, if it was recently "flooded" with data, the control keeps updating like crazy (like a queue, not an notifier) even after the VI is stopped. Once it finally catches up, its not always the most recent data. It would be nice to know that the last data value displayed is in fact the most recent. Is there any work around for this? Updating the value upon an execution change event does not work.

I see what my problem is, updating the control is an asynchronous notify() operation, vrs using a property node is a synchronous operation. The documentation supports this, for some reason (because typical event structure behavior) I thought that updating the control value would be more like an enqueue() operation. I can see that there is a race condition if I modify the Xcontrol data during one of these notify() occurances. In fact, during rapid updates doing this is absolutely awful and results in out of date display very often. I'll have to rethink how to do this as modifying data in the Xcontrol can't happen fast enough to be practical.

I've got an X-control which I am updating very quickly, but I noticed that even though the data is being sent to the X-control indicator, the data never gets to the facade.vi My x-control display then gets out of sync, i.e. if you read the data out (with a property node) immediately after writing it (by directly wiring the indicator), its wrong. Am I doing something wrong or is this a real bug? LV2011 No SP1

Sometimes I've had success with the following on broken builds: In the advanced tab, enable debugging. In additional exclusions, uncheck removed polymorphic VI instances, uncheck remove unused members of project libraries. as already mentioned, include front panel/block diagram for suspect VIs. Also, if you launch any daemons, try including block diagrams/front panels for all of them. Sometimes the error for that problem doesn't show up quite right.

Hardware is either RTS/CTS or DTR/DSR You still have a termination character enabled by the way. You probably need to turn that off.

One more thing, you are sending "N?\r\n" I'm gonna assume that this is using codes display. Your VISA Configure is adding a "\n" to all writes for you. It might be in your best interest to turn this off. The actual data on the line will be "<XON>N?\r\n\n<XOFF>" If you want additional control over the line (which I've done before to debug this exact situation) turn off flow control entirely, and manually put all the data on the line. If your xon char=0x11 and xoff=0x12, then your codes display to send for that message would be: /11N?/r/n/12 In hex, the data would be: 2F31 314E 3F2F 722F 6E2F 3132 Hope this helps Arg, i put the slashes in the wrong direction Codes Display: \11N?\r\n\12 Hex: 114E 3F0D 0A12 sorry about that

Since you are using XON/XOFF flow control, perhaps the control character is not being set to the correct character. Check the documentation on your device for what the XON/XOFF characters are. You can change this setting by using a property node. It is in Serial settings -> XON flow control character, and Serial settings -> XOFF flow control character. Additionally you can manually set the flow control state to force it to something on your end, but since the read is failing, this probably wont help you.

Check this out, https://decibel.ni.com/content/docs/DOC-13859 Then check out some more of darin's black magic. There is an Xnode tool in the code repo as well that will help you as well.

I don't use the NI build version, however, This is what I did on my last project: as a post build for the exe I create a file called <executablename>.exe.info this file is encrypted with the following contents: 1. build date 2. build version 3. build author (I programatically retrieve the windows login info) 4. 32 bit CRC of the file (my companies proprietary algorithm) 5. Sha-1 hash 6. String (for all the stuff I forgot) In the exe I decrypt the file (its just a hard coded password) and return those items. I find that the build date is far more useful than the build version, and it constantly gets out of sync anyway if you have multiple people making builds from a source repo. Additionally the exe is able to check that it has the correct version file as it can run a SHA-1 on itself since it was generated after the build. If the encrypted file doesn't exist, the executable simply returns (unreleased.) This is good while I test on production equipment so that operators don't accidently use something I left on a tester.

I just put a constant down and wire it to the get default path primative. Its helpful to see where its being loaded from to make sure its using the ones compiled into the application. I've actually been messing around with this technique a little bit; I'm not sure its a great idea to be compiling 2 disk copies. It would be better to have a packed library with the child classes (although this introduces a whole new set of issues in maintenance and understand-ability) There really should only be one copy of the compiled code in the run time environment at a time.

Are all the classes loaded into memory before you read the file?

See this thread: http://lavag.org/topic/15369-packed-libraries-break-inheritance-relationships/ Basically, my understanding is that the problem with loading a class at runtime in an exe is that the dependencies of the class (such as items in vi.lib, user.lib) are not available without the development environment. With the introduction of packed libraries, the class and all its dependencies are compiled into a binary avoiding this situation. The problem is, that packing all the dependencies not only packs the target plugin class, but also packs up the Parent. This means that your plugin architecture will be destroyed. The accompanying thread links to a ni thread which details a procedure from removing this behavior. (its really obtuse IMHO, that doesn't mean I wont do it, it just feels like a highly irregular and obfuscated way to code) Here is that link to the NI website: https://decibel.ni.c.../docs/DOC-19176

Everything works as described in the link. Thanks again.

Thanks you for this.

This is exactly what I'm trying to do, thank you. What a hack job that is, I never would have thought to delete the Parent library in the child build. Thanks again, I'll try it this weekend sometime.

If I build a packed library with a class which is a descendant of another class, it is breaking the relationship of the child to the parent. Do packed libraries only support hierarchies that are fully enclosed in the packed library?