Comm Buffer Size?

[CT63]

I have a 400ETH connected to a windows 10 pc with 6gig memory. The pc is only used for the cnc machine. Automatic updates and internet disabled and no programs running in the background. Several times I've lost communication with the 400ETH while running a G code program. Had to close and restart uccnc to establish communication. Changed the Ethernet cable with a known good one and checked power supply and connections. Machine and components are properly star grounded. Seems intermittent. All default settings. Look ahead is 300 and kernel freq is 100k.
Wondering if increasing the comm buffer size or slow down the kernel rate might help?

[cncdrive]

The UC400ETH drops connection if there are several packets received in error or if packets are not received within a time frame.
So, the PC is sending packets and if a packet has a CRC error (corrupted data) then the controller asks the PC to send it again, then if it again contains an error then again it asks to send it again.
If the packets are wrong for a few times then the controller has to stop and cut the connection, because it could not get a proper packet in a reasonable amount of time, so the communication seems to have a problem. The same is if no packets arriving for an amount of time.

Changing the communication buffer size will not resolve this problem.
If the communication buffer runs dry the controller will not cut the connection, but will stop the motion waiting for more data, so if you lost the connection is not a problem with the communication buffer size.
The kernel speed also has no relation to the lost connection.

If you have the device connected via router/switch then check the connection settings in the router, e.g. lease time.

[CT63]

No router or switch the 400ETH is connected directly to the pc. Seems to be happened with the latest uccnc release.

[cncdrive]

I've talked to my collegue and he confirmed that the communication of the UC400ETH and UC300ETH is cut only in 2 case, if the communication stops or if too many packets have errors.
The exact numbers are 1sec no received packets and 5 neighbour packets error which means that 5 packets next to eachother has CRC error.

Also he confirmed that we did not change anything in the communication for a long time (many versions) now, so it is not likely a new version issue, but probably something else is going on.

What we think that you could check are:

1.) Try to run the same codes without the machine connected to see if it is maybe a noise problem. I mean to see if the issue happens or not without the power electronics in the machine running.
2.) Check if the blue LED on the UC400ETH is stationarily on or if it is blinking? If it's blinking means an instabile communication, because the blue LED is switched on with each packets coming in and is switched off if no packet arrives in that time frame, so if it is blinking means that the communication is lumpy for some reason.

We have these ideas and things to check for first round.

And I have left the UCCNC latest version 1.2029 running here for the night with a UC400ETH connected running a long 500 000 lines code and now it is 11h am and it is still running without issues.

[CT63]

I checked the Blue led and it's blinking at a high rate of speed while running the same gcode. Tried a different gcode file and the same thing. I never noticed the blue LED blinking becasue the 400ETH is in a control cabinet. All the low voltage wire is separate from the power cabling. Looks like a PC issue? Any suggestions. I recently switched over from a XP machine that died to a Windows 10 machine. I really dislike Windows 10....

[cncdrive]

If it's blinking then something is not really good, the communication is then not fluent.

Can you upload one g-code to let me check and run it here.

Isn't there a net conflict maybe? I mean the PC has only this ethernet connection?
Or does it have another ethernet port or USB network card/Wifi maybe?
By net conflict I mean for example if the IP range is the same for more than one network cards/devices, that could cause strange problems.

Or it could be that the video card or the PC is for some reason not up to the task, but it is hard to tell what it is.
When the UCCNC is in idle and if you check the CPU % in the Task manager is it around 0%?
And when you run the g-code then what CPU % is it showing?

I'm running a Win 10. on my Pipo PC which is kind of a tablet, not totally flat, but is a bit triangle shaped and has an ethernet port and touch screen,
this runs the UCCNC good, however it is a totally low end computer and I would not recommend it for anything.
I'm using this PC for one purpose only to test the UCCNC different releases on Win 10., this PC is low-end enough, so that if anything loads too much resources then issue happens on this computer for sure.

[CT63]

I reloaded the Ethernet driver and the blue LED is on steady now. For future reference to others on the forum this was a early windows 7 OS and did the upgrade to 10 awhile back so suspect the driver must have gotten corrupted in the process. Thanks for your help Balazs.

[cncdrive]

Good to hear you found the reason for the problem.