In our production we use several pumps with frequency drives, so we used FbDrive and MotSpdCL blocks in the control chart for each pump.

Operators are now able to control pumps and change speed setpoints after compiling and loading AS and OS. There are no active alarms in the running pump faceplate. See attachment.

The problem is that the motor block indicates "PLC Process Control Failure" alarm state with black background of the current speed value and a black symbol "S". I can not understand how this state of the MotSpdCL block is formed or where it comes from. The status bytes of all incoming signals have a value of 16#80, all output bit statuses are normal. This state cannot be reset or acknowledged.

EventState tags inside MotSpdCL structure on the server have 16#0200FFFF value for all pumps.

I need your help or advice on how to fix this.

Hello,

The symbol 'S' (system error) usually symbolizes one or combination of the following:

• potential external process control error (CSF) which could arise from an external device or hardware faults (realized by the error connection at the input parameter CSF of the block)
• Process specific errors such as runtime monitoring or feedback monitoring. (Lesser probability in your case)

Considering the error message is "PLC Process Control Failure" could be related to:

The error propagation could happen from the connected FbDrive block which needs to be investigated further. (tough to conclude with the current screenshot/information). However, I hope these inputs give you a direction to troubleshoot your issue.

You can also refer the 'Error handling' section 2.1.6 in the manual linked here (you can also refer FbDrive's error handling from the manual) -> APL 9.0 SP3 Manual

 Hello and thanks for the answer.

TechnoBlaze

The symbol 'S' (system error) usually symbolizes one or combination of the following:

• potential external process control error (CSF) which could arise from an external device or hardware faults (realized by the error connection at the input parameter CSF of the block)
• Process specific errors such as runtime monitoring or feedback monitoring. (Lesser probability in your case)

Considering the error message is "PLC Process Control Failure" could be related to:

● Module errors (only for hardware controllers)

● I/O access errors (only for hardware controllers)

● Parameter assignment errors (only for hardware controllers)

The error propagation could happen from the connected FbDrive block which needs to be investigated further. (tough to conclude with the current screenshot/information). However, I hope these inputs give you a direction to troubleshoot your issue.

Checked. There is no CSF signal at MotSpdCL input.

It has nothing to do with feedback monitoring because there is an issue in any state of the motor. Anyway, I can try to switch off all Fbk monitoring functions for a while to be sure.

About FbDrive:

All outputs have 16#80 statuses, as mentioned before. "Bad" output = 0. Please advise on what else to pay attention to?

What additional screenshots and information needed?

For now, I have only one proposal - entirely delete and clean this block from the multi-project, and pull it out again from the APL. But this is an extreme case.

Hi Oreca,

Yes, FbDrive working with SE Altivar 630.

Your proposal with DataXchange1 = 16#04 didn't work.

ExtMsg1 = 0 

ExtMsg2 = 0

ExtMsg3 = 0

Trip = 1 (The need for inversion was verified during commissioning)

RbkWH_Lim = 90

RbkWL_Lim = 10

But,

RbkWH_En = 0

RbkWH_MsgEn = 0

RbkWL_En = 0

RbkWL_MsgEn = 0

Oreca

Hi,

I cannot see any error in your print screen, only one thing which you can try:

- Insert an Or04 block and connect its output to: ATV_In_Out.On. The input of the Or04 should be connected to: M.Fwd and M.Rev. 

Download and check if this works...  

Sorry, but this makes no sense in my case.

ATV configured for 3-wire (3C) control. So it must have 1 in bit0 (On) of the command word in normal mode and 0 for the stop. Start command is given with a positive edge on bit 1 (NoCoastSt).

https://www.se.com/ww/en/faqs/FA238669/

Yes, one of these reasons is quite probable.

GSD file obtained from Schneider Electric website. But the Altivar doesn't support either 1 or 20 telegrams and its control word bits are not exactly the same as in the FbDrive block. My tests over the past week confirm that the PLC Process Control Fault comes from it.

Well, this information needs to be discussed with our VFD specialists. The situation looks like FbDrive can work normally only in a 2-wire scheme when On input can be used for Switch On command only. it is necessary to clarify whether we can switch back to a standard scheme...

One question left without an answer. How does the EventState tag on the server get its value?

Why EventState tag on OS Server set to 33 619 967 (0x0200FFFF)?

For example, for the HE19-GP02B pump, we can see that the MotSpdCL block used the DB637 instance.

EventState tag on OS Server has DB637.DBD0 address. But the same address in the PLC has a different value.

I can't understand where the value comes from on the OS Server? Okay, I know that the first four bytes in the DB instance are occupied by FwdAut.Value, FwdAut.ST, StopAut.Value and StopAut.ST tags. Why EventState has an incorrect address but nevertheless get the value from somewhere?

I really need to know who and from where the 25th bit set up.