Echo on RS485

[jaroslav_sobota]

Hi Mike,
in order to cancel the echo, try to manually modify the .rio file with Modbus driver configuration. It contains a line

Parity 0 (or 1 or 2)

Change this line to

Parity 32 (or 33 or 34)

With this setting you should get rid of the echo. Remember that you must do this anytime you change some setting in the Modbus configuration dialog because it will override this manual change.

Hope this helps, let me know.

Best regards
Jaroslav

[MikeyH]

Thanks for the reply Jaroslav. How do I go about editing that? Is it through Linux, or a separate program?

Cheers

Mike

[jaroslav_sobota]

Hi Mike,
sorry for the confusion. The *.rio file is part of your project, you can find it in the same folder as your source *.mdl files. Therefore you can edit it on your Windows PC with your preferred plain text editor.

Kind regards
Jaroslav

[MikeyH]

Hi Jaroslav,

This seems to work, however I now get this error.

Also I only seem to received the first register, is that related to the above error?

Cheers

Mike

[jaroslav_sobota]

Hi Mike,
yes it can be related. Please upload the project source files so I can inspect details of timing, Modbus baudrate etc.

Try the following and observe if the problem persists:

• Read only 1 register, no writing. Delete all the other items from Modbus configuration.
• Read 2 registers, no writing.
• Read 4 registers, no writing.
• Read 4 registers, write 1 register.

Let me know.

Jaroslav

[MikeyH]

Hi Jaroslav,

Files enclosed, I will try your suggestions by the end of the day hopefully. I have noticed if I use a larger block (INQUAD or INHEXD) I randomly pick up more registers further down.

This is also the same project I asked about best timing practice, https://forum.rexygen.com/topic/89/project-timing

Cheers

Mike

3_1579570165365_WDTL_HIL_exec.mdl 2_1579570165365_modbus_write_task.mdl 1_1579570165364_modbus_read_task.mdl 0_1579570165364_master_cfg.rio

[MikeyH]

Hi Jaroslav,

Trying what you suggested has mixed results. I remembered something you showed me awhile ago and looked at the log for just the driver read/write. See below for what the log is saying. This was done with no writing and three registers being read, 0x1000, 0x1010 and 0x1020.

0x1010 seems to return the same value as 0x1000. This shouldn't be the case, 0x1000 is correct though. I changed the read order in the configuration settings and 0x1010 started reading correctly, 0x1000 now does not and returns the same value as 0x1010. It seems hit or miss whether 0x1020 reads the correct value or not, the longer I run the simulation the more chance that 0x1020 reads correctly.

Why would changing the read order have an affect?

Could the CRC errors could also be causing this? The last byte is missing or being cut off. I still receive the correct value though.

3 registers being read (0x1000, 0x1010, 0x1020)

1 register being read (0x2010)

Cheers

Mike

[jaroslav_sobota]

Hi Mike,
thanks for the screenshots. This is very nonstandard and would require detailed analysis with the hardware on our testbench, possibly analyzing a record from oscilloscope etc. There is no way to do it remotely, sorry.

Still, you can try to run the project on a Windows PC, you'll just have to replace /dev/ttyUSB0 with COMx in Modbus configuration. Just to know if anything changes. Please stick to reading a single register.

If the end device allows it, you can also try lowering the baudrate to 9600, just to see if the behavior changes.

You can also write a test application using REXLANG, sending a single Modbus request (8 bytes: 0x01 0x03 0x20 0x10 0x00 0x01 0x8E 0x0F) and receiving the response, just to know if you receive a valid echo and a valid Modbus response from the device. See example 0401-01 for inspiration.

Hope it helps at least a bit.

Kind regards
Jaroslav

[MikeyH]

Thank you for the help Jaroslav, I will try both the REXLANG and Windows solutions to see what happens.

How do I run the project on a Windows PC?

Cheers

Mike

[jaroslav_sobota]

Hi Mike,
just exclude the Raspberry Pi driver from your project and enter "localhost" as Target address in the Download dialog and click Download. Local runtime core (RexCore) will be started on your Windows PC, allowing you to run your algorithms. Quite useful for testing and debugging.

2-hour demoversion is available just like in all the other REXYGEN-enabled platforms.

Hope this helps, let me know.

Kind regards
Jaroslav

[MikeyH]

Thank you Jaroslav, you learn something every day! That will help more than you know with all of my projects. especially ones with process models

Cheers

Mike