Jump to content

Jon Kokott

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jon Kokott

  1. 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.
  2. 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
  3. 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.
  4. 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 atom
  5. 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
  6. Use a picture control to change images at run time.
  7. 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.
  8. 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.
  9. Nice, that fixes the problem. So happy. Same question as asbo though.
  10. 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 mos
  11. 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 th
  12. 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
  13. 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.
  14. 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.
  15. 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 31
  16. 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.
  17. 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.
  18. 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,
  19. 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.
  20. Are all the classes loaded into memory before you read the file?
  21. 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 arch
  22. 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.
  23. 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?
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.