[George Butty]

Hi Tom

Last set of files were from a step responce that worked under all values. This is a set of data that faults most of the time after startup.

George

[TomKerekes]

Hi George,

Thanks for the plots. Unfortunately it still isn't clear to me what is going on. I think there are a few issues mixed together making it confusing. If it becomes too frustrating we could arrange a time to connect into your machine and hopefully track down what is going on.

But here are my thoughts:


Issue #1 - Acceleration too high - Jerk too Low
---------------------------------------------
The very last plot that shows overcurrent faults is simply you have too high of Max Acceleration specified (4e6 counts/sec2). On a long move the acceleration (acceleration=torque=current) continues to ramp up until it hits the peak current limit fault. On a small move the current doesn't get a chance ramp up to a level that causes a fault. Your Jerk setting is very low (9e5). This means it would take 4e6/9e5= 4.4 seconds to ramp the acceleration up to max. This doesn't make sense. You are inadvertently keeping the acceleration low by making it ramp up gradually rather than properly limiting it to a proper level. Keep the Max Jerk setting to a numeric value of ~ 10X the Acceleration so the max acceleration gets applied quickly in 1/10th of a second.

Issue #2 - no Low Pass filter
---------------------------
Your PID gains are fairly aggressive (high) and there is no Low Pass filter. With a D gain of 30 a single encoder count change will create a spike 30 high in the output for one servo sample. Add a 2nd order low pass filter into IIR filter #2 of around 500Hz and Q=1.4 to smooth out the spikes in the output.


Issue #3 "start up glitch"
------------------------
Some of the plots show what might be the "start up glitch" at Time=0 where the current spikes up to ~12A. BTW Enabling from the Step Response Screen is similar but not exactly like immediately after Homing to the index.

My guess is that the disturbance on suddenly enabling the servo is causing the peak current to trip (as we discussed earlier) but your plots don't really show it happening (although I don't really understand what there would be that big of disturbance when enabling the Servo).

Reducing the MaxOutput prevents the peak current from tripping but introduces another problem - the output saturates and results in what is often called limit cycle oscillation (output switching/slamming from +Max to -Max).

There are several strategies that could be used such as:

#1 Reduce the disturbance - (I don't think you never tried the technique I described in the previous email where we added the delay after the Index, waited for things to settle and stop, then enabled the servo to the Destination of where we stopped).

#2 Make the Servo performance more stable and able to handle disturbances without current faulting. Reducing the Max Error value to a few counts may help with this. Test using a "Step" Test of ~20 counts to see if a fault is generated.

#3 Initially Enable with a reduced set of PID+Filters that is very stable and less aggressive. Then later after the servo is operational and settled out switch to higher performance PID+Filters.


Please let me know how much of this makes sense :}

Regards

[George Butty]

Hi Tom

I have a reasonable idea were to go from here. I will try some of the things you suggested and see were it goes. Yes, I also think that my start up perameters are to agresive and that may be causing these problems.
On issue 3, item 1. I have tried starting at destination that is read after the dwell time with the same start problem. As soon as I set the max output to 200 it would over current most of the time. So I tried stepping up the maxoutput values in a .5 sec incrument,and increasing the value 6times untill I reached 200. This got rid of the over current surge but the motor would fault out most of the time when I would go to high speed jogs. I do like your idea of going to higher performance value after the system becomes stable. Will give it a shot tomorrow and let you know.

Thanks

George

[George Butty]

Hi Tom

I spent some time on retunning the machine. I lowered the acc. and increased the jerk . At this point I am running 16 times more jerk than acc.. Also reduced the P and D vaues , starting at a lower output value and then increasing to 200 at set destination postion. This seems to working well for preventing overcurent at startup and I am getting good performance while going through a program. I am still having problems with an unrealible initialization.
The unit does not overcurrent at startup but at times after initialization, the unit over currents at high speed jogs. I narrowed down the problem to the index pulse not being set high at the time of system enabling. I watched the I/O screen and payed attention to input 72 and 73 which is the two index inputs for the axis giving me the problem. After the startup program finnishes, 50% of the time both inputs become high and every thing works fine. If one of the inputs do not go high after the time of startup, then I get a overcurrent if I were to jog at high speed. What I suspect is, by the time the system gets enabled, the motor shifts from the zero postion and it initializes at a point where it is too far from the ideal startup position. Yes I know we are initializining at set position but I am quite sure that this positon is to far away from the idea location. I am aslo using an unorthidox chain drive system which has preloaded chains.This gives me a zero backlash drive which works great.
One of the down falls of this drive is that the preload puts extra startup load on the motors. It is this preload that is causing the motor to move after the stepper function is disabled.

1) Is it possible to get the stepper to hold position for some set period of time so the motor would not shift unitl the unit has been enabled?

2) The second option would be to run the unit in servo mode at a very slow speed (which it does all the time) and look for the index pulse. Stop and hold until we reinitialize at the proper position. If I were to do this, what parts of the program would have to be repeated to reinitialize and can it be done without shutting down the servo hold?

George

[TomKerekes]

Hi George,

It sounds like you are making progress and thanks for all the clues.

The over current at high speed is probably caused by the commutation being a bit off. The commutation can be wrong if the commutation offset is set to the wrong number (unlikely) or if the encoder is not zeroed at the index mark properly.

I can’t understand how either of these things could be happening. As soon as we see the index mark we instantly zero the encoder position (within 0.001 sec). It should not matter how far the motor moves afterward to come to a stop. Jerky motion due to friction in your chain drive should not cause a problem. Regarding your question: it isn’t really possible to hold position when moving like a stepper motor. The motor pole is very weak, sloppy, and springy. It is like pulling on a sled with a spring. We could stop advancing the coils but that wouldn’t really guarantee much.

It is hard to tell if the Digital IO screen doesn’t show the index mark how far we are really off – and more importantly how far encoder position zero is from the index mark. The index mark is probably only about one or several encoder counts wide. Please do some experiments. When the index mark is not indicated use the Console Screen to move one Encoder count at a time until you find where the Digital IO screen indicates the Index Mark (MoveRel0=1). You might also determine the width of the mark. I have also attached a C Program to move slowly until it finds the Index Mark, print the encoder position where it was found, and re-zero the Encoder. This will help us understand if that is really the problem.

Thanks

[George Butty]

Hi Tom

Finally we hit the mark. Did at least 6 cold restarts with no problems. It definatley had to do with the zeroing of the index pulse. I checked the band width of the index pulse and it is only 2 counts. Your program is exactlly what I had in mind. I placed it at the end of each axis startup routine and it works perfect. I am not sure why the first initialization is not adiquite because what you said about catching the pulse on the first pass should have been enough. Obviously that is not the case.
I think I can move on now. I did get Mach3 going and am wondering if the change in feed rate can be set on the fly? I can see the delay in speed change could be a problem when cutting long distances.


Thanks

George

[TomKerekes]

Hi George,

Great. I still don't understand it. Maybe noise on the Index? But I don't argue with success.

We don't have instant feed rate changes. It is hard because feedrate changes affect velocities and accelerations so the paths need to be re-trajectory planned. You can minimize the delay by setting the amount of Window's buffering to the minimum that will work reliably for your system.

We do have instant feedhold/resume.

Regards,

[George Butty]

Hi Tom

Things are going well. The startup issues seem to have gone away. I do have overcurrent problems somtimes on high speed jogs but that goes away after a reboot of the system. When I do my finnal tunning of the machine I will put a scope on the index pulse to see how bad the noise is on the signal. At this point I am more interested in finnishing the machine. Just have a few questions.

1) How can I set the deccel rate for the limit switches. A little softer stop would be nicer.

2) Can I stop the controller from disabling the unit when it hits a limit, or is there a way to reanable in Mach3

3) Will your software and Mach3 run in Windows 7. Would like to settup a new computor to run the system.

Thanks
George

[TomKerekes]

Hi George,

We don't have a way to set the decelleration rate for hitting limit switches. The axis is simply disabled. If you have separate limit switches on both ends of the travel then you can uses the "Disable Drive into Limit" option. This will allow you to reset (Re-initialize) from within Mach3 and the axes will remain enabled while still in the limit as long as no motion is generated to move further into the limit.

Yes you can use W7 with Mach3 and KFLOP.
Regards

[George Butty]

Hi Tom

I am using "Disallow drive into limit" . When the limit is tripped, I have to go into Axis to enable the tripped axis to get it to move, both in the console mode and Mach3. The limits swicth setting for my X-axis is "ch0->LimitSwitchOptions=0x4a4b0013;" Would this be correct?

I am also assuming if I wanted too I could write a C program to soften the blow on stopping . At the moment I can jog at 700 inches/ min. I can get it up to 1000 inches /min. by raising my power supply voltage to 75 volts.

Thanks

George

[TomKerekes]

Hi George,

The limit switch settings look correct. It should be possible for your Init.c program which is called by Mach3 RESET to do whatever is necessary to re-enable your axes.

I suppose the issue is that the normal Init.c program performs the brushless phase finding and other things that are unnecessary after simply hitting a limit?

I can't think of an easy way to know whether we have already performed the phase finding and everything is ok and all that is necessary is to re-enable vs starting from scratch. Maybe we just set a global flag after completing phase finding successfully?

What exactly is your Mach3 RESET programmed to do and what happens?

Regards
TK

[George Butty]

Hi Tom

I seem to be having trouble finding file Inti.c on my computor. Also I am running the mach3 reset in it's default state. How would I go checking the programed conditions on the reset button. I am also running two switches per axis.

I don,t think we have to reset from the start if I hit a switch. Once I hit a switch, the reset button starts flashing and I get a Z-axis disabled in the status field. I would go into KMotion to enable the axis and then it will come off the switch with no problems in Mach3.

[TomKerekes]

Hi George,

The Init.c name was only an example. The idea is to create a C program (that can have any name - ie. InitializeGeorge.c) that completely initializes your system. It usually includes setting all the axes channel parameters, enabling amplifiers, enabling axes, defining the Axes in the coordinate system, and anything else required by your particular system. This program is then assigned to be executed by the Mach3 RESET button. The program to be used is specified in the Mach3|Config Plugins|Dynomotion Screen. Once all this has been created there is no longer any need for the Operator to use the KMotion.exe setup program. He/she just powers up, runs Mach3, Pushes RESET and everything is ready to go. Do you have this much working?

Regards

[George Butty]

Hi Tom

Ok, I know what you are talking about now. Yes I set up an Init.c program to run in Mach3. I have it set to only run on the initial startup of Mach3. I don,t what to run it every time I hit a limit, since somtimes it takes 10 to 15 sec. to complete. Is it possible to get the reset button to just enable the drive without having it go through the startup sequence every time?
Also if I hit a limit or hit the stop button in Mach3 while the machine is running in a G -code program, the controller overcurrents and then I do have to do a full restart to get the machine running again. Any idea what would be causing this?

[TomKerekes]

Hi George,

I'm surprised you are hitting the limits so often that a few seconds to recover would be an issue.

You might consider adding a new button to your Mach3 screen to be used to re-enable your axes instead of a full reset. The new button could be programmed with something like:

NotifyPlugins(10109)

and then a case in the NotifyMach3.c program for 10109 could execute:

EnableAxis(0);
EnableAxis(1);

I think this might also handle the case with an overcurrent but you may need to disable the axis, wait for the fault to go away, and then re-enable the axis.

HTH
TK

[George Butty]

Hi Tom

The only reason I am chasing this is I have a few other machines that handle the limit stops differently and I am just comparing the two. I do like your solution to adding a button to Mach3 and then I can get it to run the way I like. I will play with that later. You are right, so I have to wait a few seconds to restart.

George

[George Butty]

Hi Tom

I am working on setting up the THC for my machine. I am slowly starting to understand how to go about doing it. Before I go any futher I would like your input on how I should approach doing this. I have a plasma machine that will take a start comand, will send a running comand once unit is fired and also send an analog max 7volt output . That output will vary depending on arc distance from the cutting surface. I read the thread that was posted on using a dual loop control setup. Would that be the best way to go. If so you posted 4 .c programs and I understand the init.c program but I am not sure were the rest of the programs are set to run. Are they also combined into the init.c program or are they set into the notifymach3.c program?

Thanks
George

[TomKerekes]

Hi George,

I think you are referring to this Post about dual loop height control.

Yes I think the dual loop would be the best approach.

Regarding the 4 files: for Mach3 the enable dual loop and disable dual loop code would be incorporated into the NotifyMach3.c program. You could then create 2 macros to do NotifyPlugins() to trigger the code to execute. The LinkChannels.c code would be added to a loop at the end of your Init.c program.

I suppose the operations to fire the head and wait for the “running signal” could be added to the enable code. Or it could be added to the M3 Spindle On code in the SpindleMach3.c file.

Regards

[George Butty]

Hi Tom

I am working on setting up the THC for my machine. I can't seem to figure out how to connect my ADC signal to the controller. Any suggestions?

George

[TomKerekes]

Hi George,

To feed an analog signal into KFLOP you would need to add our Kanalog Analog I/O board. SnapAmps do not provide any analog inputs. The only other option would be to use some 3rd party ADC converter and feed in the value digitally somehow.

Regards