Page 1 of 2

Re: Laptops without a physical Ethernet port

PostPosted: Fri May 18, 2018 4:02 pm
by dezsoe
Wireless is a joke for UCxxxETH. (IMHO, wifi is for surfing or mailing, nothing more.) I have a tablet without ethernet and I use it with USB-Ethernet converter. It's for testing, but I never had any problem with it while running UCCNC with UC400ETH.

Re: Laptops without a physical Ethernet port

PostPosted: Fri May 18, 2018 4:16 pm
by ger21

Re: Laptops without a physical Ethernet port

PostPosted: Fri May 18, 2018 5:56 pm
by cncdrive
Hi Terry,

No, we have no plans to create any new USB controllers.
USB is fine with small machines running in home garages where noise is not that much, but in indistrial environment it can have ground noise problems, disconnections etc. where ethernet is the way to go.
USB 3.0 is not better, it works the same, just with more bandwidth (faster) which makes it even more noise sensitive than USB 2.0.

Using a USB network card like what Gerry linked works and can be used, it is still a far better solution than if the controller would have USB communication, because the USB network card still isolates the communication on a short route at the RJ45 connector, so the cable running between the PC and the UC controller is still isolated (floating grounds) just like if it was native ethernet.

Wireless ethernet can theoritically work since it gives the same channel as a wired ethernet, but as the communication for this type of application requires strickt timing and relatively low latency if wireless has latency problems then that will cause problems, communication disconnetion if the required latency can't be held by the wireless device.
So, we generally advice to use wired connection only.

Re: Laptops without a physical Ethernet port

PostPosted: Fri May 18, 2018 6:16 pm
by cncdrive
We have tried a few (probably 3 models if I recall) bought randomly off ebay and all worked without problems, but it was a long time ago so I don't know what models were they, but will try to find them in the office shelves.
Basicly these are not really "adapters", but are network cards just like the ones built into your computer, the difference is the connection how it connects to the PC, because these connect via USB.

Re: Laptops without a physical Ethernet port

PostPosted: Fri May 18, 2018 6:29 pm
by Derek
Well speaking from experience as someone who has both USB and ETH the ETH is sitting in the junk box after it nearly ruined a head casting while the USB controllers run perfectly. I have three machines running right now in a very noisy electrical environment and they never ever miss a beat.

Are you discontinuing the UC-300 USB?

Derek

Re: Laptops without a physical Ethernet port

PostPosted: Fri May 18, 2018 7:21 pm
by dezsoe
I use this one.

For testing start an aircut with lots of drills and check the Statistics window for the latency graph:

ucstat.png

Re: Laptops without a physical Ethernet port

PostPosted: Fri May 18, 2018 9:42 pm
by cncdrive
We already discontinued the UC300USB about half a year ago.
The UC100 is the only USB controller we have now.

Re: Laptops without a physical Ethernet port

PostPosted: Sat May 19, 2018 1:03 am
by Derek
Well so much for picking up a spare I guess.

Did you ever figure out what happened to cause the loss of position/ regain position on my cylinder head?

Re: Laptops without a physical Ethernet port

PostPosted: Sat May 19, 2018 9:32 am
by Battwell
derek- i have a usb 300 in uk if you need one as a spare
was on my machine- now just used for office testing
swap you for the ethernet version if you want
has licence .

Re: Laptops without a physical Ethernet port

PostPosted: Sat May 19, 2018 6:18 pm
by cncdrive
Derek,

Yes, after I got the files and the problem description from you in email we figured the problem out. We could reproduce it finally, it was a syncronisation issue which sometime made the coordinates to not syncronise properly after a probing and so then the motion controller coordinates and the software side coordinates were in offset until the syncronisation happened. Then the unwanted offset got cleared and so the coordinates became in syncron again, but until that the coordinates ran with an offset.
We found not only one, but 2 separate causes for the same issue which we not only corrected, but also made some changes in the syncronisation procedure to make sure this cannot happen even if we will make any similar sync mistakes in the software in the future. Basicly we've added a forced syncronisation for the probing cycle end and also at some other routines which always require a syncronisation.
And what lead to this problem was 2 causes, one is that we had to change a few things to optimise the control for plasma THCs and second we had to change a few things because of an issue with full circles execution. Both required to the syncronisation to be changed and both messed it up.
I originally thought that the sync method was changed only in 1.2103 and so originally I crossed it out as a possible problem cause, but later I realised that it was changed earlier because of the THC...

The fix is already in the test version 1.2104, but unfortunately that version has other problems, so I advice not to use it for production. We working on the finalisation of the 1.2105 version, we testing it extensively now to make sure it will have no issues.