Jump to content

Porter

Members
 View Profile  See their activity

  • Posts

    231

  • Joined

  • Last visited

  • Days Won

    27

 Content Type 

Everything posted by Porter

  1. Porter
    Also if you could post or PM me a screenshot of your test code, I might get a better idea of what could be causing the problem.
  2. Porter
    Its worth noting that I kept the VISA locks in place only to (possibly) support multiple applications trying to access the same VISA resource. I implemented my own locking mechanism using a single element queue as a mutex for locking within a single application instance because the behavior of VISA locks (at the time) was erratic. You might want to try removing the VISA lock/unlock calls from the MB_VISA_Lock library and see if that helps. Another culprit could be the VISA flush in the TX ADU.vi. I have once come across a serial device that didn't like the flush command. Try replacing it with a read all bytes at port.
  3. Porter
    It should work as long as you have NI VISA working on the cRIO and you are using the correct serial port name. You should be able to use serial ports named with the ASRL#::INSTR format.
  4. Porter
    Glad to hear that it was useful for your test. Thanks for the feedback!
  5. Porter
    They did say that maybe Unicode support is coming to LabVIEW. I would give LabVIEW a plus for that.
  6. Porter
    Thanks for bringing this to my attention. Not sure why the dlls and so files were stripped out of the source distribution's always included list. This is now fixed in v3.1.2.1
  7. Porter
    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.
  8. Porter
    Done. New error code offset is 515000. I also compiled muParser for cRIO RT Linux. You need to manually copy the .so file to /usr/local/lib/ on the cRIO then run ldconfig. Linux 32-bit support has been axed. There is no 32-bit LabVIEW for linux since 2016 if I'm not mistaken.
  9. Porter
    I would just post it. You can plaster it with a 0-Clause BSD license and walk away. Zero-Clause BSD – Open Source Initiative That way if someone likes they can just take over development without bothering you. It looks like an interesting project but I have no experience with xControls so I wouldn't be the best person to maintain it.
  10. Porter
    Seems like the 500 000+ range would be a good place for these standard but non-NI certified error codes to go. I will make another release that will be focused on improved error handling/reporting. I can see a few VIs that should be touched up in this regard.
  11. Porter
    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.
  12. Porter
    I have uploaded the new release to vipm.io We are now at release v3.0.0 since this is a breaking change. I also started some documentation: LV-muParser User Guide.pdf
  13. Porter
    There is also Tango Desktop Project which is public domain.
  14. Porter
    Also from a while ago: Open Icon Library - Browse /0.11 at SourceForge.net
  15. Porter
    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.
  16. Porter
    What is the path to your vi.lib? Are you using labview 64-bit?
  17. Porter
    Here is the latest build with bitwise operators implemented: lv_muparser-2.3.0.1.vip I didn't manage to cross-compile for linux 32-bit. So only linux 64-bit gets the new operators for now. Here is the muParser source code (modified): muparser-2.3.5.zip Note that I changed the operator precedence to match that of C as described here: https://www.geeksforgeeks.org/operator-precedence-and-associativity-in-c/
  18. Porter
    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.
  19. Porter
    Yes. Looks like your fix was added to release v2.3.5 of muparser. I will rebuild the dlls and prepare another release for testing.
  20. Porter
    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
  21. Porter
    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"
  22. Porter
    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.
  23. Porter
    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
  24. Porter
    The dll should be in the same folder as the exe in order to be found automatically.
  25. Porter
    Here it is. muParserDLL.cpp
×
×
  • Create New...

Important Information

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

  I accept