LogMAN

I discovered a potential memory corruption when using Variant To Flattened String and Flattened String To Variant functions on Sets. Here is the test code:

In this example, the set is serialized and de-serialized without changing any data. The code runs in a loop to increase the chance of crashing LabVIEW.

Here is the type descriptor. If you are familiar with type descriptors, you'll notice that something is off:

Here is the translation:

• 0x0008 - Length of the type descriptor in bytes, including the length word (8 bytes) => OK
• 0x0073 - Data type (Set) => OK
• 0x0001 - Number of dimensions (a set is essentially an array with dimension size 1) => OK
• 0x0004 - Length of the type descriptor for the internal type in bytes, including the length word (4 bytes) => OK
• ???? - Type descriptor for the internal data type (should be 0x0008 for U64) => What is going on?

It turns out that the last two bytes are truncated. The Flatten String To Variant function actually reports error 116, which makes sense because the type descriptor is incomplete, BUT it does not always return an error! In fact, half of the time, no error is reported and LabVIEW eventually crashes (most often after adding a label to the numeric type in the set constant). I believe that this corrupts memory, which eventually crashes LabVIEW. Here is a video that illustrates the behavior:

Can somebody please confirm this issue?

LV2019SP1f3 (32-bit) Potential Memory Corruption when (de-)serializing Sets.vi

On 1/26/2021 at 2:39 PM, pawhan11 said:

- variant input and return 1d array of variants when input variant is array  (any dimension any data type in array)

There is a VI in OpenG LabVIEW Data Library that does this for you.

On 1/26/2021 at 2:39 PM, pawhan11 said:

- variant input and return array of variants when input variant is  set (any data type in set)

-variant input and return variant pairs of key values when input is Map (any data type of key and value in map)

For Maps and Sets I can get type info using Type Parsing Library but not the actual, the only way i see is digging into type descriptors...

I took this as a challenge and added two VIs to my library on GitHub - https://github.com/LogMANOriginal/LabVIEW-Composition

Decompose Map extracts variant keys and values of variant maps

Decompose Set extracts variant elements of variant sets

I have successfully tested these VIs with various different types, but there could still be bugs. Let me know if you find anything. I strongly discourage using these in production!

The library is now available on GitHub (including test cases) https://github.com/LogMANOriginal/LabVIEW-Composition

I also discovered this project, which provides some useful methods to work with variant data.

It's a separate library. Object composition was actually much more difficult to figure out than the other way around. I have attached the library for LV2017 (without test suites and package configuration). I'll also put this on GitHub in the near future.

Here is an example that overwrites elements in the private data cluster (the outer IPE addresses the class hierarchy).

Here is an example that uses JSONtext to extract data from a private data cluster. I was looking into this particular case as a way to transition from clusters to/from objects

Both examples are included in the package.

Object Decomposition LV2017.zip

21 hours ago, bjustice said:

JSONtext branch with object support:
https://bitbucket.org/logmanoriginal/jsontext/src/lvobjectserialization/

This was meant as a proof of concept to see if it can be done and if it's something worth investigating. I should probably mention that this branch has a few bugs that I haven't fixed yet.

22 hours ago, bjustice said:

Internally, we made the early decision that we didn't want to directly access class private data through string flattening or by inspecting the class' *.ctl file.

Certainly not something I would use in production right now but still, I believe there is some value in this - especially for general-purpose libraries like JSONtext. Anyway, I'll back save and upload when I have access to LV. By the way, the details are explained on the Wiki: LabVIEW Object - LabVIEW Wiki

I haven't found a better way to do this without adding (or scripting) methods to every class. The only function that currently breaks encapsulation natively is Flatten To XML, which has its own limitations.

If you are interested in object (de-)composition, I have a library that does most of the heavy-lifting (extracting private data and putting it back together), including functions to work with clusters of any size and shape. I can save it back to LV2017 and post here.

4 hours ago, Neil Pate said:

OK, so deleting the branch on the remote only deletes it from being used in future, it still exists in the past and can be visualised?

Only the name is deleted, commits are left untouched. It is actually possible to restore the branch name if you know the commit hash - https://stackoverflow.com/a/2816728

This can be useful if you deleted a branch before it was merged into master, or if you want to branch off a specific commit in the history that is currently unlabeled.

Here is some documentation from Atlassian, generally applicable to GitHub as well:

• Git Branch | Atlassian Git Tutorial
• Pull Requests | Atlassian Git Tutorial

13 hours ago, Neil Pate said:

I still don't really get this. I want to see the branches when I look in the past. If the branch on the remote is deleted then I lose a bit of the story of how the code got to that state don't I?

The Network Graph mentioned by @JKSH does give you some visualization on GitHub. I personally prefer the visualization in Sourcetree and bash.

Here is an example for GitHub - microsoft/vscode: Visual Studio Code

The command I use is

git log --oneline --graph

You can see that branches still exist even after merging. Only the name of the branch, which is just a fast way to address a specific commit hash, is lost (although it is typically mentioned in the commit message).

That said, some branches can be merged without an explicit merge commit. This is called "fast-forward" - https://stackoverflow.com/a/29673993. Maintainers on GitHub can decide if they always want a merge commit, or not.

2 hours ago, govindsankarmr said:

The error is -1073807339 , VISA Read in MB Master.lvlib:MB_ADU_RTU.lvclass:RX ADU.vi:1->MB Master.lvlib:MB_Master_Serial.lvclass:Querry.vi:1->MB Master.lvlib:Read Holding Registers.vi:1->Untitled 2. Can anyone help me what is the reason of this error.

Here is some information about this error: VISA Error -1073807339 (0xbfff0015) Timeout Expired Before Operation Completed - National Instruments (ni.com)

There could be many reasons for a timeout error. The error message only indicates that a timeout occurred before a reply was received, which is not very useful. NI IO Trace might give you some additional clues.

Maybe put the master in a shift-register on your while loop. Not sure if that makes a difference.

1 hour ago, Neil Pate said:

It's been a while but when using the NI Modbus library I found there was some weirdness regarding what the base of the system is. This might just be my misunderstanding of Modbus but for example to read a holding register that was at address 40001 I would actually need to use the Read Holding Register VI with an address of 1 (or 0).

This is specified in the Modbus Application Protocol, although implementations vary between 1-based and 0-based. The mapping of addresses is typically resolved internally.

Quote

The Request PDU specifies the starting register address and the number of registers. In the PDU Registers are addressed starting at zero. Therefore registers numbered 1-16 are addressed as 0-15.

-- MODBUS Application Protocol 1 1 b

2 hours ago, Neil Pate said:

But what is this all about? I have done a bit of digging and it seems the current best practice is indeed to delete the branch when it is no longer needed. This is also a totally strange concept to me. I presume the branch they are talking about here is the remote branch?

You got it right. "Delete branch" will delete the branch on your fork. It does not affect the clone on your computer. The idea is that every pull request has its own branch, which, once merged into master, can safely be deleted.

2 hours ago, Neil Pate said:

I still am not sure I 100% understand the concept of local and remotes having totally different branches either!

This can indeed be confusing if you are used to centralized VCSs.

In Git, any repository can be remote. When you clone a Git repository, the source becomes remote to the clone. It doesn't matter if the remote is on your computer or on another server. You can even have multiple remote repositories if you wanted to.

You'll notice that the clone - by default - only includes the master branch. Git allows you to pull other branches if you want, but that is not mandatory. Likewise, you can have as many branches of your own without having to push them to the remote (sometimes you can't because they are read-only).

On GitHub, when you fork a project, the original project becomes remote to your fork (you could even fork a fork if you wanted to...). When you clone the fork, the fork becomes remote to your clone. When you add a branch, you can push it to your fork (because you have write-access). Then you can go to GitHub and open a pull request to ask the maintainer(s) of the original project to merge your changes (because you don't have write-access). Once merged, you can delete the branch from your fork, because the changes are now part of master in the original project (there is no reason to keep it).

Notice that the master branch on your fork is now behind master of the original project (because your branch got merged). Notice also that this doesn't affect your local clone (you have to delete the branch manually). You can now update your fork on GitHub, pull from your fork, and finally delete the local branch (Git will warn you about deleting branches that have not been merged into master).

There is a page which describes the general GitHub workflow: Understanding the GitHub flow · GitHub Guides

Hope that helps.

3 hours ago, ShaunR said:

You can turn it off, but not on.

You could run a VI via CLI to turn it on.

For starters, there are a few DWarns:

c:\nimble\penguin\labview\components\mgcore\trunk\18.0\source\ThEvent.cpp(216) : DWarn 0xECE53844: DestroyPlatformEvent failed with MgErr 42.
e:\builds\penguin\labview\branches\2018\dev\source\typedesc\TDTableCompatibilityHack.cpp(829) : DWarn 0xA0314B81: Accessing invalid index: 700
e:\builds\penguin\labview\branches\2018\dev\source\objmgr\OMLVClasses.cpp(2254) : DWarn 0x7E77990E: OMLVParam::OMLVParam: invalid datatype for "Build IGL"
e:\builds\penguin\labview\branches\2018\dev\source\typedesc\TypeManagerObjects.cpp(818) : DWarn 0x43305D39: chgtosrc on null! VI = [VI "LSD_Example VI.vi" (0x396f46b8)]
e:\builds\penguin\labview\branches\2018\dev\source\UDClass\OMUDClassMutation.cpp(1837) : DWarn 0xEFBFD9AB: Disposing OMUDClass definition [LinkIdentity "StatusHistory.lvclass" [ Poste de travail] even though 5 inflated data instances still reference it.
e:\builds\penguin\labview\branches\2018\dev\source\UDClass\OMUDClassMutation.cpp(1837) : DWarn 0xEFBFD9AB: Disposing OMUDClass definition [LinkIdentity "Delacor_lib_QMH_Message Queue V2.lvclass" [ Poste de travail] even though 1 inflated data instances still reference it.  This will almost certainly cause a crash next time we operate on one o

Here is some information regarding the differences between DWarns and DAborts:

I'd assume that one of the plugin VIs or classes is broken. You can try and clear the compiled object cache to see if that fixes it.

Alternatively uninstall each plugin until the issue disappears. (start with LVOOP Assistant, I remember having issues with it in LV2015).

It could be open source and still be maintained by NI, as long as they have a way to generate revenue. There is also great potential in the NXG platform, which - as far as I know - is written in C#. Even if LabVIEW is not of interest to millions of people, keep in mind that most open source projects only receive contributions from a small portion of their users.

The Linux kernel is probably not a good comparison, because it is orders of magnitudes more complex than LabVIEW. Nevertheless, Linux "only" received contributions from approx. 16k developers between 2005 and 2017 - 2017 Linux Kernel Report Highlights Developers’ Roles and Accelerating Pace of Change - Linux Foundation. Compare that to relatively young projects as Visual Studio Code (~1400 contributors), or the .NET Platform (~650 contributors). These are projects with millions of users, but (relatively speaking) few contributors.

2 hours ago, Neil Pate said:

The full complement of engineers at NI can barely make any progress into the CAR list, what hope is there for anyone else?

It depends. Companies might be willing to pay developers to fix issues. Enthusiasts might just dive into the code and open a pull-request with their solution. Some items might not be of particular importance to anyone, so they are just forgotten.

Good selection by @Mefistotelis

Try to figure out what motivates them (games, machines, information, ...) and help them find the right resources. Try different things, perhaps something sticks. If not, move on to the next.

Here are two links that can get you started with python in a few minutes.

• Take your first steps with Python - Learn | Microsoft Docs
• Python Getting Started (w3schools.com)

1 hour ago, Matt_AM said:

I've seen that I'm not supposed to send classes via queues so this is my work around to properly cast my variant to the correct data

Not sure where you got that. It's a valid approach: Command pattern - LabVIEW Wiki

The Actor Framework, for example, takes this idea to the extreme.

1 hour ago, Matt_AM said:

When I was talking about events/queues, I mean more like a queue to send my data (not read) or an event struct with a 0ms timeout to monitor if a stop condition occurred.  I understand I don't want to induce additional delays in my read to avoid timeouts. 

I'm not a fan of the 0ms timeout case because it adds unnecessary polling. The rest sounds good to me. It is probably best if you build a prototype to see what works best for you.

You use some patterns in the wrong context.

4 hours ago, Matt_AM said:

I am using the factory template for my power supply class since I know what my outputs and inputs are.

4 hours ago, Matt_AM said:

I was thinking about using the factory pattern for an XNET Read class, but there are 3 basic methods to read from XNET - signal, frame, and XY.

The Factory pattern is only a means to create new objects without explicitly referencing them. Here is a very simple example using a Boolean to select from two classes.

In this example, Class 1 and Class 2 both are children of Superclass. Depending on the input value, one of them will be returned. The caller doesn't need to know how to create those objects and only sets the input value to True or False. A typical implementation uses a String instead of a Boolean, which allows for many more options and adding more classes later.

In any case, the output of a Factory is the most common ancestor of all possible children (Superclass in this example).

4 hours ago, Matt_AM said:

I am trying to figure out how I can use something like a dynamic dispatch to read anything from XNET without having to create 3 specific XNET read subclasses to an XNET read class.  And then taking that further, what about a generic read class where I could read DAQmx data as well as XNET data?

Dynamic dispatching is not something that magically merges different functions into one. It is only a way to change the behavior of a function at runtime.

Perhaps you are familiar with Polymorphic VIs. Dynamic dispatching is actually very similar to polymorphism. The difference is how they are resolved. Polymorphic VIs are resolved at edit time. Dynamic dispatch VIs on the other hand are resolved at runtime. This is why dynamic dispatch VIs must always have the same terminal pattern. This is of course a very simplified explanation.

For your particular question, there are two parts to it:

• Create specific subclasses for each type of power supply - For example, XNET and DAQmx are entirely different technologies, so it makes sense to have separate classes for each.
• Use the Strategy Pattern to change the behavior of a particular method - For example, your XNET class could use different strategies to do the actual read operation (XY, double, etc.).

The Strategy Pattern encapsulates an operation in an object. You need to write one object for every possible strategy and then provide the desired strategy at runtime (i.e. using a Factory). Here is a basic example.

In this example, XNET is a subclass of Power Supply, which has a Read Data method that returns an array of double. When XNET is created, the desired read strategy is passed as an argument. The strategy has another dynamic dispatch method to do the actual read operation. The Read Data method then uses the strategy to read the data. DAQmx would work similarly, perhaps with its own set of strategies.

I believe that this comes very close to what you have in mind.

5 hours ago, Matt_AM said:

My current thought is so have a "Read" and "Read Type" class used to build my XNET read.  Read would be an abstract class containing queues and events so my Read Type Class knows where to send the data.  Read Type would be another class that would implement how I want to read this specific type of class.  For example, Read Tye could be XNET signal/frame/XY or DAQmx Analog/digital/counter since the read type class is my strategy of how I want to read my data. 

Don't put events and queues inside the reader class. Instead, have a separate class that uses the reader class to produce events or populate queues (these should be separate classes altogether, one for queues and one for events).

I suggest you play around with the different patterns to get used to them before you use them in production. OOP can get confusing very quickly if you are only used to functional programming.

On 12/20/2020 at 5:31 PM, crossrulz said:

Now imagine a "Senior Engineer" being brought in on a project and being told to redo everything because you used an Event Structure.  No, I am not exaggerating.  He had issues with the Event Structure in LabVIEW 6 and swore them off forever.  Good thing I didn't listen to him, managed to get him to leave me alone, and the project was successful.

Glad to hear it worked out well for you. I wish I had this confidence 10 years ago...

On 12/20/2020 at 5:31 PM, crossrulz said:

My point here is that titles should be taken with a grain of salt.

I agree. Unfortunately the decision is not always up to us, especially for young teams without expert recognized by higher-ups. In our case it went something like this: 

NI is also not very helpful in dampening expectations:

Quote

The Certified LabVIEW Architect (CLA) is the final step in the three-part LabVIEW certification process. The exam verifies the user’s ability to build a sensible VI hierarchy and project plan for delivering an application that fulfills a set of high-level requirements. Certified Architects provide technical leadership, helping ensure the developers on their team follow best practices and become more competent and efficient developers.

-- Certified LabVIEW Architect (CLA) - National Instruments (ni.com)

The rest is history.

To be fair, our case was a single incident. The general experience with contractors has been very positive and insightful. Still, I would probably raise an eyebrow if a CLA told me that they don't know how to work with classes. Just seems weird considering that it is the final stage in the certification process.

6 hours ago, drjdpowell said:

Trying to rework the entire architecture of a large project sounds very expensive and risky.

Funny how you spell "is" 😄

11 hours ago, ShaunR said:

Actually. Yes. Elitist zealotry deserves mocking.

Actually had to google that. If I understand it correctly, you are saying that my sentence is phrased in a way that is offensive to you (and others perhaps). That was not my intention. Let me try to explain myself and hopefully clear up what I presume is a misunderstanding.

15 hours ago, LogMAN said:

A CLA who isn't familiar with fundamental OOP concepts is incapable of making such decisions and in worse case puts the entire project at risk by making random decisions or avoiding OOP because they don't see the value in it.

By "A CLA who isn't familiar with fundamental OOP concepts..." I mean somebody who has no prior knowledge about OOP whatsoever. They don't know what a class is and how inheritance or encapsulation works. It is my opinion that this makes them incapable of choosing between different OOP frameworks and libraries themselves (of course they could ask somebody they trust).

For the second part "and in worse case puts the entire project at risk by making random decisions" imagine somebody without any prior knowledge about OOP being brought into a project that is heavily based on OOP (i.e. using Actor Framework). They are brought in by management to evaluate the situation and get the product ready for market. Of course management will listen to the CLA as an expert (as they should).

If the CLA ignores the fact that they don't know anything about OOP (worse case scenario), the best they can do is decide based on their instinct, feedback from other developers, or simply by tossing a coin and hope for the best. There is a great chance that this will put the project at risk because everyone listens to that expert. I can't be the only one who went down this rabbit hole.

The last part "or avoiding OOP because they don't see the value in it" is about changing architecture late in a project because of a personal vendetta against OOP. Let's take the example from before. The CLA might decide that Actor Framework is not a good solution simply because they don't like OOP stuff. So they tell management to toss everything away because it's "no good" and start from scratch using their own approach.

Unless the architect has really good arguments, decisions like that are toxic to any project. I have actually experienced a situation that went in the opposite direction (replacing everything with objects because OOP is THE way to go). We eventually reverted to what we had before thanks to the power of Git. (that was probably the most expensive revert we did - so far).

Just to clear up one additional point because I believe that it didn't come across in my original post. I believe that there is value in OOP but I don't think it is the only answer to everything. On the contrary. Frameworks like DQMH completely eradicate the need for frameworks like the Actor Framework. Depending on your needs and what you feel more comfortable with, either one is a great choice. I simply expect a CLA to have basic knowledge about OOP, even if they decide against it.

5 minutes ago, ShaunR said:

I've never read such a load of clap-trap on this forum.

Did you only come here to mock me?

If you disagree with something I said, please feel free to express your point of view and perhaps we can find common ground.

I believe it should.

OOP (and interfaces in the near future) are architecturally relevant and at the core of frameworks and libraries that drive so many applications. A CLA should be able to assess if a particular framework is a good choice architecturally, or not. A CLA who isn't familiar with fundamental OOP concepts is incapable of making such decisions and in worse case puts the entire project at risk by making random decisions or avoiding OOP because they don't see the value in it.

It probably makes sense to focus on fundamental concepts in the exam, because frameworks and libraries eventually get outdated and replaced by new ones.

@Matteo.T You need to start a new topic for your question, it doesn't belong to this thread.

• Do you receive any error at the error output terminal?
• Does the other team see any error in the server logs?
• Did the other team give you any idea about what kind of web service they provide?
  Since the other team suggested Postman, chances are high that they use a RESTful service.
  JKI has a REST API Client library on their website which you could try: JKI HTTP REST API Client for LabVIEW

1 hour ago, X___ said:

I wouldn't use a language which is based on a lot of inaccessible C++ code for mission critical software... like driving a space rocket, for instance.

Unless you work entirely on Linux and OSS, most of the core libraries are closed source. Even if that was not the case, you still need to trust the hardware. That's why it's important to test your mission critical software (and hardware) before you put it in the field. No amount of open source will make your software more secure or reliable. You only get to fix bugs yourself and be responsible for it.

To be fair, most of us are probably not doing rocket science... right?

52 minutes ago, ShaunR said:

.NET can go hang - it's not cross platform -

"There will be just one .NET going forward, and you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more." - Introducing .NET 5 | .NET Blog (microsoft.com)

52 minutes ago, ShaunR said:

and we can already pass NuLL pointers, it's just not a LabVIEW type.

Pointers yes, values no. If you raise a .NET Event with a NULL value, the .NET Event Callback will not fire... 

Make sure that you have the rights to distribute those binaries before you put them in your build specification. There is a license agreement that you accepted when you installed them on your machine.

Note that you don't have to distribute those assemblies yourself. Perhaps there is a runtime installer available which your clients can use. As long as the assemblies are installed on the target machine, LabVIEW will either locate them automatically, or you can specify the location in an application configuration file.

Here are some resources on how assemblies are located:

• Loading .NET Assemblies - LabVIEW 2018 Help - National Instruments (ni.com)
• How the Runtime Locates Assemblies | Microsoft Docs