GE 90-30 Mailbox Full

I have a GE 9030 that stops communications on COM2 with a Fault of Mailbox Queue full. COM1 continues communicating. Any suggestions?

What device is displaying this fault? Is this COM2 on a PCM module or a CMM311 module? Has it been working properly and suddenly stopped?

My first impression is that you are getting the fault because requests for data are occurring faster than they can be processed. What I can't say from the information provided is whether the PLC is the source of the requests or whether they come from some external device.

It is a CMM311. COM2 is getting some analog inputs through a radio serial connection from a Versamax PLC. It has worked for a long while.

The ports on a CMM311 can be master or slave. If configured as a master, look for COMMREQ instructions to troubleshoot the communications transactions. There are diagnostics included with the COMMREQ instruction that could point you to the source of the problem. COMREQ instructions should be triggered by one-shots. Ideally the logic should not execute a second COMMREQ before successfully completing the transaction initiated by the first, but it is possible to do so.
If configured as a slave, there may not be enough time to respond to a request for data before another request comes in. When that happens, eventually a queue will overflow.

Reasons why you are getting errors now when it has worked for years: If there have been recent program changes to either PLC, the changes may have reduced the time available for external communications. There could be an increase in noise on the serial line due or interference with the radio signal to the installation of some new equipment.

Where do I find these Diagnostics.....It is running on a 1 shot.....can it be slowed down?

Where do I find these Diagnostics

Click to expand...

The manual GFK0582 gives details about 90-30 serial communications. The COMMREQ status word, defined in the third and fourth words of the setup for the COMMREQ instruction will return the error codes associated with the transaction.

can it be slowed down

Click to expand...

If the logic clears the COMMREQ status word before executing one and then waits for a change in its value before sending another, it should be as slow as it needs to be. If, instead, it sends the next COOMREQ after a fixed time period it can be slowed down further.
If you have a copy of the logic, post it here and I'll take a look at it and give you an idea of how it works. If your company frowns on posting your code to a public forum, send me a PM and I'll give you my email address.

NOCON C4Att,G,%M00062; BLKMOV_INT 7 0 8 921 0 0 7200 CMMPort2Config1,G,%R00925; H_WIRE; H_WIRE; BLKMOV_INT 19536 24387 13379 0 0 0 0 CMMPort2Config8,G,%R00932;


Not quite the ladder but it is a NOCON followed by a BLKMOV w/ 7 INT followed by Register and then another BLKMOV w/ 7 INT followed by the Register.

That's the "Attach" command that initially establishes a communications link. There should be another similar pair of BLKMOVE instructions ahead of another COMMREQ.
Each BLKMOVE instruction loads values into seven consecutive %R addresses, In this case %R925 - %R931 for the first BLKMOVE and %R932 - %R938 for the second BLKMOVE.
The value of 7 at IN1 defines the size of the data block (7 words).
The value of zero at IN2 commands the COMMREQ be executed in NOWAIT mode, which means that ladder logic execution can continue without waiting for the COMMREQ to be executed.
The second and third elements of the first BLKMOVE define the COMMREQ status word. The value of 8 at IN3 denotes %R memory and the value of 921 at IN4 denotes an offset of 921. The two elements combined denote %R922 as the address of the COMMREQ status word.
The value of zero at IN5 and IN6 are not used for this command.
The data block defined by the value at IN1 starts at IN7 and continues to IN1 - IN6 of the second BLKMOVE.
The value of 7200 at IN7 is the command code, in this case "Attach".
The values in IN1 - IN3 of the second BLKMOVE are packed ASCII data, two characters per %R address with the SNP ID of the target device.
The value of zero represents the last two characters of the SNP ID. In this case only six characters are used.
Values at IN5 and IN6 are optional.
IN7 is not used for this command.

I can get the other BLKMOVs in the AM, and I greatly thank you for your explanation, obviously I am new to this but it does make sense. And the manual was helpful as well, as you may know with GE it can be hard to find the correct information, and GE is all I am tasked with.

Does the NOWAIT have anything to do with the Mailbox Full?

I forgot to add that Power Cycling the PLC (Clearing the RAM) fixes this problem for a while.

Does the NOWAIT have anything to do with the Mailbox Full?

Click to expand...

I don't think you can select anything other than NOWAIT. That is, the COMMREQ will execute in NOWAIT mode regardless of what you enter. Either that or you would get an error indicating that the COMMREQ instruction could not be processed. WAIT mode means that the PLC has to suspend execution of the ladder logic while the COMMREQ instruction is processed.

I forgot to add that Power Cycling the PLC (Clearing the RAM) fixes this problem for a while.

Click to expand...

That makes sense. Cycling power should clear the queue. It will take a little time before it overflows again.

While I am trying to learn the process, which you have helped with, I guess I forgot our original question....Is it possible to empty this mailbox with code, and not power cycling.

Better to prevent the overflow from happening in the first place.

There are two COMMREQ codes, 7000 to clear and 7001 to read the CMM module's diagnostic status words. I'm not sure if clearing will also empty the queue. There is also a code which will do the same thing as pushing the white reset button on the CMM311 module which I will have to look up. It isn't listed in the GFK0582.

Edit: Details of the hard and soft reset COMMREQs are in appendix B of the manual GFK0255, which is the manual for the PCM module. The PCM is the same hardware as the CMM module, just a different firmware chip which includes the MegaBasic interpreter. I guess you would have to execute a COMMREQ to read the fault table entry to see if there is a CMM module fault and if so, execute the reset COMMREQ.

If this is an issue brought on by an increased scan because of logic edits then this may help.
Some CPU's have a setting in their hardware configuration to extend the "Communications Window" the CPU uses during its Sweep.

Regarding your question about resetting programmatically. I came across this note on page 8 of GFK0582C.

If the MODULE OK LED is off (hardware malfunction) the Restart/Reset pushbutton is inoperative; power must be cycled to the entire PLC for CMM operation to resume.

Click to expand...

I don't think this is the case in your situation because I expect a CMM311 hardware problem would have entered a "Loss of Module" fault in the PLC's fault table.

So I pushed the reset button and that brought back COM2 but appeared to kick COM1.