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