Another "what do I need" thread. Vmc retrofit
The computer I have there for cad/cam and now for reading lots of pdf's was bluescreening like crazy today If you got it started you could be sure it would crash within the hour.. SSD's are fast and quiet but none of my computers whit them are working as stable as HDD's.
I did almost go mad when I was trying to tune the PID settings today.. Got it quite good, forgot to save and restarted Linuxcnc And now I cant get it as good again
Max velocity is set to 10m/min
Acceleration is set to 1000mm/s²
I got those numbers from the machine manual.
This is where I left it anyway. If I read the graph correctly then the axis is off by ~0.18mm under acceleration. Suggestions are appreciated
I did get homing to work though.
And some more info on the tool changer:
-It takes 8 seconds for the carousel to do a full revolution.
-The carousel can be quite off position and still be "pushed" to the correct spot by the lock pin
-The hydraulic pump that activates the drawbar has one way valve in series so the pump only need to run until the "drawbar is fully extended" sensor senses that. Then a electronic valve releases the pressure when you want to retract the drawbar.
- Z needs to be at +10 from its home switch to clear tools in the carousel
this sample is for 3 axis machine with joint 0,1,2
first need to put in your ini file:
# this is the minimum acceleration limit, your machine is set this in startup
MINIMUM_ACCELERATION = 350
# this is the limit of maximum acceleration
MAXIMUM_ACCELERATION = 700
and add this to postgui halfile,
or make a new file named "postgui_halfile.hal" :
loadrt wcomp count=1
loadrt mux4 count=1
addf wcomp.0 servo-thread
addf mux4.0 servo-thread
setp wcomp.0.min [POSTGUI_PARAMS]MINIMUM_ACCELERATION
setp wcomp.0.max [POSTGUI_PARAMS]MAXIMUM_ACCELERATION
net accel-out-mux-sel0 mux4.0.sel0 <= wcomp.0.under
net accel-out-mux-sel1 mux4.0.sel1 <= wcomp.0.over
net m68-e0-q wcomp.0.in <= mux4.0.in0 <= motion.analog-out-00
setp mux4.0.in1 [POSTGUI_PARAMS]MINIMUM_ACCELERATION
setp mux4.0.in2 [POSTGUI_PARAMS]MAXIMUM_ACCELERATION
setp mux4.0.in3 [POSTGUI_PARAMS]MAXIMUM_ACCELERATION
net accel-out-mux ini.0.max_acceleration <= ini.1.max_acceleration <= ini.2.max_acceleration <= mux4.0.out
last thing is check your ini file HAL section POSTGUI_HALFILE = postgui_halfile.hal
now program "M68 E0 Q###"
Q number is the acceleration
a program is not running
The per-axis max_velocity and max_acceleration pins are sampled when the machine is on and the motion_state is free (homing or jogging) but are not sampled when in a program is running (auto mode) or in mdi mode. Consequently, changing the pin values when a program is running will not have effect until the program is stopped and the motion_state is again free.
Ref: (2.7) www.linuxcnc.org/docs/2.7/html/config/em...l.html#_ini_settings
The pins may still be useful for changing the max_acceleration values without restarting, example, in
$ sim_pin ini.0.max_acceleration ini.1.max_acceleration
Do anyone have any suggestions on what to change to further decrease the following error? If I increase FF2 then the initial "peak" decreases but it overshoots like crazy just after. (the big dip on the graph)
You could try a faster servo-thread rate.
You might also find some of the discussion here interesting:
I was thinking that you could try doubling the rate, ie 2kHz servo-thread not 1kHz.
PCW has reported that that helps.
Also try plotting position-cmd and position-fb, see if it really is as bad as f-error suggests, the email discussion suggested that f-error calcs might be a bit wrong.