Jump to content
flarn2006

I found some more hidden INI keys

Recommended Posts

The file @lordexod attached is extracted from 'lvserver.rsc'.

And of course, pylabview can extract that as well, to pure XML. ie:

  <DNmsh>
    <!-- D. Name Strings List -->
    <Section Index="1" Name="Class ID" Int5="0x00000000" Format="inline">
      <String>ClassID</String>
      </Section>
    <Section Index="2" Name="Owner (Deprecated)" Int5="0x00000000" Format="inline">
      <String>Owner</String>
      </Section>
    <Section Index="3" Name="Owning VI" Int5="0x00000000" Format="inline">
      <String>OwningVI</String>
      </Section>
    <Section Index="4" Name="Class Name" Int5="0x00000000" Format="inline">
      <String>ClassName</String>
      </Section>
    <Section Index="5" Name="Modified" Int5="0x00000000" Format="inline">
      <String>Modified</String>
      </Section>
    <Section Index="6" Name="Is On Block Diagram?" Int5="0x00000000" Format="inline">
      <String>IsOnBD?</String>
      </Section>
    <Section Index="7" Name="Owner" Int5="0x00000000" Format="inline">
      <String>Owner</String>
      </Section>
    <Section Index="8" Name="Delete" Int5="0x00000000" Format="inline">
      <String>Delete</String>
      </Section>
    <Section Index="9" Name="Tag:Set Tag" Int5="0x00000000" Format="inline">
      <String>SetTag</String>
      <String>TagName</String>
      <String>Value</String>
      <String>isPersistent</String>
      <String>OldValue</String>
      </Section>
    <Section Index="10" Name="Tag:Remove Tag" Int5="0x00000000" Format="inline">
      <String>RemoveTag</String>
      <String>TagName</String>
      <String>OldValue</String>
      </Section>
[...]

 

Share this post


Link to post
Share on other sites

Here are some "secret" INI keys related to CLFNs:

  • extFuncGenNoWrapperEnabled=True - the most interesting one here; adds "Generate Wrapper" option to CLFN context menu (on by default). When this option is unchecked (off), LabVIEW doesn't generate the wrapper for DLL call, i.e. ExtFuncWrapper function is not called and the user's function is inlined into the VI code and called. This feature could slightly improve performance of external code communications, saving approx. 5 to 10 ms on each call. But you must be absolutely sure, that your CLFN is set correctly as no error checking is done in this case and any small mistake in the parameters leads to LV crash. There might be an indirect use of this feature, e.g. manual fine-tuning/debugging of some problematic function or a function with unclear parameters etc. When the option is enabled and extFuncShowMagic is set, CLFN is painted red.
  • extFuncBreakOnGenNoWrapper=True - if enabled, disallows to run VI with CLFN's "Generate Wrapper" option unchecked. The Run arrow is broken and the error is stated as "Call Library Nodes with 'gen no wrapper' are not supported.". The error is detailed as "This Call Library Node is set to 'gen no wrapper'.  This setting skips certain steps when calling DLLs in order to be faster, and can be dangerous.".
  • extFuncShowMagic=True - adds some coloring to CLFNs, when "Generate Wrapper" and "Type Only Argument" options are used.
  • extFuncExtendedOptionsEnabled=True - adds "Allow Sub-Arrays" option to CLFN context menu (off by default). I assume, it should have worked this way, but I have not found any signs that this feature is working at all. If I set "Constant" option, then a sub-array is passed into a function, else the whole array is copied and passed, no matter if "Allow Sub-Arrays" is set or not. Maybe I missed smth or it's a relic option from pre-LV2009 era...
  • extFuncArgTypeOnlyEnabled=True - adds "Type Only Argument" option to CLFN context menu, when clicking on a node's terminal (off by default). When this option is checked, LabVIEW passes 0 (aka NULL) instead of a real value of the parameter, no matter if passed by value or by reference. When the option is enabled and extFuncShowMagic is set, the terminal is painted bluegreen (cyan). Any thoughts, what was it used for? Here's its scripting counterpart.
  • allowPreallocsInDll=True - adds "Allow Preallocated Data" option to CLFN context menu, when clicking on a node's terminal (off by default). Did not study this one well, but it seems to not do anything or I'm wrong? Here's its scripting counterpart.
  • callLibNodeMayHaveLVClassParams=True - if enabled, allows to run VI with LV class wires passed into CLFNs. By default the Run arrow is broken, when class wire is connected to CLFN. Interesting, but what can we do with it in the external code?
  • AllowCLFNTakeSlice=True - unexplored too atm.

This is the pic with some options activated:

DbgPrintf_BD.png.192d491fb686369bd8eb8bf39646203f.png

DbgPrintf.vi

I also noticed that there are some private flag bits for CLFNs, e.g. extFuncVarArgs, extFuncParamsFromTL, extFuncNIValidated, extFuncTopLevelOnlyInUI.

2020-05-22_17-28-44.jpg.d9394f21a0633457eeb752f18fe421e3.jpg

I believe, some bits should be available with scripting also. Var args feature looks interesting, but it's likely an abandoned thing, isn't it? AFAIK CLFNs never supported that in any manner.

Finally some sort of off-topic, but somewhat related.

Did you know that it's possible to create an input constant for CLFN's return terminal?

2020-05-22_17-40-34.jpg.328899ecd4b115893b74394023138edd.jpg

2020-05-22_17-43-40.jpg.d71e19a4530fc595746550b4aa17e1d5.jpg

Just set Return output as non-void and do a RMB click on the left terminal. The Run arrow is not broken and the VI runs fine. Ancient bug or intended for something? I've never seen that value being passed into external code in any ways.

  • Like 1

Share this post


Link to post
Share on other sites
3 hours ago, dadreamer said:

Did you know that it's possible to create an input constant for CLFN's return terminal?

2020-05-22_17-40-34.jpg.328899ecd4b115893b74394023138edd.jpg

2020-05-22_17-43-40.jpg.d71e19a4530fc595746550b4aa17e1d5.jpg

Just set Return output as non-void and do a RMB click on the left terminal. The Run arrow is not broken and the VI runs fine. Ancient bug or intended for something? I've never seen that value being passed into external code in any ways.

There is no good reason why that should be forbidden. Without an input wired, LabVIEW will allocate the variable automatically (also true for normal parameters since around LabVIEW 6 or so. Before that LabVIEW required you to wire inputs no matter what). Otherwise it will reuse the one wired into the left terminal to store the result into. Useful? Not really but maybe it was left in as there is no harm done with it and someone might have figured out that it could be one day useful to reuse the passed in value to determine the data type (and possibly buffer size).

Share this post


Link to post
Share on other sites
On 5/22/2020 at 9:11 PM, Rolf Kalbermatter said:

Before that LabVIEW required you to wire inputs no matter what

I checked that in LabVIEW 3.1.1 and it doesn't require the Return input terminal to be connected to some constant. I also tried LabVIEW 3.0 and 2.5 but I don't see CLF Node there, only CIN, so can't check there.

1226959367_23-05-202023-05-17.jpg.e7bacc8ef2cb2b9bb69a92e241cbe1c2.jpg

Got the same in LabVIEW 4.0 (in fact it's a demo version, but DLLs are callable).

I still think, there's some sort of a bug, because in LabVIEW 7.1 and 8.0 when you created that unnecessary constant on the left, connected it to CLFN and changed the Return type back to void, the VI's Run arrow becomes broken. The same applies to the wire from the constant to CLFN. But in LabVIEW 2009 and higher the Run arrow is fine and LabVIEW allows to run the VI despite oddity with the CLFN (look at the image above).

This is the screenshot from LV 8.0:

2015246873_23-05-202023-16-14.jpg.e7d8f71d71a18a0bb4f745420ef2d1dc.jpg

Might be an omission when porting to the new managers interface?..

Share this post


Link to post
Share on other sites
4 hours ago, dadreamer said:

I checked that in LabVIEW 3.1.1 and it doesn't require the Return input terminal to be connected to some constant. I also tried LabVIEW 3.0 and 2.5 but I don't see CLF Node there, only CIN, so can't check there.

I didn't mean to indicate that you had to wire the return value. I actually never even tried that as it seemed so out of touch with anything. What I do believe to remember however is that LabVIEW required you to wire the left side of parameters. However that's 20 years ago and it could just as well have been the CIN node. Much of the object handling for the CLN was inherited from the CIN node and there you don't have a return value. In fact I'm pretty certain that the return value of the CLN is basically simply a parameter as far as the node object is concerned, in order to be able to reuse much of the CIN node object handling. The fact that the first parameter is specifically reserved for the function return value is most likely mostly a special casing for the configuration object method and the run object method of the CLN. Most other methods it simply inherits from the common object ancestor for the CIN and the CLN.

Share this post


Link to post
Share on other sites
On 5/22/2020 at 1:54 PM, dadreamer said:

Here are some "secret" INI keys related to CLFNs:

  • extFuncGenNoWrapperEnabled=True - the most interesting one here; adds "Generate Wrapper" option to CLFN context menu (on by default). When this option is unchecked (off), LabVIEW doesn't generate the wrapper for DLL call, i.e. ExtFuncWrapper function is not called and the user's function is inlined into the VI code and called. This feature could slightly improve performance of external code communications, saving approx. 5 to 10 ms on each call. But you must be absolutely sure, that your CLFN is set correctly as no error checking is done in this case and any small mistake in the parameters leads to LV crash. There might be an indirect use of this feature, e.g. manual fine-tuning/debugging of some problematic function or a function with unclear parameters etc. When the option is enabled and extFuncShowMagic is set, CLFN is painted red.

Interesting. How does this feature compare with disabling the error checking on the Error Checking tab?

Share this post


Link to post
Share on other sites
13 hours ago, ShaunR said:

Interesting. How does this feature compare with disabling the error checking on the Error Checking tab?

Even when Error Checking is set to Disabled, LabVIEW still enters ExtFuncWrapper to do some basic checks before the target function is called. A few internal functions, such as _clearfp and _controlfp, are being called also. Thereby disabling "Generate Wrapper" option should make CLFN a little faster, than disabling Error Checking. You can take it like you're calling a built-in yellow node (not taking into account the called function's own speed, of course). I did not do concrete benchmarking to compare these two options. If there's an interest, I could check this out.

Edited by dadreamer

Share this post


Link to post
Share on other sites
9 hours ago, dadreamer said:

Even when Error Checking is set to Disabled, LabVIEW still enters ExtFuncWrapper to do some basic checks before the target function is called. A few internal functions, such as _clearfp and _controlfp, are being called also. Thereby disabling "Generate Wrapper" option should make CLFN a little faster, than disabling Error Checking. You can take it like you're calling a built-in yellow node (not taking into account the called function's own speed, of course). I did not do concrete benchmarking to compare these two options. If there's an interest, I could check this out.

No need. I will explore this. From experience; a misconfigured CLFN usually results in LabVIEW disappearing without a whimper (either immediately or at some random moment) so i don't see much of a reason to have error checking and wrappers enabled at all. Especially if there is a performance benfit, no matter how minute.

It doesn't seem to have a scripting counterpart. Is that correct, or have I just missed it?

Is the setting sticky, or does distributed source code require the INI setting too?

Edited by ShaunR

Share this post


Link to post
Share on other sites
10 minutes ago, ShaunR said:

From experience; a misconfigured CLFN usually results in LabVIEW disappearing without a whimper

I'm seeing A LOT of these when re-creating Block Diagrams. It's like LV has no error support at all.

If you enable 'dprintf' options in 'LabVIEW.ini', you can at least get some information about reason of the failure.

 

Share this post


Link to post
Share on other sites
1 hour ago, ShaunR said:

It doesn't seem to have a scripting counterpart. Is that correct, or have I just missed it?

I browsed through all the properties and methods of Call Library object and didn't find such scripting analogue. Seems like VI Server doesn't expose that specific property.

1 hour ago, ShaunR said:

Is the setting sticky, or does distributed source code require the INI setting too?

Yes, like any other option, I mentioned above. Tried to open my DbgPrintf sample VI from another machine and all the parameters are in place. If you don't have extFuncGenNoWrapperEnabled=True and extFuncShowMagic=True in your .ini, then the option is "invisible" in the menu or on BD, but it's there. 🙂

Edited by dadreamer

Share this post


Link to post
Share on other sites
On 5/25/2020 at 6:21 PM, ShaunR said:

No need. I will explore this. From experience; a misconfigured CLFN usually results in LabVIEW disappearing without a whimper (either immediately or at some random moment) so i don't see much of a reason to have error checking and wrappers enabled at all. Especially if there is a performance benfit, no matter how minute.

It doesn't seem to have a scripting counterpart. Is that correct, or have I just missed it?

Is the setting sticky, or does distributed source code require the INI setting too?

Your experience seems quite different than mine. I get never the soundless plop disappearance, but that might be because I run my shared library code during debugging from the Visual C debug environment. But even without that, the well known 1097 error is what this wrapper is mostly about and that happens for me a lot more than a completely silent disappearence.

Share this post


Link to post
Share on other sites
13 hours ago, Rolf Kalbermatter said:

Your experience seems quite different than mine. I get never the soundless plop disappearance, but that might be because I run my shared library code during debugging from the Visual C debug environment. But even without that, the well known 1097 error is what this wrapper is mostly about and that happens for me a lot more than a completely silent disappearence.

I haven't seen that error message for years. If I run a debugger, LabVIEW just dies and the debugger reports an error in the LabVIEw exe. This has been the same through Windows 7-10 on the various machines I've had over the years. Maybe the difference when debugging is because I use the the gdb debugger but the sudden disappearance is consistent; not only on my machines but customers' too.

Edited by ShaunR

Share this post


Link to post
Share on other sites
12 minutes ago, ShaunR said:

I haven't seen that error message for years. If I run a debugger, LabVIEW just dies and the debugger reports an error in the LabVIEw exe. This has been the same through Windows 7-10 on the various machines I've had over the years. Maybe the difference when debugging is because I use the the gdb debugger but the sudden disappearance is consistent; not only on my machines but customers' too.

I use Visual Studio and launch LabVIEW from within Visual Studio to debug my DLLs and unless I quirk up something in kernel space somehow I always get into the Visual Studio Debugger, although not always into the source code, as the crash can be in one of the system DLLs.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.