Issues with KmotionCNC

Hi Tom,

I've been having some issues with the new versions of KmotionCNC (4.33k and 4.33l) and was hoping you could shed some light.

The problem I've been having with both 4.33k and 4.33l is that a user program called by the gcode interpreter will hang at random. The problem is not repeatable and happens at random. Some days it doesn't do it at all. Today it has happened 3 times. Most of the time it has been an S command which hangs. The S command calls a user program to update the spindle jog speed. The gcode interpreter will just stay in that position. The way i've been managing to making the interpreter move past it was by opening up kmotion (not kmotioncnc) and closing it again. The gcode then continues forward in kmotioncnc. The more serious issue is when it hangs on a M5 command. The M5 user program is supposed to turn off the relays which controll the spindle drive. Most of the time it works but on rare occasions the spindle doesn't come to a complete stop. The DAC functions properly but the spindle continues to spin very slowly because the "Spindle Run" relay doesn't turn off. Looking at the digital I/O window in kmotion I can see that the bits are switched off(are in the state that they are supposed to be) but looking on the Konnect the LEDs for those outputs are still on. The only way I've managed to get out of this situation is to power cycle the kflop by shutting down the PC and turning it back on again. Not sure if it's a bug in the program or firmware or if it's being cause by EMI noise from the power supply or something else. The console shows no errors or messages.

Another issue I've been having is when my init program runs and the 2 Konnects are added and initialized the #1(second) Konnect begins to quickly toggle its outputs for a brief moment. I can hear the solenoids on the pallet changer firing away which are controlled by that board. I thought it might be a noise issue due to the length of the ribbon cable but then realized this never happened in KmotionCNC 4.32 and the #0 Konnect is stable and doesn't flicker it's outputs on startup like the #1 Konnect does.

The following are issues that I have ran into in 4.33l but not in 4.33k.

My home user program worked perfectly in 4.32 and 4.33k but an issue with the "move" function creates a follow error in 4.33l. The program has a number of Jog() commands which work fine but once the Move() command is reached it'll move the axis and then error out the axis because it exceeded max follow error. I then changed the Move() command to MoveAtVel() and set the velocity to something relatively slow. This lets the homing program work now but there is a hard thump at the end of the MoveAtVel() move which tells me that either the Acceleration or the Jerk values set in the init program are not being used. Its like the deceleration curve is a step rather than a ramp. What's weird is the axes work fine and decelerate properly when being controller through gcode and jog buttons and even my tool change user program, which uses Move() commands but the Move() commands in my homing program don't.

In 4.33k when i hit the halt button during a tool change the tool change would finish and the machine would wait at the next line of gcode which was fine. In 4.33l, when I hit the halt button during a tool change the axes would stop and the tool would unclamp with the toolholder falling out and then the next line of gcode would execute which was a spindle start command, and the spindle would start spinning while the spindle was unclamped. Essentially only some of the code from the user program was executed, out of sequence and then the next line of gcode was executed and at that point the program would halt. So now I'm afraid to use the halt button. Also hitting the halt button during an axis move makes the axis stop with a step deceleration rather than being ramped down smoothly. Not sure if that's the way halt was designed or if its supposed to decelerate the axis using the accel and jerk values.

Your advice would be greatly appreciated.

-Tom

I played around with the system today some more. I reverted back to 4.32 and am having the same issues with the gcode hanging on the M5 user programs. It seems to be a hardware issue as this is occurring more and more frequently. It eventually got to the point where the spindle wouldn't even turn on just after initializing the system. An M3 or M4 command would have no effect. Looking at the digital I/Os in Kmotion I can see that the I/Os associated with turning the spindle on get activated but the LEDs on the Konnect are not reflecting the state in Kmotion. So it's either the kflop or the konnect board. At this point I'm leaning more towards it being the kflop as the system would hang on S commands in the gcode and that has nothing to do with the Konnects. I would try to swap the two Konnect boards with each other to see if the problem changes but that would take a few hours to rewire everything and a good chance of mixing some of the wires up as none of them are labeled. Let me know what you think.

-Tom

Hi Tom,

All very strange. Please post all your programs and how they are configured so we can take a look.

One thought I had was that if you are printing Console messages and they are never read then maybe that could eventually cause a hang (although it shouldn't). That the only think I can think of that running an instance of KMotion.exe might do to free things up. When not debugging you might remove all prints.

Maybe there is some conflict in the Virtual I/O Bit settings? Which Digital I/O's are you using and looking at?

Do you realize the Konnect Terminals are pluggable, it shouldn't be too hard to swap.

With regard to ToolChanger M6 Halts: There have been some changes in that area. Previously a Halt that occurred during C Program MCode Actions like M6 would not be immediately recognized until further down in the GCode after some Motion. We felt this was a bug, but your scheme might have been using that to an advantage. It may take some work but I think the new scheme should be better. A Halt during a Tool Change should now stop any axis motion and Halt GCode on the M6 line. When continuing the Gcode the M6 will be repeated. In this case you will likely need to treat it like a special case and fix things up and resume where the Halt occurred.

Regards

Regards

Hi Tom,

I'm glad you brought up the removable terminals. I forgot they slid onto header pins. Made swapping the two Konnects really easy. After swapping the two Konnects the machine ran fine for the next two days without a hitch however the problem returned on the third day so by this point the Kflop that I order from you had arrived so I was able to swap those out. I noticed that the board I was using before was Rev 1.2 and the new one I received was Rev 1.3. The interesting thing was that the issue I was having with homing the axes and having that deceleration issue went away and now the homing program works as expected. I thought that maybe my kflop was bad and thought that that would fix the Konnect issue I was having.

Today I was running the machine and a similar issue occured where the Konnects became unresponsive. This time on the console an error message was displayed: "COMM ERROR AUX1 A4 (signature not A5)"

I looked around on the web and found https://groups.yahoo.com/neo/groups/.../messages/8999 and I noticed that the length of the ribbon cable was mentioned. I also noticed that Rev 1.3 had a filter cap to reduce noise? Could the length of my cable be the issue here and am being a victim of electrical noise? Will shielding the cable solve the issue or is crosstalk between neighboring lines on the ribbon cable the culprit? I will post a couple of pictures so you can get an idea of the setup and length of the cable.

http://www.cnczone.com/forums/attach...d=284504&stc=1

http://www.cnczone.com/forums/attach...d=284506&stc=1

Hi Thomas,

I would think that a bad KFLOP would be unlikely as it would be hard to imagine how KFLOP could be damaged in a way to still be functional but just more noise sensitive. I suppose it is possible.

The only difference in KFLOP Rev 1.3 and Rev 1.2 is that a filter capacitor on the KFLOP Reset line has been added to reduce the chance of noise coming in the connectors and resetting KFLOP.

The Konnect cables are a bit longer than I would like but that shouldn't be a problem.

Regarding COMM ERROR AUX1 A4(signature not A5). This would indicate a noise problem. Each 180us period the 5 bytes (32 inputs + signature) is read from Konnect and the signature should always be a hex A5 (10100101) pattern. The error indicates a A4 (10100100) pattern was read with an error in bit 0. If a signature error occurs the communication is halted and the Konnects must be re-initialized.

Shielding the ribbon cable may help although I'm not sure where to get shielded ribbon cable. Moving the ribbon cable away from those other cables may help.

You might try adding something like a 16 gauge GND wire between the GND Lugs on KFLOP and each Konnect.

Regards

Hi Tom,

Thanks for the input. I don't know where to get shielded ribbon cable either but I happen to have some braided copper cable shielding from a cable I took apart when removing the old controller from the machine. I managed to get the cable inside and soldered a wire to the end of it so I can ground the shielding. Hopefully this will do the trick. Only time will tell.

Attachment 284522

Attachment 284524

Thanks,
Tom

We are with high honored manufacture of shaft couplings and vacuum pump blowers used in CNC router.If you need them,I would like to quote you for your reference.Looking forward to your respond everybody.
Skype:z1990338416 Email:[email protected] Attn:kate Mob:86-15069159203

Hi Tom,

Nice. Where did you connect the shield? I would have made as short as possible connection to the KFLOP DC GND Lug.

Regards

The wire to the shield is connected to the ground connections on the power terminals to the left of the board. Thank you for the suggestion. I will try to rig something up and connect the wire to the Kflop GND lug.

Thanks,
Tom

Tom,

I also had many noise issues on my machine and tried to put additional filter caps on the J4 and J6 connector that goes to the ribbon cables to no avail. It got slightly better but still would pick up noise and hang up my system.

The answer was to add a ferrite core and have the ribbon loop through the core. These cores act as a resistor to EMI noise that can interfere with the KFLOP. See the photo below, as soon as I did this my machine was solid as a rock. I found these on ebay for pretty cheap and they work miracles.

Russ

Attachment 287434