gshort Posted April 26, 2012 Share Posted April 26, 2012 I've been trying to use the "distance to go" methods as described in the "Setting up Coordinate Systems" document. I have set Coord[1].TPSize to 1024 for now as I have lookahead set and set Coord[1].TPCoords to the bitmask for my coordinate system axes. If I have a watch on Coord[1].TPExec.Pos[x] for the axes of interest they all seem to be set to nan. Indeed all the 32 Pos[x] array elements appear to be that way. Additionally I tried to use the &1g command from the terminal window and got "No data to display" while the &1t gives "No targets defined", whereas "&1d" does report the current demands for the axes. I'm running on firmware 1.4.0.63. I'm clearly doing something wrong, any pointers much appreciated. Link to comment Share on other sites More sharing options...
curtwilson Posted April 26, 2012 Share Posted April 26, 2012 I have not been able to get this to fail. Obviously, your system is behaving as if a buffer had not been defined. Of, course, make sure your setup variables have the values you want. With Coord[1].TPSize set to 0, issue the "free" command. One of the response lines tells you how much memory is available for the "lookahead buffers". This buffer space is used for the dynamic lookahead buffers, the cutter comp buffers, and the target position buffers. A target position buffer requires 288 bytes per move, so you will need at least 294,912 bytes free to be able to define a 1024-move buffer. Link to comment Share on other sites More sharing options...
gshort Posted April 30, 2012 Author Share Posted April 30, 2012 OK, I've figured it out. I was performing the rapid move from a PLC. Until you run a motion script, TPExec.Pos[x] remain at nan. This is not ideal if you intend to monitor this from an MMI. When I run a motion script, I was rather expecting TPExec.Pos[x] to reflect the position for distance to go calculation. However it just looks to match what is in Coord[c].CdPos[x] i.e. the target demand for that axis. Whereas the g command, for instance, provides an intermediate position information for the time the command is run. Up to now, our MMI has not needed to run an online command to gain status information and we'd really prefer not to have to do this, especially as the status information we read is done on a per axis basis. Is there any way you can suggest us doing this i.e. does the intermediate position information exist somewhere in the Coord[c] structure ? Link to comment Share on other sites More sharing options...
curtwilson Posted April 30, 2012 Share Posted April 30, 2012 When running a motion program with the target-position buffer enabled, Coord[x].TPExec.Pos holds the axis target (move-end) position for the presently executing move. Coord[x].CdPos holds the axis target position for the most recently calculated move, which can be, and often is, one or more moves ahead of the presently executing move. The whole point of the target-position buffer is to store these position values from calculation time to execution time. When you request the present target position values with the on-line "t" or program "tread" command, Power PMAC just reports back the values of TPExec.Pos. When you request the present distance-to-go values with the on-line "g" or program "dtogread" command Power PMAC subtracts the present instantaneous (motor) command positions, converted to axis values, from the values of TPExec.Pos. Note that we do not automatically compute the instantaneous positions in axis coordinates on an ongoing basis, as this would be a huge computational overhead, so this is done only "on demand". I suggest you use the buffered program "dtogread" command if you do not want to do on-line queries. It automatically does all of these calculations for you (including cutter comp offsets) and places the results in local variables Di for your use. When you command a rapid move directly from a PLC program, none of this motion program logic is used. It is easy, however, to use the PLC program to command a rapid move with motion program logic. For example, you could replace your PLC program line: X(MyXdest) Y(MyYDest) with: cmd"&1 cpx rapid X(MyXdest) Y(MyYdest)" or with: start500 where you have: open prog 500 rapid X(MyXdest) Y(MyYdest) close Link to comment Share on other sites More sharing options...
gshort Posted May 1, 2012 Author Share Posted May 1, 2012 Thanks, Curt. We were hoping to do it without issuing a command, as all our other MMI axis status are retrieved directly from the data structure. Link to comment Share on other sites More sharing options...
curtwilson Posted May 1, 2012 Share Posted May 1, 2012 If you put code like the following in a background PLC program that is continually scanning: dtogread; MyXDistToGo = D6; MyYDistToGo = D7; MyZDistToGo = D8; then you have the information you want readily available to your MMI by simply querying the values of your user variables, in the same way as you acquire other values. Link to comment Share on other sites More sharing options...
gshort Posted June 15, 2012 Author Share Posted June 15, 2012 I've been using the g command successfully now, but have found one further gotcha. If I have a motion script that say moves the X axis by 10 which is aborted when it has only moved 5 for instance. If I then load another motion script which may not move X at all, the g command will still report that X has 5 units to move. After a subsequent move of X the g command reports the correct data, but until the move occurs the reported positions are incorrect. I'm finding a similar problem if I have a spindle which I then turn to a positioning axis. Its reported position from the g command after I stop it as a spindle and before I move it is incorrect. Link to comment Share on other sites More sharing options...
curtwilson Posted June 15, 2012 Share Posted June 15, 2012 When you abort a motion program, the reported distance-to-go for each axis is still calculated as the destination position of the most recently executing move minus the present commanded position. This is as it should be, as many users would want to see that the move in progress had not finished. Fundamentally, the act of aborting, whether by command or due to some sort of fault, does not clear the target position buffer (nor should it). As you note, as soon as another programmed move is calculated, the distance-to-go is correct for this move. What you desire is the ability to clear the target position buffer at some point before you actually calculate your next move. Because we can't clear the buffer automatically on an abort, this must be done as a discrete step, from a command. (Loading another program cannot be the trigger for this, as we do not know why you are doing this.) We do not have an explicit command to clear the target-position buffer. However, you could easily clear the buffer with a command like: cpx inc x0 y0 z0 This commands a zero-distance move, making the target position equal to the present position, so all distances-to-go are zero. Alternately, you could use logic in your HMI to report zero DTG when in these modes. Link to comment Share on other sites More sharing options...
gshort Posted June 18, 2012 Author Share Posted June 18, 2012 Although you've paraphrased my question to some degree, the one thing that appears incorrect to me in this is if having aborted a motion script and start a new one and that then initiates a move, that the g command has its buffer cleared for all axes. As I mentioned if this second motion script never moves a particular axis that axis will still have a reported distance to go from a motion script that has been aborted and is no longer running. If this is the expected behaviour and this has to be cleared manually its worth at least pointing this out in the documentation, but it does seem wrong to me. Link to comment Share on other sites More sharing options...
curtwilson Posted June 18, 2012 Share Posted June 18, 2012 Either I'm not understanding your question or I'm not able to duplicate your issue. If I command a multi-axis move and abort it in the middle, multiple axes still show a non-zero "distance-to-go". This is an intended feature. If I then command a new programmed axis move with only one axis explicitly commanded (or even just not all axes that had non-zero distance-to-go), any axis that is not explicitly commanded is implicitly commanded to do a zero-distance move. As soon as this move starts, these axes will report zero distance-to-go. (In one test, one of my axes reported a distance-to-go of about 10^-16 motor units, probably due to some floating-point round-off issue, but any formatting for display would show this as 0.0.) Link to comment Share on other sites More sharing options...
gshort Posted June 19, 2012 Author Share Posted June 19, 2012 Sorry, Curt. I can't reproduce it either now. I must have made a mistake, although I could have sworn I saw the g command have non-zero values for a new motion script for axes that I wasn't moving. If I manage to reproduce it again reliably I'll let you know. Thanks again for your attention. Link to comment Share on other sites More sharing options...
gmschoon Posted October 16, 2017 Share Posted October 16, 2017 I have not been able to get this to fail. Obviously, your system is behaving as if a buffer had not been defined. Of, course, make sure your setup variables have the values you want. With Coord[1].TPSize set to 0, issue the "free" command. One of the response lines tells you how much memory is available for the "lookahead buffers". This buffer space is used for the dynamic lookahead buffers, the cutter comp buffers, and the target position buffers. A target position buffer requires 288 bytes per move, so you will need at least 294,912 bytes free to be able to define a 1024-move buffer. Hi We are attempting to use "dtogread" in a plc routine, however the D value for the axis of interest is zero (Ldata.coord=1, but D32 is zero, indicating no axes are being reported) Coord[x].TPExec.Pos & Coord[x].CdPos are both reporting correctly for executing & calculated moves, and the online "g" command returns expected distance to go values. The "free" command indicates buffer space is not an issue. Would "dtogread" fail in this way if insufficient buffer space is designated by Coord[x].TPSize? Thanks Link to comment Share on other sites More sharing options...
curtwilson Posted October 17, 2017 Share Posted October 17, 2017 When you use a PLC program for commands like "dtogread", the values are placed in local D variables for that PLC. If you want to access these values from outside of that PLC program, you must use the full data structure -- e.g. Plc[17].Ldata.D[32] Link to comment Share on other sites More sharing options...
Recommended Posts