Laserdave7

Looking for documentation for the Power Clipper Acc-24S3 and Acc-8AS. Did I overlook them on the filedepot, or are they covered in other manual(s). Thanks Edit: I found the section for the 24S3 in the Clipper User Manual. So question is just for the 8AS.

I'm trying to download a correction file for motor #3 to a Clipper. When I download the included file it causes an "Access Violation" in PCommServer and it shuts down. The table is 65.63 in size (file size ~23k). When I load a smaller table i.e. 30.30 it works fine. Is there some limitation I'm overrunning? Thanks, Dave CompTable.pmc

Is it possible to add the 4c2 Yaskawa option to a GeoBrick in the field?

Very helpful. The piece I was missing was the placement of the deadband in the diagram. Thanks for the help, Dave

Thank you for your reply. I will try reducing Ixx31 and see if that solves the problem. I am confused about something though. According to the PID Diagram in the PMAC User Man. the I and D term are before the P so it seems like a P term of 0 ((-16+16/16) * Ixx30 per the deadband) should block both. Also the Tuning Pro help file states "Because the proportional gain term Kp (Ix30) is outside the brackets in the filter equation (see previous page), it also affects derivative and integral gains". Where am I going wrong in my understanding? Any help you can provide to help me better understand whats going on is greatly appreciated. Thanks, Dave

I am using a Geobrick and have an axis that is dithering even with the deadband set to -16 gain factor. Only one axis does this. I can see the DAC values fluctuating and hear activity in the motor. I have tried Ixx65 values as high as 48 and it wont stop. How can I diagnose where this stimulation is coming from. My understanding is that Ixx64=-16 should remove all stimulation from the motor... Also if I look at Ixx68 I see it jumping around. I manually removed Ixx30 and it stopped. Seems like it's not entering deadband... Thanks, Dave

What is the proper way to tune a vertically oriented axis. When I tune the step response in tuning pro I can't seem to get the upward motion to pull all the way into position in the dwell period without resonance occurring. I have tried high Kp and low Ki and low Kp and High Ki. I can get it close but when it pulls in tight it starts to resonate. Is there a proper way to bias the drive to compensate for the effects of gravity on the stage? Thanks, Dave

Is PCommServer also multithreaded? My application is experiencing the exact same problem. Will PCommServer fire unsolicited events from multiple threads? If so I can put a lock in my code to force sequencing... Thanks

Thanks for the info Steve. This is consistent with what I am seeing. If I close everything other than the terminal window (PEWin32) to execute the program and view responses in the Unsolicited tab at the bottom, I get mostly correct but missing once in a while. This is a concern for me because it means I can't use this deterministically. Is this issue: timing on the GeoBrick or in the PCOMServer? I noticed that there is an "Interrupt" event in PComServer and that serveral of the interrupt values were labeled as user definable (In sample code that comes with PCOMServer) but I haven't found anywhere in the manual that explains how to use these yet. Would these be any more deterministic? If not then I think my solution will be to use the digital IO to function as an interrupt to the computer and then retrieve the info in solicited fashion. Thanks, Dave

Hi Steve, I currently Have I64=1. This issue shows up in PEWIN32 with none of my software running. I closed the position display, the MotorStatus, and the Watch windows to eliminate as much polling as possible. It seems to reduce the errors, but I still get dropped messages. Dave

Hi Guys, I'm having a problem with inconsistent unsolicited messages. I'm using a GeoBrick over USB and Procomm Server. I am trying to send a message to the host to command it to change laser parameters. I have the following code loaded in the Brick: ;############################################ ;M70 - Set Laser Q Rate N70000 Read(Q) If (PARAM_INCLUDED & Q_PARAM_FLAG > 0) TEXT_NO_CR=1 ;I62 P301=Q117 SendP"QRATE " CmdP"P301" Endif Return I run a simple program "M70 Q30000" Sometimes I get 'QRATE' and '30000'. Sometimes I get just 'QRATE'. Sometimes Just '30000'. I see this in my code as well as in PEWin32 Pro2. I have tried putting dwells as large as 100 after each SEND/CMD but no help. How can I make this robust. I need to know that this will be 100 percent consistent. Is there a better way to accomplish what I'm trying to do? Thanks, Dave