LogMAN

So this just happened to me and I'm quite confused by it. As it turns out, the .NET Constructor Node not only provides terminals for error in, error out and the reference, but actually two more "hidden" terminals:

Notice: I left the error terminals untouched and none of the wires are connected (try it yourself). This never occurred to me. Only now, while hunting a null reference exception I found the constructor node looked "off", like this:

The strange part is that the terminal doesn't actually carry the reference (which is why I receive the null exception). It only specifies the type. The upper left terminal is a void type input, so the wire is always broken.

Does anyone know why these extra terminals exist? They don't seem to be part of the specification as far as I can tell.

Any fancy things we can do with this?

How about a fade animation for switching between FP and BD?

Or slowly connecting wires with some sparkling effect at its current position?

By 2020 Hollywood will use LV for the next generation of CGI, just wait for it

21 hours ago, Neil Pate said:

Anybody else troubled by things like this?

Absolutely. We still use LV2015 for our projects, even though newer version are "superior" in some aspects. Still wondering if there is anyone at NI actually using LV/NXG for real-world applications nowadays. From my perspective, design has become much higher priority in newer versions than responsiveness did in the past. My dev machine is equipped with decent hardware and still LV2017+ and NXG feel slow. The kind of slow where you wait for some freaking animation to finish, not the kind of slow where the code runs slower...

It has gotten to a point where we are frustrated enough to consider moving away from LV, especially for more common tasks that can easily be done in text languages. In the past we implemented those tasks in LV mostly for convenience (only one language to maintain), but maintenance has become more and more tedious and very frustrating in newer versions (don't even get me started on NXG, it's a disaster). I really hope NI takes a hint and allows disabling all the "cute" features in LV and NXG. LV2020 is likely the last version we'll consider for internal testing. Hopefully with positive results or my keyboard will get much more busy than my mouse.

16 hours ago, smithd said:

They're trying to ease you into nxg

Says a lot about it, doesn't it

On 6/4/2018 at 10:35 AM, shoneill said:

Every time I try to download videos my IP gets banned.....

You might want to reduce the number of parallel connections to two (seems to be working fine on my end). The server bans IPs with too many connections at once:

6 minutes ago, jacobson said:

Were the old NIWeek videos moved to another location?

The other videos are still online, but not available right now until traffic for the current videos has gone down. Once all of us finished choking the server all videos should be available again. This has happened in the past as well:

1 hour ago, halum said:

look at my work its is correct or no plz

expression:  1) z = (3>>x)+(5<<y)

2) z = (x² ^ 2) | (y & 1)

I understand you are eager to learn programming in LabVIEW, but you should really start by learning the concepts first. The learning curve you try to take is way to high in my opinion. That being said, these are your current solutions as far as I can tell:

1) z = (x << 3) + (5 << y)
2) z = (x² ^ 2) | (y & 1)

Again, you should manually calculate some results and see if your code returns the correct results.

31 minutes ago, halum said:

1) z = (3>>x)+(5<<y) what does it mean << and >> its an array? and by any tools can i design it in block diagram

To answer your question: No, its not an array. I think GregSands already provided good help to this particular question:

22 hours ago, GregSands said:

Secondly, look at the built-in help to explain the operators.  Right click on the Formula Node, then Help, and then look for the allowed operators.  You'll see the ones you need, including >> (right shift), << (left shift), & (and), ^ (exclusive or), and | (or).  Note that ^ is not "to the power of".  That should make completing this fairly straight-forward.

Of course this is only useful if you work with the Formula Node, just like you did with the other solution. That being said, before you continue writing anything in LabVIEW please take your time to understand what your expressions are doing. Try to make it simpler to understand. For example, instead of trying to get this entire expression to work, start with one portion of it, like the first part:

z = 3 >> x

You have to answer the same questions as before: What do you expect this expression to return for z?

There are a lot of resources on the internet that also explain very well what these expressions do. You just need to know what to search for, so here is a translation table for you:

• >>    Arithmetic Shift Right
• <<    Arithmetic Shift Left
• ^       Bit Exclusive Or
• &      Bit And
• |       Bit Or

I suggest you try and understand what each of these expression does before combining them into longer expressions. Here is a full list of operations with their names for the Formula Node: http://zone.ni.com/reference/en-XX/help/371361P-01/lvhowto/precedence_of_operators_in/

31 minutes ago, halum said:

2) z = (x² ^ 2) | (y & 1) when i put the boolean oppeartion and try to connect input and out put variable, message show demande mathscrpt

I'm not an expert with Formula Nodes, but this should be possible to do without MathScript. From what I can tell the "x²" probably isn't allowed in the Formula Node, so maybe use "pow(x,2)" instead? If you get an error message please post the entire message here, maybe someone knows why this error happens.

8 minutes ago, halum said:

I mean i cant design a Virtual instrument for this expression

You did it for the other expression, so which part do you have trouble with? Is there maybe an error message when you create the VI?

5 hours ago, halum said:

is my work until now correct?

You are the one who wrote the program, you should know better than anyone if it produces the right results or not. If you don't, maybe you should start by understanding the expression before writing any code. Let's take your first example:

if ((a + b) >= 4)
    c = (a - 2) + (b * 3)
else
    c = (a + 5) * (b - 2)

What do you expect for a = 2 and b = 3? Your program returns c = 9. Is this correct?

Before writing any code I suggest calculating a few results by hand. That way you can compare your results to what the program returns. This is how you make sure your program works correctly.

Edit:

On 5/7/2018 at 5:56 PM, halum said:

but the first and second  expression i m really  not understand how can i resolve it

Can you explain more detailed where you have trouble? The third expression seems to be working, so what is the problem with the other two?

40 minutes ago, 0_o said:

However, the crashes didn't happen during execution and you refer to DWarns and not DAborts.

You mean they didn't happen in the executable right? The executable has no automatic error handling (unless compiled with debugging enabled, maybe), so the errors still happen but silently.

Error 1097 indicates that the library corrupted memory. Memory that doesn't belong to the library, which is a serious issue. I'm not an expert with Call Library nodes, but this should be taken care of. Here is an article that might be of help: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P6tcSAC

@jacobson mentioned before:

19 hours ago, jacobson said:

A DWarn is something that LV could recover from and a DAbort is something that LV could not recover from.

A DWarn doesn't mean LV restored the corrupted memory, just that it was able to continue operation despite the memory being corrupted. You should still make sure it doesn't happen again!

42 minutes ago, 0_o said:

I have several ways to check for memory issues and already saw that even when I close a reference to a dll using the call library the memory is not freed till the calling vi is closed (BD closed) and that is often the stage when LV crashes.

Sounds to me like the Call Library nodes are not configured properly. The library is unloaded by LV when closing a VI which causes the library to free all of its memory. Since the library accessed memory in the address space of LV, it tries to free it, causing LV to crash in the process.

44 minutes ago, 0_o said:

Why should the call library behavior be expected?

I meant that this is to be expected while working on the Call Library node. At least it takes me a while to figure out the correct settings before it works without errors.

Some of your crash logs point towards the TSVN Toolkit. Possibly related: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019RInSAM

Edit: OpenCV also causes some issues:

<DEBUG_OUTPUT>
21/02/2018 17:31:12.240
DWarn 0x50CBD7C1: Got corruption with error 1097 calling library OpenCVWrapperToCpp.dll function ?lv_Canny@@YAXHHNNH_NPAH@Z

I suppose you were working with the Call Library function at that moment, so these problems are to be expected. Just make sure to restart LV every now and then to reset the memory or LV will crash eventually.

1 hour ago, mje said:

Somehow there's an auto-magical cursor scaling in the image that doesn't appear on screen.

A screenshot consists of two elements: A picture of your block diagram and a separate picture of the mouse cursor at that moment. The software also reads the position of the cursor and puts it back on top of the block diagram, scaling it to the current cursor size (of Windows that is) in the process. This is why it looks bigger in the screenshot that it does on your monitor.

That being said, if NI isn't willing to implement high DPI cursors in LV "classic", maybe there is a way to add or replace the cursors using one of the resource editors.

There is actually an idea on the Idea Exchange for this and it was rejected for already been implemented!

1 hour ago, mje said:

I'll preemptively say NG isn't an option, there are reasons I'm still working in LabVIEW 2017.

You probably won't like their solution...

Here you go: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-LabVIEW-DPI-aware-to-support-high-DPI-screens-and-Windows/idc-p/3672540/highlight/true#M37286

I have never used these protocols myself, so I can only point directions. Here is a topic that has a solution regarding SOAP: https://forums.ni.com/t5/LabVIEW/SOAP-web-service-possible-to-access-from-LabView/td-p/3198844

It's done for LV 2015, but you can always save for previous version to make it work with any version down to 8.0

Somewhere down that thread is a link to a topic on LavaG, might prove useful as well:

18 hours ago, kaly2002 said:

The program is ok, but the icon is missing.

Yes, I can see how that could be an issue. Unfortunately I'm not aware of a solution to fix the icon. The standard functions like Addition, Subtraction, etc... are not really VIs. They are written in C or whatever language they use to program LV nowadays. So, they can do stuff we can't.

When creating a source distribution you can remove the front panel and block diagram in the source file settings:

Be aware that removing the block diagram prevents you from using the VI on a newer version of LabVIEW as it cannot be recompiled.

Edit: You might find this article helpful: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019LY1SAM

1 hour ago, Blokk said:

My first post on LAVA

Welcome!

1 hour ago, Blokk said:

Is this my PC, or others can see such issues on the site?

I haven't had issues for the past few years and didn't notice any problems today. The posts in your picture are from 2014, so maybe they weren't fixed during the upgrade. Please post a link to the topic in question, so we can compare.

1 hour ago, ChuckBorisNorris said:

So the syntax is correct when sent from one PC but not the other, maybe that's a clue?

It's a good sign. At least you can be sure that it'll work if you wipe your machine and install it from scratch

If you still want to figure out which part is causing your issues you'll have to eliminate factors one-by-one. Here are a few things you can try:

• Log-in with a different user account and try to access the database
• Copy the database to your local drive and try to use it with your application
• Create a new database that has the necessary tables and try to use it with your application

Still, you read masses that are way off compared to the values you'd expect, right? Since you do voltage measurement you also have to consider side-effects from other parts of your setup (like wires running alongside that transfer signals which may induct into your wires).

I suggest you take a graph of your input signal over a reasonable duration and have a look at it. Try to figure out if the source signal is acceptable for your needs. If that's the case and the output is still wrong, maybe you can share some sample data and a VI to find a solution.

On 11/29/2017 at 11:29 AM, ChuckBorisNorris said:

I know I had to repair my Office 365 installation last week and I'm wondering if that could be the cause

Have you since tried reinstalling? Repair might have skipped repairing the database driver.

Other than that, there are a few clues on the web which indicate that the error code is caused by some invalid character in your query:

http://digital.ni.com/public.nsf/allkb/3BC28421B4761BCC8625710E006D76CB

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P83sSAC

http://digital.ni.com/public.nsf/allkb/D8FF30B4409602B386256F3A001FC96C

Since that is clearly not the case (unless you have some weird zero-width character in your query), you should try reinstalling the software.

You could also try running your VI on another machine to see if it works or not.

You should check your (raw) input signal. Sounds to me like the input signal from the force sensor is not as stable as you think it is. The equation is a simple conversion from force to mass, so it'll produce the same output given the same input. Even if you don't take the average over your input signal, the calculated mass should stay within reasonable limits.

59 minutes ago, Gab said:

actual weight of my system is ~400 g but my daq program giving me a strange value (like 40g, 29g, etc..)

Check the datasheet of your force sensor. Its output might be scaled (the same could apply to your DAQ settings).

59 minutes ago, Gab said:

why this happen for stable mass system hanging with spring ?

How stable are we talking about? 400 g isn't that much (in my world that is )

Paintainable is very nice, I like it a lot!

If you want to describe code behavior rather than the impact on the developer, I suggest "Melodramatic Solution".

I get the same behavior on my machine using your sample project (attached to the post on the dark side). As in your picture the indicator of the Sub-VI changes its state, but the indicator on the Main VI doesn't.

However, I created a VI from scratch with the exact same block diagram as "ReadDVRData" (created manually) and it works fine. Copying the block diagram doesn't work as well as reconnecting and replacing the terminal doesn't work. This is something NI should be concerned about. Looks to me like the terminal assignment is broken or some other weird optimizations failing. Did LabVIEW crash during development by any chance?

If I remember correctly the default buffer size is 4096, so even in async the function has to wait for the buffer to clear if the provided data is bigger than the buffer size. Does increasing the buffer size change the result?

Files as in "Downloads" or files as in "Attachments"?

I have no issues attaching files and images to posts:

Empty VI.vi