jacajack / liblightmodbus Goto Github PK

Hi

Thanks for the great library.

When dynamic memory allocation is disabled, I get a segmentation fault in the modbusMasterInit() function. I cannot see anything wrong with it after trying to debug for several hours (I might be doing something wrong somewhere). I can reproduce it in both Os X and debian.
This issue disappears once I enable dynamic memory allocation

I have created a project in order to reproduce and isolate the problem as much as possible in this repo https://github.com/ASL07/lighmodbus.
If you run the build script, it will trigger the execution of the test main(). It will throw a segmentation error after the program ends.

If add_definitions( -DLIGHTMODBUS_STATIC_MEM_SLAVE_REQUEST=256 -DLIGHTMODBUS_STATIC_MEM_SLAVE_RESPONSE=256 -DLIGHTMODBUS_STATIC_MEM_MASTER_REQUEST=256 -DLIGHTMODBUS_STATIC_MEM_MASTER_RESPONSE=256 -DLIGHTMODBUS_STATIC_MEM_MASTER_DATA=256 ) is comented out in CMakeLists, then the issue disappears, however, once these macros are defined, then we get the error again.

I have tried to modify the size of the buffers and it makes no change either.

Could you please have a look into it?

Regards

Hello,
I have started using liblightmodbus 3.0 in some of my software projects; initially I was successful, but I was immediately halted while trying to port to the new version a PIC24 project.
The default behavior of the XC16 compiler from Microchip forbids variable declarations inside a for header (in compliance with the C90 standard I believe), which liblightmodbus does in a few points (i.e. here). Therefore my compilation fails with the error error: 'for' loop initial declarations are only allowed in C99 mode.

Trying to use C99 mode with the -std=c99 flag causes some other issues in my project which I did not yet explore extensively. Personally I like to declare indexes inside the for header as well, but the PIC compiler often leaves me with little choice. I'm here to ask if you would be willing to accept a pull request where variable declarations have been moved outside the for statement, in which case I'll see to it. Otherwise I'll keep trying to use "C99 mode" and fix the other issues that arise with that.

I am new to Modbus communication, and I am trying to learn it. I am using LPC1768 as the master and the Raspberry Pi as the slave for Modbus communication. Everything is working fine when I use the second version of the liblightmodbus library. When using the third version, even though no error is there, when I call the modbusMasterInit() function in my main loop, it's blocking the microcontroller from doing anything. Thus, I am not getting any output. Can you tell where I am going wrong?

I am adding a snippet of my code for reference.

int main(void)
{   
	SystemInit();
	debugInitialize(DEBUG_BAUDRATE);
	UART_Init(C_UartOne_U8, MODBUS_BAUDRATE);
	debugPrintf("Pendant powered up");	
	debugPrintf("Default function count = %d\n", modbusMasterDefaultFunctionCount);  
	
	ModbusErrorInfo err;
	err	= modbusMasterInit(
        &master,          
        dataCallback,                  		// Callback for handling incoming data
        masterExceptionCallback,					// Exception callback (optional)
        modbusDefaultAllocator,         	// Memory allocator used to allocate request
        modbusMasterDefaultFunctions,   	// Set of supported functions
        modbusMasterDefaultFunctionCount	// Number of supported functions
      );
	assert(modbusIsOk(err)); 
	
	debugPrintf("Modbus master initialized!"); 	
	
	osKernelInitialize();
	
	debugPrintf("Kernel initialized!");  	
	
	tid_thrMODBUS_COMM_Q = osThreadNew(MODBUS_COMM_Q, NULL, &MODBUS_COMM_Q_attr);
	
	osKernelStart();

	return 0;
}

Hi,
I did some test with liblightmodbus in slave mode using serial port:

1. first, wait for slave address as a start of frame
2. with a start of frame call modbusParseRequest() on every incoming character until get a valid CRC or an exception.
   In some case I got a frame with correct CRC but it is not passed the length check as example frame:

• Valid frame: 0xa 0x10 0x0 0xd 0x0 0x1 0x2 0x0 0xac 0xd4 0x0

• Invalid frame: 0xa 0x10 0x0 0xd 0x0 0x1 0x2 0x0 0xac 0xd4
  In both case it passed CRC check but the frame with invalid length is returned exception.
  Could you suggest me a solution to handle this. Thanks you!

Hi, I'm looking for example of integrating Modbus TC master functionality, currently I'm using espidf but any example will do.

Thanks

Hello,
I'm beginner and i want to use the modbus lib for an AVR128DA48 as a slave and i dont find / understand how to use your lib.
If you can help me to understand and find solutions.
best regards.

Good Day

Thanks for the great project.

I noticed that genconf.sh incorrectly adds the 02 modules when the intention is to only add 22.

To reproduce:

./genconf.sh --endian little --mres 32 --mreq 32 --mdat 32 -m "03 04 22" -s ""

[info] cleaned build environment
[info] updating version number
[info] using little-endian build configuration
[info] master request buffer size is 32 bytes
[info] master response buffer size is 32 bytes
[info] master parsed data buffer size is 32 bytes
[warning] skipping slave base module
[info] master function 2 is going to be included
[info] master function 3 is going to be included
[info] master function 4 is going to be included
[info] master function 22 is going to be included
[info] master base is going to be included
[info] frame examination module is going to be included

In the slave code, when a request is received, the user-defined register callback is called for every registers with arg type MODBUS_REGQ_X_CHECK (where X is either R or W), then the register back is called again for every register with arg type MODBUS_REGQ_X.

In modbusParseRequest01020304 one comment says the check is for "Check if all registers can be read". I'm not a modbus expert, but I fail to find information about the first check then read/write behavior in modbus specifications. Is it a specified behavior or a design in implementation?

Please can you help in porting for pic micro controller pic 18f6722 with uart.

Greetings. You've made overall great and easy-to-use library. However, I recently came across the following issue (which might be not an issue, but caused my app to behave unexpectedly). The issue is as follows:

Having received full MODBUS frame, my app executes:
if (MODBUS_OK == modbusParseRequest(&sstatus)) { // Do something with the data recieved }

modbusParseRequest returns MODBUS_OK (with no exceptions raised) if the address is either 0 or does not match the one of the slave. This lead to condition under 'if' being true upon reception of any valid frame. I managed to fix the issue for my app by changing the condition to

(MODBUS_OK == modbusParseRequest(&sstatus) && sstatus.request.frame[0] == sstatus.address)

I MIGHT have missed the exception being raised (why would I bother if the parser says that all is OK), but still.

Thanks.

When I compile the slave part of liblightmodbus, there's a warning about an unreachable statement in the function modbusParseRequest16 from the file sregs.c, as shown in the following snippet:

//Check if frame length is valid
if ( status->request.length >= 7u )
{
    frameLength = 9 + parser->request16.length;
    if ( status->request.length != frameLength )
    {
        return modbusBuildException( status, 16, MODBUS_EXCEP_ILLEGAL_VAL );
        return MODBUS_ERROR_OK;  // Unreachable!
    }
}

@Jacajack
I am trying to make your library work with the ESP32 using ESP-IDF.

Do you by any chance have a TCP example that I can use as a starting point?

I think this should be LIGHTMODBUS_F16M

I am very interested in testing this library

Hello,
I've found your library very useful as a lightweight, hardware-agnostic library to handle Modbus communication, and I've integrated it into a project for an ESP32-powered device.

The official framework for ESP32 (ESP-IDF) is mostly CMake-based, so I believe it would be easy to integrate liblightmodbus as a component for ESP-IDF.

Basically the build system looks for CMakeLists.txt files that describe attributes for the component (source files, include dirs, etc...). For now I'm including liblightmodbus as a git submodule in my project and refer to it with a different CMakeLists.txt:

components
    /liblightmodbus/CMakeLists.txt    <- custom component descriptor written by me to include liblightmodbus into an ESP-IDF project
    /liblightmodbus/liblightmodbus     <- actual Git repository

It would be easier for me to just clone liblightmodbus into the components folder and expect its CMakeLists.txt to work.
Since I've seen there is already some distinctions in it based on an AVR variable, would you agree to adding something similar for ESP32? The ESP-IDF framework defines the ESP_PLATFORM variable when building, so I've found that simply adding the following lines to the very beginning of CMakeLists.txt make it work (at a very basic level):

if (ESP_PLATFORM) 
    idf_component_register(
        SRC_DIRS src src/slave src/master
        INCLUDE_DIRS include .
    )
else()
    return()
endif()

This cuts off all of the configuration checks and libconf.h generation, so that part still needs to be addressed. If you were okay with that I could work a little more on this extension and create a pull request.

Warning in file master.c in line 97

I want to use liblightmodbus on a Microchip MCU (PIC24); unfortunately the xc16 compiler does not include the header inttypes.h.
I replaced the file with stdint.h and the compilation was succesful and the resulting firmware worked correctly.
Is it possible that only stdint.h is required for liblightmodbus? if so, i would suggest to replace inttypes.h with stdint.h.
I can make a pull request if you wish!

In this line MODBUS_REGQ_R_CHECK should be replaced by MODBUS_REGQ_W_CHECK if I'm correct.

Please advise on best knowledge ideas/where to start to implement function 21 (0x15) Write File Record
Thanks in advance.
Tac.

There are some deprecation warnings which need to be taken care of

Hi!

It's been over 2 years since the v2.0 release, the last major update to liblightmodbus. I think that many things can be still improved and cleaned up. Since there are apparently quite a few people using this library, I feel that I owe you all a next release. But before I break anything, I'd like to hear your suggestions and ideas.

An overview of currently planned changes can be found here. If you have anything to suggest, please write a new comment below or open a new issue.

Please let me know what you think.

@Jacajack The library looks great! I took a quick look at the code, and correct me if I am wrong but it looks like a parsing library, right? I mean, it just builds o parses the modbus-rtu frame, and the sending and receiving part you manage it on your own code, right? If that's what it does, its exactly what I've been looking for and too lazy to develop myself.

I would really like to use this library on a LPC4337 MCU development board. The LPC4337 is built around a ARM Cortex-M4F processor (and an additional Cortex-M0 processor also, but for the moment I am using just the M4). I am using a custom built multi-platform development environment based on CMake, make on Linux and mingw32-make on Windows, the GNU ARM Embedded toolchain, and OpenOCD for flashing and debugging (the board has a compatible ftdi jtag adapter). For peripheral drivers I am using the manufacturer's supplied drivers: LPCOpen. The board comes with a RS-485 transceiver connected to one of the uarts of the mcu and that's what I plan on using to communicate two board together or a board with another modbus-rtu device.

So, I was thinking that to port this library to my platform I would just copy the src directory, the include directory and the example to my project and try to build it and see how it goes. For sending and receiving I going to use LPCOpen's uart APIs.

I'll let you know how it worked out. :)

Hi,
Just wanna try this library, is there any project template for using it with UART of any MCU? just how to add the library to the project & implement UART routines to call the library functions.

is their master example also, all have seen is slave test files.