Hello. This is my forst post, so forgive me if it’s in the wrong place.
I bought a 3018 Pro several years ago, and assembly went fine, but I could never establish a connection. Being an engineer, I managed to find the USB/RS232 driver chip had a floating output pin, so I replaced the chip on the board and it “sort of” worked, in I could move the spindle around a little, but it seemed to drop steps and continued to be unusable. So I bought a “compatible” card on Amazon, and it didn’t support spindle control, so I just put the whole project aside.
My wife griped that she’d like some two-layer acrylic tags for her garden, so I dusted off the 3018, ordered yet another control board from Amazon, installed it, and although it works much better, it processes 10 to 137 (record so far) gcode lines before I get a “serial device not working” in Candle. Momentarily disconnecting the USB cable is the only way I’ve discovered to reset whatever action it’s stuck doing. My files are Easel generated gcode with the appropriate machine choice.
I’ve tried all five USB ports on my laptop and two different cables. My laptop is older, but it runs all the manual motion I care to make.
I’ve tried disconnecting the spindle in case it’s noise or power issues. I’m about ready to put it back in the back of the cabinet and celebrate only blowing a few hundred bucks.
Any debugging suggestions? I’ll try the “test” file that came with the GRBL program that was included with the original shipment next time I’m out in the garage.
A secondary problem is if the crash happens during a Y-axis move, the tray moves beyond it’s range and the bearing pushes out of the plastic doodad, and the T-bearing springs out the other side. Should the pressed-in bearing in the vertical mechanism move around so easily?
UGS didn’t have a x32 version of anything recent, so I switched to my new laptop, and that fixed the problem. So it’s either my x32 laptop is too slow or UGS is “better”. I need to try an x32 version of UGS on my old laptop before I declare the solution to the problem. Thanks for the prod in a productive direction.
You don’t happen to know how to make UGS work on Linux, do you? The program opens, and the only new /dev that appears when I plug in the USB is ttyUSB0, which if I try to connect to, it fails. I followed some instructions on Sparkfun to install CH340 drivers, but that didn’t make anything improve.
Never mind. I found a “sudo chmod a+rw /dev/ttyUSB0” allowed me to connect, and everything worked until it stalled after a few hundred steps. This experiment was with a x64 Dell Inspiron 3000 series with added RAM and SSD, and it still fails.
I guess I have move the CNC to my “3D printer lab” where I have a modern desktop, and build an enclosure to control the sawdust. Arghh! Maybe there’s a simple USB extender available…
Did you get it sorted out? If not the first thing to try for electrical noise related issues is to replace the USB cable with one that has ferrite filters (those cylindrical lumps) on both ends. The 3018 spindle is a serious EMI generator and unfiltered USB cables are antennas. The usual 3018 cable is the cheapest the seller could find and not very good
Sorry for necroposting, hope this is of some small help
Those brass anti-backlash nuts can be of poor quality and strip out, and/or the fixed end has become unglued (well, unpressed since they’re usually press fit). The fixed nut can be glued back in. Don’t get carried away, a drop of CA or a little dab of epoxy should be enough. The assembly is a wear item and you want to be able to replace it if it does wear out.
If one of the nuts stripped then you have to replace it. It’s a T8-4, not the common 3D printer T8-8. 4mm lead, 2mm pitch, two start. I suspect that there are only a few suppliers of these t nut a-b nuts, and one of them cheaps out on the brass from time to time. 3018nc dot com, while not the cheapest, is a good source for 3018 parts. They offer both OEM style and upgraded parts.
There are a lot of 3018 makers, not just one factory, and the quality ranges from decent to utter cr*p
I’ll try a dab of glue on the fixed nut. I wasn’t sure it was meant to be a weak link to give to save other parts.
I successfully carved my project by using my “modern” laptop. The slower laptops just couldn’t handle it. I’d experiment with the baud rate but I have no clue on how to change it on the control board end, if even possible.
Just double check your gcode sender on the laptop that doesn’t work to make sure it’s set for 115200, having a wrong port speed seems to be an occasionally reported issue. Gcode sending doesn’t take much, an older RPi can handle it. However some older laptops have older graphics that some of the gcode senders need.
If yours can run a recent web browser then try one of the browser based gcode senders, like cncjs, openbuilds sender, or GSender
It fails with a slow-ish laptop, so I was just wondering if there’s a way to slow the interface down, in case that’s the issue. The fact that it stalls tells me that a GRBL transaction was clobbered at the PC end, either with an underrun transmission or overrun reception. The fact that the stall occasionally results in one axis going beyond the limit says the transmitted packet was somehow garbled, probably by an underrun.
