I might have found a modbus problem ...??

This is excellent!
I read some of your comments in iirc too.
I have no TCP devices but another fellow on this forum does and has used EMC's CL with TCP . Maybe he can test
I will forward your patch to Marc ( CL's creator ) as well.

Chris M

Hi Chris,

I had a problem running this modified software at 300 baud. It runs fine from 600 - 115,2 kbaud.

I decided not to try and fix it so it runs at 300 baud since the errors were very odd, so I simply took the 300 baud option out of the menu and the software.

I'll be very surprised if anyone misses the 300 baud option setting.

On Modbus RTU, I tested all of the speeds. I also tested all of the functions that are available with a slave simulator program, I also tested some of the functions with a PLC. (The PLC didn't support all of the functions.)

The slave simulator was capable of running Modbus TCP so I set that up and tested the software with that also. I also tested all of the modbus functions
that are available with TCP.

Both the Modbus RTU and the TCP performance is very good. At 38,400 baud this software can read 5 holding registers, in about 25 ms from a Siemens S7-200 PLC. The TCP performance was very quick with the simulator software. I wasn't able to test the Modbus TCP performance with a PLC. But it should be unchanged as most of the changes I put in were for the Serial Modbus RTU implementation.

The manual should probably be updated as I no longer get CRC errors which were being caused by partial reads of the modbus response messages. I ran the software connected to the PLC, via Modbus RTU, reading and writing holding registers for 10+ hours at 38,400 baud and never had a "Modbus failed" message popup.

A 400 ms time out value worked fine for all of the speeds.

In the original code, there were some hard coded time delays in the Modbus RTU code that are no longer needed, so everything runs much faster. The downside is that if all delays are kept at zero on the modbus configuration page, the cpu loading can be significantly affected by the Modbus thread. Increasing either time delay value to some nominal value like 25 ms will reduce the loading. I monitored the CPU loading with HTOP. But at least now the user can decide how fast they want to scan the Modbus slave/s via the controls.

The default Modbus TCP port is still set to 502 in the source code, however the manual says it defaults to 9502. I didn't have any permission problems running the TCP version at either 502 or 9502.

Let me know if you have any problems. If it works out, perhaps we can have them include the changes into the next release version.

It would be great if you could forward these changes onto Marc also.

A .rar file is attached that contains the altered files.

Whoops.. this forum doesn't accept .rar files. See the following message with the attached zip file.

Thanks,

Dave

OK.... this forum won't accept a .rar file.

Attached is a .zip file.