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
    At the time, I was using the actor framework for a large project. I had multiple com ports and multiple devices on each com port. I decided to have an actor per device. Each modbus device actor would build its own modbus instance from the device's configuration file. Since the modbus instances were thread safe, I didn't have to worry about sharing a com port with multiple devices. Devices on the same com port simply wait in a FIFO queue for the port to be available. I could have instead implemented a modbus master actor and spun up one of these actors per com port. The device actors would then have to send/receive their modbus data through the modbus master actor running on their com port. This way, the modbus master library doesn't need to be thread safe (in terms of shared com port), but I found that it added an extra layer of complexity. I prefer to handle serial communication in my hardware abstraction layer rather than my application layer. Otherwise the device's driver would be tied to the actor framework and would be difficult to reuse for other projects
  2. Porter
    NI Labs Modbus API is now on GitHub! Password protection of VIs has been removed. https://github.com/NISystemsEngineering/LabVIEW-Modbus-API
  3. Porter
    The idea would be to include the LAVA CR except for non-vip packages and the uncertified section. On LAVA, we used to submit our code to the uncertified section first. Then after some discussion, testing, debugging and polishing, we would report to the moderator that our code is ready to be certified and placed in the appropriate category in the CR. I'm not sure if this is being enforced anymore. The how-to is from 2009:
  4. Porter
    I think that when a package is hosted in multiple repos, VIPM displays the entry from the most recent package version. So if you release a new version on the LAVA repo, it will show up as an update for the LVTN version. This is definitely not what we want to do. A solution could be to make separate LAVA and LVTN packages. For the LAVA package, you could append _LAVA to the product name and have the LVTN package listed as incompatible. For the LVTN package, have the LAVA package listed as incompatible.
  5. 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.
  6. 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.
  7. 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.
  8. Porter
    This is fixed in the latest version (v1.3.3.1) here:
  9. Porter
    Is anyone interested in releasing an open source Modbus server for Labview?
  10. 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.
  11. 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.
  12. 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
  13. 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
  14. Porter
    Yes, that is the modbus comm tester.
  15. 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.
  16. Porter
    You mean something like this?
  17. 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.
  18. 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.
  19. Porter
    Make sure that the libmuparser-xxx-lv.dll is put in the same directory as the executable.
  20. 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
  21. Porter
    I figured that I'd let you take it for a spin before making the next commit. Just pushed changes to github now.
  22. Porter
    Error details as cluster: lv_muparser-1.1.1.2.vip
  23. 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.
  24. 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
  25. Porter
    Also looks like mupExpr Construct.vi would require Error Token and Error Position outputs.
×
×
  • Create New...

Important Information

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

  I accept