Kmotion auto disconnect when sending signals via Step Response

I have been tuning my motors for the last couple of days and having some success, except I really have hit a wall with regards to Kflop disconnecting from my computer when moves of a certain size or speed are sent to the board. I am using a Snapamp 1000 as an amplifier, and I am currently running two DC servos (MCG 1D-3303). Things seem to be going fine until I reach a certain threshold, usually a size move of 100000 or more and velocity over 80000. I suspect that the motor leads are somehow interfering with the USB, but I can't seem to sort it out. The motor cables are shielded and grounded to the control cabinet. Any help here is greatly appreciated.

Hi Spank,

What kind of motor power supplies do you have? Are they isolated from earth GND? How are you powering KFLOP+SnapAmp?

Does KFLOP Reset? (LEDs Flash?) Or does Windows disconnect the USB Device?

How much mass are you moving? Could it be a regenerative braking issue?

Regards

Hi Tom. My motor power supply is similar to this PMDX.COM - Products for CNC and motion control applications. I have an older version of their 80vdc power prep module. This is fed AC via a large Torroid transformer that is dropping 110V ac to 60 or so, I don't remember exactly the specs. At any rate, The PMDX is putting out a steady 80VDC. As far as I know it's isolated from ground. Kflop is getting power from a dedicated 5vdc supply that I got from a local electrical surplus. I think it's a switching supply, although I'm not entirely sure. Again, I think that's isolated as well. I don't know if Kflop is resetting because I am looking at my screen when it happens. This is something I can look for tonight when I get back to the shop. If it means anything, I do have to rerun my SnapAmp current limits C program before testing again. Kflop automatically reconnects after the autodisconnect. How would I know if it was a regenerative braking issue? Are you saying that motors might be backfeeding to snapamp? If so, what makes me think that that isn't the case is that It can disconnect if I send a big enough move before It starts to return back to zero. Also, right now there very little mechanical load attached to the motors right now... ie, I have been testing my X axis motors (one slaved to another), and I have them disengaged from the rack until I feel comfortable with how the motors are tuned... Obviously I'm not there yet!

-Spank

Quote:

---

Originally Posted by TomKerekes

Hi Spank,

What kind of motor power supplies do you have? Are they isolated from earth GND? How are you powering KFLOP+SnapAmp?

Does KFLOP Reset? (LEDs Flash?) Or does Windows disconnect the USB Device?

How much mass are you moving? Could it be a regenerative braking issue?

Regards

---

Hi Spank,

It sounds like your supplies are indeed isolated from earth GND, but it is a simple matter to test with an ohm meter.

Do you have any other Earth GND connections?

It also sounds like KFLOP is being reset if the SnapAmp Peak current settings are being reset. Another way to verify this is to do something like turn off a KFLOP LED (Bit 46 or 47). If the LED turns back on then most likely KFLOP was reset. What Rev of KFLOP do you have? Rev 1.3 has a filter Capacitor on Reset which can reduce the susceptibility of a spurious reset especially when long ribbon cables are connected to the KFLOP connectors.

How much current is your +5V supply rated for?

Regards

Hi Tom,
What should I look for with my ohm meter to see if I am actually isolated? My cabinet has a star ground to "earth" that the machine is is grounded to. I put earth in quotes because at my new place, I don't know for sure if my ground is truly a stake in the ground or equivalent. Right now my star ground runs back to my electrical panel ground, which is the closest thing I can find to ground. I am more than happy to install a ground stake, but it will be a few months before that takes place given the epic snow I have outside at the moment. Perhaps this is part of the problem? I will try the LED reset test. I will check to see what rev of Kflop I have. I'm pretty sure I was running the latest version from my laptop when I started tuning, and in an effort to see if reverting to an older version might make a difference, I reflashed Kflop with a previous version from my desktop machine to no avail. You mentioned the ribbon cable, and that is interesting. I had to use a longer ribbon cable that what I had previously when I had Kflop mounted directly on top of Kanalog. With the snapamp I had to use a longer cable that I had, and perhaps that is an issue. When I say longer, it's not excessively long, but necessarily than what I had connected previously.
Spank

Hi Spank,

Quote:

---

What should I look for with my ohm meter to see if I am actually isolated?

---

If two circuits are isolated (not connected together) then the resistance between the two circuits should be very high (more than 100K Ohms). But if the circuits are connected together then the resistance should be low (less than 5 ohms).

In some cases ground circuits are intentionally connected together. For example DC GND and Earth GND. However it is usually important that the grounds are only tied together at one place as intended. Multiple connections can cause currents to take unintended paths. These are referred to as Ground Loops. So a good test is to remove the intentional connection and test that the circuits are indeed isolated. If the Ohm meter still shows a low resistance then there is another connection someplace.

A special, separate ground stake is usually not required. What is usually more important it how, how many, and where the ground connections are made.

Please try and reduce the ribbon cable lengths as much as possible. SnapAmp comes with a short 18 Gauge DC GND wire to KFLOP. Make sure that is connected properly as well.

Regards

Quote:

---

Originally Posted by TomKerekes

Hi Spank,

If two circuits are isolated (not connected together) then the resistance between the two circuits should be very high (more than 100K Ohms). But if the circuits are connected together then the resistance should be low (less than 5 ohms).

In some cases ground circuits are intentionally connected together. For example DC GND and Earth GND. However it is usually important that the grounds are only tied together at one place as intended. Multiple connections can cause currents to take unintended paths. These are referred to as Ground Loops. So a good test is to remove the intentional connection and test that the circuits are indeed isolated. If the Ohm meter still shows a low resistance then there is another connection someplace.

A special, separate ground stake is usually not required. What is usually more important it how, how many, and where the ground connections are made.

Please try and reduce the ribbon cable lengths as much as possible. SnapAmp comes with a short 18 Gauge DC GND wire to KFLOP. Make sure that is connected properly as well.

Regards

---

Hi Tom,
I checked the isolation of my two circuits, and it appears that they are indeed isolated. Both my 5VDC and 80VDC are isolated from Earth ground. I was sort of hoping that I would find that they were not isolated, as I would have something more or less clear to sort out. I set bit 46 to off, and it appears that Kflop is indeed resetting, which is causing the USB disconnect.

Hi Spank,

It seems KFLOP is being reset. This is might be caused by a noise glitch coming in to Reset through one or more of the Connectors/cables. Or by a +5V supply problem or ground noise.

I didn't see that you ever answered my previous questions:

What Rev of KFLOP do you have? Rev 1.3 has a filter Capacitor on Reset which can reduce the susceptibility of a spurious reset especially when long ribbon cables are connected to the KFLOP connectors.

How much current is your +5V supply rated for?


Also measure the +5V voltage. What is it? How long are the wires?

You might take a picture of the boards layout for us to have some idea of how things are arranged.

Regards

Quote:

---

Originally Posted by TomKerekes

Hi Spank,

It seems KFLOP is being reset. This is might be caused by a noise glitch coming in to Reset through one or more of the Connectors/cables. Or by a +5V supply problem or ground noise.

I didn't see that you ever answered my previous questions:

What Rev of KFLOP do you have? Rev 1.3 has a filter Capacitor on Reset which can reduce the susceptibility of a spurious reset especially when long ribbon cables are connected to the KFLOP connectors.

How much current is your +5V supply rated for?


Also measure the +5V voltage. What is it? How long are the wires?

You might take a picture of the boards layout for us to have some idea of how things are arranged.


Regards

---

Hi Tom,
Sorry for not answering your earlier questions. My Kflop is Rev 1.2, so I guess mine is more susceptible to spurious reset with longer ribbon cables. My 5VDC supply is rated at 25 watts, or 5 amps. I am getting anywhere from 5v to 5.17v coming out of the supply. Interestingly, when I measure one of the 5v terminals on Kanalog, I'm getting 4.8 volts. The 5v supply wires from the terminal bus to the Kflop is probably 18 inches to two feet. I am getting 5.17VDC at JR1. I will post up a picture when I get a chance.

Thanks,
Spank

Hi Spank,

I supect it is noise coming in the Reset line on the connectors as your Supply's current capability and voltage levels seem fine.

You might try adding a 0.001uF ceramic capacitor on the reset line as close as possible to KFLOP. One approach is to crimp an extra ribbon cable connector on one of the ribbon cables near KFLOP. KFLOP JP4 and JP6 have Reset on pin 4 and GND on pin 8. The capacitance value is not critical. See this older Thread on our Yahoo Group.
https://groups.yahoo.com/neo/groups/.../messages/9011

Attachment 271352

Regards

Thanks Tom,
I added a capacitor as you suggested today, and now I get a window that pops up when I attempt to run my Snap Amp Current limits Cprogram which says that the menu options do not match the attached board type. If I go to my analog I/O, I can see my snap amp attached and receiving supply voltage, but I am unable to send anything through the SnapAmp because I am now unable to enable it via the console.

Disregard that. I realize I had Kflop unselected in the menu. As far as I can tell, the cap seems to have done the trick! Thanks for your patient support as always Tom.

-Spank

This evening I have run into another disconnect issue. After installing the capacitor on the reset line for JP4 on Snapamp, everything runs fine on my X axis (2 DC Servos, rack and pinon gantry setup. One slaved to the other). Tonight I hooked up my Y motor. It's the exact same motor that I have on both sides of the X. After wiring it, whenever I send my current limits C program to Snapamp, I get an immediate auto disconnect, and I also will then hear a faint clicking noise until I turn off my cabinet and recycle the system. When I disconnected the leads running to the Y servo, this problem disappeared. I rechecked my leads,and everything looks correct. Any ideas?

-Spank

Hi Spank,

Sounds like an immediate over current for the Y Motor. Have you checked the Y motor and the Wiring. Check with an Ohm meter for shorts of the motor leads to shields or GND.

What does your enable SnapAmp Peak Current Limits Program do? Anything beyond setting the limits? Post it.

Regards

Hi Tom,
Here is the program I am executing:


#include "KMotionDef.h"

main()

{

// peak current limits

WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT0,12);

WriteSnapAmp(SNAP0+SNAP_PEAK_CUR_LIMIT1,12);

// clamp supply to 90V

WriteSnapAmp(SNAP0+SNAP_SUPPLY_CLAMP0 ,SNAP_CONVERT_VOLTS_TO_ADC(90.0));

WriteSnapAmp(SNAP0+SNAP_SUPPLY_CLAMP1 ,SNAP_CONVERT_VOLTS_TO_ADC(90.0));

// enable supply clamping

WriteSnapAmp(SNAP0+SNAP_SUPPLY_CLAMP_ENA0 ,1);

WriteSnapAmp(SNAP0+SNAP_SUPPLY_CLAMP_ENA1 ,1);

}


So far I haven't been able to find any shorts on the leads to the motor.

-Spank

OK,
I disconnected the motor from the cable running from my cabinet to where it connects when the motor is installed. I reconnected the short leads running direct from the motor to SnapAmp, and I eliminate the error, so obviously there is something happening between my cabinet and where the motor sits that I have to chase down.

-Spank

I spent the better part of this weekend getting my motors setup and tuned after sorting out my cabling issue. It appears that one of my servos isn't functioning properly. It is exactly the same spec as the two motors I have running on my X axis, but for some reason I can't find a set of parameters that give me anything close to adequate step response. Luckily, I had another motor from the same manufacturer (MCG), that I originally was going to use on the Z axis, but I decided a while back that the Z will remain stepper based. The smaller motor worked beautifully. I will start another thread regarding the seemingly bad servo, but here I really wanted to get some guidance on why I can't seem to execute Gcode commands in KmotionCNC. With my X and Y axes enabled, I can jog in KmotionCNC, but if I try to send a G0 command from the command line, nothing happens. Similarly, if I try to run a simple Gcode program, for say a rectangle, the program seems to run on the screen, but nothing happens at the machine. Again, I am still able to jog. Am I missing something on my init.c program? Here is my Init.c program. Note, that I am enabling the Z axis, even though I don't have the parameters set in the file yet.

Code:

---

#include "KMotionDef.h"

main()
{
       
       

                        ch0->InputMode=ENCODER_MODE;
        ch0->OutputMode=DC_SERVO_MODE;
        ch0->Vel=80000;
        ch0->Accel=200000;
        ch0->Jerk=5e+006;
        ch0->P=6.4;
        ch0->I=0.01;
        ch0->D=40;
        ch0->FFAccel=0;
        ch0->FFVel=0;
        ch0->MaxI=0;
        ch0->MaxErr=100000;
        ch0->MaxOutput=1000;
        ch0->DeadBandGain=1;
        ch0->DeadBandRange=0;
        ch0->InputChan0=0;
        ch0->InputChan1=0;
        ch0->OutputChan0=8;
        ch0->OutputChan1=0;
        ch0->MasterAxis=-1;
        ch0->LimitSwitchOptions=0x100;
        ch0->LimitSwitchNegBit=0;
        ch0->LimitSwitchPosBit=0;
        ch0->SoftLimitPos=1e+009;
        ch0->SoftLimitNeg=-1e+009;
        ch0->InputGain0=1;
        ch0->InputGain1=1;
        ch0->InputOffset0=0;
        ch0->InputOffset1=0;
        ch0->OutputGain=1;
        ch0->OutputOffset=0.002;
        ch0->SlaveGain=1;
        ch0->BacklashMode=BACKLASH_OFF;
        ch0->BacklashAmount=0;
        ch0->BacklashRate=0;
        ch0->invDistPerCycle=1;
        ch0->Lead=0;
        ch0->MaxFollowingError=1000000000;
        ch0->StepperAmplitude=20;

        ch0->iir[0].B0=1;
        ch0->iir[0].B1=0;
        ch0->iir[0].B2=0;
        ch0->iir[0].A1=0;
        ch0->iir[0].A2=0;

        ch0->iir[1].B0=1;
        ch0->iir[1].B1=0;
        ch0->iir[1].B2=0;
        ch0->iir[1].A1=0;
        ch0->iir[1].A2=0;

        ch0->iir[2].B0=0.00296047;
        ch0->iir[2].B1=0.00592094;
        ch0->iir[2].B2=0.00296047;
        ch0->iir[2].A1=1.84173;
        ch0->iir[2].A2=-0.853569;



       
       
        EnableAxisDest(0, 0);
       
       
        ch1->InputMode=ENCODER_MODE;
        ch1->OutputMode=DC_SERVO_MODE;
        ch1->Vel=80000;
        ch1->Accel=200000;
        ch1->Jerk=5e+006;
        ch1->P=6.4;
        ch1->I=0.01;
        ch1->D=40;
        ch1->FFAccel=0;
        ch1->FFVel=0;
        ch1->MaxI=0;
        ch1->MaxErr=100000;
        ch1->MaxOutput=1000;
        ch1->DeadBandGain=1;
        ch1->DeadBandRange=0;
        ch1->InputChan0=1;
        ch1->InputChan1=0;
        ch1->OutputChan0=9;
        ch1->OutputChan1=0;
        ch1->MasterAxis=0;
        ch1->LimitSwitchOptions=0x100;
        ch1->LimitSwitchNegBit=0;
        ch1->LimitSwitchPosBit=0;
        ch1->SoftLimitPos=1e+009;
        ch1->SoftLimitNeg=-1e+009;
        ch1->InputGain0=1;
        ch1->InputGain1=1;
        ch1->InputOffset0=0;
        ch1->InputOffset1=0;
        ch1->OutputGain=1;
        ch1->OutputOffset=0.08;
        ch1->SlaveGain=-1;
        ch1->BacklashMode=BACKLASH_OFF;
        ch1->BacklashAmount=0;
        ch1->BacklashRate=0;
        ch1->invDistPerCycle=1;
        ch1->Lead=0;
        ch1->MaxFollowingError=1000000000;
        ch1->StepperAmplitude=20;

        ch1->iir[0].B0=1;
        ch1->iir[0].B1=0;
        ch1->iir[0].B2=0;
        ch1->iir[0].A1=0;
        ch1->iir[0].A2=0;

        ch1->iir[1].B0=1;
        ch1->iir[1].B1=0;
        ch1->iir[1].B2=0;
        ch1->iir[1].A1=0;
        ch1->iir[1].A2=0;

        ch1->iir[2].B0=0.000769;
        ch1->iir[2].B1=0.001538;
        ch1->iir[2].B2=0.000769;
        ch1->iir[2].A1=1.92081;
        ch1->iir[2].A2=-0.923885;



       
        EnableAxisDest(1, 0);
               
                ch2->InputMode=ENCODER_MODE;
        ch2->OutputMode=DC_SERVO_MODE;
        ch2->Vel=80000;
        ch2->Accel=200000;
        ch2->Jerk=4e+006;
        ch2->P=7.4;
        ch2->I=0.009;
        ch2->D=40;
        ch2->FFAccel=0;
        ch2->FFVel=0;
        ch2->MaxI=3;
        ch2->MaxErr=1e+009;
        ch2->MaxOutput=600;
        ch2->DeadBandGain=1;
        ch2->DeadBandRange=0;
        ch2->InputChan0=2;
        ch2->InputChan1=0;
        ch2->OutputChan0=11;
        ch2->OutputChan1=0;
        ch2->MasterAxis=-1;
        ch2->LimitSwitchOptions=0x100;
        ch2->LimitSwitchNegBit=0;
        ch2->LimitSwitchPosBit=0;
        ch2->SoftLimitPos=1e+009;
        ch2->SoftLimitNeg=-1e+009;
        ch2->InputGain0=1;
        ch2->InputGain1=1;
        ch2->InputOffset0=0;
        ch2->InputOffset1=0;
        ch2->OutputGain=1;
        ch2->OutputOffset=-0.2;
        ch2->SlaveGain=1;
        ch2->BacklashMode=BACKLASH_OFF;
        ch2->BacklashAmount=0;
        ch2->BacklashRate=0;
        ch2->invDistPerCycle=1;
        ch2->Lead=0;
        ch2->MaxFollowingError=1000000000;
        ch2->StepperAmplitude=20;

        ch2->iir[0].B0=1;
        ch2->iir[0].B1=0;
        ch2->iir[0].B2=0;
        ch2->iir[0].A1=0;
        ch2->iir[0].A2=0;

        ch2->iir[1].B0=1;
        ch2->iir[1].B1=0;
        ch2->iir[1].B2=0;
        ch2->iir[1].A1=0;
        ch2->iir[1].A2=0;

        ch2->iir[2].B0=0.00169702;
        ch2->iir[2].B1=0.00339403;
        ch2->iir[2].B2=0.00169702;
        ch2->iir[2].A1=1.88124;
        ch2->iir[2].A2=-0.88803;
       
       

        EnableAxisDest(2, 0);

       
               

       


DefineCoordSystem(0,2,3,-1);



        return 0;
}

---

Hi Spank,

I don't see anywhere that you enable Axis 3. I see where you include Axis 3 in the Coordinate System. You shouldn't enable or include axes in the coordinate system that are not configured. Try removing the disabled and undefined Axis from the Coordinate System with:

DefineCoordSystem(0,2,-1,-1);

Please indent your programs consistently so that it is easier to read and check for errors.

Regards

Thanks Tom.

That was indeed the problem. I had actually defined the coordinate system as you suggested initially, but I had an issue when I ran the program with my motors clicking, and I attributed that to my coordinate system. Sorry about my program being sloppy; I will be more careful in the future if I post up some code.

-Spank