shoneill

8 hours ago, drjdpowell said:

Doubtful.  You went from Git from SVN,  I'm coming from Hg.  In Hg, if you want to go to an earlier commit, you just go to that commit.  If you want to make changes, then you make a new branch coming off at that point.  If you like those changes, you might merge that offshoot branch with the main one. 

Correct me if I'm wrong, but you can also do all of that with SVN....

On 6/23/2020 at 9:42 PM, Antoine Chalons said:

Funny enough I've seen the opposite situation where an alliance partner company has been using NI HW+LabVIEW for years (rather successfully) and a new CTO was hired to give a new dynamic to the company, but he (the new CTO) thinks NI HW is too expensive and LabVIEW is slow and unstable by nature and definitely not a good tool for any industrial application ; so the lad is slowly but surely pushing his team to use some "real programming language".

I was wondering if anyone has seen similar situations?

Nope. This situation would lead to either me or that other person getting fired because I'd call out their obvious ignorance on the subject immediately. I know about the fundamentals of human psychology and programming (which are kind of the same thing, just viewed from different angles and different problems to solve) to be willing to risk my job proving that person wrong,

For me a CTO who is ignorant on the technical level of things to this extent, letting their own personal beliefs lead their technical decisions is a reason to quit anyway. So I would just accelerate the process by causing a direct confrontation.

6 hours ago, Mefistotelis said:

If you're going after testing my definition:

You haven't offered a definition. You've made some statements using already-used words with a meaning which is (I think) different than you are trying to apply it. Hence my meme.

LVRT does NOT organise program flow. That's done by the compiled code of the VI directly which is implementing the program flow.  I do not know where you get your idea from.  Again, I feel you have misunderstood what the LV Run-Time does. It is really comparable to the C++ Run-Time installations which exist on practically every windows system. So for me, if you agree that VC++ is not virtualised, by extension, you also agree that LabVIEW is not virtualised.

21 hours ago, Mefistotelis said:

There are similarities between Labview and Java, but there are also considerable differences:

I feel like you're stretching here to make similarities seem to exist when tey do not.

Your argumentation for the LVRT is obviously flawed. If that were the case, every program which accesses Win32 functions is virtualised? No. It isn't. It's linking between actual compiled machine code. It is not platform-independent, it is compiled for the current machine architecture.

So is VisualC++ vistualised because there are VC++ runtimes installed on Windows?

To paraphrase "the Princess Bride".

To make comparisons with games, you might be better off looking at the blueprint editor which is part of Unreal Engine.  Feels a lot like LabVIEW.

Not controlled from within the game, but it's a lot closer to the kind of thing you're trying to infer here.

22 hours ago, Mads said:

PS: A similarly interesting performance nugget that can be nice to know about is the effect of branch prediction😃

I did NOT know that branch prediction could have such an effect. Nice post. Thanks.

That article brings some old memories to light. I remember during the old "Prime number" coding challenge on the NI site there were times where adding a dummy case to my case structures during processing produced measurable changes in execution speed. I couldn't explain it, but I accepted the improved execution times and carried on with my business.  Seeing how the execution was more or less deterministic, could it be that I was moving between "good" and "bad" patterns for the case structure. IIRC, the results were tested on a Pentium 4, with a 31-stage pipeline.  May be completely unrelated, but that was always a point which stuck with me that I couldn't really explain.

On 2/12/2020 at 2:53 PM, Mads said:

To give a simple example; if I have a table of 350 000 rows containing a time stamp (real) and 3 columns of  measurements (real),  and I select a time (sub)period from this table; it takes up to 0,6 seconds to retrieve the measurements on my test machine (using either a single SQL Execute 2D dbl, or the Select many rows template). For comparison the current binary file solution can locate and read the same sub-periods with a worst case of 0,03 seconds. 20x times faster.  This difference would not be an issue if the accumulated time per batch of request was still sub-second, but the end users might combine several requests, which means the total waiting time goes from less than a second ("instantaneous") to 5-30 seconds...

I'll just drop a link to a post on the dark side. I made that post after doing benchmark comparisons between TDMS and SQLite (sound familiar?).

It might be important to take into account that "first read" performance and "typical" performance can be orders of magnitude different. And the differences my be a function of the file type.

OTOH, as mentioned in the post, the same mechanism can be (ab)used to create a 64-bit file cache when using 32-bit LabVIEW, so that's nice.

<Pedantic>

The horizontal can opener thing is apparently not true. The main mode of operation of opening cans was vertically, even before (especially before) the "rotating wheel" versions were invented in 1870. Yes, 1870, nearly 150 years ago.

A version which removed the complete top of the can (horizontal cutting) only appeared in the 1980's.

According to a wikipedia entry I met down the pub.

</Pedantic>

29 minutes ago, Mads said:

Any tricks to this? (I'm using LV2018)

I love it when old posts come up and I simply can't remember writing them, but my name is on it, so it must have been me..... No, no tricks. Haven't done that in years. It was for simply LVLibs, no classes, no hierarchies. LLBs don't play well with classes (no sub-folders, no ability to store multiple VIs with the same name).

I suppose the PPL is the proper replacement for this now, although that's not source code....

Hmm, of course I run into problems at the target boundary. The Probes don't execute in the same context as the FPGA code.

Using a FP control of the cluster I want to investigate (hopefully all Abstract classes have been re-assigned) I run into problems.  Concrete classes become abstract classes because the abstract classes are the only ones included with the Probe (On the FP).

I thought I saw yesterday that the information is passed as part of the TypeDescriptor of the Variant resulting from a conversion but I don't see that any more.

I suppose this is ultimately a serialisation / deserialisation problem across context boundaries. Unfortunately, I can't use Variant or String directly on the FPGA.......

I've actually gotten it to work with general refnums.

One note: If the actual value of the items is not important (which is the case for me - I just want to make sure all elements in a cluster have actually been assigned) then all the information required is contained within the TypeDefinition returned when performing a "Flatten Variant to String".  I've written parsers for this before, but that was like 15 years ago in LV 6.1....

I got the class name part working with the NI VI GetClassName.vi. I'm going tot try to get it working with FPGA DMA channels...... lol. Wish me luck 🤪

I seem to have trouble getting this working with classes. I'd like, if possible to have the name of a concrete class included as "Value.

I don't know how to go about that...... Anyone got some tips?

On 9/3/2019 at 2:42 PM, styrum said:

😂He knew what was coming:

" I expect some sort of reaction from the defenders of OOP"

I refuse to accept the OPs idea of all people opposing his childish rant as being a "defender of OOP". I'm a defender of intelligence and critical thinking.  I'm an engineer. The OP is a petulant fool.  Of course some things are true, some things of OOP are good, some are bad. Judgement is required. Being intellectually lazy and understanding "OOP is a framework" is just not worth even arguing against. If he was working with me, I'd make sure the guy is fired.  Dead weight.

I've had several beers. This means this post is completely honest. If possibly not accurate.... ☺️

It's a rubbish post.

OOP is not a framework, as the author claims it is. He / she has clearly not understood what OOP is, what it's supposed to do, how it's supposed to work and when it's NOT best suited to the job.

Yes, OOP needs to be used wisely. No, it's not a band-aid for people who still don't know what they're doing.

And the claim that OOP does not map to the human mind..... well, darling, back when OOP was introduced, it's still better than completely unstructured code.

As with all software tools, if you don't understand it, it will hurt you.

Statefulness, messaging and concurrent code organisation actually has nothing to do with OOP. Yes, OOP can be used to get that working, but the two are completely unrelated topics. They can both co-exist without each other.

If it remains hard to trace, try clearing your compile cache. Works wonders for me sometimes.

I my test (After setting all to disable debugging) User Events are second only to Queues and Notifiers. They're 20% faster than Channel (High Speed Stream). And Notifiers and User Events are very close in performance.  Sometimes User Events win, other times Notifiers, depends on which other methods are running concurrently.

This is in a VM with only 2 cores.

nvm, I opened it in 2019 VM.

Sigh. Please, don't try to benchmark with debugging enabled.

Can you save it in an older version of LabVIEW?

I would always recommend wiring up the output of the read nodes to an array indicator (outside the sequence so that it has no effect on timing).  Compiler optimisations can do weird things when you're not actually wiring up certain outputs.  For example, you're not using the data output of the variant but you are of the map. Not saying it explains the differences, but I've seen things like that wildly affect performance in the past.

I would look at the code, but I'm currently trying to get 2019 installed in a VM.

I'm an avid GoT fan, but I'm waiting for Season 8 to arrive..... 🤣

On 5/4/2019 at 4:29 PM, ShaunR said:

It's a conjugation. I think Americans are the biggest perpetrators especially for "setted". They do other funny stuff like leaving out letters and putting dates the wrong way round 

Even God appears to agree with Shaun....

Mark 1:34 “And he healed many who were sick with various diseases, and cast out many demons. And he would not permit the demons to speak, because they knew him.”

16 hours ago, rscott9399 said:

It is simply a test bench to develop and test different functions. This is just the main place to select different VI's you want to test is all.

Again, i appreciate your help and concerns. I fully agree, im not teaching anyone labview lol im a matlab guy truthfully 

No problems. I understood from the previous post you were teaching LabVIEW as opposed to using LabVIEW to teach something else.

All clear now. And either way, the community is always ready to help.

Also, I don't mean to be mean, but are you sure you're in the position to create code to teach people LabVIEW?

This isn't advanced LabVIEW. If this is the quality of material students will be using to learn LabVIEW it might be best not doing it at all.

Again, I'm not being mean, I'm being honest (and if anything I'm being diplomatic). Don't you have access to people who have (a lot) more experience in LabVIEW to help you out?