Jump to content
OMRON Forums

paddax

Members
  • Posts

    44
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

paddax's Achievements

Enthusiast

Enthusiast (6/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. You are on the money 🙂, the firmware version was 2.3.xxx.
  2. 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.
  3. 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.
  4. 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?
  5. Is there a solution that does not require editing init scripts, this is the sought of thing that will leave my customers confused.
  6. So the answer to the actual question is....
  7. 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
  8. 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
  9. 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.
  10. 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.
  11. 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?
  12. 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?
  13. 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.
  14. 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
×
×
  • Create New...