- This topic has 14 replies, 1 participant and was last updated 2 years, 4 months ago da
.
-
Post
-
I would need to communicate with 4 inverter schneider ATV12 to give it some basic command, start direction, speed reference, and take some other basic data, absorption, frequency, alarms.
The communication of the ATV12 is modbus in RS485, I use one SlimLine CPU compact ethernet, which has a TCP / IP port and an RS232 port, I took a look on the forum and I don't know if I understood correctly, but there might be the possibility of having a TCP / IP converter -> Modbus RS485 directly to SlimLine using various FBs? Did I understand correctly or am I completely off the track?
In any other way I could still use the RS232 port of the CPU but at this point I would have to put a converter right?
For information, I already use the TCP / IP connection of the SlimLine to communicate with a weintek HMI panel and a router.
The system SlimLine can do both as a TCP / Serial converter (Topic) as a Modbus TCP / Modbus RTU converter (Topic) but these two features are not needed in your case. As far as I understand you want to manage the inverter from a PLC program.
To do this you only need to instantiate an FB ModbusMaster and manage commands to inverters (You can refer to this topical). Of course it was better to use a MPS054A1 * 0 CPU module that already has the isolated RS485 serial port, but if you have the compact model in the range of converters Serial / Serial you can find the converter that's right for you.
Regarding the TCP connection you can use it to connect with anything you want, the only limits are given by the amount of sockets that the system can manage (currently 32) and by the use of relocatable memory RMalloc. Each socket uses the amount of memory defined in its creation.
Thanks for the clarifications, I still have a question, to be able to manage all 4 inverters I would need 4 serial / serial converters? Or is one enough?
In case one is enough, how should they be connected?
The main characteristic of the Modbus protocol is precisely that of being able to operate in multidrop, that is, to have a master system that on a two-wire connection dialogues with one or more slave systems, each slave system will have its own address (Defined Modbus node).
So in your case you will have to set a different address (Modbus Node) for each inverter and then you can talk to everyone with just one RS485 serial line. The connection is simply in parallel, the two wires are paralleled on all devices (see this application note).
Perfect, very kind as usual. Last question :) instead using an RS485 / ethernet tcp / ip converter and connecting the inverters in tcp / ip to theelsist could I have the advantage of being able to directly access the inverters perhaps via easyaccess? so maybe it would be possible to change the parameters at a distance?
A bit of confusion… First of all, if you use a converter Ethernet / Serial to communicate with the inverters and if you want to access it from the HMI via EasyAccess you have to "unhook" it from SlimLine, otherwise the ModbusMaster of the SlimLine it takes care of communication.
Much, but much, much better is using the delo serial port SlimLine to dialogue with the inveter, then go on to SlimLine a TCP server on a TCP port (Let's assume the 1000 port). When you connect from Ethernet to the 1000 port of the SlimLine (You can do it using EasyAccess), from the program you can disable the ModbusMB FB and enable the FB DataStreamExch or ModbusTCPGateway to route data from the Ethernet connection to the serial port to which the inverters (Forum).
I am using the Modbus Master FB with excellent results to communicate with 5 inverters. But in an apparently random way the FB reports me an error that spying on it with Toolly is 10007506, if I have not misunderstood it indicates an error in receiving data, however this error does not interrupt the communication, which continues without problems. The error comes out at random a little on all inverters more or less every 2/4 minutes, here is the report of the spy console
03:23:03 (.310)|Tx|02 03 1C 20 00 01 82 63 03:23:03 (.011)|Rx|02 03 02 00 03:23:03 (.002)|Rx|Error:10007606, On Case:212, Back:51 ... 03:23:05 (.310)|Tx|03 03 1C 20 00 01 83 B2 03:23:05 (.016)|Rx|02 03 02 00 05 01 B7
It is clear that some characters are missing in the answer but I don't understand why. The configuration of Baud rate etc. I would say that it is correct otherwise I think it would never communicate, instead I can control the inverters.
The timeout is 100mS, the delay is 10mS (but even bringing it to higher values 300mS) the problem occurs the same. Some advice ?
As you say and as you can see from the spy report, characters of the answer are lost in the FB ModbusMaster the parameter must be defined IFTime indicating the interframe time. In the RTU protocol the packets are separated by a time that varies according to the baud rate, so it must be set correctly.
If the device that responds for some reason inserts a pause in the response, the FB interprets it as the end of the packet and goes to check it, finding it in error.
The FB ModbusMaster_v1 it has been completely redesigned, the control over the interframe time has been eliminated, the packet is completely sniffed and verified making it independent of the times.
You don't tell me which FB you use, I suggest you switch to version v1 and check its operation, beware that in the transition to v1 we changed the definition d and the timeout and delay times, now they are REAL values expressed in seconds.
Thanks for the quick reply, I wanted to try to update the library with the FB ModbusMaster_v1 where can I find it?
Perfect it seems that updating to ModbusMaster_v1 the problem is gone.
Always very helpful and helpful as always!
Wandering in the forum I came to know about this FB ACModbus, considering that in certain instruments I use your systems to communicate via Modbus RS485 with 5 Inverters, I would like to have some more info on this FB that I presume was born recently.
If I have not misunderstood it is "convenient" to use it when you need to read non-consecutive registers on multiple devices, correct?
How does communication improve? Could the use of this FB improve communication performance and therefore also speed?
Thanks for the explanations
As you rightly said the FB ACModbus, Array command Modbus, was created precisely to facilitate communication with Modbus devices by allowing you to define the commands to be executed through an array of type structures ACMODBUS_DATA.
The use of the FB certainly simplifies the writing of programs as it deals with all the scheduling operations of the commands, optimizing the passage from one command to another, with the aim of obtaining the best possible performance.
But if whoever wrote a program in ST using the FB ModbusMaster by appropriately scheduling the commands it has already implemented all the possible strategies to minimize the times it has already obtained maximum performance and therefore also the FB ACModbus will not be able to do more.
I don't know what version of the library you have, but if you download the latest version from the site, you will surely find the Modbus master management FB.
Now it's called ModbusMaster_v1, whoever is familiar with our libraries knows that every time the I / O parameters are changed in a library object (Function or FB) the name of the object is also changed by adding a version, as in this case "_v1".
If a previous ModbuMaster object has been used in an old project, it can be recovered from the library eLLabObsoleteLib.
It goes without saying that in case of revision of an old project it would still be better to always use the latest versions available.
- You must be logged in to reply to this topic.