AndyS
-
Posts
22 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by AndyS
-
Hello and happy New Year! 🥳 Today I upgraded via VIPM from V3.0.0.3 to 3.1.1.3 and I was wondering why my application was not executable any more on LabVIEW 64Bit but still on LV 32Bit. I figured out the the DLL files for 32Bit and 64Bit are binary identical. Adding the DLL from the LV64 manually to a DLL node I got this error: So the VIPM installs the 32Bit DLL where the 64Bit DLL should be.
-
1) sorry, you're right. They are constants from the view of the muparser 🙂 2) My thought with the optional input was to give every user the ability to shift the error codes into a range that best fits to his project or application. Alternatively there could be an additional VI that configures a (functional)global with this offset value. This would avoid the additional input of the Construct.vi and it would be sufficient to configure it once per application run ... if the input itself is what you don't like. The NI documentation says that the free ranges are -8999 to -8000, 5000 to 9999 and 500.000 to 599.999. I don't know which one is the best. https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/errors/error-codes-and-messages.html
-
Two questions: 1) I defined a formula with a missing variable (see picture). I expected an error but I got a NaN as result. I can live with this but is it really as expected? (Remark: I did not test it with the old package version, so I don't know if the behaviour has been changed with the update) 2) Error codes: The Error code range of 5000 + x is used by many user VIs. Would it be possible to have an additional input in the Construct.vi that allows to define the error code offset? (5000 as default)
-
Great work - thank you! I already installed it and testing will be done implicitly in the next weeks and months.
-
Sounds great! Thank you for your work!!!
-
C:\Program Files\National Instruments\LabVIEW 2020\vi.lib Yes, LabVIEW64. I have added another VI search path in my LabVIEW paths configuration. This is probably the reason why it took a while until it found the DLL.
-
I installed it and all tests have been successful! Great! Thank you!! 🙂 The only I'd like to remark is, that LabVIEW was searching for the DLL when I placed a muparser VI for the first time. After a while the dll was found the reference updated. LabVIEW did not search again.
-
@Porter - do you see a chance to integrate the binary-extensions and the precedence bugfix into the new version?
-
I also checked the new VIP and unfortunately it does not work as (I) expected. Running from the code is fine but when I created an EXE I was wondering why the application builder still did not create a .\data folder. The EXE itself was also not executable (broken arrow). I figured out that you must copy the DLL manually into the same folder as the EXE is. Then runs successfully. Then I played around because I never experienced that a hard linked DLL was not copied to the support folder by the application builder. The solution was, that the original DLL must not be located in the LabVIEW resource folder but in the project folder of your source code => C:\Program Files\National Instruments\LabVIEW 2020\vi.lib\LAVA\muParser After I moved it to the new location and updated the DLL nodes, the application builder created the .\data folder, copied the DLL into it and the EXE file was running.
-
ok 🙂 👍
-
uh ... that's a lot of work and because you're supporting different platforms and each time the binary (DLL, lib, etc) have another name you'll need several cases. Why don't you add an exported DLL function that delivers the path to the DLL itself. You could call this once (by using a static link within a conditional disable structure) but then it should be sufficient with the dynamically linked calls without wrapping them into a conditional disable structure.
-
Thanks for you explanation. It's working now when I moved the DLL beside the EXE 😀 Nevertheless I'm not really happy with this solution, because all the other DLLs are within the support folder (.\data) of my application. I know (or at least I haven't found out something different) that it is not possible to figure out the support folder by a LabVIEW function. From that point I understand why the muparser-DLL must be located beside the exe. to @Porter: Do you think it could make sense to modify the mupLibPath.vi to give the user the chance to define where the DLL is located? I was thinking about adding a functional global that keeps the latest path value. By default it would be the path as it is used currently. The problem here is that it conflicts with the re-intrant and inline configuration of the VI. Appended you'll find a quick hack - just as an idea. mupLibPath.vi
-
Hello Ryan, I found another problem but I'm asking myself if I'm doing something wrong ... I created a small EXE file, using the mu-parser. For testing it just calculates the result of "3 * 25". The problem now is that the EXE does not find the libmuparser-x64-lv.dll. I manually created a data-sub-folder and copied the DLL into it but it did not help. So currently I don't know where the DLL has be located for an EXE-File. Then I modified your "mupLibPath.vi" in a manner that it searches the DLL in the support folder of the EXE and now it works. So for me the question is: Is there a bug and the muparser was never used within an EXE file? (I cannot imagine) or does it need to be located somewhere else than in the support folder. Thanks for your answer! And by the way: the author of the muparser project has fixed the issue with the missing priority parameter. I hope for an official release soon.
-
Did you get the C file by PM? Sorry to ask but the WebUI behaviour is a bit strange here.
-
As I wrote in an earlier post I'm missing bit-operations and some more. Since I had some time left, I downloaded the latest LabView-muParser code and added the missing functions: ~ Binary-Not (flip all bits) & Binary And | Binary Or |^ Binary XOr << Bit-Shift left >> Bit-Shift right % Modulo Operator (also for floating point values) Support of values given as hex (0x1A2c) and binary (0b101101) My question to you Porter: Are you interested in integrating it into your project? Then everybody could use it. The modifications are only in one file (muParserDLL.cpp).
- 172 replies
-
- 2
-
-
- expression
- math
- (and 1 more)
-
Ok, I implemented it like suggested and it's working fine. Nevertheless I'm semi-happy with this solution because I have now a dependency to JSON text in a toolkit where I havn't had it before. One final question for my understanding (see the following picture). In opposite to the screenshot of my first post, I connect now the original array with all variant data information to "From JSON Text.vim". Nevertheless the value can still not be reconstructed. Why?
-
Ok, it took a while but yes, you're right. How can LabVIEW know the data type of a variant if the only you offer is the value information. It can't. But: JKI JSON can ... I tested it shortly and somehow they are able to reconstruct the variant. I didn't had the time to went deeper into the code but I assume that they take a closer look to the data. E.g. everything that comes in " " must be a string. Everything without must be a number, enum, bool, ... every number with a . included must be a floating point. That's my assumption without seeing the code. I also assume that the input variant and the output variant might be not exactly the same if there are unusual data types used. The problem on JKI JSON is the low speed in comparison to JSON text - so I would highly prefer to go on using JSON text. I'm not sure if there is a way to combine the best of both worlds but it would be really cool.
-
Sorry, if you're wondering about the variant to data ... I did a mistake. In my project code it looks like in the following screenshot. But the result / problem stays the same: JSON_Text_test.vi
-
Hi! I have to convert a dynamically generated array into a JSON string and back. Unfortunately I found that the un-flatten method loses the variant data. See the screenshot of FP and BD and the comments inside. JSON_Text_test.vi Is this a bug in JSON Text or is my data-construction not supported as expected? In case of the letter I have modify huge parts of my code. So I hope that it is a bug 😉 The 2nd thing I recognized is that the name "Value" of the cluster is not used during flatten. Instead the name of the connected constant / control / line is used. I found the green VI ("Set Data Name__ogtk.vi") at OpenG Toolkit that allows me to programmatically set the variant data name. As you can imagine I would prefer not to need the OpenG VI. Thanks in advance for your kind help 🙂
-
Yes - checked it and I can confirm that it is working 👍
-
done, looking forward to KuDos https://forums.ni.com/t5/LabVIEW-Idea-Exchange/VI-Scripting-Add-property-quot-MissingFileName-quot-to-all/idi-p/4022884
-
If the original VI does not exist any more, you can use the property "MissingVIName" to get its name (I'm using LV2019SP1). I created a VI that recursively replaces all missing VIs based on a lookup table. So far this works fine with missing VI but it does not work with missing *.ctl files (type def) for controls or constants because there is no "MissingTypeDef" property available. Does anybody have an idea how to get the missing ctl-file name? Thanks in advance!