Jump to content

FrankB

Members
  • Content Count

    17
  • Joined

  • Last visited

Community Reputation

5

About FrankB

  • Rank
    Active
  • Birthday 10/08/1970

Profile Information

  • Gender
    Male
  • Location
    Germany - Moenchengladbach
  • Interests
    my family, handball and motorcycling

Contact Methods

LabVIEW Information

  • Version
    LabVIEW 2017
  • Since
    1998
  1. I see. Just another thought: You mentioned, that you are getting data from 21 different channels. Is it neccessary to have the data off all channels (and measurement) within a single 3d plot? Or is it ok to have only the FFTs of one channel in one 3d plot and then have the ability of scrolling through the different channels. Maybe have an additional 3d plot for a second channel for data comparison? In that case you can reduce the needed memory by factor 21 or at least 10.5. And scrolling through the channels should be not too boring. The FFTs are calculated real fast. 20k FFT with each havi
  2. This happens on my machine too. Off course you have more memory available than just 160MB and I don't know the correct reason why LV claims so early that the memory is full. Afaik the amount of memory you can use in your VI is depending on your hardware (physical memory and so on) but I'm not sure how it is calculated. But I still wonder why you want to collect this huge amount of data in memory. Your single measurement shots are small enough to have no negative effects to the memory usage. Simply stream the data to a file after each light measurement of a single setpoint. Or are there any n
  3. Hi wallage, If you use a waveform with data type DBL you will end up in more than 4GBytes of raw data. You may use SGL to reduce the needed disk space by at least factor 2. In your example you collect all data in memory before writing it at once to the binary file. Solution: Open the binary file and write each measurement - 21 waveforms with their 1000 samples - directly to the binary file and close the binary file after finishing all data acquisitions. Similar to your TDMS write example. On my machine, which is not the newest one, less than 70 seconds are neccessary to store the 1,6GB b
  4. Hi goran, I'm sorry for my mistake. Due to the fact, that you specified the number of pulses which you want to generate, the counter out task uses automatically the second counter to detect when to end the task. As your DAQCard-6036E has only 2 counters they are both needed for your CO task. If you change your CO task to continuously generating pulses my solution should work. This is probably not a correct solution for your problem. If you only want to end the puls generation after quite a while and it is not too important if there is a 'jitter' of about some 10 or 100s millisecond in stop
  5. Hi goran, there seems to be no task or timing or channel or or or ... property that gives feedback about the amount of time a task was running or the number of pulses which were generated. And getting a system timestamp right after starting and stopping the task and then calculating that probably xy pulses where generated might be ok only with very low frequencies. An accurate solution is to use a separate counter and task to count the digital events of the pulse train task. Use 'Count digital events.vi' - Example for starting. Regards, Frank
  6. Hello Ammar, I am pretty sure that the people here on lavag.org could provide help on allmost any LabVIEW specific question. But first of all they have to understand the (your) problem itself I've tried multiple times to understand what you are actually doing and what exactly the problems are. Maybe its my bad english, but I didn't manage to catch it. As your post was read by various users and no one has answered until now I imagine that they couldn't get it as well. Try to formulate what your are doing and into what problem you run in simple and clear words. The answer will surely be out
  7. Hi Val Brown, maybe you have not saved your .lvproj after building the executions as LV has to store the build stuff in order to remember it the next time. Another reason would be source code controlling of the project and developing with multiple engineers. Sometimes the importance of the .lvproj file is underestimated and old versions of the .lvproj file will overwrite the newer ones. Regards, Frank
  8. Hi, the error occures because of using the wrong ActiveX class constant at type input of the 'Variant To Data' primitive. Select the class 'Excel._Worksheet' and the conversion will work properly. Now your example will write values to cell A2 of the worksheet with index 2. If you want to write more than 1 value, you have two possibilities: - explicitly set '_Worksheet.Range' to a single cell (Cell1 input) which you want to overwrite with the next scalar value. This for each of your values. Advantage: values can be spread all over the sheet. Disadvantage: slower. - set both inputs, Cell1 an
  9. Ok, I caught your problem now . We haven't found a straight solution for this problem, too. And if I remember correctly, we reported the need of getting VI menu references via VI Server mechanisms some years ago, cause we had exactly the same problem . This should be a good product suggestion for future releases of LV. Regards, Frank
  10. Hi Shaun, I'm not sure if I cought your problem right and I don't know the Passa Mak project. But what about some mechanism like this one in the screenshot? Implement some little standard components in all the VIs which should be supported by the Passa Mak thing. Produce events with changing a value (which represents a Q name for sending information back) and receive the according menu reference from the VIs. Any other solution without any extra code in (Main)VIs would be better. But I have no idea for such an improved way. Regards, Frank
  11. Hi Sharon, I think this should be possible with scripting, but if I take a closer look at your example problem, I would prefer a different solution. It seems that you need a variable number of timers (including reset and enable functions or so). My preferred first approach would be a functional global VI where you can handle all the settings of each timer within the uninitialized shift registers. You may then use this timer VI at different places on your block diagram for initializing the timers, resetting, en-/disabling, evaluating them. An improved solution could be made with LabVIEW class
  12. Hi sydney, I'm pretty sure that there is not a solution for directly catching events from subs that where not handled by the subs themself. There may be many solutions to get aware in a calling VI of something that you do in sub VIs. But if you like to do it with an event here is a little example VI (screenshot only) for something that should do what you need. Uh, little bit to slow for that forum. Daklu posted a similar solution in his post Regards, Frank
  13. Hello Herbert, there is no straight way to change the runtime menu of controls with the help of predefined .rtm files, as far as I know. You have the possibility to copy some predefined template .rtm file (say one of 'GraphDataSensitive_A.rtm' ... 'GraphDataSensitive_Z.rtm') over that file which is currently bound to Control (say 'MyGraphMenu.rtm'). After a small amount of time your context menu will show the items from the template. That works, so far, in the development environement but I've not evaluated it with an EXE. Probably the better solution will be the programmatic assembling of
×
×
  • Create New...

Important Information

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