Jump to content

mike5

Members
  • Posts

    160
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by mike5

  1. Excellent! Thanks! Br, Miha
  2. Hi all, I'm working on some VI Scripting stuff for manipulating classes in my projects, but right at the start I'm having problems: how the heck do I get a refnum to a class, so that I can inspect it using properties and such? I tried with Open VI Reference, but I get Error 1059: Unexpected file type. After that I'd need to check all its members, add some new ones (maybe from a template), all such "basic" stuff I tried searching the net, checked the VI scripting examples, but I just cannot find anything. if anyone could help, I'd be eternally grateful. Thanks and br, Mike Oh yeah, and I'd need to get this from an existing class in file, not create a new one or something dragged on a Block Diagram. Mike
  3. mike5

    Subversion

    These files are a product of merge conflict. For binary files (which VIs are), you get rid of them in SVN approved way: If you have conflicts with binary files, Subversion does not attempt to merge the files itself. The local file remains unchanged (exactly as you last changed it) and you have filename.ext.r* files. If you want to discard your changes and keep the repository version, just use the Revert command. If you want to keep your version and overwrite the repository version, use the Resolved command, then commit your version. Br, Mike
  4. Well. Found the problem, and it was me Sorry for the noise.
  5. Hi all. I have a strange problem with data value references. I have an object, that stores its values in a hash (variant), and that hash is in a data value reference. There are two threads, and each one of them has a copy of this object. In one thread I am adding stuff to the hash, and in the other I am accessing it. Each thread accesses the DVR in lock-action-unlock manner, so no thread is locking the DVR for a long period of time. This is what happens: thread 1: add to hash 07:55:45,255265 thread 1: add to hash 07:55:46,803353 thread 2: hash.size=2 07:55:57,504966 thread 1: add to hash 07:56:00,908160 thread 1: add to hash 07:56:00,972164 thread 2: hash.size=4 07:56:00,967164 The last two are out of order, but that's because I am logging the addition some time after the fact. So, it seems that after the app is running for a while, the "DVR sync" is working the way it should, but at the start it takes 11 seconds for it to happen. Is there a way to make it fast at the start as well? Some sort of "flush" maybe? Thanks and br, Mike
  6. Woot! Thanks for all your help guys. Got exactly what I need! Mike
  7. No luck for me. Still 1097. I'm on Win7 64-bit. You? Br, Miha
  8. I tried to make this work, but I always get error 1097 when calling recv. Did anyone manage to get this working? Here's my VI, if you want to try it yourself and maybe spot an error. Thanks and br, Mike Peek Raw Socket.vi
  9. Ok, tnx. I'll see how I'll handle this. I don't like the options too much. Br, Miha
  10. Ok, I see that I will have to elaborate. I mistakenly thought my question was clear enough. I have actually a TCP connection open in LabView, but I would not like to read from it, I would like to call some VI that would block (with the timeout set by me) until data is available. Then I will call another VI that will actually read from the connection and do something with the data. Or to be specific - I am using STM, but STM only has one parameter. The timeout can be set when reading a message, but unfortunately this timeout isn't used only when waiting for the data. It also seems to be used internally. The effect is, that if I set the STM timeout too short (lets say 100ms), then STM stops working because the timeout is too short to compose the entire message. So the timeout needs to be larger, about 1000ms. But I don't want to wait for 1 second for a new message. I want to wait for it just for 100ms. If it arrives, I will read it, if not, I will do other things. And since I don't want to modify the STM library and break compatibility with NI, I decided to look for some other function that would wait for new data without removing it from the connection. If the data comes, then STM will be used with its default settings to read the message. I hope my intention is clearer now. Thank you for any pointers, Mike
  11. Doesn't anyone know a solution to my problem? Or will this better get answered in some other forum like "application Design & Architecture" which has more visits? Br, Miha
  12. Yeah, sure - LabView is just the tool for it No, I need to see if there is anything on my TCP connection without actually disturbing the incoming data in any way. Br, Miha
  13. Hi all. I'm looking for a way to check whether data is available on a TCP connection without actually reading it. Thanks in advance, Miha
  14. Well, yes. But I need the data in little-endian byte order. Br, Mike
  15. Christian, thanks to your answer and some reverse engineering of flattened variant, I now have exactly what I was looking for. Just if someone who knows can answer this: Does variant always end with four 0 bytes, or can this be something else as well? Thanks and best regards, Mike
  16. Yes, yes, yes... If I understand you correctly, I can "Flatten to string" the variant in little-endian byte order, and it will correctly serialize the internal data as well. Then I remove the variant container, and the data remaining would look like I was using the "Flatten to string" directly on the raw data? For the reverse I would take the raw data, put the variant container around it and use the "Unflatten from string" to get the correct data inside the variant. If the answer is yes, then this is exactly what I was looking for. Br, Miha
  17. Is there a way to create a SubVI with a real "poly" input? I mean an input wire that takes anything without losing information what "anything" is - it may be a custom cluster that sub knows nothing about. What I would want is then serialize this cluster for Data transmission in little-endian order using "Flatten to string", but I want to flatten the raw data, it cannot be encapsulated into a variant (I suppose that "Variant" carries some additional meta-data - I still have to check this). I hope I have correctly describe what I want to do., I have a feeling this sort of thing is very hard in LabVIEW. I hope I'm wrong. Thanks in advance Mike
  18. Hi, I would like to dynamically load classes on a real-time PXI. The process is defined here, and I guess it works even on real-time (haven't tried it yet). The current problem is making sure that the class and all the required VIs are actually deployed to the device. With static loading LV loads everything it needs on the RT device, but if I load the classes dynamically, what is the best way to ensure that the required classes will actually make it to the device. Thanks in advance, Mike
  19. Well, sort of like the DOM XML tree , since the functionality doesn't exist on LV-RT . I wanted to use property nodes so that the interface would feel the same as the native LV interface. Also, read property box does give me the ability to wire DVR directly into it. Br, Mike
  20. Thanks, I'm just playing with that. It doesn't come out quite the same, but maybe it will have to do... Mike
  21. Hi all, is there a way to create a custom property node in LabVIEW, and append some custom properties to it? These could be simple values or another property node of the same type. Sort of like the XML DOM property nodes. Thanks in advance, Mike
  22. A bit updated version of that doesn't leave all these open references lying around: Br, Miha
  23. Anyway, here is the project/library dependent solution that I promised yesterday: I hope it helps somebody. Br, Miha
  24. Thanks for the offer, I thought about this as well, but ideally I am looking for a solution that would not require the developer to explicitly call a function in each implementation of the class. But if I'm forced to... Br, Mike Anyhoo, I'll post my Windows only solution tomorrow when I'm back at the office for any other unfortunate soul looking for this information... Mike
×
×
  • Create New...

Important Information

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