Infi 90 modbus communication
Hello,
With MFP02 processor through MFP INTERFACE communication module printer port we read/write data to Rotork Pakscan controller to manipulate valves. There is a part of program C which not documented. Please see picture. Time after time some registers are not readed. Maybe somebody had similar problem or have more experience, because for now I don't know where to look for a problem.
With MFP02 processor through MFP INTERFACE communication module printer port we read/write data to Rotork Pakscan controller to manipulate valves. There is a part of program C which not documented. Please see picture. Time after time some registers are not readed. Maybe somebody had similar problem or have more experience, because for now I don't know where to look for a problem.
Answers
This question has not yet been answered.
by Alan Rank: 16 on 5/15/2020 5:20:17 AM | Like (1) | Report
Hi Tomas,
I don't recognize the interface at all so can't help on that front. However, assuming that the interface worked at some stage in it's life it would also be reasonable to initially infer that something has changed external to the interface rather than within the interface code itself.
Have the registers that are not being read worked in the past or have they never worked?
Are these registers random or do they relate to a specific device or function?
Are these registers failed all of the time or does the fault come and go?
Does the MFP side or the Pakscan side of the interface have an diagnostic log that could be interrogated?
Could some of the function blocks associated with the interface have been deleted?
Can you create or edit the data file?
What about using Wireshark or similar to monitor the data lines. Wireshark can be set to trap any exception codes issued by the Pakscan controller and it might point to the problem.
Good luck,
Alan
by
The registers worked in past.
Unreaded registers are random.
The register are not readed one or two cycles.
On MFP side I can see timeouts and in Pakscan CRC errors.
Whitch data file?
I dont have much experience with wireshark in such things.
by Alan Rank: 16 on 5/20/2020 7:00:29 AM | Like (0) | Report
Hi Tomas,
If the Pakscan is reporting CRC errors that could indicate a possible random corruption of data or both devices are randomly talking at the same time, which is a no-no for modbus. What is the communications protocol between the MFP and the Pakscan, RS232, RSR422 or RS485? Is the link point to point or via converters, repeaters or isolators? A power supply problem at either end might be causing noise and improper screening may not help either. Do you have communications contractor you could lean on to inspect the installation and perform some diagnostics.
From the CLD it looks like there is a data file that contains the configuration for the interface. If the failures are random the datafile doesn't matter greatly, although without the data file no modifications are possible.
I am not suggesting that you replace the MFP02 and interface to solve the problem but do you have a disaster recovery plan for the interface, that is, can you replace the interface if the MFP fails during fault finding or even at some later stage? At a minimum it sounds like you would need a current NBS backup as well as the function code config file and MFPs with the same firmware revision as the units in service. A C program from an MFP cannot be used with the later controllers without recompiling for the newer processors.
There is still a reasonable market for second hand MFPs but that approach would need to fit with your plant's support policy. There are obviously still current Modbus RTU products still available (Symphony GPI) for the BRC410 but this would require some engineering.
Alan
by
Hi Alan,
The communication between MFP and Pakscan is RS-232 without converters. We have four sets of MFP and Pakscan. Valves is for railcars loading/unloading. The problem in communication is in three of four sets. I replaced MFP and Pakscan station and a RS-232 cable , but it didn’t helped. If I will not find any solution I am thinking to test Symphony GPI.
Thank you a lot for advice
by Alan Rank: 16 on 5/22/2020 4:49:31 AM | Like (0) | Report
Hi Tomas,
I'm probably not telling you anything you don't already know but one of the secrets to fault finding is to prove a component healthy or otherwise beyond doubt. It sounds like you have lots of components that are not proven one way or the other. Are you saying that you have 4 railcar loading facilities and 3 are playing up or 1 facility with lots of spares? Can you set up some of the equipment in a workshop and test operation that way. In addition you could use a pc based modbus simulator to remove either the MFP or the Pakscan from the equation. As far as replacing components go, have you replaced the NTMP01, they are very reliable but are still an active component. There are also several jumpers on the NTMP01 that can set to incorrectly configure the ground connection. Having a plan to move to Symphony GPI is a smart move but if the problem is external to the MFP you will be no better off. The Symphony GPI still uses the same NTMP01 and cable.
Alan
by Riley McKernan Rank: 1499 on 6/17/2020 7:47:30 AM | Like (0) | Report
Just like GPI and HGS, many of those old custom interfaces would generate a log file.
For example, with GPI you could go to the module in Composer - R Click the module, RunTime - View Files.
File #1 is a log file that gets generated when the InvokeC block is first run. File 2 is the mapping and the 32xxx files are system files. You could R Click and save as File 1 and view it with Notepad.
If such a file is available in the custom app there may be clues to the problems.
Add new comment