NI LabVIEW Modbus API Discussion

[smithd]

Hey Jerome,

I did a quick investigation and it turns out the issue was just a dumb mistake on my part. I was under the mistaken impression that using the call and forget flag would allow me to forget about the vi--ie, LabVIEW would close the reference when the vi stopped executing. Instead, you are required to close the reference you opened, even though that reference doesn't actually reference the vi that launched.

Long story short, its an easy fix and I'll have something out here in a little while. Thanks for catching it.

-Daniel

[smithd]

Hey Faust,

It would be very beneficial if you could provide a screenshot of the code you use to call the two different modbus libraries. If there is a change to how unit IDs are handled I'd like to roll that into the next build.

Thanks,
Daniel

_Faust wrote:

It works fine with the older library which I am using for nearly all applicatioms. So I am sure the function code and address are right. Thanks for the suggestion though

[_Faust]

Will try to do that today. I had to work on another project umfortunately with high prio.

I have another question though that was actually the reason why I started using this api.

With the old library I had occasional problems when using a TCP to RTU gateway. Sometimes the returned message ID would not match. If i requested a float and a float is returned it gives never an error, also if the transaction IDs dont match.

In practise this results in wrong values if im reading a flowmeter or something.

[Jérôme.H]

Hello smithd,

Thanks a lot for your very quick answer. Indeed it's with TCP.

I'm happy that you understood the problem quickly and that maybe you can correct it too.

Please ask me if you need any other precision.

Best regards,

[arielec]

Hello smithd

I used the modbus library as slave in a CRIO-9074 for a modbus TCP communication.

Everything works fine, communication is OK ,  but my (CRIO-9074) stops the communication with the master computer after numerous connections and disconnections.

Because this application works in a production, I'm must correct this problem quickly.

Please feel free to ask me if you need any other precision.

Best regards,

[smithd]

Hi Ariel,

Is it correct to say that this is the same problem that Jerome described?

If so, is it also safe to say that you identified memory usage as the cause of the disconnection. That is, are you monitoring memory usage and seeing it go up towards the limit of the controller before the disconnection occurs?

Either way, I'll go ahead and provide a patch up here in a few hours. I'm going to wait a bit longer to build the package since this isn't an issue for most use cases.

On the topic of use cases, why are you repeatedly connecting and disconnecting? If the 50k number is correct, it should take a very significant number of connects and disconnects before you run out of memory (that is why the leak had not been caught in over a year). Can you describe your use case?

Thanks,

Daniel

[arielec]

Hello smithd,

This seems to be the same problem Jerome described.

My use case is as follow, the line PC is connected for each product, around 200 times a day. This represents 1000 connections a week. With 50k of memory used each time, my 40M of memory are entirely used. Thus stopping the communication.

Thanks and best regards.

[smithd]

Ah, interesting use case. Definitely makes sense, though.

I've attached a patch below. Please unzip the contents to C:\Program Files (x86)\National Instruments\LabVIEW 2013\vi.lib\NI\Modbus Library

It should ask you to overwrite three files. If it doesn't, you may be unzipping it in the wrong location or way (for example, windows by default may try to unzip /Network Protocol/Network Protocol/..., which is incorrect).

Thanks,

Daniel

[arielec]

Hello smithd,

Your patch has tremendously decreased the memory leak, from 50k to only 2k per connection.

It should alow to work for around 3 months instead of the previous 1 week term. This is a fairly satisfying result as in the course of such a period the device should be put off tension more than once.

Thanks again for solving this problem in such a short notice. I would follow the evolution of this library on this forum with much attention.

Best regards.

[smithd]

Hey Arielec,

Glad to hear it. When I ran it on a PC I saw a small growth, as you say, but it evened out after a little bit. I think that smaller growth was related to the monitoring information I mentioned above. Can you confirm that it is still growing after a longer period of time? If so, I'll go ahead and re-run my tests on a cRIO.

Thanks,

Daniel