Jump to content

Mellroth

Members
  • Posts

    602
  • Joined

  • Last visited

  • Days Won

    15

Everything posted by Mellroth

  1. We had a similar issue with the ethernet based cDAQ chassies NI-9188. In that case the solution was to define a higher sample rate than we actually needed, just to fill the transmit buffer on the cDAQ side, then decimate the samples on the receiving end. When we asked NI about this, the response was that it probably had something to do with the new DAQ Streaming engine. /J
  2. I should probably have said Proxies (or at least that is how I see them), so that the code I'm developing doesn't need to know where the actual code is situated. I good example is when you call into folders that are not called by symbolic paths in LabVIEW. By putting a proxy caller under a symbolic path your code can call this code safely from any location, and if the proxy uses relative paths to the actual code it can be moved between platforms/computers/LabVIEW versions. /J
  3. I don't get it, why do you call LabVIEW add-on VIs dynamically These VIs should/could be directly called on the Block Diagram; giving you higher performance, and less complicated code. For me, the main reasons to call VIs dynamically is either 1. to spawn parallel processes 2. to dynamically load plug-ins 3. to break the hard link to a specific set of VIs at edit time /J
  4. Just info for the thread; if you want X samples you'll actually get X mod (4) * 3 samples out, or roughly 0.75X So the input should approximately be set to X * 4 /3 to get close to X samples out. I've seen this type of bug in another application a long time ago, and then it was due to the conversion from a 24bit stream to a 32bit stream. /J
  5. Late Friday night and almost in sleep mode... AQ said that to really reach out to all customers we really need to give our code to NI, but since LV 2011 we have the LabVIEW Tools Network built in to LabVIEW and this enables each and every user to easily install features they need (from OpenG, LAVA or LVTN). LVTN has no restrictions for licensing that I know of, but NI still reviews and put code under the NI umbrella and even publish some code of their own. I currently know nothing about JSON, but from reading through the threads here at LAVA it is probably something I will look into in the future. And when I do, I like to be able to select the implementation that I want to use; NI version, LAVA version or any other version. Installing these from LVTN/VIPM mean that new features/versions are available to me directly and I don't have to wait until the next LabVIEW release. Bugs detected in LVTN modules are also likely to be fixed much faster since the fix can be released regardless of the LabVIEW release cycle. /J
  6. OK, I guess you mean the Case structure, not the for loop? In that case; yes you could use the numeric as the selector, but in my experience you actually gain performance by using booleans instead of numerics in case structures. /J
  7. The boolean keeps track of the LF/CR characters because the original code removed one of two starting '.' characters. Only checking for equal 46 would remove all occurrences of double '.', not only at the start of a new line. /J
  8. And you can do even better still... Since the decoding is about removing escape characters, it is possible to reuse the input buffer and have a single FOR loop to do the decoding. The separate search for new lines is unnecessary since we can deal with these characters on the fly. Attached is a VI that I tested on the "NOT WORKING.rar". The original code (except header and footer removal) takes about 650ms and the buffer reuse version takes about 4ms. yEnc Decoder.vi It also think it is possible to speed up the footer search by performing the search backwards. To do this replace the footer search string "=yend " by "=yend .*$". /J
  9. Nice! Personally I would get rid of that bundle/unbundle of Horizontal/Vertical coordinates, as it only adds confusion. /J
  10. I'm very disappointed you didn't say "%^<%Y-%m-%dT%H:%M:%S%3uZ>T" /J
  11. We have added a number of YouTube clips to demonstrate the basic usage of the AppBuildSupport as well as the ProgressBar module /J
  12. In a previous project we had a similar issue, but with a Ethernet chassie (NI-9188). The reason for the "hang", or rather a very long detection time, was that a previously used 9188 device (existing in MAX) was unplugged from the system. We solved it (I think) by refreshing the MAX configuration. /J
  13. I believe I had the same issue on LabVIEW 2011. My solution was remove the defaultConPane key from the ini file and start LabVIEW. Stop LabVIEW re-add the ini file token /J
  14. The reason you get this error is that you cannot register for FP events for controls on a VI that is not in memory. And, you cannot keep the front panels opened since you want to show hide the VIs in the SubPanel control. Event if you try to register for control events while the FP is in memory, the event registration goes invalid when the FP is closed. My best bet, even though I haven't tried it, is to use UserEvents instead. Or if you want to play safe, use Notifiers or Queues to do the signalling. /J
  15. Maybe I misunderstood what you were trying to do. I thought you liked to be able to silently load a VI even if it was broken? Option 0x20 really allows you to do this; unless you also set option 0x10, the VI will silently be loaded into memory. /J
  16. You can specify the tabbing order from the Edit menu -> Set Tabbing Order..., at least in LabVIEW 2011. I think I recall that this was named something like "Set Frontpanel order" in earlier LabVIEW versions, but I cannot check right now. /J
  17. Here you go ChartUpdateProblem_lv2010.vi /J
  18. To make it easier to download, the toolkit is now "Certified with LabVIEW", and has been added to the LabVIEW Tools network. This means that it can be downloaded directly from within VIPM. vipm://WF_AppBuilderSupport?repo_url=http%3A%2F%2Fftp.ni.com%2Fevaluation%2Flabview%2Flvtn%2Fvipm /J
  19. Attached is a small VI that generates 4 sinewaves and plots them in two equally configured WfmCharts. ChartUpdateProblem.vi The WfmCharts is configured as Scope update mode All plots have thicker lines to make the problem more visible Plot1 and Plot 2 are anti-aliased In this case the Stop button overlays the plot area in the upper WfmChart. Run the VI and notice the difference in the lines in the upper and lower WfmCharts. The upper chart should have somewhat jagged lines, and if you run the VI for a while you might even get to see this ;-) Pressing the stop button forces LabVIEW to redraw the upper chart. If you move the stop button outside the plot area, the problem dissapears, but the same problem can be seen if you move the plot legend inside the plot area. /J
  20. I would be very careful not to overlay any controls/indicators on a chart, as it might result in strange artifacts, especially when the chart is updated very frequently. If the chart is not updated very frequently, I would use a graph instead if I wanted cursors. /J
×
×
  • Create New...

Important Information

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