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.

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?

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

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

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?

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?

It is working with this package. Thank you very much.

Hello maxvoxel8, could you please provide some information regarding this debian package for USB-to-serial converters. I am currenty facing the same issue. Best regards, Christopher

Hi, I am working with an CK3E ARM PowerPMAC running FW 2.5.4.0. For integrating our own custom service, I was trying to use init.d for running the service at startup. Unfortunately, when running update-rc.d the whole init.d structure gets messed up. After that, a lot of services get started, that bring error messages in the console (samba, winbnd, etc.). Event if I don't add a new service on a plane .vhd image, I get these error messages during boot after simply running update-rc.d. Additionally there are more services starting than before running update-rc.d. So my question is: Why is update-rc.d messing up the startup sequence and how can I fix that? How can I add a new service to the startup procedure without using update-rc.d? Best, Christopher