Jump to content

Götz Becker

Members
  • Content Count

    135
  • Joined

  • Last visited

  • Days Won

    2

Götz Becker last won the day on June 5 2012

Götz Becker had the most liked content!

Community Reputation

11

About Götz Becker

  • Rank
    Very Active

Profile Information

  • Gender
    Male
  • Location
    Munich

LabVIEW Information

  • Version
    LabVIEW 2011
  • Since
    2004
  1. The data comes from a fixed set of subsystems, mostly LabVIEW-based. This code fragment comes from a proxy style application which tries to reduce load to the backend data storage (TCP connected, 400GB ringbuffer) in which itself is a fine grained isNaN check in the floating point transient recorder.
  2. I updated my usecase example to clarify more what I am looking for: Basically I do want to compare the cluster raw contents against each other. The flatten to string works but I hope that it can be made more efficient and elegant. Updating a custom routine for all cluster elements when the cluster changes and implementing the isNaN for both sides is cumbersome and might be forgotten.
  3. Hi, is there an easy way for checking a mixed cluster for equality, ignoring the rules for floating point comparison (NaNs)? I just want to check if the data I receive is new or not. My current idea is: Loosing type safety and the buffer allocation is for my current use case ok (slow and non RT), but I wonder if I miss something. Edit: A colleague mentioned that a "to variant" does the some "trick" but might be faster... I guess I'll have to benchmark a little.
  4. The last part I don't understand. What do you mean with "graph" in respect to the TDMS file structure? From my understanding a error rate of >0% _will_ always result in some broken data. TDMS has no integrated consistency checks, as long as the TDMS segment headers survive, the whole file will look correct when opened. Nothing I would want in any form of production quality code/system.
  5. I still don't see why you want to build the file transfer on UDP, but I could imagine that if you know your packet loss rates and patterns, you could build a FEC (like RS codes) to counter the losses. At least it would be a fun thing to try
  6. The "owner" is still the VI and it gets cleaned up no matter what. This can lead to a race condition which may lead to lost writes. I hacked together a small nutshell (LV2011) to demonstrate the problem. test_vi.vi tcp_server.vi tcp_conn_server.vi As long as you know all variable names in the static part and access them at first there, this is not a problem. But this detail can be easily forgotten and when such an app grows, it could be a nightmare to debug.
  7. The dynamic nature of VIRegister has a drawback when used with dynamic code. Since the obtain refnum is done directly done, the potentially new global refnum has the lifetime of the calling VI references. e.g. use this with a dynamic TCP handler and created a new named register inside the dynamically instanced VIs. This new ref will be invalid when the instanced VI goes idle. This can produce some very hard to find bugs if not all references are obtained in a permanent running VI!
  8. I have seen a medical application switched back from LVOOP to normal clusters because of a much longer startup time on cRIO (LV2009) with LVOOP. Other than that it did work very nice with LVOOP.
  9. I opened a thread in the idea exchange for this: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Inplace-Typecast/idi-p/1771970
  10. This is what I actually did for getting rid of the buffer allocation, basically switched from array of I32 to an array of cluster of I32 and SGL as type for the RTFIFO for the interloop communication. Now the typecast is done in a lower priority loop where I can tolerate the timing/jitter induced. The general question remains... is there a way of an inplace typecast in LV?
  11. I was optimizing a tight realtime loop. During my first tries I ignored the buffer shown at the typecast because of the remarks from AQ here in the forum. After hours of tracing the code with various trace user events (I presumed the "scanned variable read" function was the cause of all the "wait on memory" trace entries), it was clear that the cast of a SGL to I32 takes some microseconds (~ 2 us on the used PXIe-8133). The way the type cast works is actually well documented in the help... too bad I thought I knew it better. It would be nice if the typecast would only do a buffer allocation
  12. Hi, is there a way to do a typecast e.g. from SGL to I32 inplace, without the buffer allocation?
×
×
  • Create New...

Important Information

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