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

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.