Porter

I finally had a moment to take a look at this. Nice job!

I particularity like the conditional auto-indexing tunnel vim and the delete elements from array vim.

I will have to tell our developers to start moving away from the openG array VIs.

Are you going to put this up on github or the NI Tools network?

It is solved now. I unchecked the exclude PPLs and DLLs in the build spec of LF.lvlibp

And moved the resulting LF.lvlibp to the same directory as the other PPLs.

I have been transitioning my framework's core libraries to packed project libraries. Unfortunately, the higher level PPLs depend on lower level PPLs, but i think that I've managed to sort out all of the broken connections. Now the issue that is bothering me is that whenever I open a project containing a higher level PPL, I get a bunch of "VI cannot be found on disk errors" that refer to VIs within the higher level PPL.

My initial thought was that the file paths were too long, but that doesn't seem to be the case. 

Has anyone else come across this behavior when using PPLs?

I wonder if they will also release a community edition for Linux.

It would also allow open source developers to maintain their projects after they have changed jobs. I'm glad to hear that NI is moving in this direction.

How are they going to prevent companies from just using the community version though?

Its easiest to use VI Package manager. Just search for Modbus, select the package and install.

I would highly recommend that you use one of the existing modbus libraries to communicate with the E5CN.

See:

OR:
https://github.com/NISystemsEngineering/LabVIEW-Modbus-API

v1.3.5 has been released:

Improved RTU CRC calculation speed
Added Slave ID input to "Open TCP Session.vi"
Updated documentation

@Masony, something like this?

I thought that it would be nice to extend the muParser library's functionality to include automatic CVT tag lookup. This means that if you input an expression that contains CVT tag names as variables, their values will automatically be substituted during eval.

This new CVT expression parser IS AN expression parser. So I tried to make a child of the mupExpr class. Who's silly idea was it to pass this class by reference?! LabVIEW doesn't support dynamic dispatch on class DVRs.

So I've re-worked the mupExpr Class to wrap only the muparser handle (hParser) in a DVR. This gives a similar protection as wrapping the class in a DVR but allows us to pass the class by value instead.

If anyone objects to this change, please shout out now before I commit changes to github.

The code is attached, with an example: NICVT Expression Test.vi

You need to install NI Current Value Table v.3.3.0 before opening the project.

NICVTExpr.zip

7 hours ago, Volker Hampel said:

I have attached the VI that I use tu read the registers. 

Since your input registers are contiguous, I would suggest reading all of them with one call of read input registers. See attached.

Modbus Read Waveform.vi

How much data are you transferring? For example, if you are reading 1000 input registers, one register at a time, then you can't expect to get a sample rate of 100ms.

Screenshots or sample code would be useful if you are looking for help.

Are you using the Modbus Comm Tester?

Is now. 😛

Just in case anyone is still interested, the source is now available on github: https://github.com/rfporter/SET-Toolkit

It should show an error on every subsequent read... but it doesn't:

It just keeps going as if nothing is wrong.

18 hours ago, smithd said:

I don't actually understand what the problem was with this. As you said in your comment on that issue, each access should be synchronous for a given master or slave, so there is no such thing as multiple transactions outstanding on the connection. The transaction ID check just sort of verifies that. If an error occurs, you must close the connection and reset. I can't think of any reason that would not be the right response, can you? I'm also confused by this because that part of the code was implemented by Tanner, who is the person who posted that issue to yours, so presumably he thought that code fixed the issue?

Note that this behavior (close and reopen) is different from serial (wait, flush the buffers, and hope things start to work again), not because the serial way is better but because serial is a 5c chip twiddling the voltage on some wires. The serial version has no connection to close.

His code has not fixed the issue yet. It does catch the error, as did Plasmionique Modbus Master, but it is up to you to catch the error and reset the connection. If you don't reset the connection, this can happen:

Yikes! No errors being reported and read register 0 is returning the value for register 1.

Tanner's proposed fix works. I implemented it in the Plasmionique Modbus Master. With it you can have multiple pending transactions. The responses will be matched up with the requests using the transaction ID.

TCP Test.vi

18 hours ago, smithd said:

I do, thats why I make sure to enable the term char.

Hah. I didn't see that. I was looking somewhere else. But anyway, I don't see a case where you would only get a LF. In the ASCII protocol, a lone LF should never be sent within the message. And if, for whatever reason, a bit flips to make an LF, then hopefully the error would be caught by failing the CRC check.

17 hours ago, smithd said:

I think I see what you mean and attached an implementation. Looks to be about 3x faster (edit: 2x with debug off) to read from the lookup vs calculating it out.

Just a thought tho, it probably makes other code around it slower by completely trashing your CPU cache (its about 1/4 of the L2 cache on a zynq-based cRIO).

For comparison, I copied the CRC calculation from the modbus spec. It's slightly faster (when run on my computer) than your method. I'm not exactly sure why though. And it uses less memory (512Bytes for LUT instead of 131kBytes).

crc bench.vi

CRC16_Modbus.vi

On 11/30/2018 at 1:28 AM, smithd said:

I got back to looking at the code today, I had forgotten but it looks like I did make the object thread-safe. All of the request-response calls are mutexed.

It is thread safe as long as you use the same instance of serial master when communicating with multiple slaves on the same bus.

I finally took a look at the code. I have a couple comments/questions:

Serial Shared Components.lvlib->Configure Serial Port.vi: Case structure for number of stop bits. I suggest having some override for this. Maybe have a property node for the stop bits setting. I've come across a number of situations where I have needed RTU with no parity and one stop bit.

RTU Data Unit.lvclass->Calculate CRC.vi: I think that there is a more efficient way to calculate the CRC using a lookup table. I'd be happy to share it when I get around to implementing it on Plasmionique Modbus Master.

Serial Shared Components.lvlib->Serial Read.vi: I don't like the idea of polling the bytes at port every 8ms. Why not just read the specified number of bytes and let VISA handle the timeout?

Serial Shared Components->Serial Read to CRLF.vi: Why not just read until LF (let VISA read take care of this)?

ASCII Data Unit.lvclass->Read ADU Packet.vi: Why is start character written to request unit ID of Serial Data Unit? Shouldn't it be the unit ID?

IP Data Unit.lvclass->Read ADU Packet.vi: Transaction ID mismatch will discard the packet. What will happen on a noisy network connection with multiple transactions being sent out? See: https://github.com/rfporter/Modbus-Master/issues/1

Why does TCP Master/Slave need Protocol Read to CRLF.vi?

TCP_NODELAY.vi: Cool... Was this ever used & tested?

I actually still use the OpenG ini library for a lot of my config files. As I recall, it's output was a bit more human-readable compared to the MGI ini format. Recently I've started to look at TOML as a possible replacement: https://github.com/erdosmiller/lv-toml

Of course JSON or XML could also work very well but they look a bit more intimidating to the non-technical user.

Plasmionique Modbus Master cannot act as a slave.

NI Modbus Library contains a good slave for testing purposes: https://github.com/NISystemsEngineering/LabVIEW-Modbus-API

On 8/17/2018 at 6:19 PM, smithd said:

The significant area where your version and this version differ is your attempt to make the object thread safe which...doesn't hurt, but I'm still not sold on. Maybe its just how I write applications, but I can't think of any situation where I'd want to share the port between loops. I thought I had a use not too long ago but since the port is multidrop anyway I just serialized everything.

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

NI Labs Modbus API is now on GitHub!

Password protection of VIs has been removed.

https://github.com/NISystemsEngineering/LabVIEW-Modbus-API

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: 

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.