paddax

You are on the money 🙂, the firmware version was 2.3.xxx.

Yes it is using PMAC single step "S" command. It appears to happen in either coordinate system even though there is only a single axis in the second coordinate system.

The manual states The h command is very similar in effect to a %0 command, except that deceleration and subsequent re-acceleration are controlled by Coord[x].FeedHoldSlew, not by Coord[x].TimeBaseSlew. Also, execution can be resumed with an R or S command, instead of a %100 command. In addition h works under external time base, whereas a %0 command does not. I've found to my embarrassment and luckily no one's health that issuing "%100" when halted resumed the program execution. CPU: PowerPC,460EX VERS: 2.4.0.180 The desired functionality is when an event occurs the system should halt until the condition is cleared, the way I've implemented this is to prevent R and S commands during this phase. Is there a simple method of preventing execution in a modal manner.

Previously I could run two IDEs simultaneously from 2 different computers with no impact on performance (IDE ). With the latest software (3.1.1.0) and firmware (2.3.2.5) a second IDE is all but unusable. Is this an issue with the firmware or is the IDE placing too large a burdon on the PPMAC. CPU reports PowerPC,460EX Further investigation (running top) shows that the ssh layer in the PPMAC is the culprit, the gpascii shell is a fraction of the overhead of the ssh communication. Is it possible to change the IDE to use Telnet?

Is there a solution that does not require editing init scripts, this is the sought of thing that will leave my customers confused.

So the answer to the actual question is....

CCDistance and CCSize make no difference as Cutter compensation is working! My problem is tread reports the actual position not the programmed position e.g. T reports the programmed position and the currently active cutter compensation T -> X10:-1 tread reports D6 -> 9 Is there a way to determine the actual programmed position via an equivalent to tread or is the only way to do this issuing a "T" command and interpreting the string

Please reread the question, tread is working but reporting different result to the online command T. The difference is the cutter compensation value. Put another way, if cutter compensation is not used the system works perfectly. T and tread report the same correct values. When cutter compensation is applied the following occurs 1. The program moves through the correct path 2. T reports the programmed target positions 3. tread reports the actual target positions not the programmed target positions From my configuration Coord[0].SegMoveTime=5; // ms #define MaxStoppingTime0 Motor[1].MaxSpeed * Motor[1].InvAmax #define LHSegsNeeded0 MaxStoppingTime0/(2.0 * Coord[0].SegMoveTime) Coord[0].LHDistance=4.0/3.0*LHSegsNeeded0; Coord[0].TPSize=3 + Coord[0].LHDistance; // at least 3, plus the number of lookahead segments Coord[0].TPCoords=$1E6; // Axes X, Y, Z, B, C, W normal is set to 0,0,-1

The functions tread, pread and dread calculate values based on programmed positions but appear to have an error when cutter compensation is active. Given the following program normal I0 J0 K-1 ccr 1 ccmode1 X10 Y10 ; Read value here X-10 Y-10 on line command T reports an X value of 10:-1 tread reports an X value of 9 The manual states these command are equivalent. Our MMI is using tread, pread and dread values and these are not actually reporting the programmed target, position and desired position which is confusing.

I think you missed the point, we're agreed the technology Jog Start=cpx xxxx Jog Stop=[Feedhold] -> Wait for condition -> Abort The question is now what is the best "Wait for condition" so that the following is true. 1. The machine desired position does not deviate from the kinematic path 2. The duration of "wait for condition" is minimised. [FeedHold] May be "%0", "H", "Coord[x].SegOverride=0", this decision has not been taken but my preference is "%0" unless you can give a better reason.

This is where my current development is going, I'm having a bit of trouble with timing as its common for a user to jab the Jog button repeatedly and expect the machine to react. What is the best variable to monitor to know when to issue the abort?

Incremental jog works well using the cpx command however continuous jog presents a different problem. If you set the increments too low the TS value will inhibit feed rate and if its too high it will inevitably quantise the jog requests and therefore not feel natural. At the moment I'm issuing a very large cpx command to move the axis which works fine but my new problem is the only way to stop the cpx is to issue an "abort" which causes the coordinate system to leave the kinematic path. Is there a way to stop a cpx command other than abort?

The only method we have to clear Macro.Status[0].RingError is to perform a $$$. This seems a bit heavy handed. This is in the condition where the PMAC is working but is reporting an historical error such as when a slave is reset.

1.6.1.1

Is it possible to pass an array index to a subroutine e.g. open subprog calculate(PIND, PSIZE) ;PIND is the index to the first "P" element ;PSIZE number of P variables to calculate close global MY_ARRAY(100) call calculate(&MY_ARRAY(0), 100) doesn't seem to work

Thanks for the work-around but I think I'd prefer the bug was verified and if necessary fixed.

Our system has Endat encoders with 100,000 counts per mm, the first three motors are orthogonal linear axis The following command issued from a part program causes the first three motors to move until trigger JOG1..3^1000000^0 If the trigger is found within the specified distance system works as expected however if the trigger is not found motor 1 will stop after exactly 10mm however motor 2 never stops (EOT at 100mm) and Motor 3 stops after 11.5mm Issuing the following command in a part program or Rotary buffer did something entirely unexpected. JOG2,3^1000000^0 Motor 2 stopped after 10mm but motor three moved in a NEGATIVE direction and seemed to be moving indefinately (at least 100mm). Please note that if the trigger is found the axis does stop, even if it is going in the wrong direction. Individually JOGn^1000000^0 the program worked as expected.

Could you update the "Power PMAC User Manual" to reflect this?

Just found the syntax global MY_MATRIX(16) allocates 16 P variables Unfortunately the matrix functions msolve etc. require P variable indexes not the actual P variable expansion, is there a way of getting the starting index of MY_MATRIX The manual states the following global SurfaceNormal(3); global ToolNormal(3); the following command could be used: AngleCosine = sumprod(&SurfaceNormal, &ToolNormal, 3, 1, 1) This syntax doesn't seem to work.

Is there a method of block allocating P variables via the IDE, the global keyword seems to allocate a single P variable above the range 8192 but my application needs to allocate blocks of P variables for use with the matrix library.

PMAC Jog is implemented as a Jog of an axis, is it possible to Jog a kinematic axis rather that a physical axis? Same as the above but using a handwheel? I'm pretty certain the answer is no so the next question is how can this be simulated?

Is there a methodology for sharing #define(s) between compiled and scripted code?

Is there a methodology for sharing #define(s) between compiled and scripted code?

I upgraded to 1.6 IDE today, since the upgrade my compiled plc is no longer running in the Power PMAC. 1. The project worked before upgrade 2. The bgcplc02 is being compiled 3. Reverted to 1.5 IDE and I'm back up and running

[quote='bradp' pid='206' dateline='1252511542'] To determine if a motion program is running in a C.S. look at Coord[n].Ldata.Status. If all of the four low bits are zero then it is executing. To determine if a PLC program is executing look at Plc[n].Ldata.Status. If all of the four low bits are zero then it is executing. [/quote] This no longer works after upgrading 1.6.0.30. Is this a bug or intended and what replaces it :(