Messages

31

dspMC/IP Motion Controller / Re: DSPMC Feedforward CFF and CDFF gains

« on: February 04, 2010, 06:15:31 PM »

Hello PIV:

Aside from using AxisWorks to tune the servos driven by dspmc, I have no experience. However, there are a lot of tutorials on the net, and much on WIKI, that explain the meaning of the multitude of terms in PID tuning.

AxisWorks helps to get the numbers in the ballpark. The motor sound tells a lot about how good the numbers are, as well as a good curve on the graph. There are commercial tuning programs available.

Having read many of the tutorials on the subject, it is clear that the PID tuning process involves a lot of trial and error, and patience. 

I came across a couple of good tutorials with graphical examples of the various tuning parameters.

http://digital.ni.com/public.nsf/allkb/806F6F0B775FAF32862572FA0052F2AB

http://zone.ni.com/devzone/cda/tut/p/id/2923

John

32

dspMC/IP Motion Controller / Re: DSPMC controller and Orom Servo Driver/Motor interface

« on: November 23, 2009, 12:42:25 PM »

xavi:

The "digital part" is the encoder signals. The encoders must be connected, as they supply the feedback to the controller for position and direction. The motor "tach" signal goes strictly to the servo driver.

John

33

dspMC/IP Motion Controller / Re: DSPMC controller and Orom Servo Driver/Motor interface

« on: November 16, 2009, 07:01:38 PM »

Hello Xavi:

I am not familiar with the Omron servo driver or motor. However I am in the process of implementing a dspmc/IO controller on an existing machine with DC brush motors, and analog +/- 10v. servo drivers. My installation is not complete, but there are several members with finished operational systems, who may add further commentary.

The analog +/- 10v. control signal is generated by the dspmc controller, and is output through port J2, board 7711.  The servo driver reads this voltage, and moves the motor accordingly. The pin on your servo driver should be labeled "signal" somewhere in the data sheet. The servo motor also outputs a Tach signal, which is wired to the servo drive, and not the dspmc controller. Also, the analog output for each axis should have the ground from the 7711 board to the servo driver. Board 7711, port J2, pin #15 on the 7711 is the X axis analog output, pin #3 is the Y axis analog output, and Pin #17 is ground. The X and Y axis wiring should be twisted pairs, shielded cable.

In the dspmc guide, the X axis is labeled 0, the Y axis is labeled 1, the Z axis is labeled 2, and the A axis is labeled 3.

Regarding the encoder outputs, they must go to the dspmc through the J6 connector. The encoder outputs are 5v. These connections are A+, B+, Z+(the encoder  reference) +5v, Ground.
All of these signal wires must be done with shielded wire, and the cable shielding connected at only one end, to the chassis ground, not the signal ground of the encoder, or controller, or servo drive.

The 7711 boards are not opto-isolated, so be careful working with the connections. The 7535 board is opto-isolated.
 
After making the connections, the servo drivers will have to be tuned, and adjusted properly, using the software from Vital Systems, AxisWorks.  The data sheets for the Omron servo drives should have a basic setup or starting point regarding the pot settings for gain, tach, balance, etc.

John

34

General Mach Discussion / Re: Problems threading on the lathe

« on: October 03, 2009, 03:25:05 PM »

Hood:

1.) 20,000 per second? Check your math.

2.) My threading comment was a generalization, and I did refer to higher RPM's for smaller diameters.

3.) Are you spinning 2" shafts 1000 RPM when cutting a thread?

I think we all are interested in seeing this particular problem within Mach code, solved in the best possible way. Also, I appreciate this forum because of the vast pool of skilled people willing to help other people. My shop is 4-axis milling (2) machines, no CNC turning yet, and (2) engine lathes.

Still learning.

 

   



   

 

35

General Mach Discussion / Re: Problems threading on the lathe

« on: October 03, 2009, 02:13:56 PM »

Art:

Thanks for explaining a little more about what goes on within the program, and the particular problems you are working at solving. I really appreciate, and value your feedback.

My first CNC machine goes back to 1980; teletype machines, and paper tape!

Like a complex machined part, the solution to the threading problem is breaking the job down to the individual pieces of the puzzle, and solving them one at a time.

Thank you, and those involved with you, for your work to make Mach a better tool for us all. 

John

36

General Mach Discussion / Re: Problems threading on the lathe

« on: October 03, 2009, 12:15:23 AM »

Hello all:

I have read the entire thread this afternoon, and marvel at the efforts to solve this problem. The electronic/technical skills of all involved is certainly high, and a great deal of work has been put forth by all.

However, this problem appears to be escalating to higher and higher levels of complexity, with computer clock microsecond timing and motor speed variables shifting about seemingly at random. I wholly agree with the post's of  Simpson36. Perhaps it is time to rethink the problem, i.e. think "simple."

Engine lathes have been cutting threads for a long, long time, and the problem of synchronizing the spindle/carriage is done with a precision lead screw, geared to the spindle, which moves the carriage by means of a bronze half-nut, engaged at the appropriate time as indicated by a carriage dial geared to the lead screw. The machinist was the computer, watching the carriage dial to engage the half-nut at the exact moment, to synchronize spindle and threading tool exactly, after selecting the gearbox change gears for the thread pitch. 

The spindle index-pulse signal has now replaced carriage dial and half-nut, and the machinist's eye. The lead screw is geared to the carriage motor and motor encoder. But, the old school gear train between spindle and lead screw is gone; replaced by microsecond time clocking counters, motor speed and torque guesstimates, number averaging, and much more things that this writer does not understand at all. However, it does seem akin to the old-school gearing system, except rubber bands are used where gears and keyways used to be! And, it is not simple.

May I suggest using an encoder on the spindle, with the index-pulse retained of course. The spindle encoder signals become the baseline source of all timing for carriage motor drive synchronization. These spindle encoder signals become an electronic gearbox, if linked correctly with the carriage drive encoder counts. Spindle speed can vary all over the place, as well as the Computer frequency clock ticks, and will in no way affect the "electric gearbox" ratio between spindle and carriage.

Example 1:
500 count/rev encoder on spindle, carriage encoder .0001" linear travel per encoder pulse (2000 count/revolution , .1/5 inch pitch leadscrew)
Cutting a 1/4-20 thread, the pitch is .05" per 500 pulses per revolution of spindle. .05 linear travel = 500 linear motor pulses, per 500 pulses from spindle encoder.

Example 2:
Cutting a 1/2-13 thread, the pitch is .076923077" linear travel. This = 769.23077 pulses per 500 spindle pulses per one spindle rotation. It would take 4 revolutions, or 4 full pitches before a full .0001 pulse step had to be added, if the ratio was 500/769.

With a 500 count spindle encoder, at 600 RPM, the pulses per second are only 5000 pulses per second. If I read the thread correctly, the number of 25,000 PPS is the clock speed of Mach3. I seriously doubt anyone is going to want to do threading over 1200 RPM, and the coarser the thread, the lower the spindle speed becomes. If the spindle speed must be high, i.e. fine pitch, small diameter, the Mach threading program should be able to post an upper limit spindle speed for a given thread pitch. 

I am sure there are elegant, mathematical routines to synchronize the lathe spindle and carriage, for any thread pitch. Machining threads to a known standard of precision is fundamental, in the machine industry.

Regards,
John

37

G-Code, CAD, and CAM discussions / Re: How do I increment value in M98 subroutine

« on: August 11, 2009, 10:31:38 PM »

Worked like a charm. That is exactly what I wanted.

Thanks Graham.

38

G-Code, CAD, and CAM discussions / How do I increment value in M98 subroutine

« on: August 11, 2009, 02:26:53 PM »

I would like to increment the Z axis depth when using a M98 call to subroutine, to make multiple passes at increasing depths.
For example, an OD path of a part, using cutter comp.

There is an example of such a move in the Wizard for cutting a spline. That code loops in a M98 call subroutine, and the rotary axis increments a given amount of degrees after cutting each tooth, and the Q value is set to the number of splines cut. The rotary table angle increment is 360 divided by the number of teeth input in the Wizard.

I wrote a part contour using G42, and put it into the subroutine called by the M98. There seemed to be no way that the Z axis could be incremented by codes within the called subroutine. That would have made the code much shorter, and also logical.

Since the M98 will make any number of repeating calls i.e. the Q value,  it should be easy.

I ended up using the beginning offset lead-in line bringing the tool into the work, on the line before the "M98 o0001 Q4".
Then I made multiple copies of those two lines,  with each successive lead-in containing the Z depth I wanted.

I edited the "o0001" called subroutine so there was no Z value, just the OD contours in the X,Y, I,J etc.

It all worked, but there has to be a better way of stepping down the Z making multiple passes around the part. I read the manual regarding "Parameters" ,and they all must be integers.

Is there something like a parameter, that can be incremented in discreet numerical values, like .05, or .25 etc.?

On my old Sharnoa CNC control, you could put any value in a parameter, #5=.0156, and then increment that parameter later in the routine, #5 +.1=#5.
Then the Z value would read, Z-#5 where you wanted the depth to change. Each time through the sub-routine the depth would change, or any Axis letter for that matter.

Any suggestions would be appreciated.

Thanks,
John