Leaderboard

View File Plasmionique Modbus Master This package contains the Plasmionique Modbus Master library for LabVIEW. It supports RTU, ASCII and TCP modes with the following function codes: 0x01 - Read Coils 0x02 - Read Discrete Inputs 0x03 - Read Holding Registers 0x04 - Read Input Registers 0x05 - Write Single Coil 0x06 - Write Single Register 0x07 - Read Exception Status 0x0F - Write Multiple Coils 0x10 - Write Multiple Registers 0x16 - Mask Write Register 0x17 - Read/Write Multiple Registers 0x2B/0x0E - Read Device Identification Other features include: - Sharing a COM port across multiple Modbus sessions using VISA locks (10 second timeout). - Sharing a Modbus session across multiple communication loops. - TCP transaction ID handling to ensure that requests and responses are matched up correctly in case responses are received out of order. - Modbus Comm Tester, available through the "Tools->Plasmionique" menu, for testing communication with a slave device without writing any code. - Detailed help document available through the "Help->Plasmionique" menu. Examples are included in "<LabVIEW>\examples\Plasmionique\MB Master\": MB_Master Comm Tester.vi: Demonstrates usage of API to open/close connection and communicate with a Modbus slave device. MB_Master Multiple Sessions.vi: Demonstrates usage of API to open concurrent Modbus sessions. MB_Master Simple Serial.vi: Demonstrates polling of a single input register over serial line. Download a copy of the user guide here: MB_Master - User Guide.pdf Note that Version 1.3.4 of this library has been certified compatible with LabVIEW and has been released on the LabVIEW Tools Network: http://sine.ni.com/nips/cds/view/p/lang/en/nid/214230 The most recent version of this library will always be released on LAVA first before going through NI's certification process. ***This project is now available on GitHub: https://github.com/rfporter/Modbus-Master Submitter Porter Submitted 04/01/2016 Category LabVIEW Tools Network Certified License Type BSD (Most common)  

I like that you decided to simplify the RTU serial read...I was stubborn and wanted to follow the spec, I think that was a mistake. Serial APIs have come too far since RTU was created. The visa lock thing is neat, I didn't know that existed until recently. My only comment there is that if you went with a DVR for both you could put that in the parent class so you can't execute a query unless the parent lets you, which feels nicer to me. Probably not any real reason to do it. I also like that you somewhat simplified the class hierarchy. I can tell you right now I've never seen anyone make a new ADU or implement a new network protocol, so simplifying things on that front is great. The places I've seen extension are adding new function codes or changing slave behavior (which obviously doesn't apply here). A few other thoughts from that perspective: -I'd recommend pulling the PDU out of the ADU class and instead make the PDU a parameter of TX/RX and an output of RX. This is just a style thing of course but it makes the code easier to comprehend and for people adding new function codes its clearer where the data is going and what the library is doing with it. -I'd just make the PDU a typedef cluster. I went back and forth on this and ended up with the class, but I think that was a mistake. It doesn't need extension and doesn't need encapsulation, so.. -Pulling the individual 'build write...' and 'interpret response' functions out of the PDU class or library would, I think, make it feel like more of a level playing field for people adding new functionality. Like, it makes it clear that the function codes are happily mutable while in contrast you really shouldn't be touching "TX ADU". More importantly, it makes it less likely that someone adding a custom function code just adds it to your class and then saves it, making their version incompatible with the baseline.