10-06-2016 10:34 PM
hi,
can you pls share your code
regards,
Dinesh
10-07-2016 03:14 PM
Hi Daniel,
Thank you for your inputs & pointers to previous posts. It was really useful & helped a lot in improving my understanding of the Modbus implementation in Labview.
I was starighaway able to comeup with multiple instances of modbus slaves on the cRIO that shared a common memory. This is exactly what I was looking for ! On the way encountered minor issues like no opening to setup custom IP address for the ModbusTCP slave interfcaes & error while trying to shutdown the slave instances. But they were easy to fix; modified the create slave instance vi to include an additional control for setting up the ip address & for getting rid of the shutdown error message had to modify the Close vi so the data value references are not deleted twice but just once.
Also glanced through your example for event generation, looks straightforward to implement that. Will try that out soon.
Haven't started yet on expanding Modbus (including custom codes), I am sure I will have more questions for you when I get there
Thanks again for your inputs !
Rineesh
10-07-2016 07:08 PM
Hello Dinesh,
The code is from the Plasmionique Modbus Master package available here: https://lavag.org/files/file/286-plasmionique-modbus-master/
Once the package is installed (using VI package manager), the VI from the screenshot will be located in the "<LabVIEW>\examples\Plasmionique\MB Master\" folder, or you can search for "modbus" in example finder. The filename is "MB_Master Comm Tester.vi".
10-10-2016 06:40 AM
Hi Smithd,
Would this be a good place to ask about the real time modbus library? As i understand it is basically this library refined somewhat.
I think i am seeing a memory leak with connect, disconnect. That means if a modbus master reconnect to the slave for each read for example the memory would run down over time.
I have attached test VIs. Running the slave test vi on a sbrio-9627 and the master tester on a windows computere I see a fairly fast drop in available memory on the RT target.
I understand that this is not a good way to read from a modbus slave (we dont always have a choice in how a client would read from our modbus), but i think we should be able to handle this without running out of memory.
The master is made using the Plasmionique Modbus Master because i cant find the RT modbus library for windows ( a bug in labview 2015 pallets i believe), but i would think the effect would be the same with any master.
Is there something i am doing wrong or misunderstanding, anything i can do to remove the leak or get the memory back regularly?
Thanks in advance.
10-10-2016 10:36 AM
The version you're using is the official version and as such is supported by the normal applications engineering department through phone, email, or forums. In general I'd suggest working with them for possible bugs like this.
However, I will say I've seen this come up before and I was unable to reproduce the claims. If I'm remembering correctly, I didn't see any growth in memory usage over time on a real-time target.
Other items you mentioned:
-The master library is available, it just doesn't appear on the palettes if you only have labview rt installed. The functions are in the same folder as the slave functions.
-A *growth* in memory is not a memory *leak*. LabVIEW is pretty notorious for growing to fill the available memory, and on most OSs will only free memory back to the OS when the entire system is running low.
-Linux RT has historically had problems reporting memory accurately. A more reliable test would be to run the same code from windows to windows or from windows to a VxWorks slave, if you have one. If you run on windows (and have the license) you can use the desktop execution trace toolkit to see if the code has any true leaks.
10-12-2016 03:11 AM
Ok, i will talk with support. Just as a note, the code i posted will run the controller out of memory and stop accepting new connections in the end (when there is zero available memory left) so it is a leak of some kind not just holding memory.
If i get the time i will try the same with the library here.
Regards
10-26-2016 03:31 AM
Hi,
I have now tried the same with the library here and i see the same memory leak. I will include the code. I Logged memory usage with Ni distributed system manager and NI max, both show a rapid increase, however I was also running profile - performance and memory (log included) and that did not show any memory increase (I did close the running program before i stopped the profiler, i heard that is critical). I have included an image from NI distributed manger, the memory increase step seen there happens regularly, but not on an exact timer (between 10 and 30 seconds).
Again the controller will in the end run out of memory and refuse new modbus connections so it is not just holding memory or Linux reporting the wrong amount.
As a side note, I have tried running the same modbus master setup (fast reconnecting) with the Modbus I/O server and there is basically no memory usage (<2MB) atleast over a couple of days of running.
Regards
Mrmas
11-15-2016 07:57 AM
Hello to everyone.
First of all thanks for doing this work.
i have an application where I use NI OPC server to communicate my VI with a PLC (sending and recieving variables).
I would like to know if it is possible to do that whit this library without using NI OPC server and DSC module.
Thanks a lot.
11-25-2016 05:14 AM
OPC is OPC and not Modbus. But if you get your PLC to the NI Labview Modbus API server, you don't need DSC. Still, using the DSC module gives you access to support and updates...
12-01-2016 08:04 AM
Dear colleagues,
I have some problems with multiple master / slave architecture.
I try to explain better: I have a 8431/8 NI PCI card with 8 COM ports. I would like to read via Modbus RTU data from different slaves (different types of sensors) continuously at the highest frequency, so I used 8 parallel loops.
When only one port is active the communication is stable, but when I try to use more than one port, communication stops and I have to re-establish connection (error 56). The problem increases at the latest ports (port 1 works well, port 2 stops every 2-3 seconds ... port 8 doesn't work)
I did some test:
- I tried the same code with a NI 8430/2 and it works (2 parallel loops).
- I use a for loop instead of 8 parallel loop (basically I serialized the requests) and I have no problem. Obviously in that way decreases every sensor read frequency because I have to wait all the responses.
Do you have any suggestions?
thanks