administrators

Hi Mike,
so here's your project source files: mike-project-timing.zip

Let's see what you have done...

Here's the same in PDF if you prefer: rexygen-project-timing.pdf

The first thing to understand is the allocation of time slots for individual tasks and drivers:

• Base tick = 20 ms
• RPI - Raspberry Pi driver, factor = 1, i.e. execution period = 20 ms
• MBM - Modbus RTU master, factor = 5, i.e. execution period = 100 ms
• modbus_write_task, start = 0, stop = 1, factor = 3, i.e. execution period = 600 ms
• modbus_read_task, start = 1, stop = 2, factor = 10, i.e. execution period = 2000 ms

The diagram above only illustrates the time slots. It does not show how long each task executes and when exactly it happens.

From what you wrote, I believe it's important to note that it's the yellow Modbus driver where the data is actually sent and received. Therefore all the Modbus registers which you have defined in the Modbus driver configuration for reading, will be read every 100ms. However, your modbus_read_task is scheduled to execute with 2 second period, therefore 9 out of 10 readings will be in fact wasted, creating unnecessary traffic on the serial bus.

Also keep in mind that by default, Modbus write commands are executed only when there is some change to write. The Modbus driver takes care of this for you to preserve bandwidth.

Is this clear to read so far? Learned something new? Willing to continue? Let me know...

I believe you could achieve what you need even with a single task, but I might be misleaded by the project source files reduced to the absolute minimum.

Best regards
Jaroslav

Hi Emmanuel,
thanks for the links, now I understand. You are right, for local HMI you can simply kill Chromium and reload it with a different starting page. For me, this is not appealing at all, but that's not important.

You can always run a bash script from REXYGEN using the EPC function block, killing and restarting Chromium in case of an event. See example 0202-11 for inspiration.

Best regards
Jaroslav

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

Hi Emmanuel,
I've never heard of such an approach. Moreover, even if it worked, you could use it only for local HMI.

Regards,
Jaroslav

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

Hi Mike,
great question, makes perfect sense. Can you please provide more details about your project? Namely:

• Do you need the tasks to execute in specific order?
• How long does it take to execute the individual tasks? I don't expect it takes more than a few milliseconds, but please confirm.
• What is the base tick?
• What is the factor of Modbus driver?
• Can you share your project source files? Or at least some minimum example?

Jaroslav

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

Hi Emmanuel,

thanks for your question. Can you share configuration of Modbus in your project (or preferably whole REXYGEN project if possible) so I can have a look at the settings you used?

There is possibility to Swap Bytes or Swap Words at each Modbus item - did you try that?

Regards, Tomas

Hi Hubert,

thank you for your question. It would be much more easier to answer if you can share project files which shows the example of such JSON string and function block settings.

If you want to access JSON array, just use "[x]" notation, i.e. weather[0].main (means field "main" in 1st item of "weather" array) - see "0302-04 OpenWeatherMap API" example.

Hope it helps.

Regards, Tomas

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