mcduff

Yes, it has both of those functions and a device disconnect also. The Device Connect specifies a particular instrument. All other calls have no specifiers, even Device Disconnect. The API kind of stinks. My guess is, you specify an instrument in the beginning and that is it; everything else defaults to that instrument. EDIT: These functions are using the RSA.DLL

This is a somewhat out of the box idea and want to bounce it off people to see if there are any issues. (It would take some time to test, so I want to check if anyone has done anything similar.) I am trying to write a program that controls a TEK RSA507A. It has a DLL API that can interface with LabVIEW. The main problem is that the DLL does not support multiple instruments running at the same time; that it, there is no handle/address analogous to a VISA Address. On this site it says "In order to communicate with multiple RSA’s simultaneously you will need to call multiple instances of the RSA API. The API will need to be called for each RSA. " I assume that means if I have name the DLL differently for each instance, then I can call multiple instruments. Idea: When EXE opens, detect the number of instruments, then copy and rename the RSA.DLL in a temporary folder, e.g., RSA_1.dll, etc. Use the temporary DLLs to call functions for each instrument. Possible Problems: These DLLs call other DLLs, do not know if there will be any data corruption when that happens. I cannot rename the other DLLs. Will Windows let me copy and use a new DLL? Is that some kind of security problem? Am I missing anything else? Cross posted here

Do you have any advice for installing WebVIEW2? I have gotten it to work on one computer but not another for the same exact installation, I think. Thanks

Here's a start to a speedier solution starting and after selecting a new color. ColorPicker_GUI_DrawColorRectangle_mcduff_MODS.vi

@dadreamer Thanks for all of your help, will have to try it out later today when I have the instrument.

Sorry for haste when making the diagram, I made some typos. So please excuse my stupidity and ignorance, but here it goes. The IQSTRMIQINFO Structure contains the following content IQSTRMIQINFO(Structure): [('timestamp', c_uint64), ('triggerCount', c_int), ('triggerIndices', POINTER(c_int)), ('scaleFactor', c_double), ('acqStatus', c_uint32)] So I should set up my cluster as shown below and use DSNewPtr and MoveBlock if I want to read the data. If I have the function in a tight loop, can I make the pointer outside the loop and use it over and over again until I exit the loop and dispose of it? Thanks

@OP Sorry, don't mean to hijack this thread but... @dadreamer A few more quick questions. I am trying to interface with a TEK RSA using their RSA API. There is a function that allows one to stream the data from the instrument to the client, called IQSTREAM_GetIQData. The function prototype looks like this ReturnStatus IQSTREAM_GetIQData(void* iqdata, int* iqlen, IQSTRMIQINFO* iqinfo) Iqdata is an array of data and I think I can use the Array Data Pointer function in the library function, iqlen is just the length of the array. I believe the problem I am having is the IQSTRMIQINFO structure. The structure looks like this IQSTRMIQINFO(Structure): [('timestamp', c_uint64), ('triggerCount', c_int), ('triggerIndices', POINTER(c_int)), ('scaleFactor', c_double), ('acqStatus', c_uint32)] There is a pointer to an array of 100 elements in the structure. If I am understanding you correctly, I should use the pointer from DSNewPtr in the cluster, instead of an array. (See example below.) In the Call Library function what should the data format be: Handles by Value, Pointers to Handles, Array Data Pointer, or Interface to data? Thanks again for all of your help.

@dadreamer Can you please save the VI for an earlier version, say 2020? What you did may help me with a different DLL but a similar problem. Thanks.

This is way out of my league, and not sure if I understand correctly, but this link shows how to get the pointer to a LabVIEW array. Not sure if you have seen this already.

This is a quick way to do a X-Y Plot, no arrays of x and y data, or bundles of x and y points. To the OP try something like this

Possible Workaround

Cross-posted on the dark side https://forums.ni.com/t5/LabVIEW/How-I-plot-the-timestamp-in-the-graph-of-the-x-axis-and/td-p/4204975

Hallo Përshëndetje (Per-shen-DEAT-ye) مرحبا (marhabaan) Salam Kaixo Demat Здравейте (Zdraveĭte) Hola Moni Bonghjornu Bok Ahoj Hej Hallo Hello Saluton Tere Kamusta Hei Bonjour მიესალმები (miesalmebi) Hallo Χαίρε (chai-ray) Hello שלום (shalom) नमस्ते (namaste) Helló Dia dhuit 안녕하세요 Ciao ສະບາຍດີ (sabaidi) Salve Sveiki Bongu नमस्ते (namaste) سلام (salam) Olá Buna Talofa Mhoro Ahoj Zdravo Hola Hodi வணக்கம் (vanakaam) Merhaba chào bạn Helo העלא (hela) Sawubona

The issues that I have found are frustrating are the following: Staff go on field test with their laptops in another timezone, and forget to change the timezone. Although the metadata is in UTC, when they look at the time in their file stamps(time created, etc,), they get all confused. Timezone caching, bit me on a field test, luckily I noticed. Started the program, realized I had not changed the TZ, and then wondered why my timed start did not update correctly.

Not sure if this is related, but I have had an issue where if the LabVIEW program had been running and the timezone was changed, the time in LabVIEW would not be updated until the program was restarted. It appears LabVIEW caches the the timezone information and the beginning of the program and never receives an event that the timezone has ben updated. I wonder if it does the same for DST. And yes, I use UTC times for saving metadata in the file, but the users of the program like a local time stamp on the file name such that it matches their notebook log.

It looks like the external dll call has an extra buffer allocation, don't know if it is real or not, just what NI is reporting, whereas, the native implementation does not. See below. That may account for the speed difference. EDIT: Execution Trace toolkit shows the same.

FYI, cross-posted on the dark side https://forums.ni.com/t5/LabVIEW/USB-6215-10-Hz-triggering-with-2-TTL-signals/td-p/4181960?profile.language=en

Maybe not a new feature, but somewhere in the talk they mentioned a 2021 LabVIEW license would give you access to Windows, Linux, and Mac versions, no separate purchases required.

Don't disagree at all with the increase of computational power, but JPL has rules for code. I think having a set of rules helps to reduce possible errors.

You thought it out more than me. The test will be when I get 2021.

Just reporting that I used the DMC image control, had the box checked, and did NOT have a black image display. (LabVIEW 2020SP1, 64bit, Win10) No commentary on whether to check/uncheck box. Just suggesting a possible work around for folks who may want to check the box.

Not commenting on whether to allow future versions ... However, if it is checked and you want to use an image control that won't change colors in the EXE version, the Image Control in the DMC controls package available on VIPM does not suffer from this problem.

MAT files are now just H5 files(HDF). Look at the library https://h5labview.sourceforge.io/ and find the example for writing a MAT file. You just need to add a special header in the beginning. I assume the dlls needed will work on Windows server, but am not sure.

Maybe this link on the dark side may help: https://forums.ni.com/t5/Example-Code/Determine-Clicked-Array-Element-Index-in-LabVIEW/ta-p/3536340?profile.language=en (Some limitations in the code, may have to change for newer style arrays) mcduff

The following will replace a row or column subset or complete row or column of a 2D array using native functions and no loops or IPEs. If your subset array is 1D all you need to do is reshape it before a replace operation. ReplaceRowColumnSubset.vi