biscchr

Hello MoMo, thank you for your explanation. The behaviour is clear now and by increasing the rotary buffer accordingly, it works as intended. Your reply helped a lot, thank you.

Hello MoMo, this was already checked. The rotary buffer never runs empty.

Hello, we are currently experiencing some unexpected behaviour when using Lookahead on PPMAC with very high blockrates. In fact, we are sending linear 3-axis moves to the rotary buffer with a spacing of 0.1mm due to customer requirements. We have tested this by moving one axis only on a straight line, like this sample G-code shows. This leads to a rate of 0.1mm/(200mm/s)=0.5ms. G90 F200.000 M5100==1 G1 X0.000 Y0.000 Z0.000 M5100==2 G1 X0.100 Y0.000 Z0.000 ... M5100==10000 G1 X999.900 Y0.000 Z0.000 M5100==10001 G1 X1000.000 Y0.000 Z0.000 All three motor settings are the same with vmax=300mm/s and amax=150mm/s^2. According the the PPMAC Usermanual the lookahead should be configured with a SegMoveTime of the blockrate or lower, so we chose 0.2ms to also be safe at fullspeed. TA is also set to 0.2ms and TS is zero. LHDistance is set to 4/3*vmax*1000/(amax*2*SegMoveTime)=6667 segments, the corresponding Buffer is 10240 Bytes. When executing the move, we are getting a lot of fullstops during movement with the LookAheadFlush bit being set. So we increased the spacing to 1mm and kept everything else the same. After increasing the spacing and executing the move, we are still getting (less) fullstops with LookAheadFlush bit being set. However, when setting LHDistance to 5000 everything works at 200mm/s, but then again, if a higher feedrate of 250mm/s is used, the fullstops come back. If we use a even lower LHDistance at 1mm spacing, e.g. 3000, we are not getting the required 200mm/s but about 170mm/s. At least the fullstops are gone. Higher LHDistance than the 5000, e.g. 10000 lead to fullstops. Btw, we are using PPMAC on ARM CK3M, Phase=16kHz, Servo=8kHz, RTI=2kHz. So we are starting to think that there are computational limits at high blockrates. However, I found an old post from Curt Wilson talking about 10000 move blocks per second, so this should be possible. But maybe not on ARM? https://forums.automation.omron.com/topic/5730-unexpected-stop/?do=findComment&comment=24653 Can you please give us a feedback if such computational limits are known? What would be the recommendes lookahead settings for this application? I would appreciate any help regarding this behaviour. Best, Christopher

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