Search the Community
Showing results for tags 'force coils'.
Found 1 result
Hi! So, I am writing ASP Core 2 project and one of the components is communicating with Unitronics V130 unit (as a Modbus Slave). Since provided .NET Driver library is not portable to ASP Core I need to implement this communication with Modbus. I have limited experience with Modbus protocols but I have used some basic functions in the past – mostly reading Registers and Coils. Just to sample some data. I used python library modbus_tk for this purpose. Using Modbus gives me options for adding more optional hardware down the line. After reviewing some libraries supporting Core I selected library Modbus https://github.com/AndreasAmMueller/Modbus made by AndreasAmMueller, written in C# as Net Standard 2.0 library. I started testing this library by communicating over Modbus TCP/IP with V130 PLC. I got mixed results. - namely "Write Multiple Coils " or "Force Coils " (Function code 15) does not work correctly. So. Modbus read functions all work great, these are: Read Coils (Function code 01) Read Holding Registers (Function code 03) Out of write functions these work great too: Write Multiple Registers (Function code 16) – named “#16 Preset Holding Registers” in VisiLogic help files Write Single Coil (Function code 05) – not referenced in Unitronics (VisiLogic) help files under “Slave Addressing” Write Single Register (Function code 06) - not referenced in Unitronics (VisiLogic) help files under “Slave Addressing” These functions are documented in help files of VisiLogic at “Slave Addressing” topic (where address offsets are defined). Now, function that does not work (at least with V130) is: Write Multiple Coils (Function code 15) – named “#15 Force Coils” in VisiLogic help files This function takes in “n” sequential bit values (“coils”) and a “starting address”. Then it writes these values in slave (in my case V130 device), starting at “start address” and for “n” values. It never sets coils to provided values. But it does set provided coils (addresses) just not to provided values. Meaning, if I want to set 16 coils (lets say some Memory Bits – MB) to 1, only some 8 coils would be set to 1, other 8 coils would be set to 0. It appears that only some byte is set to provided values (but that varies with number of provided addresses/values). Let me repeat again – all provided addresses are written to, just not the values that are provided. Interesting thing is that even if I provide only “true” (1) values, somehow “false” (0) is written to address. AFAIK if I provide only “false” values, no “true” value is written to address. Let’s see what is sent to PLC in next section Modbus implementation on PLC? I suppose Unitronics PLC Modbus implementation is compliant to Modbus specifications and implementation guides, defined by http://www.modbus.org/specs.php (I don’t know, but I would hope). As such Modbus TCP/IP ADU (Application Data Unit) should be implemented as defined in http://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0a.pdf and Modbus PDU (Protocol Data Unit) as defined in http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b3.pdf. This is nicely presented in image bellow – Modbus ADU (MBAP Header + MODBUS request). Here request is made for reading register #5 in remote server (page 22/46 from Application Protocol document): There are 6 bytes of MBAP Header, followed by “length – 1” bytes of MODBUS request (we must subtract 1 byte for Unit identifier, which is included in “length”). In example above there are 5 bytes of Modbus request that makes “length” equal 6. Function “Write Multiple Coils (code 15)” Modbus request is defined in Messaging Implementation Guide at page 29/50: This block is inserted at MOBUS request field in Modbus ADU, presented above. It takes 1 byte to describe the function code, 2 bytes for starting address, 2 bytes for quantities of values (number of “coils” we want to write), 1 byte for number of bytes and finally N Bytes for associated values. Simple test For simple test I am going to use function “Write Multiple Coils (code 15)”, writing 16 (2 bytes in length) “true” (1) values, starting at address 1200, which means Memory Bit (MB) #1200. Device ID is 1. This is Modbus request ADU, which is sent to PLC: It appears that the implementation of Modbus in NET Standard 2.0 library is compliant to Modbus specifications and implementation guides, defined by modbus.org. There is correct MBAP Header and MODBUS request. It provides correct address (1200), number of coils (16) and correct values of coils, which is “true” 1 for all, thus 2 bytes with value of 255. But the result of this operation yields, starting at correct address of 1200: 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0. We were hoping for all 1. I doubt its wrong implementation in the library, I have checked many requests against specifications from modbus.org and all seem to comply. Ofc the working functions (Read Coils) etc. all comply to modbus.org specifications and yield correct results. Only “Write Multiple Coils (code 15)” function yields wrong results and is there any chance that its not implemented according to modbus.org? Solution/hack that seems to work I found one hack that seems to work (at least with V130 PLC). But I wouldn’t recommend to use it until there is conformation that this hack does not cause some unwanted consequences. Here goes, it appears that appending one (dummy) byte (of arbitrary value) before bytes that represents values (in the above case  and  bytes) somehow causes the function to work and we can update Length byte . But it seems that updating Length does not have any effect, it works regardless (need to test that more rigorously). New (working) request would look like this, with added dummy byte: As you can see there is added dummy byte at  and length updated to 9. Result of this operation yields correct state - all 16 coils MBs are set correctly. This seems to works with any combination of values and number of coils. But this hack is untested, I don’t know if this command is really contained to just defined addresses or does it write all over the memory. I tested this only for some addresses beyond defined range by manually setting values via VisiLogic “online mode". More importantly, why does this hack work? Or even more, why “normal” Write Multiple Coils (code 15) does not work? Is this V130 specific? Any help appreciated! Best Regards! PS: To add, I did change "MODBUS: SCAN_EX" block to SCAN and SCAN_32 - nothing worked. Now I left it with "MODBUS: SCAN" block to support "older working applications" as stated in help files of VisiLogic.