mstoeger

I'd like to implement different data sources. The configuration file defines, which one(s) are loaded. All datasources are first initialized and the they shlould run. The datasources should not have frontpanels open

What is the appropriate way to do this?

datasource 1: active: OK, load and write your data into a queue

datasource 2: active: OK, load and write your data into a queue

datasource 3: not active: don't load

....

At the moment I have static parallel loops for all datasources, this seems to be a little bit bulky and rather not easily expandable in future.

I just found examples with VI-Reference, property-node "FP.open", invoke-node "Run" ... perhaps I have to make the front panels transparent?

Thank you all for your help/ideas!

Martin

Interesting approaches ... I will take a closer look to it and post my success!

Martin

Dear collegues,

What is the right way to COMMUNICATE with winscp?

I'd like to open a winscp session, then "use" the session to transport files, rename them, whatever, and after finishing the job I'd like to close the session again.

Of course, there is the possibility to write a script and run it. But: As I want to transport "livedata" packed into simple ascii-files or something similar, the effort for opening a session should be as small as possible. Is it possible to communicate interactively to a command-line application?

With the built-in "Intermediate FTP"-VIs this is not a problem, but SCP/SFTP?

Thank you!

Martin

Dear all,

today I started this topic (unfortunately wrong under "User Interface"):

I am looking for a possibility to

- read out a (linux-like) config file (comments start with #, value01 = abc, etc) --> DONE

- isolate usable lines (value01=abc) --> DONE

- parse this content to a "configcluster" --> OPEN

I have defined this configcluster as typedef. Now I want to connect this cluster to a function/VI that searches inside the usable lines (it's a string) for the names of the elements, gets the value behind the name, convert it to the type the element inside the cluster represents and inserts it into the cluster. I have the openG data Tools in use - perhaps I have overseen a simple solution?

This is an alternative to the LV-config-file VIs, in my opinion their use is rather unconvenient (and also this automatism is missing).

The advantage of my effort should be, that I can easily change/enlarge my configcluster(typedef) without applying changes to the readout-and-parsing-functionality.

I already got one interesting reply:

Take a look here

http://www.mooregood...iteAnything.htm

This does read/write to ms style config style VI's (not the linux style config VIs) but you can get a lot of insight about how something like you are proposing might be structured. In my opinion, this set of VI's pretty much solves the problem of easy to read, write, and create config files. I've used them quite a while with no problems.

I also use the LabVIEW XML schema a lot but not where I expect the configs to be edited in a text editor

Mark

Now I made a lot of progress, I produced a solution that does what I expect. As I am not fully experienced I share the code and ask all interested readers/programmers to take a look at it, perhaps improve it, give me some hints and use it! I all packed into a LV8.6-project, let me know, if I should give some more information.

Martin

PS: As I didn't attach the example config-file, it is here:

# System config-file# This file is equivalent to a Linux-like config-file.# Comments behind a # are ignored.# Values are identified by '='# Example:## Value01 = 123### Boolean values may be 0 and 1 or 'true' and 'false' without ''loglevel = 441logfilepath = c:\logssyslogserver = 127.0.0.1syslog_localport = 234basepath = d:\basepath

parseconfig_8.6.zip

Dear all,

I am looking for a possibility to

- read out a (linux-like) config file (comments start with #, value01 = abc, etc) --> DONE

- isolate usable lines (value01=abc) --> DONE

- parse this content to a "configcluster" --> OPEN

I have defined this configcluster as typedef. Now I want to connect this cluster to a function/VI that searches inside the usable lines (it's a string) for the names of the elements, gets the value behind the name, convert it to the type the element inside the cluster represents and inserts it into the cluster. I have the openG data Tools in use - perhaps I have overseen a simple solution?

This is an alternative to the LV-config-file VIs, in my opinion their use is rather unconvenient (and also this automatism is missing).

The advantage of my effort should be, that I can easily change/enlarge my configcluster(typedef) without applying changes to the readout-and-parsing-functionality.

Thank you!

Martin

Well, after all what I have read about the theme, I come to following conclusions:

- my example does not work, because I open a reference in the read case, then the queue is blocked

- the timeout of "read from queue" could be set to >1, but then the consumer loop will be executed frequently, even if no element is enqueued

- this could be done also with a FGV that does not store a reference of a queue but the data itself in an array

If the home-brewed solution has the same performance as the prepared element "queue", I don't know.

Thank you all for your interest! If new realization appears - let me know!

Martin

The advantage - in my opinion - is:

- queue used as a command-construct does not "lose" elements (a FGV could be more often filled then read-out)

- in this way I hope to get the ability to place the VI on different loops/threads and for example get even multiple previews of queue elements (I haven't done this in the previous attached example).

Well, I think queues are widely usable ....

I'll take a look at these sources, here again my problemcase in LV8.6 version --> thank you

Martin

main_queue.vi

queue.vi

Dear all,

I'd like to know, if it is possible to "wrap" queue functions inside a VI, that is someting like this "Action Engine" (antipattern probabely?) or store the Queue-Reference inside a FG. In this way it should be more easy to place it in different places/loops and the effort of wiring should be reduced.

Unfortunately, my example does not work ...

All ideas are welcome!

Thank you

Martin

queue.vi

main_queue.vi

Thank you for your comments. In the meantime I was not lazy and also tried to solve this problem. I got support by NI and they told me, what Rolf's last paragraph says:

The datatype "waveform" is "proprietary" and not documented. It is not a simple cluster.

Therefore we splitted the array of waveforms into it's waveforms and into their components (is this what we call a "workaround" or usual style of working:unsure:?)

Martin

OK, this is a code snippet of our test-dll.

Comment from my collegue:

The first function using native data types as fct arguments is working without any problems,

the second function which is taking clusters as arguments generates import errors.

///////////////// HEADER FILE FOR LABVIEW IMPORT //////////////////////#include "extcode.h"#pragma pack(push)#pragma pack(1)typedef struct {      float lvDouble;      float lvDouble2;} LVCluster;#pragma pack(pop)int __cdecl createTestFile(const char * fn, const char * str);int __cdecl saveDebugInfoTxt (LVCluster * cluster1, LVCluster * cluster2);////////////////// SOURCE FILE OF DLL /////////////////////////////////#include "stdafx.h"#include "aplbase.h"#include "writeVceDll.h" // standard definitions for afx-dlls#pragma pack (1)typedef struct {      float lvDouble;      float lvDouble2;} LVCluster;#pragma pack()extern "C" __declspec(dllexport) int createTestFile(const char * fn, const char * str);extern "C" __declspec(dllexport) int saveDebugInfoTxt (LVCluster * cluster1, LVCluster * cluster1);__declspec(dllexport) int createTestFile(const char * fn, const char * str){    // create test file 'fn', write 'str' into file.    return 0;}__declspec(dllexport) int saveDebugInfoTxt (LVCluster * cluster1, LVCluster * cluster1){    // get data from clusters and save into ascii file.    return 0;}// this is left as included by VS. we do not write any message handlers// CwriteVceDllAppBEGIN_MESSAGE_MAP(CwriteVceDllApp, CWinApp)END_MESSAGE_MAP()// CwriteVceDllApp-ErstellungCwriteVceDllApp::CwriteVceDllApp(){}// Das einzige CwriteVceDllApp-ObjektCwriteVceDllApp theApp;// CwriteVceDllApp-InitialisierungBOOL CwriteVceDllApp::InitInstance(){    CWinApp::InitInstance();    return TRUE;}

If more information is necessary, I can deliver this. So please do not hesitate to ask for it!

Martin

Dear collegues,

together with a programmer I try to implement a dll (in C) into my LabVIEW-code, that converts waveforms (or arrays of waveforms) into a fileformat, we use regularly. We studied the dataformats of LabVIEW --> no problem; he built a dll that uses a waveform as argument --> problem, we are not able to import this, it is also not possible to configure the usage of this dll manually. If I do so: "Error loading "C:\Programme\National Instruments\LabVIEW 2009\user.lib\...\*.dll". Diese Anwendung konnte nicht gestartet werden, weil die Anwendungskonfiguration nicht korrekt ist. Zur Problembehandlung sollten Sie die Anwendung neu insta" Interesting: My WinXP's language is german, my LabVIEW is english. The german part of the message is about: "The application could not be started, because the application's configuration is not correct. For troubleshooting the application should be reinstalled"

Error list:

Call Library Function Node '...*:...': Library not found or failed to load

Why?

It seems, that there apear no problems when we use standard C-datatypes (in test dlls), but the waveform ... this is strange (or we are just beginners)

So, where can I find an example of importing or using a dll for waveforms? And is there probabely a sourcecode available of a very, very simple "waveform-dll"?

I think, I made one mistake: I imported the dll three times, so I have three "import-projects" in the import-assistant. How is it possible to delete these entries? It is not enough to delete the folder in th user.lib.

Thank you for your ideas,

Martin

QUOTE (jdunham @ Sep 22 2008, 07:02 AM)

If you're using DAQmx, it has a circular buffer built in. If you set the acquisition to "continuous" it will acquire forever (not sure what happens when you roll over an I64, but at 1Hz, you won't live to see it).

There should be plenty of DAQmx examples you can use. If you need fancier access to specific points of the built-in circular buffer, you can have better control with DAQmx property nodes. Try out some of the examples and then post more questions if you hit a stumbling block.

If you are using other hardware, especially non-NI products, then Ben is right; you may have to write your own circular buffer.

OK, first of all I'll take a closer look to all available examples. As I am using NI-Hardware, it's possibel to use all features of daqmx.

But I'd like to discribe the probelm a little more detailed:

The datatype "waveform" has advantages: dt, channel names and scales and other attributes are the easiest solution to keep this information when converting data to other NON-NI-data and/or file formats.

When reading data once per second, I can start with applying filters, check limits and so on. After retrieving for example 300 reads I start with other calculations: fft, etc. And the last step is to store a piece of data with a "duration" of 300 sec into one file (or export it to another file format).

At the moment I prepare an array for y-data of all channels for 300 sec, get waveform components, and after finishing read no. 300 I build an array of waveforms again.

Sure, there are other possibilities: Get the date as 2D-array and not as waveform, take use of the function append waveforms, enlarge the daqmx buffer and read only all 300 sec., ...

But I wonder, that there is not a proven, much simpler way. Because I think, this is a just usual task.

In this way, I'll try to find the best solution - and when I'm satisfied with the result, I will share it here.

Martin

Hi,

I am looking for the best solution to first read continuousely multiple channels/multiple samples/waveforms all 1 seconds and build afterwards longer waveforms (for example 300 sec) - and the same again and again (as the program is doing unattended monitoring work).

In my opinion this is a very simple task, but the solution is not as trivial. I tried different ways, but these all seem to be a little bit complicated, therefore I ask for some good (and proven) ideas.

Thanks for your help

Martin