Wide data types support / TCP usage example

[ammaree]

@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?

[ammaree]

Thanks, problem resolved.

However, the PLC's we are using have large numbers of u32, i32 and f32 registers.

Any plans to add support for 32bit register sizes with these formats?

[Jacajack]

Hello,

Sadly, currently there's no real example for Modbus TCP. This has already been discussed in #28. I'm really going to have to look into that. Glad to hear you already managed to solve your problem, though.

As far as I know, the implementation of the 32-bit types in Modbus is non-standard and might differ between manufacturers. Because of that, I don't think integrating it in the core library would be a good idea. However, having a couple of additional vendor-specific implementations of these features in separate files might be beneficial. I'm not planning to implement them myself, but I would gladly accept any pull requests with such 'extensions' to the library.

There's a little catch though - to handle the 32-bit types properly, support for wider data types would first have to be added to ModbusRegisterCallbackArgs and ModbusRegisterCallbackResult. This sounds like something that should be implemented alongside with support for file read/write operations. I'm planning to do that in the near future, maybe even this summer, although there's no clear deadline yet.

[ammaree]

Hi @Jacajack

Overall a superb, simple and compact library, far easier to get started with compared to the ESP-IDF ESP-Modbus component.

I have added functionality in the data callback that matches the index with a set of index/count entries and, if the count is >1 consolidates successive 16bit values into a single 32/64 bit value. I have also added flags that allow for specification of:
a) un/signed or signed or float format;
b) little or big endian byte order ie. reversed if required
So far this is working well with both Carlo Gavazzi energy meters and Eliwell/Schneider PLC's

However, my solution is a kludge and does not nicely integrates with the format of your library so I am looking forward to you adding proper support for 32bit, maybe even 64 bit types as well as the file/read support.

Thanks

André

[Jacajack]

I'm happy to hear you like the library, thanks!

Good to hear you managed to find a way around that limitation. Maybe it's not a perfect solution, but definitely is a good one, if you managed to get it working with real hardware.

I will look into providing real support for that soon. I'd be great if I could find a way that combines both file read/write and wide data types support into a single non-breaking change. Let's keep this issue open until that gets done - I will try to keep you updated here.

[Silvesterrr]

@ammaree Do you maybe have modbus tcp slave example using esp-idf?
I've integrated esp-idf modbus rtu master. Building the library was much easier using liblightmodbus.

@Jacajack
My only sugestion is that it would be nice if you could directly get parsing result from modbusParseResponseRTU without needing to use calback handler. :)

[Jacajack]

My only sugestion is that it would be nice if you could directly get parsing result from modbusParseResponseRTU without needing to use calback handler. :)

@Silvesterrr Thanks, that's a good point. Do I understand correctly that you'd like to be able to call modbusParseResponseRTU while dataCallback is NULL in the ModbusMaster struct? If so, that should be relatively easy to implement.

[Silvesterrr]

Do I understand correctly that you'd like to be able to call modbusParseResponseRTU while dataCallback is NULL in the ModbusMaster struct? If so, that should be relatively easy to implement.

Yes.
It would be nice that modbusParseResponseRTU provided the result of "parsing" directly. Idk maybe by passing pointer to some structure that will be filed with results.
I think the code then would be cleaner and better to understand with quick glans.
But Im not specialist in any means thats only my fealing.

Overall the library is great thx for that :).

[Jacajack]

Ah, right, I see. Actually, I deliberately avoided that approach. The reason for that is that would require allocating an additional buffer for the processed values. That's not very desirable on low memory systems, especially considering that you can have up to 2000 coil values in a response. Sacrificing 2kB of memory for some user convenience didn't feel like a good decision to make. That's why I went with the more flexible and memory-light callback approach.

However, something like that can be achieved quite easily with the current system, if you like. You'll just need to write a small callback which puts all the data in some array of your choice. Something like this:

liblightmodbus/test/tester.cpp

Lines 123 to 129 in 0035601

	ModbusError dataCallback(const ModbusMaster *master, const ModbusDataCallbackArgs *args)
	{
	received_data.push_back(*args);
	// Always return MODBUS_OK
	return MODBUS_OK;
	}

Overall the library is great thx for that :).

Glad to hear you like it, thanks :)

[ammaree]

@Silvesterrr Have only implemented a Modbus Master, no need for slave (yet) On 25/03/29, 12:49, "Sylwester" ***@***.******@***.***>> wrote: @ammaree<https://github.com/ammaree> Do you maybe have modbus tcp slave example using esp-idf? I've integrated esp-idf modbus rtu master. Building the library was much easier using liblightmodbus. @Jacajack<https://github.com/Jacajack> My only sugestion is that it would be nice if you could directly get parsing result from modbusParseResponseRTU without needing to use calback handler. :) — Reply to this email directly, view it on GitHub<#29 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAYT7GDOS6SVCSLIGX3KA7T2WZUBXAVCNFSM6AAAAAB2BHS442VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRTGI4TCMRZGQ>. You are receiving this because you were mentioned.Message ID: ***@***.***> [Silvesterrr]Silvesterrr left a comment (Jacajack/liblightmodbus#29)<#29 (comment)> @ammaree<https://github.com/ammaree> Do you maybe have modbus tcp slave example using esp-idf? I've integrated esp-idf modbus rtu master. Building the library was much easier using liblightmodbus. @Jacajack<https://github.com/Jacajack> My only sugestion is that it would be nice if you could directly get parsing result from modbusParseResponseRTU without needing to use calback handler. :) — Reply to this email directly, view it on GitHub<#29 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAYT7GDOS6SVCSLIGX3KA7T2WZUBXAVCNFSM6AAAAAB2BHS442VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRTGI4TCMRZGQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>