Jump to content

Zyga

Members
  • Content Count

    25
  • Joined

  • Last visited

Community Reputation

0

About Zyga

  • Rank
    More Active

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2011
  • Since
    2011

Recent Profile Visitors

968 profile views
  1. Thank you for your answers and sorry for not being here for a while. Based on information from you, I have achived what I needed, but there are still things that are mistery for me. That was my thinking before I wrote this post. But it somehow did not fit to what was happening in my project. I was loading a class, changing its VI properties and then call this VI using dynamic dispach mechanism. It wasn't modified as I expected. So I suspected that LV preallocate clones for dd VIs while loading class (and I wrongly assumed that those are VI with "instance" suffix). And this would fit to what was said after: So I have created this example: And this is what happens when I call this VI first time I open the project: What supprised me most is that even though LV has allocated single clone for dd vi right after class loading, changes made on reference to its prototype applies to the clone as well (which, for some reason, is not the case in my project..). And changes applies to clones that are created afterwards which is expected. Exactly the same behaviour can be seen in executable built based on this example. Second run after project loading, has both clones in the memory from the beginning. Now operating on the reference has no effect on both clones.
  2. I wonder if someone has found a way to retrieve reference to a vi that is overriding method and has reentrancy set to shared clone. What exactly I am trying to do is to change properties of this VI controls by using externally opened reference. Actually I would like to localize FP at application loadtime (without placing code on "to be localized" VI blockdiagram). When I list all VIs in memory I get stuff like this: sDataAcquisition.lvclass:editWindow.vi:Instance:6cc60448-8771-4aea-ad60-5635b7cb9c6a.vi sDataAcquisition.lvclass:editWindow.vi:Instance:b60c6bed-8161-4566-ab34-ae4092625b90.vi sDataAcquisition.lvclass:editWindow.vi sDataAcquisition.lvclass:editWindow.vi is a method that overrides one from parental class. sDataAcquisition.lvclass:editWindow.vi has not yest been called when above list has been populated, just owning class loaded into memory. Can someone explain what Instance:xxx-xxx.vi suffix mean? Can I be sure that if I find all of instances there will be no more alocated at app runtime? I also can find stuff like that, which has longer suffixes tree: loadDrivers.lvclass:execute.vi:Instance:ed894b20-902d-486d-ae3e-062689901cdc.vi:Instance:c1440502-af17-4937-acbe-a4f891f270d2.vi loadDrivers.lvclass:execute.vi:Instance:ed894b20-902d-486d-ae3e-062689901cdc.vi loadDrivers.lvclass:execute.vi I assume that this is correlated to ancestry hierarchy somehow, but is there any documentation how/when this clones are created? Getting back to my original goal. I would like to change properties of e.g. sDataAcquisition.lvclass:editWindow.vi and all its clones.
  3. I do not believe this is a disadvantage. Serialization is special... if the parent is not serializable then the child is not serializable. Requiring inheritance from a base Serializable does not seem to me to be a bad requirement. Even in other languages where serialization is an interface, mostly they have to add special syntax checking to make sure that the interface is implemented by the eldest class or else it doesn't work. Serialization isn't functionality that can be injected on a descendant level. It's all or nothing to be meaningful because failure to preserve parent state means you aren't actually saving the state of the object. Thus the requirement to inherit from specific base seems absolutely reasonable to me... indeed, it is an advantage because it syntactically assures that the ancestors are included. Now when I am thinking of it, it sounds obvious. I am possessed by flatten to/unflatten from xml ease of use.. Flattening the names of the complete ancestry into every flattened string would be an incredible bloat of the flattened size of data. Once again, now mentioned it is perfectly plain. For me it is hard to imagine using more than 3-4 inheritance levels, but looking on e.g. VI Server I see it is reasonable to have more than that.
  4. From what I see they are not. Correct me if I am wrong, but this lib enforce "serialize" method to be overwritten and then calls it through whole hierarchy. Disadvantage of that solution is a need to change inheritance. Ok, but enough of moaning. We will use one of existing solution. Just wanted to point out where retrieving ancestry list would be useful (wonder why this information is not in the class flattened string?).
  5. I was looking for getting ancestry list at RT solution for a while. Found few posts, did some coding - no success. I just reply to this old post as @Aristos Queue asks why would someone need that information. I wish to flatten/unflatten object to other format than xml. Surely this post is a grate start, but still unable to get TD even whole data is there. If flatten/unflatten to xml function can do the job, there must be solution hidden under the hood.
  6. Zyga

    NI DAQ alternatives

    These are questions that have to be answered before every single project. And assumption is that if I choose decent vendor, he will provide me with any of above options (I wouldn't dare to demand DIO96..). More important for me is to find solution tested with pc based systems.. With NI I am sure of community and NI support. Whole bunch of pitfalls already discovered and resolved or walkaround found. If about LINX license, this is plainly answered in FAQ authors site. So Yes, you can use LINX to programm arduino for commercial usage.
  7. Zyga

    NI DAQ alternatives

    We do not have strict requirements. This question do not apply to any specific project we are going to implement in near future. This is question in general, but basically I cant think of something that 100Hz, single point measurement wouldn't be sufficient. Actually we have few industrial eol testers based on Windows PC + cdaq, and they works perfectly well. These are not always harsh environments and cDaq does well. Few matters which needs to be balanced and analyzed carefully. Depends on many factors really. Surely if you would have had few implementations over year, you could consider writing your own, good quality driver. It sound like an idea, but it might be very hard to make customer believe this is robust solution. I have never programmed Arduino by myself either, so I would't feel very confident with this solution.. I was looking on Advantech before and did not find any tempting hardware there, but Phoenix and Moxa looks way better. Yes, but getting deeper in this direction we do not need LV at all.. remote IO modeules easily controllable via LV software.. That is the main goal. From what I see there are solution that I was't aware of, but not yet tested in LV. Now most difficult question to answer to is the one from @smithd. Whether it is path worth of exploration or it is just waste of my time and money..
  8. LAVA users, We are looking for alternatives for NI DAQ devices for industrial automation. Since NI has its devices mostly focused on advanced/high speed/high precison data acquisition/processing its prices are inadequate to simple automation tasks. I would also say that NI PC based daq systems are expensive if need to be distributed systems (found this but still relatively expensive cRIO required). Just now we need to extend our compactDAQ based system with two DIO modules. We even have free chassis slots for this, but station that needs this IOs is few meters away from PC. How easier would it be if we could use single ethernet cable.. Ofcourse we can add another small cDAQ (what we probably going to do) but this is slightly expensive solution for our customer. Does anyone have some experience with 3rd party solutions? Any known daq devices vendors? Standalone ethernet daq modules? Regards, Zyga
  9. Hi, I think you might want to read this paper. I am afraid that if you do not have access to the dll sources you will not be able to retrieve this data correctly. At the first place I would split up complex data into simpler types, then pass it to dll as separated arguments. That will make things easier in your dll code. Regards, Zyga
  10. OK, If you will not be able to do so, it is not a big deal, at least I know that it is possible
  11. Hello Porter, I've been looking on this library for a while, but I wasn't able to make it work with labview. Would you share your code? Zyga
  12. Tested and it works. With multiple images stored in a single file it doesn't work. Looks like win uses them just for better apperance. All of them list in the resource hacker as a single group. When we take a look e.g. on LabVIEW, there is a group for a single file type icon. Nevertheless specifying icon path explicitly solves my problem. Thanks!
  13. Hi, I would like to associate icons with file types that are handled by a LabVIEW built application. To do so, "defaultIcon" key has to take a value of executable path with parameter "resource ID". The question is how to build in more than one icon with executable? Examples of LabVIEW keys: -library: ..\LabVIEW.exe,-8 -llb: ..\LabVIEW.exe,-3 Is it even possible with app builder? Any workaround?
  14. As far as I know ActiveX should be plan "z". It might cause unexpected problems, just like .net. It's hard to imagine how you can exchange data with compiled code without exact knowledge how it's made. I'm not experienced it this kind of things but it sounds hardly to be done. Shared variables are used to communicate e.g. with PLC systems, so it suggesting this should work way faster than mentioned 50-300ms (for sure more stable). You can also take a closer look on shared memory. I have seen some LV implementations, not only for RT targets on which it is native LV functionality.
  15. Could you provide us more details? Any particular reasons? I've used .net in my project twice or three times already, and there were no problems occurring.
×
×
  • Create New...

Important Information

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