- This topic has 9 replies, 3 participants and was last updated 10 years, 12 months ago da
.
-
Post
-
I purchased some distributed Trycom I / O modules, I wanted to use them to build a home automation system. In practice I would like to connect the switches to the 16 digital inputs of the TRPC26 module, while to the 16 outputs of the TRPC24 module I would like to connect the user control outputs (Lamps, appliances, etc.).
I was thinking of using your CPU SLine module for the logical management of the plant, is it possible to manage these I / O modules distributed via the Modbus protocol from your CPU?
The module TRPC26 use the modbus command 01 Read Coil Status for reading the status of the 16 digital inputs, while the module TRPC24 use the modbus command 15 Force Multiple Coils for writing 16 digital outputs. Using the ModbusRTUMaster function block (Manual extract), it is possible to read the inputs from the TRPC26 module and write the outputs to the TRPC24 module.
I created a program on SLine that cyclically reads the 16 inputs of the input module and supports them in 16 BOOL variables (TRPC26Input [0..15]), copies 16 BOOL variables (TRPC24Output [0..15]) on the 16 logic outputs of the output module. The two modules have been connected to the RS485 network, it is necessary to define address 0x01 (Default) to the logic input module, address 0x02 to the logic output module, see post.
In the program you will find a ladder program Logic, which places the DI0 input of the input modules on the DO0 output of the output module. You can add all the logic you need by adding lines to this file and / or adding other programs to the project.
The TRPComm performs cyclical reading and writing of I / O modules, programs InputRead e OuputWrite, they swap the read and write bits to the TRP modules in order to have the BOOL variables ordered according to the I / O on the module. Print program, program download.
Being a home automation system, I recommend you in the files InputRead ed OutputWrite to rename the support variables of distributed I / O using names that are mnemonic for your system.
For the entrances TRPC26Input [0] can become PlsLuceSalone, TRPC26Input [1] can become PlsLuceCucina, etc.
For exits TRPC24Output [0] can become CdoLuceSalone, TRPC24Output [1] can become CdoLuceCucina, etc.I ask for clarification on the example IOOverTRP that successfully tested on different manufacturers of IO modbus.
I am currently performing communication tests with a Siemens S7-200 used as a modbus slave of the connected to SlimLine. The only change I made to be able to read the aforementioned modbus slave was to set FCode= 16 # 03 and set the parameter Address in an appropriate way.
I encountered the situation which can be deduced from figurethat is, the array TRPC26Read it is not valued correctly. Indeed from the window Watch only the least significant bit of the array is correctly evaluated while the% MW100.0 display shows that communication is successful.
We need to understand the difference between FCode 16 01 # (Read coil status) e 16 03 # (Read holding register).
The command 16 01 # reads the status of logical contacts, that is Boolean variables, then reads 16 variables Points = 16, as in my program TRPCom, the 16 consecutive BOOL values of the array are valued TRPC26Read.
The command 16 03 # performs the reading of words (16 bits) of memory, then reading the variable 1 Points = 1 as in your example, only one program USINT variable is evaluated. As you can see the % MW100.0 it is valued with the value 16 # 0005 which is the value present in the Siemens PLC.
If your problem is splitting a USINT variable into 16 BOOL variables, you can use function blocks WordToByte e ByteToBit (Manual extract).
I add a Tip that can be useful to understand the addressing of systems SlimLine. SlimLine is based on an ARM processor that uses data storage in the format little-endian, starts with the least significant byte and ends with the most significant.
So as you can see from the example la % MW100.0 it is valued with the value 16 # 0005, therefore at the location with offset 0 of the array TRPC26Read allocated to the same address of% MW100.0 corresponds LSB of the word value, while to the location with offset 1 corresponds MSB.
Since the value of word 16 is # 0005, its LSB will be different from zero, ie TRUE, while its MSB will be equal to or ie FALSE. If the word value had been 16 # 0101 we would have had both MSB and LSB at TRUE value.
I wanted clarifications regarding the coding used by the SlimLine for REAL data. I have in practice to treat as a real floating point number (32bit) acquired via MODBUS-RTU from a S7-200 plc FCode= 16 # 03 e Points= 2.
From the LogicLab manual the only specification regarding the real type is that it has range -3.4E38 - + 3.4E38 while the format used by the S7-200 is "REAL 32 bit IEEE 32 bit floating point number from + 1,175495E- 38 to + 3,402823E + 38 from -1,175495E-38 to -3,402823E + 38 "
I expected the encoding to be identical but I can't memorize the acquired value in a REAL variable, I attach screenshots, I hope the tests carried out are clear.
The format used for REAL variables is IEEE 754 as mentioned in this post, your screenshots show that it is the same format used by the S7-200. In fact, in this representation format, the REAL 2.0 value is in hexadecimal 16 # 40000000 (As you can see from the debug window on S7-200).
Warning! When reading 32-bit variables via modbus, attention must be paid to the endianness of the data, in fact the modbus protocol does not specify in what order the two 16-bit parts of the 32-bit data must be returned. Therefore it is possible that in some systems the most significant part is returned before the least significant part or vice versa.
Su SlimLine as already mentioned in other posts the little-endian which starts with the least significant byte and ends with the most significant, and from what I see is the same type of representation that Siemens uses in the S7-200 (Probably uses an ARM processor). In fact, if you notice in the% MW100.16 which is the first register read by modbus you will find the least significant part of the number and in the% MW100.18 the most significant part.
So your mistake is only in the reversal of the words in the conversion WordToDouble.
I add a tip, since the representation format of the S7-200 is the same as that of the SlimLine, to have the value in REAL you just need to define a REAL variable at DB100.16 where FB modbus supports the registers read by the S7-200 to be able to use it in your program without having to use the WordToDouble.
MyVariable AT% MD100.16: REAL; {DE: "REAL variable read from S7-200"}
Yes, of course the solution you have proposed is feasible, in this post you can find an example of how to manage from SlimLine I / O modules distributed via Modbus. Once the modules are acquired, you will support I / O on memory variables of the SlimLine accessible by Modbus. The PC can be connected in Ethernet and the status of the inputs acquired via modbus TCP, using for example a SCADA software (See post), an application developed with ProfilabExpert (See post) or an application developed ad Hoc with the programming language you know. If the development of the modbus TCP protocol is too complex you can develop a communication protocol tailored to your needs (See post). If you only need to view the status of the bells, as an alternative to the PC I recommend using a operator panel touch screen that already has the native management of the modbus TCP protocol, furthermore if you want you can manage the buzzer sound and also view the intervention history of the bells. The panel can also manage historical files, allowing you to have a report on the interventions of the bells related to date / time.
- You must be logged in to reply to this topic.