Rotary Buffer Full

[biscchr]

Hello,

I am filling the rotary buffer with calls of the Command() Function of gplib.h. This works just fine until the buffer is full. Instead of returning the expected error 34, the function does not return at all but seems to hang somewhere. I have no possibility to debug this any deeper, since its within the PMAC library. I also tried the GetResponse() function and it shows the very same behaviour.

In addition, if I fill the buffer via the terminal in PowerPMAC IDE while watching the Coord[1].RotStore variable, I can see that it stops increasing as soon as the buffer is full, but no error message is returned. The following line is used to fill the buffer:

&1OPEN ROTARYM5100==45 G1X385.000Y-635.000Z-300.000CLOSE

Is there any special handling necessary when filling the rotary buffer via gplib?

[biscchr]

Hello,

I did some testing with the PowerPMAC IDE only. I am using two terminals, see the screenshot. The left one is for defining and filling the rotary buffer. The right one is just for checking the content of the rotary buffer. As you can see, the last line with M5100==44 was not inserted into the buffer since there is not enough memory left. But no error message was reported. In addition, all further commands in the terminal do not respond (rotfree, vers). As mentioned before, the very same happens with gplib.h functions Command() and GetResponse().

This is tested with firmware 2.7.0.0

What is the cause of this behaviour?

[Gregs]

The following was copied from the Power PMAC Users manual:

Rotary Motion Programs

The rules governing rotary motion program buffers are substantially different from those for the other types of Script program buffers. A pre-determined amount of memory must be reserved for a rotary buffer before any contents are downloaded. Program lines can be entered into the buffer even while the program is executing. When the end of the buffer is reached, the storage of subsequent program lines wraps around to the beginning of the buffer – hence the name “rotary”.

[biscchr]

Hello Gregs,

thank you for your response. The last line with M5100==44 from the left terminal does not show up anywhere in the "list rotary" command from the right terminal, so there is no wraparound visible. In addition, as seen in the screenshot from this post, the Coord[1].RotStore pointer does not wraparound or increment after sending the M5100==44 line. Before the last line its value is 16646121 (left terminal) and after the line its still 16646121 (right terminal, since left one is not responding).

And again, the left terminal does not respond to any input after the buffer is full.

I would be able to handle a wraparound in the buffer as in the User Manual, but I am not able to handle a freezing response from PPMAC and incorrect pointers of Coord[1].RotStore.

Please help finding a solution to this issue.

Best regards,
Christopher

[bradp]

I verified this is a problem using fw 2.7.1.0.  

You are not doing anything wrong that I can see, there seems to be a problem in gpascii or deeper..  I can not fix fw, I can just report the problem.  Since I can not say how long it will take for a fix, if you have a work around I would consider using it.

[bradp]

Greg,

Attached is a video for you to use to recreate the problem.  Please look at this and let us know what we are doing wrong or when we can get a fix for this.

[Gregs]

I believe this is the “expected” PMAC result to a full rotary buffer. The gpascii thread will “process” no more commands until the buffer is freed up. But, PMAC will continue to “queue up” characters into the communication buffer for that thread.

Other threads will work OK. Note that each instance of a “command()” is a separate communication thread.

[biscchr]

Hello Greg,

I can verify that the freezing gpascii thread is responding again after the buffer will be freed up, just as described in your post. Nevertheless, a function (command()) that does not respond for an indefinite time does not seem like an expected behaviour to me and is not manageable for a (regular) software interface.

Our application is expecting a result similar as known from Turbo PMAC, where the error 6 is returned (No room in buffer for command).

As a workaround, we will try to catch incoming rotary buffer commands by checking available buffer size first.

Please let me know if there is any intention to adapt this behaviour to a manageable one e.g. with an error code 34 (buffer full).

Thank you for your support.

Best,
Christopher

[steve.milici]

It depends on what PMAC command is sent with the “command()” function. If you are sending more lines to an already full rotary buffer, then the function will timeout with an error. Your C-code should be evaluating the error response. Any return value less than zero indicates a timeout error. This is documented in the C-API help files.

The rotary buffer in Power PMAC is not like that in Turbo. It has been “simplified” in its usage to avoid the pitfalls of Turbo PMAC. most of the new status structure elements are for debugging purposes only. I would recommend using just the “rotfree” command to determine when the buffer is ready for more lines.

[steve.milici]

One correction.

After talking with the SW developers the “command()” function does not have a “timeout”, so if you are sending more lines to an already full rotary buffer, then the function would stall just like your first gpascii thread above. Only send lines if the “rotfree” command returns enough available bytes.

[biscchr]

Thank you very much for this explanation. It helps a lot.

Since our application was tailored for Turbo PMAC and only handles the reponse of the function, we will need to add this check of available bytes in the buffer.
I wanted to do this using Coord[1].RotExec, Coord[1].RotStore, Coord[1].RotEnd and Coord[1].RotStart but you mentioned, that these should be used for debugging only.
This data would be easily available via the SHM pointer without issuing a rotfree command to PMAC, but I will try using rotfree instead.

I have read in the manuals that a G-Code command like X10 takes about 9 byte in the rotary buffer. Is there any rule of thumb how to calculate from a command length (characters) to the required space in the rotary buffer without parsing the whole string?
For a command like: "M5100==45G1X385.000Y-635.000Z-300.000" RotStore-RotExec=47, so I will use a required space of about 50bytes per line (like this).

Can you also please give me a hint where I can find the C-API help files you mentioned?

[steve.milici]

The “rotfree” command reports the largest available block (in bytes) The “rotfreeall” may report more when close to the end of the buffer. See the descriptions of these on-line commands in the “Power PMAC Software Reference Manual” for further details.

Each data token (X10, F100) uses 9 bytes. The “end-of-line” uses 1 byte. The command line “X10 Y20 Z30” would use “28 = 9*3 + 1” bytes.

The “C-API Help” in the 3.x/4.x series IDE did not “import” properly. See this post to create an external help-file and download the needed files: https://forums.automation.omron.com/topic/10062-looking-for-c-api-documentation-for-getresponse-function/

[biscchr]

After handling the available buffer size using "rotfree", we now recognized that some users still use the "PR" command from TurboPMAC.

Is there a PowerPMAC equivalent to this "PR" command? I cannot find anything in the manuals, except Coord[x].Nsync.

[steve.milici]

There is only the “rotfree” and “rotfreeall” on-line command as previously described in this post.

Note that “Coord[x].Nsync” does not provide any rotary buffer content status. It just reports the “Synchronizing Line Label” number (without colon syntax “N{line-number}”) of the most recently calculated line in any motion program.

Also note that the Turbo PMAC “PR” online command reports the number of lines that have not yet been executed (program remaining) as opposed to the “rotfree” command which reports the number of bytes of available memory in the rotary buffer.