Jump to content

Porter

Members
 View Profile  See their activity

  • Posts

    227

  • Joined

  • Last visited

  • Days Won

    26

 Content Type 

Everything posted by Porter

  1. Porter
    First of all: Thanks for sharing! Do you plan to implement array slice syntax at some point? For example, $.MyArray[5:20] would return elements 5 to 20 of MyArray.
  2. Porter
    The projects that I post on LAVA are typically developed on my spare time. They are solutions to problems that I encounter at the office but don't have time to work on during office hours. I post them here because this community is home to some of the most competent LabVIEW architects. What better place to get a decent LabVIEW code review? The result is very good code but not quite polished enough to pass the tools network requirements. The extra time and effort to bring the project through the tools network certification process is just not worth it for me. I'm not making a product for sale. It would be nice though to share these projects with a wider audience. Perhaps in a later version of VIPM, JKI could consider adding support for the LAVA repository (if/when it exists) in their free version. Maybe have an enable checkbox hidden away in a config window. Once enabled, they can display a big warning about how code from LAVA doesn't go through the same certification process as JKI and LabVIEW tools network.
  3. Porter
    Wouldn't it be nice to have a public LAVA repository for VI package manager? I'm not sure how to make this happen. Just throwing the idea out there.
  4. Porter
    This is fixed in the latest version (v1.3.3.1) here:
  5. Porter
    Is anyone interested in releasing an open source Modbus server for Labview?
  6. Porter
    In version 1.3.2 the session valid property of the MB Master TCP class was broken. This is fixed in v1.3.3.
  7. Porter
    A little bit more testing and tweaking is required. Almost ready for another release though. Here is the preview: mb_master-1.3.2.7.vip Transaction IDs are randomly generated.
  8. Porter
    I have implemented transaction IDs for Modbus TCP in the "Transaction ID fix" branch here: https://github.com/rfporter/Modbus-Master/tree/Transaction-ID-Fix Could use some feedback. Here is a vip if you would like to take it for a spin: mb_master-1.3.2.4.vip
  9. Porter
    I will look at adding it to the next release. I also want to add polling of holding registers and coils as an option in the Modbus Comm Tester. I also plan to properly implement transaction IDs for Modbus TCP: https://github.com/rfporter/Modbus-Master/issues/1
  10. Porter
    Yes, that is the modbus comm tester.
  11. Porter
    From the picture, it looks like slave ID is wrong. 11 decimal = 0x0B in hex If you want to communicate with slave ID 0x11, you should change that slave ID constant to 17 By the way, if you want to test communication with an instrument, I suggest that you try the Modbus Comm Tester. You can open it from the "Tools->Plasmionique" menu.
  12. Porter
    You mean something like this?
  13. Porter
    This project is now available on GitHub: https://github.com/rfporter/Modbus-Master If you want to make modifications to the modbus master library, I suggest that you pull the source code from that repo. To build your own release, you just need to build the "Source Distribution" then build a VIP package using "MB Master.vipb" with VI Package Manager 2014.
  14. Porter
    I use a constant relative path for performance reasons. When I tried to do anything fancy with the path in mupLibPath, there was too much of a performance hit.
  15. Porter
    Make sure that the libmuparser-xxx-lv.dll is put in the same directory as the executable.
  16. Porter
    The Modbus TCP Master uses the MBAP header. I will need more information in order to help you. What error message is produced when communication stops? Please post example code that reproduces the error. Please try the attached code. Fill in the correct IP address, port number, slave ID, holding register address before running it. Post a screenshot of the output MB TCP Read Holding Register Test.vi
  17. Porter
    I figured that I'd let you take it for a spin before making the next commit. Just pushed changes to github now.
  18. Porter
    Error details as cluster: lv_muparser-1.1.1.2.vip
  19. Porter
    You could parse the multi-expression as a csv string then use mupSetExpr and mupGetExprVars on each expression. Once all expressions have been validated, you can put the multi-expression back into mupSetExpr. This can all be added to mupExpr Construct but I think that it is too inefficient and most of the time, the first error is good enough.
  20. Porter
    Give this a try: lv_muparser-1.1.1.1.vip Get_Last_Error.vi in mupExpr is not very useful. The expression is parsed and validated in Construct.vi. Therefore I chose to add "error pos" and "error token" outputs to Construct.vi
  21. Porter
    Also looks like mupExpr Construct.vi would require Error Token and Error Position outputs.
  22. Porter
    I will package this up in a mupGetLastError.vi which will return: - Error Code - Error Token - Error Position - Error Message I will also make a mupGetExpr.vi for completeness. But mupExpr class already keeps a copy of the expression (accessible via Expression property). mupExpr will get a top-level VI named Get_Last_Error.vi that will just call mupGetLastError.vi.
  23. Porter
    Yup. 64-bit is supported. Linux too thanks to enserge. Anyone want to volunteer to test on mac (32-bit & 64-bit)?
  24. Porter
    Not sure if openG builder and lvlib is still a problem (I don't use openG builder), but I do know that including gmath library increases application builder's executable build time by about 14 minutes (LV2015). I was about to reinvent as well but then I came across muParser: http://beltoforion.de/article.php?a=muparser LabVIEW API here:
  25. Porter
    FYI LabVIEW's formula parsing VIs are located within "NI_Gmath.lvlib". This means that even if you just use formula parsing, you need to load the entire Gmath library. This is a very big library! This becomes particularly noticeable when building a stand-alone executable. Here are the results from my application: With NI_Gmath as dependency - Exe size: 40.6 Mb - Build time: 22 minutes With muParser instead of NI_Gmath: - Exe size: 29.4 Mb - Build time: 8 minutes
×
×
  • Create New...

Important Information

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

  I accept