Vectrac CNC Knee mill refit from Fanuc 0M to Camsoft

Walked away and took a summer vacation...

When I got back on this, swapping cables indicated card trouble. OH BOY, don't want to call a Galil card dead. So I took the time to install multiboot and a second operating system on another hard drive. put Galil WSDK on it. Now just hit <ESC> in early boot and select the other drive to get Galil WSDK. I should have taken the time to do this on day one.

IO shows up fine in Galil. Issue is software, if a Galil input number is not used in the .cbk the Camsoft control doesn't look for it. It is a touch flakey here, the inputs from the second card fire inputio, inputs from the first card do not. Anyway added a whole bunch of commands like:
IF #24=1 THEN MESSAGE 24 IS 1
for all 16 inputs and things are fine.
 
CALCULUS PROBLEM BELOW!

I am thinking my acceleration settings are not working correctly. Its taking about 3 inches to reach 50000 cts/sec. Keep turning them up and machine does not seem to respond. So, I'd like to know what acceleration values to use based on the math. Camsoft just told me the max AC value is 12000000

The machine has 40960 encoder counts per inch of travel.

What AC value would reach 50000 ct/sec in 0.5 inch of travel? or what AC value reached 100000 cts/sec in one inch travel? Same value?

40 years ago, this would be one of ten problems to solve on a one hour test in my engineering physics class.

Extra credit: show me the work so I can do my own with other values.
 
Take a look at the Galil manual. All of the formulas are given in the Mathematical Analysis section in the appendix.

Also take a look at your PID settings, especially the ''P''. I normally tune the servos manually from the Galil terminal program rather than trying to do it from within the operating software.
 
Worked on the acceleration issue. Its not perfect, but perfect can be the enemy of good enough. I grow and market for a living and harvest starts next week, so I will leave this for now and finish up the machine and put it to work making parts.

Here's a pic of how she looks now. that's a 32" TV for monitor, got two keyboards. Can pull the wired one out for debug work and control programming. Most the time a wireless one sits on the rolling table with the other tucked out of the way.

Right now, I'm about 80% done with all the features on the operator panel.

The rotating switch in upper right on the panel is the BIG one. I call this the machine mode. It must be in RUN to run a CNC program. In the programming several things are set correctly for machine run. For the operator the CYCLE START pushbutton won't work unless in RUN mode. Also the MDI window won't open.

The next mode is JOG. This enables the pushbuttons in the panel center. The middle button is "fast". Hold this in while pushing any direction and the machine jogs rapid. release it and it jogs slow. Camsoft does have programming command for jogging but it had a slight hesitation between touching a button and moving. As I am an official ANAL ENGINEER, I wrote a low level program for the Gali card (attached). This one responds immediately.

The next five modes are the MPG or handwheel for each axis. Only the handwheel and the 1-10 switch work in this mode. 10 is for coarse handwheel => one click is 0.010" 1 is for fine handwheel, one click does 0.0005".

IMHO, the above features REALLY IMPROVE setting up a job.

The balance of the buttons on the control panel let the operator run the machine without using the mouse or keyboard. Its just nicer that way.

I'll just mention a bit about the computer screen. The large black area in the upper left is the viewport, Camsoft's BEST feature. Load a program and you can visually see the toolpaths. The viewport can be zoomed and viewed from any angle.

The dark blue area is the Gcode window, it displays gcodes while running. A HUGE feature of this area is the ability to send the operator any message of interest.

Notice the red button in the machine is a green button on the screenshot. This is just a display of whether the machine is ready to run or in Estop.

There are several lights that just tell limit switches, homed, etc. The grey boxes are user defined functions for the machine. For example, mouse click on the Preset X and a window pops up to enter the X value for the current part.

The bottom area is just a view of the desktop. I have shortcuts to all the configuration files. For example I just programmed an ESTOP enable this morning. I cut the wire to the Estop power and ran it through a spare relay. Then added a simple command (#152=0) in shutdown.fil and another (#152=1) in startup.fil. Now Estop drops if the control is exited and won't enable until the control is up and running.


Vctrax Mill.jpgCapture.JPG
 

Attachments

  • VectraxJOGnHOME2.txt
    1.5 KB · Views: 2
Last edited:
I like the big monitor, easy on the eyes :) The operator panel is nicely laid out and logical.

Do the switches control the Camsoft program from the Galil inputs? Is the MPG also tied back to the Camsoft program?
 
Jim, you are too fast, I was still writing and editing.You may want to look at the post again now that I'm done.

Got that 32" TV from wally world for cheap.

I save the PRECIOUS Galil inputs for things the Galil card needs to know. Estop status, Servo fault and all the jogging buttons as the JOG program runs on the Galil card. I have three left right now.

Camsoft allows several vendor's IO cards. i am partial to the Adlink 96 IO card going to Opto 22 24 port IO boards. galil does not see these unless you pass it a variable. You can install a second IO card if 96 isn't enough for you :)
 
I see I missed one of your queries. The handwheel is connected to an Aux encoder input. Then a macro in Camsoft directs the motion. A clever galil programmer could write a better routine entirely within Galil here. Here again, perfect can be the enemy of good enough. The Galil programming language is pretty cryptic for those of us that do not use it regularly.

of course Camsoft language would seem cryptic to you. Here's one axis of handhweel
'X axis, #100=0 for large steps
IF\830=3THENIF#100=0THEN RAPIDSPEED 1;5000:ACCEL 20000:DECEL 20000:HANDWHEEL 1;400;OK2STOP2: GOTO :ENDHANDWHEEL ' SETTING OF 400 is .01 per click
IF\830=3THENIF#100=1THEN RAPIDSPEED 1;1000:ACCEL 20000:DECEL 20000:HANDWHEEL 1;8000;OK2STOP2: GOTO :ENDHANDWHEEL ' SETTING OF 8000 is 0.0005 per click

In camsoft all variables must be named \###, like \830 is the mode number.
Inputs and outputs are the # followed by the number of the IO. #100 is the 1 or 10 switch on the operator panel.
The : character is a line break, same as <enter> or <return linefeed>
Camsoft makes use of the dreaded GOTO command. All unix programmers were taught this is bad form by Richie.
 
The Camsoft MPG code looks much less complex that the Galil code I wrote for the lathe. I used Galil inputs 81-85 (X, Y, and Z Aux encoder inputs) for the axis selector and resolution switches. And the Aux W axis encoder for the handwheel. Then just set the X or Z axis to track the W axis at the resolution set by the resolution switch, 0.01, 0.001, or 0.0001.

#MPG
IF(@IN[81]=0)|(@IN[82]=0)
IF(JOBRUN=0)&(ESOK=0)
'SET MPG SCALING
IF(@IN[83]=0);MPGSCL=1;ENDIF;'0.0001
IF(@IN[84]=0);MPGSCL=4;ENDIF;'0.001
IF(@IN[85]=0);MPGSCL=20;ENDIF;'0.01
'MPG X
IF(@IN[81]=0)&(_TDD<>0)
PTA=1;'TURN ON POSITION TRACKING
MPGPOS=(_TDD*MPGSCL)
ACA=1000000
SPA=8000
IF(MPGPOS<>0);PAA=_RPA+MPGPOS;ENDIF
ELSE
PTA=0
ENDIF;'IF(@IN[81]=0)&(_TDD<>0)
'MPG Z
IF(@IN[82]=0)&(_TDD<>0)
PTC=1;'TURN ON POSITION TRACKING
MPGPOS=(_TDD*MPGSCL)
ACC=1000000
SPC=8000
IF(MPGPOS<>0);PAC=_RPC+MPGPOS;ENDIF
ELSE
PTC=0
ENDIF;'IF(@IN[82]=0)&(_TDD<>0)
DED=0
MPGPOS=0
ELSE;'IF(JOBRUN=0)&(ESOK=0)
DED=0
ENDIF;'IF(JOBRUN=0)&(ESOK=0)
ELSE;'IF(@IN[81]=0)|(@IN[82]=0)
DED=0
ENDIF;'IF(@IN[81]=0)|(@IN[82]=0)
WT10
JP#MPG
EN;'END MPG
 
It looks to me like there is not the equivalent of the OKTOSTOP command. If you spin the handwheel, the operator wants the axis to stop shortly after spinning stops. Its set to 2 seconds in the Camsoft macro. Without this, its easy to get several 100 thou of motion after the handwheel stops. The real trick with the handwheel is getting smooth but snappy motion, got to play with speed and acceleration quite a bit.
 
Great observation. And it doesn't need it. I did have this problem in the first iteration of the code, but changed it so the axis exactly tracks the MPG encoder in real time. Maximum possible lag is about 2 ms no matter how fast or slow you turn the handwheel. When the handwheel stops turning the carriage stops almost instantly. It is not physically possible to turn the handwheel faster than the system will react.

Interestingly, the Haas will overrun if you turn it's handwheel too fast. Bad programming on their part, this caused a couple of broken tools until we learned to approach the work more slowly.
 
You must log in or register to reply here.
Back
Top