Jump to content

Porter

Members
  • Posts

    227
  • Joined

  • Last visited

  • Days Won

    26

Posts posted by Porter

  1. Thanks Rolf for the thorough analysis.

    I axed support because cross compiling for 32-bit Linux was another hassle, and I suspect that nobody will ever need it. I also noticed that the produced .so was 3MB which seems to be abnormally large and I don't have time to figure out how to get the size back down to a reasonable 300-500kB.

  2. 1) That is indeed the expected behavior. Variable values must be explicitly specified. Their default value is NaN. Note that you are defining x,y,Z as constants in the above example.

    2) I was using 5000 range because this package is not NI Tools Network certified and therefore I have no reserved an error range to target. If there is a better starting number, I am open to suggestions. I would not propagate an error code offset input all the way to the top level though. Best to just pick a range and stick with it. But I do understand that 5000 is commonly used at the top level of user applications.

  3. I finally got the 32-bit shared object built on Linux. After 3 hours of fiddling I simply re-installed gcc-multilib and it just worked. 😡

    I have pushed the changes to github. After testing, this will be v3.0.0 because I expect the static linking to be a breaking change in some instances.

    The next step is to compile a large list of test cases to confirm that the new operators are behaving as expected under as many corner cases as we can think of.

    • Like 1
  4. 2 hours ago, AndyS said:

    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.

    What is the path to your vi.lib? Are you using labview 64-bit?

  5. On 8/30/2023 at 8:06 PM, Rolf Kalbermatter said:

    A star before the file ending is translated to 32 resp 64, a star for the file ending is translated to the respective platform specific shared library file ending.

    Is your shared library name different between bitnesses? Otherwise you do not need a star at all before the file ending

    The shared libraries were named libmuparser-x##-lv.XX

    Where ## is bitness and XX is file extension. So libmuparser-x*-lv.* worked wonderfully on the development version of the code.

    Unfortunately as soon as I build vipm package, the *s get replaced with 32 and dll. So when I open the vis on x64 labview, they are pointing to the wrong dll.

    My solution is link the CLFNs to libmuparser-lv.dll and have a post-install vi copy the appropriate version of the shared library to that filename. I know it looks weird to see a dll in linux, but it doesn't seem to break anything. 

  6. I tried the .\libmuparser-x*-lv.* trick for the CLFN path but when I build a VIPM package, it converts it to libmuparser-x32-lv.dll because I am building on LV 32-bit, Windows. So then the VIs are broken on 64 bit and Linux. If I can preserve the wildcards in the CLFN path it would be ideal.

    Here is my latest attempt. Statically linking to libmuparser-lv.dll but located in the vi.lib next to mupLib.lvlib: lv_muparser-2.2.0.6.vip

  7. Give this a try: lv_muparser-2.2.0.4.vip

    It worked with LV2020 x32 and x64, Windows.

    In Linux I had to manually copy the .so file to libmuparser-lv.dll. Permission issues with the installer of course. I think that Labview needs to be run as root during the install but my community edition was activated under my user account. After doing that manual copy it worked fine though.

    All CLFNs are statically linked to "<resource>\libmuparser-lv.dll"

  8. I prefer not to add any overhead to each call by having to retrieve the path to dll. If I recall correctly, when it was not a path constant wired to the CLFN (eg. a shift register instead) there was some overhead added to each call.

    It will be a bunch of busy of work, but I think that the API is mature enough now that it is worth the effort. I think its about 12 VIs, 4 cases each.

  9. On 8/30/2017 at 11:52 PM, Porter said:

    I also prefer the statically linked dll because I can imagine that no one will remember to include the correct DLL or even know where to find the DLL when they build their exe.

    However, since this library is under development, I think that it is wise to stick with the in-lined mupLibPath vi for now.

    When we get closer to V1.0 perhaps it will be worth putting in the extra effort to setup a conditional disable structure around each CLN.

    This is going back a while. We are at V2.x already. But this fell off of the list of priorities.

    It would allow the application builder to pickup the DLL automatically (and drop it in a support dir).

    I will need to add conditional disable structures around all muparser DLL calls in mupLib.lvlib

  10. I've put together a wrapper to the Plasmionique Modbus Master library that makes communication with PLCs a bit easier. It could be used for just about any Modbus device, but I had PLCs in mind when I was developing it.

    What is easier?
    - Modicon-style addressing instead of data address and function code.
    - Data-type conversion built-in(eg. 32-bit float mapped to two U16 registers). Word swapping option.
    - Poll list and cached data block. Allows you to poll a range of registers then lookup and convert the values elsewhere.

    image.png.17360f6ac081ba5262ebabcbac174cdd.png

    The code is up on GitHub: https://github.com/rfporter/Modbus-PLC-Client

    Its a rough draft at the moment. Comments are welcome and appreciated.

    • Like 1
×
×
  • Create New...

Important Information

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