Leaderboard

Dear OpenG and LAVA Communities, I’m happy to announce that the OpenG community is moving its primary discussions into the LAVA discussion forums. This will server two primary purposes: 1) To increase the visibility of OpenG and make it easier for more people to contribute, find support, and stay up to date about developments in OpenG. 2) To reduce the burden of the spam and other server administrative tasks. The existing OpenG discussion forums will remain available as a read-only archive, and will include a prominent notice that the discussion forums have moved to a new address, here on the LAVA forums. We hope you agree that this is a great step forward for OpenG and that it will add yet another positive element to the already solid foundation of LAVA. We are confident that it will allow the OpenG team to better serve its users, as well as increasing the amount of participation as a whole. If you have any questions about this transition, please post a topic in the OpenG forums on LAVA. Thank you, Jim Kring OpenG Founder

Hi Jim and All I would like to thank and applause the people who have made this happen :beer_mug: it just makes so much sense. I think it is a great step forward in revitaling the OpenG community and look forward to see how this evolves OpenG going forward. cheers Dannyt

Yes, that is typically what they say and as a general rule of thumb, they are right. Programmers not trained in software engineer or familiar with OO thinking often create tightly coupled applications. What they should say is, "unnecessary coupling should be avoided." Too much coupling makes it hard to change the software. What they should also say is, "unnecessary decoupling should be avoided." Too much decoupling makes the code harder to follow and may impact performance. How much decoupling is "enough?" If you can easily make the changes you want to make it is enough.

The problem with llbs is that it is a flat file structure meaning you can not have two vi's with the same name. No dynamic dispatching for one. Other than that libraries will retain their namespaces. A problem with packed project libraries is that vis they contain can not be inlined. I ran into that when trying to build the LapDog Message Library into a ppl. I have never used dlls so no comment. One thing I am considering is a source distribution in a zipfile. My app would have an "Install new plugin" function that just unzips the file into the plugins directory. Another thought is that when the initialization sees a zipfile in the plugins directory it unzips it and removes it. Then I have all the benefits of deploying a single file while still using a run of the mill source distribution.

Here are my get/set temperature vi's for a Watlow F4 controller. You also need the NI Modbus library. And there seems to be an issue with the VI snippet. The clusters constants there can be remade and should have RTU and 1 as the values in them. Hopefully this is of some help to you.

Have you tried using the in-place element structure?

If you don'y mind using windows API calls, you can also call "ShellExecute" which has a couple of minor advantages over systemexec.