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. 

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.

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.

5 hours ago, Masony said:

When I try to build an application through the application builder that is using this MB library I get an error telling me that it can't build a broken VI without attaching the block diagram (which does fix the issue). It pointed me towards the "Read Session Valid.vi" as the issue. When I looked at that vi I can see a broken arrow with the error pointing towards the "unbundle by name". Can anyone verify that this block diagram is correct? I double checked I had the newest version of the library and still get this issue.

This is fixed in the latest version (v1.3.3.1) here: 

Is anyone interested in releasing an open source Modbus server for Labview?

In version 1.3.2 the session valid property of the MB Master TCP class was broken. 

This is fixed in v1.3.3.

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.

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

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

Yes, that is the modbus comm tester.

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.

You mean something like this?

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.

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.

Make sure that the libmuparser-xxx-lv.dll is put in the same directory as the executable.

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

I figured that I'd let you take it for a spin before making the next commit.

Just pushed changes to github now.

Error details as cluster: lv_muparser-1.1.1.2.vip

9 hours ago, ensegre said:

Now it occurs to me that only the first parsing error in a (multi) expression is reported; I could think at cases where I would like to see all errors in long expressions at once (when not ambiguous), but I think this is not contemplated in muparser. For example, I don't think you can merge different expressions parsed separately into a single muparser instance.

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.

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

Also looks like mupExpr Construct.vi would require Error Token and Error Position outputs.

2 hours ago, ensegre said:

While designing an interface which should highlight syntax errors in typed formulas, I realize that I miss a VI returning directly the strings of mupGetExpr() and mupGetErrorToken() together with the number mupGetErrorPos() [when applicable], instead of tediously parsing them from the full error message. Do you envision adding it to the toolbox? I may have a go at getting them from the encapsulated form, it later

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.

16 hours ago, MikaelH said:

How about 64 bit support :-)

Yup. 64-bit is supported. Linux too thanks to enserge.

Anyone want to volunteer to test on mac (32-bit & 64-bit)?

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).

On 8/30/2007 at 3:04 PM, John Lokanis said:

So, can anyone help me not have to reinvent this wheel?

I was about to reinvent as well but then I came across muParser: http://beltoforion.de/article.php?a=muparser

LabVIEW API here: 

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