- This topic has 14 replies, 6 participants and was last updated 3 years, 4 months ago da
.
-
Post
-
With reference to the ModbusMaster block, in the IEC 61131-3 LogicLab Programming manual, the error codes that can be captured through the SysGetLastError function are mentioned. In particular, the errors during the reception of the response frame to the messages transmitted by the master which are indicated as 10007500 ~ 7 (ie from 0 to 7) but without associating the various cases. In my particular case I get the error 10007505 but I don't understand what condition it refers to (wrong character, wrong length, CRC, etc ..).
From what I understand from reading the manual, every time a read / write cycle is performed, at the end of the cycle the “Done” output is raised whether the action is successful or otherwise. However, it is possible to have indications in this sense by means of the values assumed by the “Ok” and “Fault” outputs. But in case the cycle fails, is the next read / write attempt performed directly by the ModbusMaster block or is it necessary to perform a new switching of the Enable input?
If the same memory area must always be read in a single slave keeping the "Enable" input always active, the read cycles are performed directly by the ModbusMaster block or alternating the Enable input must always be implemented to activate the several cycles?
In fact, we have not reported all the errors, generally indicating that the error is in the transmission or reception of the packet also because many times the error gives an incorrect indication of what the problem actually is. In your case, error 10007505 indicates either receiving a response from a different node ID or receiving a function code other than the one requested. The best way to understand where the problem lies is to activate espionage (Topic).
As far as consecutive reading is concerned, the output of Done denied on entry Enable, possibly defining a time of Delay if you want to interpose a time between commands. The FB has been designed to allow cascade and this topic let's deal with the topic.
The answer to your last question is implied in the previous answer.
I'm trying to configure a NetlogIII for the communication in modbus RTU with an ABB ACS580 drive connected on the RS485 fieldbus. In LogicLab I used the Sysfopen and ModBusMaster blocks. The first question is about the numbering of the ports, I could not find information on the manuals, the fieldbus corresponds to COM2, correct?
Once the program has been loaded, the inverter confirms that the connection is ok, no error and indicates that it is receiving and sending data on the modbus correctly while on the PLC the SysGetLastError variable gives me the error 10007506 and from the Toolly telnet console I display the “Answer frame too long” error.
I am trying to read a 16bit word on a memory register. I double-checked the cables, polarity, speed and parity bit of the bus on the two devices and everything is correct. There are no other devices on the bus, the termination resistor is active on both the Drive and the PLC, while the bias is also active on the drive.
On XTarget_12 (From firmware SFW184B000) the FB was created to open the serial port SysSerialPort which allows, in addition to opening, also to set the communication parameters. Although it is correct to use the Sysfopen I suggest you to use the new FB (If necessary, upgrade the firmware on the NetlogIII, See FAQ). The door Fieldbus is the COM2 port, the error 10007506 that you see as reported in the manual refers to an error in reception.10007500~7 Errore in ricezione frame risposta (Carattere errato, lunghezza errata, CRC).Now you tell me that in Telnet with Toolly you see “Answer frame too long”, so it means that you have activated it SpyOn and you are spying on the modbus communication to the drive. Then both the sent request frame and the received response frame are displayed, if you check these frames following the Modbus specification you will probably see that a certain number of registers were requested in the request and that more data was received in the response than expected. Why this happens, I should see the spying report on Toolly, but in general, you are sure you have set the communication mode correctly (Baud rate, parity, bits), you are sure you are using the right reading code and using the right register address (Remember the offset of 1). The ModbusMaster FB says: "According to the modbus specifications the address sent in the data frame is (Address-1)” This is because who is Modbus compliant adds 1 to the received address, but many devices they don't add up, so you have to add 1 to the value of Address passed to the FB. If you send me a printscreen of the Toolly screen maybe I can be more precise.
Meanwhile, thanks for the fast and complete response, exceptional support!
As soon as I can do a test with the SysSerialPort block, I actually had some doubts about the difference between the two blocks. On Toolly's console I see that the package sent and received coincide:| Tx | 02 04 9 44 00 01 5F BC
| Rx | 02 04 9 44 00 01 5F BC
| Er | Answer too longModBusMaster: Type: 0; Node: 2; FCode: 16 # 03; Address: 40005, Points: 1; IFTime: 286; Timeout: 500; Delay: 1000.
(I apologize but I couldn't find how to attach images to the forum ...)The address is not a problem because I have a series of adjacent registers so at most I should read a data different from the one desired.
Thanks for the compliments ... today a bridge day and then without phone calls you have more time for the forum. The modbus frame sent does not return to me. node is 02, but function code is 04 not 03 as you say you have set. The register address as you see is 9C44 which corresponds to 40004 (Address set -1), ask for a register 00 01 and the CRC is 5FBC.
But the answer is wrong, it doesn't have to coincide with the request at all, it would seem an echo made by the drive which absolutely must not happen, because the FB expects the answer which should be of the type 02 04 02 xx xx CRC. That is, you asked for a register and the drive replies with 02 bytes followed by their value and the CRC.
You can try to spy with an RS485 port in parallel on the communication line to see if after the request frame there is an echo frame and then actually the response frame. After the first frame received, the FB checks it and if in error it aborts waiting for the next command and therefore does not show you the possible correct frame that follows.
The reason for the error is evident, 7 bytes of response are expected and instead 8 are received.
I performed the test with the FB SysSerialPort but without success. The Drive tells me that there is no activity on the Bus and it does not exchange data, while on the PLC the ModBusMaster FB gives me error 10007010.
If instead I try again with the Sysfopen I get the packet exchange back with the error already highlighted. I have also checked on the drive manual if there is the possibility of an echo answer but I have not found a trace so I cannot explain the answer. I also tried again by lowering the bus speed to 9600 but without success, the cable is not the top but considering that it is not even 2m long I don't think there are any interference problems.
Does the error indicate that the File value is not defined, but have you passed the Output File value from the SysSerialPort FB to the ModbusMaster FB? On such short lengths the cable normally has no problems, now to understand the problem the only one is to spy communication on RS485 or send Modbus commands from Toolly (See the last post of this topic) or with a Modbus simulation program for example the best Modbus Master Simulator.
I have a problem with Toolly in practice after authentication to the SpyData command it replies that it is not active. Yet I have configured the SpyOn of the ModbusMaster FB to TRUE, why? Where am I wrong?
Is the ModbusMaster FB executed ?, in which task did you put the execution I remember that it must exist in the Back task.
Is the File parameter correctly set, does it refer to a valid FILEP?Ok Thanks, it was the location of the program that was not in Back. Now I see the data sent and received ...
I am experimenting with the use of the ModbusMaster FB without success. I have an object that accepts Modbus TCP communications. The connection to the object is successful, the Outgoing file parameter is not NULL. Using the Modbus Master Simulator program recommended another post ... it reads me the data correctly.
I set the parameters in the TCP and Modbus Master connection FB in the same way as in the simulation program. I get error 10007506: I guess I have incorrectly defined the data and how many registers to read ... can it be?
The data I'm trying to read is a value in the 5 number register defined as 32 bit integer (it's a temperature).
I define a DINT variable in LogicLab, I define the other parameters, the address minus one, so I give it 4, but I always get that error. I tried to define the variable in a different way (INT, USINT, etc ...) but nothing.
I know I'm making a trivial mistake because the object communicates in modbus, but I don't understand where I'm wrong.
Use espionage is the solution that allows you to understand where you are wrong. We talk about it first in this post or if you are looking for you will find many topics that talk about the spy console (article).
I take this post again to understand the difference of 10007500-7 type errors. I'll explain. I have one SlimLine Cortex M7 [MPS054B110], through a TCP / IP connection I query a modBus device which returns 8 BYTEs to me on 4 different addresses each to compose float (REAL) values. The request occurs continuously and it happens to me in an absolutely random way (I have checked everything: time, contemporaneity with other functions, etc.) that after 2-3 days or after 5, the communication is interrupted generating the error 10007505.
The only way to restart communication is to reboot the SlimLine. Thinking it could be a problem with the device, I connected a PC to the device itself and with a small program in Python I monitored it for 2 consecutive weeks but the communication never stopped. In detail, what does this error mean in addition to the generic "Error receiving response frame (Wrong character, wrong length, CRC)" ?. Can you think of any other tests to carry out?
The error you mention appears if you miss characters in the response string, it could be a problem similar to the one reported in the last posts of this topic. Useful to understand the problem would be to have a spy report of communication with Toolly.
Because it works for a while and then freezes is very strange, of course using the ModbusMaster FB that uses the IFTime to split the modbus packets, it is enough for the slave device for some reason to fragment the response on multiple TCP packets that this could generate the problem.
As recommended in the topic I linked to you, I suggest you replace the Modbus management FB with the new version ModbusMaster_v1 which has been completely redesigned, eliminating the control over the interframe time, the packet is completely sniffed and verified making it independent of the times.
- You must be logged in to reply to this topic.