AndyS
-
Posts
22 -
Joined
-
Last visited
AndyS's Achievements
-
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).
