Temco PLC as Modbus Master

Chelsea, thank you for the answer!
The command to write the register in my program is correct and everything worked, but after I connected the wires to the RS485 SUB connector, not to the terminals marked with “+” and “-”, but to the terminals “+” and “EARTH”, see screenshot. Is this a mistake in marking the terminal?

I have a new question, see the program:
%D0%B8%D0%B7%D0%BE%D0%B1%D1%80%D0%B0%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5

When I try to work with a variable, see “90 IF HR40001 <> 1 THEN 100 ELSE 120”, nothing happens. But if I change the line to “90 IF 1.11.MB_REG0 <> 1 THEN 100 ELSE 120” everything is OK.
The question is why? After all, I assigned the value of a variable earlier in line 20? Why do I need to re-read the Modbus registers for each operation?

It’s a pity that I did not find this in the instructions, this would speed up the development process :slight_smile:

Colleagues, another question: I’m trying to read MODBUS INPUT REGISTERS using a command from Chelsea, but to no avail. The MB_IN_REG command is not perceived as correct and is displayed in gray, see screenshot:

Sorry, keywords are fixed agian. We should add it to document soon.
MB_COIL → 01/05
MB_DISINPUT → 02
MB_INPUTREG → 04
MB_REG → 03/06

Hi Chelsea,
Now I was able to read the value of INPUT REGISTER, thanks for your help. I’ll understand further.
But my question on reading the assigned values of the Modbus variables remained unanswered, see the post above.

Colleagues, I have a question: the program that I use to emulate several Modbus Slave devices generates errors when receiving packets from the T3 controller: “Invalid function code 0” and “Invalid CRC”. I guess that is not maintained interval of silence, at least 3.5 characters at the beginning of the message and 3.5 characters at the end. Please check their availability and reply to this message. Thank.

Colleagues,
unfortunately, I still have not received answers from you to my questions.
And since my T3 controller polls Modbus variables with errors that I wrote above, I decided to try to query one variable and introduce a 10 second delay between polls.
What came of this, look at the video: https://youtu.be/yBKmrRPqymk
The question is, why is this happening? Why are requests executed without delay?

One more question, please tell me, can we use a maximum of 128 variables in the T3-LB controller or more? I mean the number of variables that will be visible in BACnet.

I am not at my desk just now but I believe you are correct, 128 is the maximum for now.

Maurice Duteau

The polling is added to a pool of network points which automatically get refreshed by the network points task. there is no manual control over the polling rate. Yet.

I see that this could be useful and we’ll be looking at letting you control the polling rate by program control soon.

Maurice Duteau

Greetings!
I have a new question: I get Modbus temperature value with a sign. When the temperature is greater than zero, the controller displays it correctly, but when the temperature is negative, the controller displays it in the form “65526”. I guess this is a conversion problem. Please tell me, how I can write in the program that the value of the Modbus variable should be signed?

Default value is unsigned, so have to ask customer conver it if the value is negative.
10 VAR1 = 65526
20 IF VAR1 > 32768 THEN VAR1 = VAR1 - 65536

Hi @chelsea, thanks for the answer, I succeeded.

Unfortunately, you did not answer my question about pauses in Modbus requests. I see that polling by the controller is unstable and this is bad. You probably don’t suspect this, because usually Modbus Slave devices do not display read errors. I see these errors in the emulator program, see video: https://youtu.be/H3B0p6gX5Pw
I don’t see your code in which the controller generates a request, but I believe that in the controller’s request the pauses equal to 3.5 characters required by the Modbus standard are not met.
See below for an example of Python code in which these pauses are implemented:

    # Sleep to make sure 3.5 character times have passed
    minimum_silent_period = _calculate_minimum_silent_period(self.serial.baudrate)
    time_since_read = _now() - _latest_read_times.get(self.serial.port, 0)

    if time_since_read < minimum_silent_period:
        sleep_time = minimum_silent_period - time_since_read

        if self.debug:
            template = (
                "Sleeping {:.2f} ms before sending. "
                + "Minimum silent period: {:.2f} ms, time since read: {:.2f} ms."
            )
            text = template.format(
                sleep_time * _SECONDS_TO_MILLISECONDS,
                minimum_silent_period * _SECONDS_TO_MILLISECONDS,
                time_since_read * _SECONDS_TO_MILLISECONDS,
            )
            self._print_debug(text)

        time.sleep(sleep_time)


    def _calculate_minimum_silent_period(baudrate):
        """Calculate the silent period length between messages.
        It should correspond to the time to send 3.5 characters.
        Args:
            baudrate (numerical): The baudrate for the serial port
        Returns:
            The number of seconds (float) that should pass between each message on the bus.
        Raises:
            ValueError, TypeError.
        """
        # Avoid division by zero
        _check_numerical(baudrate, minvalue=1, description="baudrate")

        BITTIMES_PER_CHARACTERTIME = 11
        MINIMUM_SILENT_CHARACTERTIMES = 3.5
        MINIMUM_SILENT_TIME_SECONDS = 0.00175  # See Modbus standard

        bittime = 1 / float(baudrate)
        return max(
            bittime * BITTIMES_PER_CHARACTERTIME * MINIMUM_SILENT_CHARACTERTIMES,
            MINIMUM_SILENT_TIME_SECONDS,
        )

I await your reply!

Hello!
@chelsea, @maurice, I’m sorry, but I’m used to that when asking questions they have to answer.
Please tell me, do not you think so? Or do you intentionally ignore my question and believe that the problem does not exist?
I got a few more questions on less significant issues than stability on Modbus, but I can’t ask you them until I get an answer from you to an already asked question.

Hi @maurice,
I wrote all in detail in the message:
https://forums.temcocontrols.com/t/temco-plc-as-modbus-master/566/10?u=aleksei
and added in the message:
https://forums.temcocontrols.com/t/temco-plc-as-modbus-master/566/17?u=aleksei

UPD:
Probably the reason for the unstable operation of Modbus is not so much in the pause between requests, but in the structure of the requests themselves. Watch the video: Temco Modbus Polling Problem - YouTube
I made the same request to the Modbus register from the “Modbus Poll” program and from the T3-LB controller. Requests from the Temco controller come in torn form, unlike requests from Modbus Poll. Do you see this problem? Please tell me, can it be solved programmatically or is it a hardware problem?

There is a modbus delay parameter in some of our products, please check around in the T3000 user interface for it, advanced parameters tab. If its not in there for the T3-LB we can add it. I have asked one of the team to check on this as well.

@maurice , there is no such parameter in the settings.

All right, I will ask one of the team to add the modbus delay parameter to the T3-LB series

Hi @maurice,
today I did an experiment with one of my WAGO controllers and set up a poll of one Modbus register on TCP on it and similarly set up a poll on T3-LB, look what came of it: Temco T3-LB Modbus Polling Problem - YouTube
You see that the problem of T3-LB is not only in the pause between requests, but in a chaotic data stream. Is it fixable programmatically? If so, how long will it take?

Would you mind to use wireshark and send on the capture of this same test. We can work better from that than the movie.