Jump to content

John Lokanis

Members
  • Content Count

    797
  • Joined

  • Last visited

  • Days Won

    13

Everything posted by John Lokanis

  1. I am running into a very strange issue. I have a second dev machine that I want to use. I took all my code and zipped it up, then copied it to the new machine and unzipped it. Both machines have the same version of LabVIEW (2013) installed from the same DVDs. Both machines have the same VI packages installed. All files are in the same position on the drive on both machines. (EXACTLY the same). I *should* be able to open the project on the new machine and get no dirty dots. I assume it will want to compile all the code once since I have separated source from BD. Instead, one of the pro
  2. Thanks for the input. I decided to create a object cache FGV. This seems to alleviate the speed issues. There is still a blocking issue since it is a singleton implementation but that is unavoidable. I suppose I could store the cache in a DVR or SEQ and 'peek' it to check for a hit, but I am not sure it is worth the added complexity. Has anyone timed these options for performance? Anyways, attached is my simple object cache VI if you are interested. -John Class Object Cache.vi ps. I prefer this implementation to a 'load at startup' option because it allows the cache to chan
  3. I have an application where I am loading plugins from disk and executing them. Each plugin is a child class of my plugin class. I am using the factory pattern. During development, I started out by having a static plugin class object for testing purposes and then later switched to loading the plugin class default value from disk. My architecture works by dynamically launching a generic plugin handler that then loads the required plugin class and dynamically launches a method in that class. So, the handler and the plugin are disconnected from the main application. They communicate using me
  4. Solved it with a variant. I changed the system class DVR input in the handler to a variant and then cast it to the proper type within the handler. Now the system class is happy to have the strictly typed vi ref of the handler in its private data. I also added a test to the handler launcher that checks the stored ref and creates a new one if it is invalid. I wrapped this in an IPE structure to prevent multiple callers from updating this ref at the same time. I suppose that is not absolutely necessary since the ref is to the same VI type, but this prevents me from leaking references if two
  5. My handler VI is not in a class, but it is in a library. I have already made some child classes of my system that enable additional features, like networked messaging. I suppose I could add a new child for dynamic launching, but that would mean that the networked enabled system class would need to inherit from the dynamic launching system class. Should would be nice to have multiple inheritance for this situation. Also, I consider the dynamic launching feature to be a core feature of the system so I would prefer to have it in the top parent. I don't like adding complexity if I can avoid i
  6. Figured it out. My 'handler' VI has an input of type 'system class' and I was trying to add the strictly typed refnum of the handler to that 'system class'. Looks like I will have to find an acceptable hack to fix this. I am thinking of passing the class to the handler as a generic reference and then casting it in the handler to the proper type. Any better ideas?
  7. Well, either way, I still want to encapsulate the reference. I just don't see why I cannot use a strict type VI ref in class data. I can use other type def'd data types in class data. What is special about this case?
  8. I have a system class wrapped in a DVR that I pass to all processes in my application. This allows me to create communication channels between these processes (ie: a message system) and limit it to only the processes that I pass this DVR to. If I want to have two parallel systems, I just create two instances of the system class and wrap each of them in a DVR and pass it to the proper processes. This allows me to segment my system into multiple independent systems within one application instance. If I was to use a functional global as you suggest, I would be limited to a single 'system' wit
  9. I am trying to solve a performance problem with my application and I have run into an issue I do not understand. For some reason, I cannot create a class data element that is a strictly typed vi reference. I can create a generic one just fine, but if I try to make it strict, I get an error. The reason I am trying to do this is to avoid the overhead and 'root loop' issues with the Open VI Reference call. In my application I am dynamically launching multiple child objects using a more generic 'handler' VI. I simply open a reentrant instance of this 'handler' vi, pass in the child class a
  10. Here is a new idea I have been meaning to post: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-comments-to-point-to-more-than-one-object/idi-p/2692537 Please take a look and Kudo!
  11. Went to post on the exchange and found that the same basic idea already existed. So I am linking to it here. Please give this your Kudos... http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Dot-convention-for-accessing-nested-LVCLASS-properties/idc-p/2692469#M26234 Basically, I am looking for the property node to have consistent behavior when working with classes. For those of you who use property node access to your class data and use composition, this will lead to much cleaner code.
  12. This topic is one of the reasons I gave up on source code control for the early stages of a project. I have reverted to the 'zip and copy to server once a day' method for backups. Once the project is stable and working, I will put the whole thing into Perforce for future maintenance. But at this point, I seem to rename 50% of my classes as I code them and decide they need to do something different or need to be split into multiple classes. And don't get me started on how I should have designed it on paper first so I didn't have to rename so many things. I went into this project with exact
  13. The class hierarchy window contains none of this information. It only shows you what classes are children of other classes. Messages are not children of the processes that execute them. The VI hierarchy window is just a mess, showing every single VI connection from a VI perspective, but again, not the information I am looking for. The node map is intended to show links between processes/actors via the messages they send/receive. This only works for messages systems where the message is a class. The idea is the process appears as a central node with the messages it can receive surround
  14. I am thinking of expanding on this for a CLA Summit presentation. But before I invest a lot of time, I am wondering how many others think a tool like this would be useful. If you are interested, please reply or 'like' this post so I have an idea of the level of interest in this subject. thanks, -John
  15. Yes, always from inside the project. I cannot reproduce the 330x result. This is what I get running outside the project from the desktop: Of course, now I get the same results from all locations. Must have been something weird about my machine at the time. (Also running Win7 and LV2013)
  16. This is a very strange problem. I have put together a demo project to demonstrate the speed differences in array vs variant attribute storage methods. I also included a test of different variant database designs to show some pitfalls. I first built this project in the following folder on my machine: C:DevelopmentSourcesandboxVariant Attributes It seemed to be working well and demonstrating the effects I was after. I then moved the folder to my desktop: C:UserslokanisDesktopVariant Attributes When I opened the project from here, and tested it, the demo ran 1000x faster and no longer dem
  17. Cool. Now what other speed improvements are lurking under the hood that we don't know of yet? It would be nice to have a list so we could re-factor our code to take advantage of them.
  18. Interesting. I just tried removing the indicators outside the frame and turning off debug and error handling. I saw no difference in the absolute speeds or the relative speed factor between the methods. I wonder why you see a difference.
  19. LV 2013 added a new function (or just exposed it) that gets the name of a class. I wanted to see if this would be faster than the old method I used before based on the path of the class. So I created a little experiment. It turns out the new functions is MUCH faster. I am concerned that what I am seeing is real, however, and not due to some compiler optimization with the way I created the experiment. So, please if you have a moment, take a look and tell me what you think. (I added code to strip the file extension because that is the use case in my application, but removing that makes
  20. I have that but it does not work for some reason. Still does not address my issue. (even if it did work).
  21. I have looked at that but don't see a function that does what I am trying to do. Maybe I am missing something?
  22. Does the clone class function rename the new class FP controls correctly in this version (when cloning native LVOOP classes)? I have also seen a lot of LV2013 crashes when cloning a class. Seems (anecdotally) related to having additional VIs open (not in the source class) that have broken arrows. It also does not like it if I switch to my mail program while the cloning is being performed.
  23. Has anyone come up with a way to auto-update the accessors for a control in the class private data when you change it's type or rename it? I find myself doing this a lot as I re-factor code. It means removing VIs from the project and then deleting them on disk, then building new accessors. Or, I could manually edit the accessors but that is even slower. I am just curious if anyone has created a scripting VI to automate this. thanks for any tips. -John
×
×
  • Create New...

Important Information

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