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?

Dear PMAC Support, We are using Clipper. When we came cross a geometry with many short blocks (about 1mm each), we found the actual velocity on the geometry is much slower than programmed one, and the worse, the velocity is fluctuating. Important note here is that all these short blocks are tangentially connected. But it doesnt help on its feedrate. We tried to replace these short blocks with SPLINE2, we tried to turn on lookahead function, we tried to adjust I13 segment mode, velocity on this geometry seems not affected, still very slow and fluctuating. Only way we can improve this is to reduce TA and TS, which is not what we expected as the machine becomes a bit jumpy with smaller TA and TS. Pls help. Thanks. Luke

Charles, Thanks for your reply. I did that already, still the same error. I think it is not due to gathering data issue, my PLC1 is simply too big. I just wonder, besides shifting code to other PLCs, if i can increase PLC1 buffer size? Thanks. Cheers, Luke

Hi PMAC Support, I am using Clipper. Now with inceasing size of PLC1, clipper reports an error "no room in buffer for command". When this error occurs, the size and address of the other buffers are messed up. If I delete a few lines in PLC1, everything goes back normal. I just wonder anyway to increase PLC1 buffer size and how? Thanks. Luke

when we run G02/03 circular path on a clipper, we found clipper command positions are slightly different from mathmatical positions of G02/03. With increased feedrate, this position difference is getting bigger. We dont have any kerf turned on when doing this test. I can provide data collected if needed. Pls advice. Thanks.

Hi Sina, Attached are the DAC test results and my clipper settings. Let me know your analysis. Thanks. Luke

Hi Sina & Brian, Here are parameter settings on my clipper: I7000=1001 I7001=5 I7002=3 I10=3421867 Ixx29=0 We tried to use Ixx29 to solve DAC zero drifting issue, is there better way to tune DAC zero output? Thanks for your help. Cheers, Luke

Thanks Sina. It really helps. Could you pls help me further on the following DAC issues: For these DAC ports, we found on the same clipper card the output voltages are different from port to port, say, DAC1 max output can be 7.8V, and DAC2 may be 8.6V, with the default settings. and positive and negative outputs are not symmetic too. Any particular reasons behind? are we suppose to check and adjust each DAC port on each clipper? Thanks.

I have used clippers for a while and found many of factory default setting clippers have 2 issues for axis analog channel DACs: (1)DAC output not symmetric, ie, one end could be +9V, and the other end could be -7.5V. we have to check and adjust for every newly arrived card (2)I used scope to meansure DAC output and found its pretty noisy with lots of hi-frequency spikes My quesions are (1)if DAC output symmetry is a concern or we supose to tune it when it comes in (2)if the noise on DAC port is acceptable and has any impact on axial control accuracy and stability? My thanks in advance.