lukewang

Hi Curt, Thanks for the manual. As we are going to use ACC-8D opt 6 directly with clipper WITHOUT ACC-8D card. So I have a few questions for the manual: We use panasonic servo motor A5 series. if we use ACC-8D opt 6 card for this servo drive, we intend to wire as follows: (1)Servo drive differential encoder signal outputs A+/A-, B+/B-, C+/C- are led into ACC-8D opt 6 card inputs (TB1). (2) ACC-8D opt 6 card outputs(TB2) are connected to clipper encoder differential inputs directly. Here are my questions: (1)on ACC-8D opt 6 card, should I connect 0-GND (TB1, pin 26) to GND on servo drive and leave TB1 pin 25 (+5V) unconnected? remember we are using differential encoder signals. (2)on ACC-8D opt 6 card, should I connect TB2 pin 25(+5V) and TB2 pin 26 (0-GND) to clipper +5V power supply? Thanks for yor help. Cheers, Luke

Hi Curt, We did try some encoder feedback isolation board from the third party. It works fine for the first couple of months. Then something strange happened: axis drifts without any following error but axis position display is unchanged. The same controllers used on laser applications are perfect. That's why it rings my bell on plasma electrical noise. Can you point to me more detailed info of ACC-8D opt 6? I cannnot find it on Delta Tau website. Thanks. Cheers, Luke

Hi, We are using clipper with ACC-1P option (a piggyback motion card for extra 4 servo channels on the top of clipper) for plasma cutting machines. After over 10 installations on different OEM's plasma cuttin gmachines, we found that encoder feedback ICs on the ACC-1P motion card are very easy to get damaged (almost every ACC-1P card on our machines have been repaired at least once or twice, some of them 4 times!). However, the encoder feedback ICs on base card are hardly damaged. Plasma unit is quite noisy electrically. But I am quite confused with the difference between base card and ACC-1P card. Just wonder if ACC-1P card is really more vulnerable than base card? Anyway we can stop this problem continuing? Thanks. Luke

Curt, tried to attach a cfg file here, too large to work. So I wrote an email to you. plc check ur email for the details of my test. Thanks. Luke

Sorry Curt, I didnt do the test as per your suggestion until today. DEFINE CCBUF 8 issued first Then I run a NC program with M8, motors run away during M8 execution. Here is my M8 sub-program: N8000 BSTART M199==1 ;-------Begin-------------- INC LIN X0Y0 ;these two zero-distance moves used to avoid M8 executed ahead of its previous motion block LIN X0Y0 ABS While (M199 = 0) EndWhile ;-----------End---------- BSTOP Close If I remove LIN X0Y0, everything is fine. But I have to use them to make sure M8 acts in order. Any solution? Thanks.

Curt, I use rotary buffer as follows: &1 DEF Rot 2000 I didnt use CCBUF. Any clues? Thanks. Luke

Look at this NC program: G91 G41 H10 (turn on left kerf of 10mm) G01 X-100 Y300 (kerf on left side of path) G01 Y0 G01 Y0 G01 Y-100 (kerf changes to right side of path) G40 (turn off kerf) I wonder how come kerf changes from left to right side of path after 2 zero-distance moves? if I remove the 2 zero-distance moves, kerf is perfect.

I did the test with Isx86. Yes, my rotary C axis is affected by this variable. My problem is solved. Then another problem is coming. I have 2 rotary axes, both of them seem to be controlled by Isx86, which is not ideal. I prefer each of them being controlled by separate feedrate limits, anyway I can do it? Thanks Jeff and Curt.

Thanks, Sina. Now it is clear.

Hi, I am running this NC proggram with a kerf: ABS CCR(1) CC1 Linear X-172.646 Y-505.895 C-200 Linear C30 (path following axis C runs away here) Linear X0 Y-400 C30 CC4 if I turn off kerf now: ABS CCR(0) CC1 Linear X-172.646 Y-505.895 C-200 Linear C30 (path following axis C is fine here) Linear X0 Y-400 C30 CC4 or if I add a zero-distance move after Linear C30: ABS CCR(1) CC1 Linear X-172.646 Y-505.895 C-200 Linear C30 (path following axis C is fine here) Linear X-172.646 Y-505.895 CC4 It seems kerf affects path-following axis control? why? Thanks for your help. Luke

Hi Sina, Is that because intergal length issue? TM command can only have 23-bit integal? Cheers, Luke

Hi, I came cross a feedrate higher than programmed one when running an arc with huge radius. Then I found the following explaination in PMAC manual: "If the specified feedrate causes a move time of over 223 msec (about 2 hours 20 minutes) to be calculated, the move will be executed in 223 msec, at a higher speed than what was programmed." It is really beyond my comprehension. How come feedrate control be affected by block length? What's the theory behind? Thanks. Luke

Thanks for your help. I think the best solution should be that relating cutting speed to laser power and manage a dwell 0 or similar to improve the corner. I will have a try.

I am using Clipper to control a laser cutting machine. When cutting a square or a sharp corner, I experienced a problem: the corner has a noticable arc inserted automatically. Only way to reduce this arc seems to reduce TS, or use exact mode allowing machine a short dwell at corner. Both solutions are not ideal. The first one caused machine vibration, the second caused corner over-burn. Just wonder if there are any Clipper parameters which can fine tune this corner with minimum arc radius and maximum velocity. Thanks in advance. Luke

One thing I dont understand is that velocity may get slower in this high block rate situation but it should not get bumpy regardless how i set up I variables. The reason being bumpy is that small blocks have various lengths, unless I set a very small TS to meet constraint of shortest block, or velocity will fluctuate on blocks with different lengths. Reducing TS/TA/Isx13 a lot or adjusting them on the fly may be not feasible due to machine dynamic contraints. Since TS/TA/Isx13 has been set up at initial machine tune-up, it is not feasible either to change them just for certain part of geometry. I used to work on an interpolation algorithm. If it looks ahead 50 blocks, then it assumes the velocity must be decelerated to zero at the end of 50th block. For any block joints between, it works out a transition velocity on each joint point depending on the angle formed by two joint blocks. If all short blocks are joined tangentially, the transition velocity on each block joint may not be dropped at all. This kind of lookahead will solve this problem. And it makes sense for a series of smoothly connected short blocks, velocity stays stable. Anyway Clipper can achieve that?