JKSH

Interesting. Looks like there's some type propagation issue when the Decimal String to Number node is combined with the Negate node:

Remove the Negate node and the problem disappears.

The issue seems to exist in the LV 2020 beta too. Would you like to post in the beta forum, for the attention of NI R&D enginners? http://www.ni.com/support/beta-program/ (I'm happy to post on your behalf, if you prefer)

6 hours ago, Brad Fuller said:

Is this topic still alive?  I have invested a huge amount of time in a LV2017 application, and now I would like to be able to control the multiple front panels from remote using websockets. I have hit a roadblock with the Labview method in that the plug-ins required are not allowed by browsers. It seems like this websocket approach might work with any browser with no need for the Labview Run Time on the client-----I would like to use Android mobile phones for instance. Is "smarlow"still here?

There are multiple demonstrations in the wild about using WebSocket with LabVIEW. Google should be able to help you.

Here is one endorsed by NI: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000kJV5SAM

@smarlow has not posted in over a year, but might be lurking: https://lavag.org/profile/17965-smarlow/

On 11/21/2019 at 10:01 AM, ThomasGutzler said:

Good find!

@Jim Kring happy to assist in any way I can when you're looking into this bug.

Jim does not come to LAVAG often (e.g. see https://lavag.org/topic/21017-where-are-openg-product-pages-for-packages/?do=findComment&comment=129287 )

I'd imagine you'd get a lot more interest if you post at the JKI forums

13 minutes ago, ThomasGutzler said:

Unfortunately, nobody seems to care about this any more

Nested malleables + VIPC is not a combo that I use

19 hours ago, Mefistotelis said:

Is that fixed in LV 2019, or do NI still avoid UTF

LabVIEW NXG uses UTF-8 for all text strings.

I think classic LabVIEW (version 20xx) will unlikely ever get full Unicode support.

Oops, I just realized: We can't use strcpy() because that would also try to copy the terminating null byte. Use memcpy() instead. (Sorry, my C is rusty)

You're welcome

39 minutes ago, GregFreeman said:

My only follow up question is, is it necessary to size the LStrHandle to fit the string and use strcpy?

Yes. The string bytes must be placed in the memory space immediately after the 4-byte header:

(source: http://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/how_labview_stores_data_in_memory/)

Here's another illustration:

• A 5-char C string takes 6 bytes of contiguous memory, ending with a null byte:
  • ['H', 'e', 'l', 'l', 'o', 0x00]
• A 5-char LabVIEW string takes 9 bytes of contiguous memory, starting with a 4-byte integer:
  • [0x05, 0x00, 0x00, 0x00, 'H', 'e', 'l', 'l', 'o']

The LStrHandle cannot hold a pointer to a char array that is held elsewhere.

1) LabVIEW manages the memory of the string itself. You must allocate the memory to hold your full string plus a 4-byte header, then copy all of your string data from the DLL memory into LabVIEW memory:

LStrHandle cString2LVString(const char *myCString)
{
	const int headerSize = 4;
	const int stringSize = strlen(myCString);

	// Allocate memory for the LV string
	LStrhandle h = (LStrHandle)DSNewHandle(headerSize + stringSize);

	// Write the LV string header
	(*h)->cnt = stringSize;

	// Copy the data into the LV string
	memcpy( (*h)->str, myCString, stringSize );

	return h;
}

2) Assuming that you initialized an empty array in LabVIEW and passed the handle into your Call Library Function Node for iir_get_serial_numbers(),

typedef struct
{
	int32 len;
	LStrHandle str[];
} **LStrArrayHandle;

int iir_get_serial_numbers(LStrArrayHandle arr)
{
	LStrHandle buffer[1024]; // Make sure this is big enough for all cases, or use
	                         // a dynamically-resizing array like a C++ std::vector.
	int n = 0;
	while(s_deviceInfo -> next)
	{
		buffer[n] = cString2LVString(s_deviceInfo->serial_number);
		++n;
	}	
	// NOTE: At this point, n equals the number of devices

	// Resize the LabVIEW array
	const int headerSize = 4;
	const int arraySize = n*sizeof(LStrHandle);
	DSSetHandleSize(arr, headerSize+arraySize);
	
	// Write the array header
	(*arr)->len = n;
	
	// Copy the string handles into the array
	for (int i = 0; i < n; ++i)
	{
		(*arr)->str[i] = buffer[i];
	}
	
	return 0;
}

3) Yes you can.

NOTE: The variable names are different, but from the LabVIEW Manager's point of view an array handle is basically the same thing as a string handle (in Classic LabVIEW, a string is an array of bytes). Allocation, resizing, and data copying techniques are the same for both types of handles. See http://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/how_labview_stores_data_in_memory/

You are calling Open VI Reference using a path that points to your hard drive (D:\DEBUG\debug\vi_01.vi). That VI is not inside your executable. It is possible to make this work, but your executable will break if you move the VI on your hard drive.

It is safer to open a strictly-typed Static VI Reference. This loads a copy of Vi_01.vi is stored inside the executable itself:

For more info, see

• https://forums.ni.com/t5/LabVIEW/Static-VI-Reference/td-p/3334006
• http://zone.ni.com/reference/en-XX/help/372614J-01/glang/static_vi_ref/

9 hours ago, jcarmody said:

I've done it using a parameterized query

Wrapping the queries in a transaction ("BEGIN TRANSACTION" + "END TRANSACTION") could speed things up a lot for 250000 rows

On 10/31/2019 at 11:11 AM, Michael Aivaliotis said:

My workaround to the large files problem was to accept the fact that I will lose the revision history on those files. Not a huge deal, since most large files I had were installers and binaries that didn't have revisions per say.

Files that don't have revisions don't need to be commited into the repository itself.

GitHub has a nice feature called GitHub Releases which lets you host "release files" -- it's designed for installers/packages/binaries, but you're free to store other files there too. Each Release is linked to a tag/commit in your Git repo so you know which version of your code was used to generate the installer. Here's an example of some releases from an NI repo: https://github.com/ni/niveristand-scan-engine-ethercat-custom-device/releases/

BitBucket has a lightweight variant of this called BitBucket Downloads (the link is somewhat tangential, but it's the best I could find).

I like GitHub's release file hosting more than BitBucket's, but I like BitBucket's issue tracker more than GitHub's.

8 hours ago, Rolf Kalbermatter said:

That was my first thought too 😆. But!!!!

The Call Library Node only allows for Void, Numeric and String return types and the String is restricted to C String Pointer and Pascal String Pointer. The String Handle type is not selectable. -> Bummer!

How about creating the initial handle in LabVIEW (e.g. an empty string), passing it into the DLL as a handle, then calling DSSetHandleSize()?

2 hours ago, ShaunR said:

There is a test for 1 that I have seen (can't remember off hand what it was called) but it was mainly for c/c++ and counted things like the number of if/else or entries in Case statements to arrive at a figure for "complexity"

Sounds like VI Analyzer

I can't commit to direct collaboration, but I'm happy to share my thoughts, experiences, and code from a similar project.

https://www.tensorflow.org/api_docs/ comes with a warning:

Quote

A word of caution: the APIs in languages other than Python are not yet covered by the API stability promises.

This means new versions can break backwards compatibility which would be a pain for a non-Python based wrapper/binding project. This is probably a reason why NI might not stick to the latest and greatest version of TensorFlow.

I can see 2 possible approaches:

1. Wrap the TensorFlow Python API, and integrate into LabVIEW using the Python Node.
2. Flatten the Tensor C++ API into a C API, wrap the C API, and integrate into LabVIEW using the Call Library Function Node.

#1 guarantees that the wrapper won't be broken by a TensorFlow update, but restricts the wrapper to Windows and LabVIEW >= 2018 only. I also don't have experience with the Python Node and don't know what limitations might exist.

#2 allows the wrapper to be used on Linux RT and on older versions of LabVIEW, but there's always a risk of compatibility breaks between TensorFlow versions. Also, given the large number of classes and functions (see https://www.tensorflow.org/api_docs/cc ), it might make sense to write a code generator (like VI scripting) that produces the actual wrapper code, instead of writing the wrapper by hand.

I've written a code generator to (partially) wrap the C++ API of the Qt toolkit (see https://github.com/JKSH/LQ-CodeGen ). This generator makes many assumptions based on Qt's features and coding conventions so it's not usable for generic C++ libraries, but its source code might provide some ideas and hints. The final wrapper library is at https://github.com/JKSH/LQ-Bindings

34 minutes ago, Michael Aivaliotis said:

You can't create a wiki for an organization.

You can create a GitHub-hosted website for an organization: https://pages.github.com/

3 hours ago, Michael Aivaliotis said:

GitHub does not have a good way to group related repositories, so they visually seem to belong together... Having numerous OpenG repositories will make this a bit messy.

A poor man's way of doing that is to prefix all of the repository names with "OpenG". Users can then use the "search" feature within the Organization to find all repos related to OpenG. For example, https://github.com/ni?q=niveristand vs. https://github.com/ni

There's also GitHub Topics, although it crosses organization boundaries: https://help.github.com/en/articles/classifying-your-repository-with-topics

• e.g. https://github.com/search?q=topic%3Averistand+org%3Ani

20 hours ago, Michael Aivaliotis said:

How can we improve OpenG? Where is the OpenG repo?

https://sourceforge.net/projects/opengtoolkit/

@Rolf Kalbermatter has access.

1 hour ago, Neil Pate said:

Anybody know what these error codes mean? 

I found a post with the exact same error codes: https://forums.ni.com/t5/SystemLink/Package-deployment-failed-through-SystemLink/td-p/3839425 (Google had exactly 1 hit on ni.com)

JoshuaP suggests installing ni-certificates first. (His solution is for SystemLink rather than NIPM, so I'm not sure how applicable it is to your case)

1 hour ago, 0_o said:

remember to stop your subscription or else they will continue automatically to charge you additional 12$ each month just for the subscription if I understand correctly

The Humble Monthly is the ongoing subscription.

The Humble Book Bundle (and other "Bundles") are once-off payments where you decide how much to pay.

2 hours ago, Thang Nguyen said:

We are using NI Softmotion, cRIO and NI 9503 to control stepper motors now. But since NI will discontinue these products we need to look for replacement.

I can't find any announcement that that NI SoftMotion, CompactRIO, or the NI 9503 will be discontinued. Where did you hear that?

1 hour ago, IAN CHUNG said:

But it will show this error or the program crashed.

Oops, sorry... I didn't notice CL_RenderingDATA. This means the union is 64 bytes long.

Try using a cluster of 16 SGLs, and only read the first 3 values.

Or, try changing the parameter configuration:

• Type: Array
• Data type: 4-byte Single
• Dimensions: 1
• Array format: Array Data Pointer
• Minimum Size: 16

2 hours ago, IAN CHUNG said:

Trying to call the function below...

ER_CODE KMAPI CLGetMeasData(DEVICE_HANDLE hDevice, CL_COLORSPACE Type, CL_MEASDATA* pColor);

So here are more details about the other parts of the function: https://stackoverflow.com/questions/38632316/typeloadexception-using-dllimport

• ER_CODE: I32
• KMAPI: stdcall
• DEVICE_HANDLE: Pointer
• CL_COLORSPACE: Enum (size is not well-defined in C, but it's usually 32-bit)

Your CLFN must have Calling Convention = "stdcall (WINAPI)" and have 4 parameters:

2 hours ago, IAN CHUNG said:

Actually just need Evxy.

...

typedef union tCL_MEASDATA

{

        CL_EvxyDATA           Evxy;                                       

        // ...                           

}

CL_MEASDATA;

 

typedef struct tCL_EvxyDATA { float Ev; float x; float y; } CL_EvxyDATA;

If you only want to read Evxy from the function, you can pretend that the parameter type is CL_EvxyDATA* instead of CL_MEASDATA*. This works because is a CL_MEASDATA union and CL_EvxyDATA is one of the structs it can store.

Make a Type Definition: A Cluster that contains 3 SGL numbers, and use this cluster to to tell the CLFN how to interpret the data.

On 7/13/2019 at 12:06 AM, Aristos Queue said:

1. I noted a few uses of lowercase "boolean". Capitalizing that B is often confusing because it is the only non-class type that is typically capitalized. Text languages have solved this by using keyword "bool", and therefore that is the actual type name. LabVIEW doesn't typically type out data types. NI style guide says to capitalize Boolean. Does LV wiki agree?
2. When I'm editing the wiki, I will generally follow NI documentation style guidelines (so "subVI" instead of "SubVI", for example).
   Are there any particular conventions that the community has established that differ from NI standard practices?

These are purely stylistic issues. I'd personally prefer Boolean and  subVI, but I'll follow the community guidelines (when they are produced).

On 7/13/2019 at 12:06 AM, Aristos Queue said:

3. When discussing language features (as opposed to editor features), LabVIEW 20xx uses "LabVIEW"... LabVIEW NXG has moved to using "G" and uses "LabVIEW" to discuss the IDE. We find that this provides clarity in many documents, and it provides less of a mouthful when speaking (The NXG root class is "G Object" instead of "LabVIEW Object", for example).
Does the wiki prefer "LabVIEW" or "G" when discussing language features?

This one has ramifications for the ease of understanding of an article (especially for newcomers). I'm not sure what's best here.

Perhaps we can let NI spearhead the effort to "normalize" the use of "G". We can stick to "LabVIEW" for now since it's more common, but switch over to "G" later when NI's efforts bear fruit.

On 7/13/2019 at 12:06 AM, Aristos Queue said:

4. When behaviors diverge, what is the preferred way to document distinctions between LabVIEW 20xx and LabVIEW NXG? Should they be separate pages (so the former can be easily deprecated in the future) or do we prefer same-page-different-sections for easier side-by-side comparison?

I'm with Rolf; same-page is much more useful in the forseeable future.

6 hours ago, ShaunR said:

This is a historical "problem" due to compilers being case sensitive. This was one of the reasons that I went for Pascal compilers over C since Object/Open/Turbo Pascal is case insensitive and boolean or Boolean are synonymous (as a type). I've always maintained that there is no excuse for case sensitvity as it only introduces errors, obfusicates and increases foot-shooting but has zero benefits (unless you consider obfusication a benefit which is arguably a security risk). 

This thread is about literature, not code.

It's a question of finding a balance between practicality and professionalism. Side A can reasonably accuse Side B of being a Grammar Nazi while Side B can reasonably accuse Side A of being sloppy.

6 hours ago, ShaunR said:

I've had many conversations with C/C++ programmers over capitalisation of types and function names (initial caps vs camel case vs lower case etc) and my response has always been "whatever".

My response would be "be consistent within a project". Feel free to have different conventions across different projects.

So for the Wiki, we should at least be consistent within a single article or group of closely-related articles. Some might even argue that the whole Wiki is a single project.

6 hours ago, ShaunR said:

Do we really need to bring this problem to a wiki, of all things, about a language in which case is irrelevant?

No, as long as you don't care when people write "LabView".

4 hours ago, Lipko said:

So the question is: is it possible to read property names with illegal characters somehow (so that I can read old files too) in Labview, if it is possible in Diadem?

If was written successfully, then it can be read too.

The key is to find out what name was stored in the TDMS file. If you call TDMS Get Properties.vi without wiring the "property name" and "data type" input, you're meant to get an array of all available properties in the "property names" output.

11 hours ago, Lipko said:

The property names are not listed when calling TDMS Set Properties.vi without the property name and data type terminals connected.

I presume you meant TDMS Get Properties.vi? If so, then that's very weird. My next guess would be you're opening different files in LabVIEW vs. DIAdem.

Try calling TDMS Get Properties.vi without the name inputs immediately after you write the custom property.

56 minutes ago, Lipko said:

Creating user properties is working fine using TDMS Set Properties.vi, but I can't read them with TDMS Get Properties.vi.

1. What level of properties did you write? File, Group, or Channel?
2. What level of properties are you trying to read? File, Group, or Channel?