Kogna Auto Disconnect - Requires Power Cycle

[griffinboyle]

Hello,

I am currently using a Kogna to control a noisy electric-arc-based metal-additive 3D printer prototype. In the past, we had used the KFLOP to accomplish this, and experienced somewhat frequent "Auto Disconnect" errors. After improving my grounding scheme, and providing a short wide ground strap right at the board, these reduced in frequency, but still occurred fairly often - this in part lead me to switch to the Kogna, as it operates over Ethernet and thus offered superior common-mode immunity compared to USB. This resulted in a noticeable reduction in the frequency of these Auto Disconnect errors, however came with new caveats. On the KFLOP, after the auto disconnect occurred, I had been able to restore connect by either disconnecting and reconnecting the USB, or by resetting the USB driver via an IO output and a jumper to the device pin. However, on the Kogna, disconnecting and reconnecting the Ethernet cable does not restore the connection, and ultimately requires a power cycle to restore connection. That being said, despite disconnecting from the KMotion application, and failing to respond to ping requests, the Kogna appears to otherwise be functioning completely normally and continues to run my firmware - responding to button presses that jog motors, and the likes.

Any ideas as to why this is happen/what can be done to mitigate it? Furthermore, any ideas as to how I can recover the Ethernet connection without a complete power cycle of the board?

Thanks,
Griffin Boyle

[TomKerekes]

Hi Griffin,

Sorry you are have problems we would like to resolve this.

Have any clues what causes the disconnect? When the machine is idle?

What Version are you using?

What type of PC do you have?

What type of network do you have? Direct connection? Is Kogna the DHCP Server? Or do you have a router?

What messages on the Virtual COM port?

My testing shows if I unplug the Ethernet to Kogna the Virtual COM port I get an Auto disconnect message and COM port shows "No Ethernet Link". Reconnecting shows "Ethernet Link Restored" and it reconnects properly:

Code: Select all

KOGNA 5.4.2 Build 11:04:43 Nov 10 2025
Flash Reading from Block 16...
Board Serial Number/Domain Kogna_SN214
IP Addr 0 request via DHCP
Searching for DHCP Server
DHCP Timed Out
KOGNA IP Address Assigned 192.168.113.100
KOGNA DHCP Server Started
multicast received from: 192.168.113.101 Kogna: 192.168.113.100
Com Buffer Flushed
DHCP  Request received MAC = 16 09 01 19 A6 81 Assigned 192.168.113.101
No Ethernet Link
Ethernet Link Restored
Searching for DHCP Server
DHCP Timed Out
KOGNA IP Address Assigned 192.168.113.100
KOGNA DHCP Server Started
multicast received from: 192.168.113.101 Kogna: 192.168.113.100
Com Buffer Flushed
DHCP  Request received MAC = 16 09 01 19 A6 81 Assigned 192.168.113.101

[griffinboyle]

Hi Tom,

Thanks for your reply - since thoroughly shielding my cables and providing a short, direct, DC bond to the chassis, the disconnects no longer appear to be provoked by the broad-spectrum noise resulting from the impulse trigger transformer waveform that we use to achieve breakdown across our spark gap, and are now a more rare event which seems to occur equally as often when idle as when actively operating.

I am using version 5.4.1, with the KMotion and KMotionCNC software running on a MinisForum PC using Windows 11. I have a direct Ethernet connection from the PC to the Kogna (no USB adapter or anything like that), with a static IP configured to circumvent any possible DHCP funny business, and with all of the "Power-Saving" and "Offloading" features disabled to ensure that the connection stays live and responsive (I had previously operated with the default features enabled, and had disabled these features as one of several attempts to reduce the frequency of disconnects).

I did recently (just the other day) find that I was able to recreate the observed behavior (Auto Disconnect which requires power cycle to restore Ethernet connection) by developing a static charge on my body and then discharging to an optocoupled output on the Kogna - I have since remedied this particular ESD-based disconnect source, but I am still suspicious that other potential sources remain. This has however provided me with a pretty repeatable method for entering aforementioned state, which bodes well for troubleshooting/testing recovery procedures, and potentially hints at the root cause - but the fact that this occurs even when the system is idle with no operator nearby to introduce a discrete ESD event gives me some pause... The ESD-based Auto Disconnects resulting from the optocoupled output I mentioned were resolved by providing a DC reference to the output (it is a camera trigger which is more recently often hot-swapped and left disconnected from the camera when video logging is not necessary, which results in the optocoupled output floating - as it was only provided with a DC reference when it was connected to the camera). That being said, all other Kogna IO which I either optically or galvanically isolate is already provided with a DC bond to earth ground, so I wouldn't expect similar behavior from any of my other IO. Nor would I imagine that, left to its own devices, a voltage difference could develop and reach the point where some form of ESD could occur.

I haven't been to directly observe the Kogna COM port output while one of these Auto Disconnects occurred, however I have observed the COM port after the fact, and attempted to disconnect and reconnect the Ethernet cable - even restarting the Ethernet device from the control panel - and observed no indication that the Kogna was aware of any this. I also tried, while in this state, resetting the Kogna IP address, in hopes that it might reinitialize the Ethernet MAC, to no avail. I was however able to capture the event in a Wireshark capture, but all I see is that the Kogna suddenly stops sending packets, and the KMotionServer eventually just starts searching for the Kogna again and getting no reply - and as mentioned in my previous post, I get no replies to any command prompt ping commands.

Any ideas on how I might go about restoring the Ethernet connection without power cycling?

Thanks for all of your help,
Griffin Boyle

[TomKerekes]

Hi Griffin,

One possibility is a noise glitch entering the peripheral RESET# signal that is on several connectors. Crosstalk on cables might cause a reset. The signal is an output only signal that is driven hard to 3.3V. If I short it to GND through a 10 Ohm resistor it causes the Ethernet to disconnect which doesn't recover if the cable is unplugged and restored. btw it takes ~200ma to force RESET low which exceeds the Absolute Max current for the RESET Driver so that really shouldn't be done.

This peripheral RESET# goes to the the Ethernet Transceiver IC. It does not reset the DSP. When I force reset the USB COM port shows "No Ethernet Link" and never reports a Link being present regardless if the cable is unplugged and resconnected.

We added a ResetEthernet function which basically resets the Ethernet Stack and re-establishes communication.

Code: Select all

#include "KMotionDef.h"

int main()
{
    ResetEthernet(); // Reset Ethernet Stack
}

Here is a Patched Version for V5.4.1. Copy these files to the DSP_KOGNA Folder:

DSPKOGNA.out
DSPKOGNA.bin
DSPKOGNA.sym
KMotionDef.h

Please let us know if this works for you.

[TFrenken]

Hi Tom,
I think I have the same problem as Griffin with noise resulting in a Reset of the ethernet connection and the DSP Working normal. So far I have hard wired the RESET# signals to 3.3V to cope with the disconnection issues. Of course I did all kinds of additional grounding inside the cabinet before to mitigate the problem. In my machine the connection reestablishes itself after some minutes if I did nothing.
Is there a way to get rid of the RESET# function altogether?

Regards,
Thomas

[TomKerekes]

Hi Thomas,

So shorting #RESET to 3.3V stops any disconnects for you? Could you provide more details? Where are you shorting it? Could you try cutting the #RESET wire near the Kogna Connectors to see if that also solves the problem? Another option would be to add a small Ceramic Cap (0.01uF) between reset and GND near a Kogna Connector. Here is a simple way:

CapacitorOnReset.jpg (10.71 KiB) Viewed 21954 times

#RESET shouldn't really be shorted to 3.3V. It violates the spec on the #RESET driver chip and also there is supposed to be a delay (~100ms) between 3.3V and releasing #RESET.

We can't really get rid of #RESET as it is used by other IO Boards. We could add a buffer to drive the external Reset to isolate from the internal #RESET but that would require a board change.

I've been trying to inject noise on signals next to the #RESET to cause an error but haven't been able to do so. As I described in the previous post it is driven very hard to 3.3V.

Thanks

[TFrenken]

Hi Tom,

sadly, the disconnects still occur but not as frequent as before. Some disconnects are temporary and others require a restart. I cut the #RESET wire on another machine, and it helped bit did not solve the problem completely. I am currently trying to get rid of the problem completely by adding capacitors to ground, thanks for the tip to use capacitors between #RESET and ground to get rid of noise as well. I will disconnect the #RESET from 3.3V to avoid damaging the driver.
Could there be a problem with the board that causes the disconnects? There does not seem to be a real cause for the disconnects with this machine and it even happens when all the drives are idle so the noise should be minimal. Is there a way to see if the #RESET function really is the cause of the disconnects?
I use the KOGNA on 3 machines at the moment, all with quite the same servo drives + VFD and only 2 of them had disconnects. Actually the one without issues does have the worst grounding and quite a lot of noise from a 15kW VFD. The next machine should be converted to KOGNA next month, so I hope to solve the problem before that. Other than that I am very happy with all the possibilities your KOGNA and KMotionCNC offers.

Regards, Thomas

[TomKerekes]

Hi Thomas,

Sorry for the problems, we are determined to resolve this. But difficult as we can't re-produce it. Any additional info or clues on the issue would be appreciated.

I cut the #RESET wire on another machine, and it helped bit did not solve the problem completely.

Did you cut the wires on all 4 connectors (JP4, JP6, JP7, JP9) if those have cables?

Below is Patched DSP Firmware that may help determine if Reset is the issue. After a disconnect please display the MMI Registers. Also see if an Ethernet re-initialization will restore the connection.

Here is a Patched Version for V5.4.1. It will report as 5.4.1XX. It has 2 additional Com Port commands:

M - will display the Ethernet MMI Registers. If the PYH gets reset they all go to zero. Normally they read:

Code: Select all

MMI Reg0 =     3100
MMI Reg1 =     782D
MMI Reg2 =        7
MMI Reg3 =     C121
MMI Reg4 =      1E1
MMI Reg5 =     DDE1
MMI Reg6 =       6F
MMI Reg7 =     2001
MMI Reg8 =     4000

If Reset they will read:

Code: Select all

MMI Reg0 =        0
MMI Reg1 =        0
MMI Reg2 =        0
MMI Reg3 =        0
MMI Reg4 =        0
MMI Reg5 =        0
MMI Reg6 =        0
MMI Reg7 =        0
MMI Reg8 =        0

E - Will reinitialize the Ethernet Software and Hardware


Copy these files to the DSP_KOGNA Folder:

https://www.dynomotion.com/Software/Pat ... PKOGNA.outt
DSPKOGNA.bin
DSPKOGNA.sym
KMotionDef.h

Thanks

[TFrenken]

Hi Tom,
thanks for the help. It took me some time to evaluate the problem further because the machines have to be running a lot lately. However I changed some things on the setup this weekend and it seems the disconnect problem is mostly solved. During testing I noticed that my KOGNA ground (soft ground with 1K Ohm resistor and 10nF capacitor) varied from my overall ground/earth of the system in times quite a lot, after I changed to an even softer grounding(1M Ohm) of the KOGNA, the disconnects occurred more often even with all the reset wires cut. So I switched KOGNA to one hard ground and using capacitors of 10nF from KOGNA GND on the breakout boards to overall ground to get GND to overall Ground potential. So I think that a difference in the ground potential(static and EM induced) and EM induced in the #RESET signal was the reason for that kind of "hard disconnects".
After the changes one machine is running without problems and on the other I still got quite a few "soft disconnects" when there is an error message but the connection seems to reestablish directly without losing position or other problems. Only once during the last days the machine had a "hard disconnect" with loss of position but was also able to reestablish the connection on its own. The "soft disconnects" may be due to the network settings on the Laptop used so it should be possible to get rid of those, what still troubles me is the one"hard disconnect". For now I hope that changing the KOGNA in the near future will get rid of this problem as this machine currently has our "first KONGA" which is used for commissioning of new machines and might have been damaged along the way. As of now 2 of our 3 KOGNA machines run great and a 4th machine is prepared for KOGNA at the moment.

Regards,
Thomas

[TomKerekes]

Hi Thomas,

Thanks for the update.

During testing I noticed that my KOGNA ground (soft ground with 1K Ohm resistor and 10nF capacitor) varied from my overall ground/earth of the system in times quite a lot

Was the resistor and capacitor in parallel?

I switched KOGNA to one hard ground and using capacitors of 10nF from KOGNA GND on the breakout boards to overall ground to get GND to overall Ground potential. So I think that a difference in the ground potential(static and EM induced)

So by this you mean there was one direct connection from Kogna GND to earth ground? And also other Kogna GNDs on breakout boards to earth ground through 10nF capacitors?

After the "hard reset" were you able to determine if Kogna re-booted and had to have its parameters re-initialized?

Are all your Kognas Rev 1.3?

Thanks